[EXP] Edge ADC Control-Plane Exploitation and Application-Delivery Trust Compromise

Report Type: EXP
Threat Category: Edge Application-Delivery-Controller Exploitation and Application-Delivery Trust-Boundary Compromise Risk
Assessment Date: August 19, 2026
Primary Impact Domain: Edge Application-Delivery Trust and Control-Plane Security
Secondary Impact Domains: Appliance Resilience, Traffic-Path Integrity, Certificate and TLS Trust, Administrative Control, Service Availability, Downstream Application Security
Affected Asset Class: ADCs, Load Balancers, Reverse Proxies, WAF-Adjacent Appliances, and Traffic-Management Infrastructure
Threat Objective Classification: Edge Control-Plane Exploitation, Traffic-Processing Exploitation, Application-Delivery Trust-Boundary Compromise, Traffic-Path Manipulation, Appliance Availability Impact, and Downstream Application Exposure

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

BLUF

‍  Edge application-delivery-controller exploitation creates material business risk because internet-facing, partner-reachable, or insufficiently isolated ADC, load balancer, reverse-proxy, WAF-adjacent, and traffic-management appliances sit directly between external traffic and critical downstream applications. The durable risk includes two primary exploitation paths: control-plane interaction with management, API, administrative, diagnostic, authentication, or configuration functions; and traffic-processing interaction with exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or comparable packet and application-processing surfaces. Successful exploitation may produce command execution, appliance instability, process or service failure, configuration exposure, TLS or certificate risk, traffic-path manipulation, administrative-control compromise, rare outbound communication, availability degradation, or downstream application impact. Immediate executive action is required to establish whether suspicious ADC-facing activity occurred before remediation, whether independent appliance or application-delivery effects followed, and whether configuration integrity, routing integrity, certificate trust, administrative state, service availability, and downstream application trust can be validated.

Executive Risk Translation

Edge ADC exploitation shifts the business risk from a single appliance vulnerability to uncertainty over whether the organization can still trust the infrastructure that routes, terminates, inspects, authenticates, balances, and protects access to downstream services. If the organization cannot reliably correlate suspicious control-plane or traffic-processing activity with appliance instability, command execution, configuration access, certificate exposure, routing changes, administrative activity, outbound communication, availability degradation, or downstream application behavior, leadership may need to treat the affected application-delivery trust boundary as unverified until investigation proves otherwise. That response can expand into emergency patch validation, management-plane isolation, exposed-listener review, appliance forensic analysis, configuration comparison, certificate and credential rotation, backend application review, WAF and proxy policy validation, traffic-path restoration, availability validation, legal and compliance assessment, cyber-insurance coordination, executive reporting, and customer or partner trust management.

S3 — Why This Matters Now

·        Publicly disclosed ADC exploitation demonstrates that material application-delivery risk can originate through both exposed control-plane functionality and exposed traffic-processing functionality.

·        Load balancers, ADCs, reverse proxies, and WAF-adjacent appliances often sit at the boundary between the public internet, partner networks, authentication flows, TLS termination, protocol processing, traffic routing, and business-critical downstream applications.

·        The durable enterprise concern is broader than one management endpoint, vendor, vulnerability, exploit primitive, protocol, or feature. The relevant question is whether externally reachable ADC functionality can be converted into appliance execution, instability, configuration or trust manipulation, traffic-path impact, availability degradation, or downstream application impact.

·        Public proof-of-concept availability, exploitation-attempt reporting, affected-version status, and vulnerable-feature configuration can increase urgency, but compromise confidence must come from correlated appliance, protocol, management/API, service-health, configuration, certificate, outbound, administrative, routing, availability, or downstream-application evidence.

·        Patching alone is not sufficient containment when suspicious ADC-facing activity, command execution, service or process faults, configuration access, certificate access, virtual-service changes, outbound communication, administrative changes, or downstream anomalies occurred before remediation.

·        The highest-risk control-plane condition occurs when suspicious management/API activity is followed by command execution, configuration export, private-key or certificate access, virtual-service manipulation, backend-pool changes, rare egress, administrative-control changes, logging degradation, or downstream application exposure.

·        The highest-risk traffic-processing condition occurs when suspicious or exploit-shaped activity against an exposed listener, virtual service, protocol handler, NAT function, ALG, or comparable processing surface is followed by process or service faults, watchdog behavior, restart, failover, resource exhaustion, connection disruption, availability degradation, or downstream application impact.

·        ADC environments can make malicious activity difficult to classify because legitimate vendor support, patch validation, firmware updates, protocol testing, load testing, health-check changes, certificate rotation, failover testing, backup jobs, configuration migrations, monitoring activity, and emergency maintenance may resemble suspicious behavior when viewed in isolation.

·        Missing request bodies, absent protocol telemetry, rotated management logs, incomplete API records, weak appliance-health telemetry, poor listener or traffic-processing inventory, absent configuration baselines, limited certificate-access logging, incomplete egress attribution, or weak downstream application mapping can force broader investigation because the organization cannot quickly prove whether the edge trust boundary remained intact.

·        Existing CyberDax edge-adjacent coverage for identity/session disclosure, firewall-management-plane compromise, or hosting-control-plane exploitation does not replace a reusable ADC behavior model spanning control-plane and traffic-processing exploitation.

S4 — Key Judgments

·        Edge ADC and load-balancer exploitation should be treated as an application-delivery trust-boundary risk, not only as a vulnerability-management ticket, appliance patch event, or management-plane problem.

·        The primary enterprise risk is reduced ability to determine whether exposed ADC functionality led to command execution, appliance instability, configuration exposure, virtual-service manipulation, certificate or TLS-offload exposure, traffic-path disruption, administrative-control compromise, outbound communication, persistence-like changes, availability degradation, or downstream application impact.

·        Suspicious control-plane activity followed by command execution, configuration access, certificate access, routing changes, rare egress, administrative changes, logging degradation, appliance instability, or downstream application anomalies remains a strong compromise signal.

·        Suspicious traffic-processing activity followed by process or service faults, watchdog restart, appliance restart, HA transition, failover, resource exhaustion, abnormal connection behavior, service unavailability, or downstream availability degradation is a separate high-value detection path and does not require management/API interaction.

·        A single scanner hit, vulnerable-version finding, public proof-of-concept reference, unusual user agent, management endpoint request, malformed protocol message, isolated protocol transaction, appliance crash, failover event, enabled processing feature, exposed service configuration, or appliance error should not be treated as confirmed compromise without supporting correlated evidence.

·        Business exposure increases sharply when affected ADCs terminate TLS, front authentication workflows, route customer traffic, support partner access, protect regulated applications, process specialized protocols, connect to internal services, manage high-availability applications, or hold certificates, API material, configuration backups, or administrative credentials.

·        Incomplete telemetry increases cost because the organization may need to reconstruct management/API access, traffic-processing activity, appliance state, service-health events, configuration changes, certificate handling, virtual-service routing, backend-pool exposure, outbound communication, administrative activity, availability effects, and downstream application behavior across separate systems.

·        The most damaging outcome occurs when ADC exploitation results in confirmed or suspected command execution, certificate or private-key exposure, credential access, backend-routing manipulation, traffic mirroring, authentication-flow disruption, sustained appliance instability, customer-facing availability impact, downstream application exposure, legal and compliance review, cyber-insurance scrutiny, or board-level concern about edge application-delivery resilience.

S5 — Executive Risk Summary

Business Risk

Edge ADC exploitation can weaken the organization's ability to trust the infrastructure that delivers, routes, terminates, balances, processes, and protects customer-facing, partner-facing, and internal application traffic. Risk increases when affected ADCs or load balancers support internet-facing portals, authentication-fronting services, TLS termination, specialized protocol processing, WAF-adjacent controls, regulated applications, payment-adjacent workflows, partner access, high-availability applications, customer-support services, file-transfer paths, executive communications, or business-critical web services. Business impact is not limited to the vulnerable appliance; it can expand into uncertainty over whether adversaries executed commands, destabilized appliance services, accessed configuration backups, exposed certificates or private keys, modified routing, altered headers, changed persistence settings, weakened logging, created administrative access, initiated outbound communication, disrupted application delivery, or affected downstream applications after apparent remediation.

Technical Cause

The risk is driven by externally reachable ADC functionality that processes attacker-controlled input across management/API control surfaces or traffic-processing surfaces. Control-plane exposure may involve unauthenticated or weakly authenticated management/API access, unsafe input handling, command injection, insufficient management-plane isolation, or weak source restrictions. Traffic-processing exposure may involve malformed, oversized, abnormal, repeated, or protocol-inconsistent input reaching listeners, virtual services, protocol handlers, NAT functions, ALGs, or other packet and application-processing components. Technical exposure becomes material when suspicious ADC-facing activity aligns with command execution, service or process faults, watchdog behavior, restart or failover, resource exhaustion, configuration-object access, virtual-service changes, backend-pool changes, routing or rewrite manipulation, TLS or certificate changes, rare egress, administrative activity, connection disruption, availability degradation, or downstream application effects. Exposure increases when asset inventory, management-interface mapping, traffic-facing-interface mapping, listener and protocol inventory, virtual-service mapping, configuration baselines, appliance logging, service-health telemetry, outbound monitoring, and downstream application telemetry are incomplete.

Threat Posture

The threat posture is elevated because edge ADC exploitation can turn a traffic-management appliance into an attacker-controlled execution point, credential source, certificate exposure point, routing-control layer, availability disruption point, downstream application access path, persistence location, or staging point for additional activity. Exploitation does not require endpoint malware or user credential theft when the initial path is direct interaction with an exposed ADC control plane or traffic-processing function. The posture becomes critical when suspicious ADC activity affects appliances tied to customer trust, regulated workflows, authentication routing, TLS termination, partner access, backend application access, service availability, disaster-recovery paths, multi-tenant application delivery, high-availability clusters, or environments where multiple downstream services depend on the same edge traffic-management layer.

Executive Decision Requirement

Executives must require measurable assurance that exposed ADC and load-balancer assets are inventoried, affected versions and vulnerable features are remediated or isolated, management/API surfaces are restricted, exposed listeners and traffic-processing functions are documented, partner-reachable paths are understood, configuration state is compared against known-good baselines, virtual services and backend pools are reviewed, TLS and certificate material is protected, administrative accounts and API keys are validated, appliance-health and availability events are reviewed, outbound appliance communication is examined, logs and diagnostic artifacts are preserved, downstream applications are reviewed for traffic-path and availability impact, and post-remediation monitoring is operational. Leadership should also require evidence that legal, compliance, cyber insurance, network engineering, application owners, SOC, incident response, infrastructure teams, communications, and business owners can support rapid decisions if command execution, certificate exposure, routing manipulation, appliance instability, downstream access, customer-facing disruption, or application-delivery trust loss is suspected.

S6 — Executive Cost Summary

Edge ADC exploitation creates financial exposure because the organization must determine whether infrastructure trusted to route, terminate, inspect, balance, process, or protect application traffic allowed adversaries to execute commands, destabilize appliance services, access configuration, expose certificates, manipulate traffic paths, weaken administrative controls, disrupt availability, or reach downstream applications. The cost profile is different from a routine appliance firmware update because affected devices may sit in front of customer portals, authentication flows, partner services, regulated applications, payment-adjacent workflows, support platforms, file-transfer paths, specialized protocol services, and business-critical web applications. Response cost is driven by the work required to validate exposed assets, preserve management, network, protocol, WAF, and appliance-health records, inspect appliance state, compare configuration, review virtual services and listeners, inspect backend mappings, validate TLS and certificate handling, rotate credentials and keys where needed, analyze service instability and outbound communication, coordinate with application owners, confirm downstream traffic and availability integrity, and prove that post-remediation application-delivery trust has been restored.

Cost increases materially when ADC logs rotate quickly, request bodies are unavailable, protocol transactions are not retained, API parameters are redacted, appliance shell or process telemetry is inaccessible, service-health telemetry is incomplete, listener or protocol ownership is unclear, NAT or ALG configuration is poorly inventoried, certificate access is poorly logged, configuration exports are not baselined, virtual-service ownership is unclear, backend-pool mappings are outdated, approved administrative and protocol sources are not documented, outbound egress cannot be attributed to the appliance, change-management context is incomplete, or downstream application owners cannot quickly identify which services depend on the affected traffic-management layer. The highest-cost cases occur when suspected or confirmed compromise affects TLS termination, private keys, authentication-fronting services, regulated applications, customer portals, partner workflows, high-availability application delivery, multiple downstream services, reused credentials, backup archives, diagnostic bundles, appliance clusters, or critical availability-dependent business operations.

Low Impact Scenario

Rapid investigation confirms suspicious ADC management/API probing, suspicious traffic-processing activity, or exploit-attempt behavior without evidence of command execution, configuration access, virtual-service manipulation, certificate or private-key access, administrative changes, rare egress, logging degradation, persistence-like appliance changes, sustained appliance instability, downstream application anomalies, or post-remediation activity. Activity may involve internet scanning, public proof-of-concept-like requests, failed API access, malformed control-plane attempts, malformed or abnormal protocol traffic, isolated status errors, transient resets, or limited appliance instability, but management/API logs, network or protocol telemetry, appliance-health records, configuration comparison, certificate review, outbound telemetry, change records, and downstream application checks support a failed, contained, or non-impacting event. Response is limited to targeted patch validation, management-plane or exposed-function isolation, evidence preservation, focused configuration review, administrator review, certificate precaution, egress review, availability validation, short-term monitoring, and executive assurance that application-delivery trust was not materially affected. Estimated impact $450K - $3.5M.

Moderate Impact Scenario

Confirmed or strongly suspected ADC exploitation affects one or more exposed or partner-reachable appliances where suspicious control-plane or traffic-processing behavior aligns with appliance instability, command-execution evidence, service or process faults, configuration access, virtual-service changes, certificate-object access, backup or diagnostic artifact access, rare outbound communication, administrative changes, logging degradation, connection disruption, availability degradation, or downstream traffic-path anomalies. The organization cannot immediately determine whether attacker-controlled commands executed, private keys were exposed, routing was manipulated, backend pools were altered, authentication flows were affected, diagnostic artifacts were exported, API keys were accessed, appliance availability was intentionally disrupted, or downstream applications were reached. Response requires enterprise-focused ADC asset review, management/API, protocol, network, WAF, and appliance-health reconstruction, appliance-state inspection, configuration comparison, certificate and credential review, administrator and API-key validation, outbound traffic analysis, downstream application review, availability validation, change-management reconciliation, legal and compliance review, cyber-insurance coordination, executive reporting, and strengthened monitoring for post-remediation activity. Estimated impact $4.5M - $24M.

High Impact Scenario

Edge ADC exploitation becomes an enterprise-impact event when suspected or confirmed exploitation results in command execution, certificate or private-key exposure, credential access, configuration export, virtual-service manipulation, backend-routing abuse, authentication-flow disruption, traffic mirroring, sustained or coordinated appliance instability, downstream application exposure, customer-facing availability impact, administrative-control compromise, persistence-like appliance changes, or multi-appliance compromise. The organization may need to assume that customer-facing services, partner workflows, TLS-protected traffic, regulated applications, backend service paths, administrative credentials, API keys, configuration backups, and downstream application trust were affected until audit evidence proves otherwise. Response may require extended appliance forensics, emergency management-plane or processing-function isolation, broad credential and certificate rotation, application-delivery redesign, configuration restoration, backend application review, customer or partner notification analysis, legal and privacy escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal validation that affected ADCs and dependent applications can safely remain online. Estimated impact $30M - $140M+.

S6A — Key Cost Drivers

·        Number and sensitivity of affected ADC, load balancer, reverse-proxy, WAF-adjacent, and traffic-management appliances, including internet-facing, partner-reachable, production, disaster-recovery, staging, high-availability, authentication-fronting, TLS-terminating, protocol-processing, and critical application-delivery assets.

·        Scope of exposed control-plane and traffic-processing surfaces, including administrative interfaces, API endpoints, diagnostic functions, authentication handlers, telemetry endpoints, configuration paths, listeners, virtual services, protocol handlers, NAT functions, ALGs, support functions, and partner-reachable paths.

·        Availability and retention of ADC management logs, protocol telemetry, network-flow records, WAF records, reverse-proxy records, CDN records, load-balancer records, appliance syslog, service-health records, administrative audit logs, configuration-change records, certificate-management records, DNS records, proxy records, firewall records, NDR telemetry, endpoint telemetry where available, downstream application logs, backup records, and change-management records.

·        Whether response must reconstruct suspicious management/API requests, suspicious traffic-processing activity, appliance instability, command execution, process or service faults, configuration reads and writes, virtual-service changes, backend-pool changes, certificate access, private-key exposure, outbound communication, administrative changes, logging degradation, availability effects, and downstream application behavior across separate telemetry sources.

·        Whether ADC management/API access and unnecessary exposed traffic-processing functionality can be restricted to approved administrative networks, VPN paths, privileged-access workflows, vendor-support sources, documented partner paths, approved listeners, and required protocols without disrupting operations.

·        Scope of sensitive material potentially exposed, including certificates, private keys, key stores, SAML or OIDC material, API tokens, administrative credentials, backup archives, diagnostic bundles, packet captures, configuration exports, backend credentials, and application-routing data.

·        Size and complexity of the affected application-delivery environment, including hardware appliances, virtual appliances, cloud-hosted ADCs, managed ADC services, high-availability clusters, NAT or ALG functions, specialized protocol processing, multi-region deployments, shared backend pools, hybrid-cloud paths, and multiple downstream applications depending on the same traffic-management layer.

·        Ability to distinguish legitimate vendor support, firmware updates, patch validation, protocol testing, load testing, backup jobs, certificate rotation, health-check tuning, failover testing, configuration migrations, monitoring activity, emergency maintenance, red-team activity, and incident-response cleanup from attacker-driven behavior.

·        Need to rotate or review ADC administrative credentials, API keys, certificate material, private keys, backend credentials, service credentials, monitoring credentials, vendor-support accounts, deployment secrets, and reused passwords.

·        Business disruption caused by emergency patching, control-plane isolation, listener or processing-function restriction, management-interface shutdown, virtual-service review, routing rollback, certificate replacement, backend-pool validation, WAF or proxy tuning, failover events, appliance rebuilds, and customer-facing service interruption.

·        Legal, privacy, regulatory, cyber-insurance, communications, customer, partner, executive, or board-level obligations triggered by suspected certificate exposure, credential access, regulated application exposure, authentication-flow disruption, customer-facing outage, downstream application impact, incomplete containment, or inability to prove non-exposure.

S6B — Compliance and Risk Context

Figure 1

Edge ADC exploitation and application-delivery trust compromise executive risk model showing how exposed control-plane or traffic-processing functionality can escalate from exploit-attempt behavior into command execution, appliance instability, configuration exposure, certificate risk, routing manipulation, availability degradation, downstream application exposure, customer-facing service disruption, and enterprise-level business exposure.

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

Edge ADC Exploitation and Application-Delivery Trust Compromise Risk

Risk Description

Adversaries may exploit externally reachable ADC, load balancer, reverse-proxy, WAF-adjacent, or traffic-management functionality through management/API control surfaces or exposed traffic-processing functions. Control-plane exploitation may lead to appliance-level command execution, configuration exposure, certificate or private-key access, virtual-service manipulation, backend-pool modification, routing or header-control changes, administrative-control compromise, outbound communication, persistence-like appliance changes, or downstream application exposure. Traffic-processing exploitation may produce process or service faults, watchdog behavior, restart or failover, resource exhaustion, connection disruption, availability degradation, or downstream application impact without requiring management/API access. These outcomes may increase business interruption, customer-facing availability risk, credential and certificate exposure, regulated application concern, partner-workflow exposure, legal and compliance review, cyber-insurance scrutiny, notification analysis, and board-level concern around edge application-delivery resilience. Compliance exposure should be driven by correlated evidence of exploitation effects and business impact, not by vulnerable-version status, feature enablement, malformed traffic, scanner activity, public exploit availability, KEV status, isolated management/API requests, or isolated appliance faults alone.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated $4.5M - $30M+ for materially exposed enterprise environments with internet-facing or partner-reachable ADCs, vulnerable or weakly isolated management/API surfaces, exposed traffic-processing functions, TLS termination, authentication-fronting services, customer-facing or partner-facing workflows, regulated downstream applications, incomplete request or protocol logging, weak configuration baselines, limited appliance-health telemetry, incomplete certificate-access logging, unclear virtual-service or listener ownership, weak outbound monitoring, incomplete administrative activity baselines, or poor downstream application mapping. Exposure may exceed $30M - $140M+ where ADC exploitation results in confirmed or suspected command execution, certificate or private-key exposure, credential access, configuration export, virtual-service manipulation, authentication-flow disruption, traffic mirroring, sustained appliance instability, downstream application exposure, customer-facing outage, multi-appliance compromise, incomplete containment, cyber-insurance review, legal escalation, communications response, or board-level reporting.

S7 — Risk Drivers

·        ADCs, load balancers, reverse proxies, and WAF-adjacent appliances can concentrate public access, partner routing, TLS termination, authentication flow, protocol processing, backend application delivery, and business-continuity dependencies at the network edge.

·        Management/API exposure creates high-risk conditions when unauthenticated or weakly authenticated exploit behavior can reach command endpoints, diagnostic functions, configuration objects, certificate material, or administrative controls.

·        Traffic-processing exposure creates a separate risk path when externally supplied traffic can reach vulnerable listeners, virtual services, protocol handlers, NAT functions, ALGs, or other packet and application-processing functions.

·        Appliance-level command execution can create a path to configuration access, credential exposure, certificate exposure, outbound communication, persistence-like changes, internal service access, and downstream application impact.

·        Traffic-processing exploitation can produce process or service failure, watchdog behavior, restart, failover, resource exhaustion, abnormal connection handling, or availability degradation without producing command execution or management/API artifacts.

·        Vulnerable-version status, public proof-of-concept availability, exploitation-attempt reporting, vulnerable-feature configuration, and KEV status can create urgency, but they cannot prove compromise or non-compromise without correlated appliance, protocol, configuration, certificate, outbound, administrative, routing, availability, or downstream evidence.

·        Patch completion can create false closure when pre-remediation management/API activity, traffic-processing anomalies, appliance faults, command execution, configuration changes, certificate access, administrative activity, outbound communication, or downstream traffic-path effects have not been reviewed.

·        ADC administration, firmware updates, vendor support, health-check changes, protocol testing, load testing, certificate rotation, failover testing, configuration migration, backup jobs, monitoring activity, vulnerability validation, and emergency maintenance can resemble suspicious behavior without strong baselines.

·        Business exposure increases when affected appliances support customer portals, authentication-fronting services, regulated applications, partner workflows, payment-adjacent processes, file-transfer paths, executive communications, high-availability applications, specialized protocol services, or multiple downstream services.

·        Missing or inconsistent management logs, protocol records, listener mappings, request bodies, API parameters, appliance syslog, service-health events, configuration-change records, certificate records, endpoint telemetry, DNS logs, proxy logs, firewall logs, NDR telemetry, downstream application logs, backup comparison data, or change-management records can increase investigation scope and cost.

·        Limited ability to rapidly identify exposed management paths and traffic-processing surfaces, restrict control-plane access, isolate vulnerable functions, compare configuration, review virtual services and listeners, validate backend pools, inspect certificate material, rotate credentials, and confirm downstream application behavior can extend operational disruption.

·        Command execution, certificate exposure, credential access, routing manipulation, backend access, traffic mirroring, sustained appliance instability, authentication-flow disruption, customer-facing outage, and incomplete containment can transform an appliance vulnerability into legal, regulatory, communications, cyber-insurance, customer, partner, executive, and board-level exposure.

S8 — Bottom Line for Executives

Edge ADC exploitation should be treated as high-priority application-delivery trust, appliance resilience, certificate protection, credential exposure, availability, and downstream application risk. The executive question is not only whether an appliance was patched, whether a scanner touched a management interface, whether public proof-of-concept code exists, whether an affected protocol feature was enabled, or whether traffic is still flowing; it is whether the organization can prove that suspicious ADC-facing activity did not lead to command execution, appliance instability, configuration access, private-key exposure, certificate misuse, virtual-service manipulation, backend-routing abuse, administrative compromise, rare outbound communication, sustained availability impact, downstream application access, or continued access after remediation. Response must validate exposed control-plane and traffic-processing surfaces, appliance state, configuration integrity, virtual services, listeners, backend pools, TLS and certificate handling, administrative accounts, API keys, service-health events, outbound activity, downstream application behavior, and post-remediation monitoring before leadership can rely on the affected edge application-delivery layer.

S9 — Board-Level Takeaway

Edge ADC exploitation turns application delivery into a board-level issue involving customer-facing availability, TLS and certificate trust, credential protection, partner access, downstream application exposure, and business-continuity confidence. The risk is not simply that an appliance was vulnerable, a patch was required, internet scanning occurred, or a protocol-processing feature was exposed; it is the possibility that adversaries used externally reachable control-plane or traffic-processing functionality to execute commands, destabilize appliance services, access configuration, expose certificates or private keys, manipulate traffic routing, alter backend service paths, weaken administrative controls, disrupt application availability, reach downstream applications, or retain persistence-like access on infrastructure that customers, partners, and internal applications depend on. Leadership should require evidence that ADC asset inventory, management/API isolation, exposed-listener and protocol inventory, patch and feature-remediation validation, WAF and network records, appliance-health telemetry, configuration baselines, certificate review, administrative-account review, egress monitoring, downstream application validation, incident-response readiness, legal readiness, and business-continuity planning can support rapid, defensible decisions when edge application-delivery trust exposure is suspected.

S10 — Threat Overview

Edge application-delivery infrastructure presents a concentrated trust boundary because ADCs, load balancers, reverse proxies, WAF-adjacent systems, and traffic-management appliances combine externally reachable network functions with administrative control, TLS termination, protocol processing, virtual-service configuration, backend routing, availability management, and access to downstream application environments. Exploitation therefore does not need to follow one universal technical path to create material enterprise exposure.

The first major path is control-plane exploitation. Adversaries may interact with exposed or weakly isolated management, API, administrative, diagnostic, authentication, telemetry, or configuration functionality using unauthenticated, weakly authenticated, malformed, manipulated, or exploit-shaped requests. Successful exploitation may enable command execution, configuration access, backup or diagnostic access, certificate or private-key exposure, administrative-control changes, virtual-service or backend-pool modification, routing manipulation, rare egress, persistence-like appliance changes, or access to downstream applications.

The second major path is traffic-processing exploitation. Adversaries may send malicious or exploit-shaped traffic to exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or comparable packet and application-processing components. Observable consequences may include protocol-handler or service faults, process crashes, watchdog behavior, restart or reboot activity, unexpected HA transitions, failover, resource exhaustion, abnormal connection handling, service unavailability, traffic-path disruption, or downstream application availability impact. Traffic-processing exploitation must not be assumed to produce command execution or management/API artifacts unless independent evidence demonstrates those outcomes.

These paths may converge on the same enterprise consequence: reduced confidence in whether the application-delivery layer remains trustworthy. A compromised or destabilized ADC can affect customer-facing services, authentication paths, TLS-protected traffic, partner connectivity, regulated applications, backend routing, high-availability architectures, and multiple downstream services that share the same edge infrastructure.

Detection and investigation therefore require behavior correlation rather than vulnerability identification alone. Vulnerable-version status, exposed functionality, public proof-of-concept availability, KEV status, scanner observations, malformed requests, protocol anomalies, enabled processing features, crashes, restarts, failovers, or resource exhaustion establish exposure or investigative priority but do not independently prove exploitation. Higher confidence requires correlation between suspicious ADC-facing activity and materially independent appliance, configuration, certificate, administrative, egress, availability, traffic-path, or downstream application effects.

S11 — Threat Classification and Type

Threat Type

Edge application-delivery-controller exploitation and application-delivery trust-boundary compromise risk.

Threat Sub-Type

Pre-authentication or weakly authenticated control-plane exploitation, ADC management/API abuse, traffic-processing exploitation, protocol-handler abuse, NAT or ALG processing abuse, appliance-level command execution, appliance instability, service or process failure, diagnostic-function abuse, configuration exposure, virtual-service manipulation, backend-pool modification, routing or rewrite manipulation, header-control abuse, TLS-offload exposure, certificate or private-key access, API-token exposure, administrative-control compromise, appliance-originated outbound communication, persistence-like appliance change, logging degradation, availability disruption, downstream application exposure, and multi-appliance control-plane compromise and application-delivery exposure risk.

Operational Classification

Edge control-plane exploitation, traffic-processing exploitation, application-delivery trust-boundary compromise, traffic-path manipulation, appliance availability impact, and downstream application exposure pathway.

Primary Function

Exploit exposed or insufficiently isolated ADC, load balancer, reverse-proxy, WAF-adjacent, or traffic-management functionality through either management/API control surfaces or externally reachable traffic-processing functions. Control-plane exploitation may progress into appliance-level command execution, configuration access, certificate or credential exposure, routing or virtual-service manipulation, administrative-control compromise, outbound communication, persistence-like appliance modification, or downstream application access. Traffic-processing exploitation may produce process or service faults, watchdog behavior, restart or failover, resource exhaustion, abnormal connection handling, service unavailability, traffic-path disruption, or downstream application availability impact without requiring management/API interaction. Both pathways can create uncertainty around application-delivery trust, TLS handling, backend-routing integrity, availability, containment completeness, and customer-facing service assurance.

S12 — Campaign or Activity Overview

Figure 2

Edge ADC exploitation and application-delivery trust compromise activity model showing exposed control-plane or traffic-processing functionality, exploit-shaped input, appliance execution or instability, configuration or certificate exposure, traffic-path manipulation, administrative-control compromise, outbound communication, availability degradation, downstream application exposure, and post-remediation trust validation.

This report assesses edge ADC exploitation as a behavior class rather than a single product advisory, scanner wave, exploit string, public proof-of-concept, actor cluster, protocol, vulnerable feature, or appliance patch event. The activity model includes two principal access paths: suspicious interaction with exposed management/API, administrative, diagnostic, authentication, telemetry, or configuration functions; and suspicious interaction with exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or comparable packet and application-processing surfaces.

·        The activity is best understood as an application-delivery trust, control-plane resilience, traffic-processing resilience, certificate protection, routing-integrity, availability, and downstream-application threat rather than a routine internet scan, generic appliance error, isolated API request, malformed protocol event, or standard vulnerability-management issue.

·        Adversaries may target ADCs and load balancers supporting customer portals, authentication-fronting services, TLS termination, partner access, regulated applications, high-availability services, public web applications, support workflows, file-transfer paths, specialized protocol handling, or business-critical application delivery.

·        Control-plane activity may involve rare source infrastructure, unusual geographies, suspicious ASNs, rare user agents, malformed API requests, command-delimiter patterns, encoded command content, abnormal methods, oversized requests, repeated failed-to-success patterns, abnormal status sequences, response-size deviations, or management/API handler faults.

·        Traffic-processing activity may involve malformed, oversized, repeated, protocol-inconsistent, abnormal, or fuzzing-like traffic directed at listeners, virtual services, protocol handlers, NAT functions, ALGs, or related processing components.

·        Activity may remain limited to reconnaissance, malformed requests, failed exploit attempts, vulnerable-function probing, abnormal response behavior, transient faults, or isolated instability, or it may progress into command execution, process or service failure, configuration export, certificate access, virtual-service changes, backend-pool manipulation, routing changes, administrative changes, rare egress, sustained availability degradation, or downstream application impact.

·        The activity becomes highest risk when suspicious ADC behavior affects appliances that terminate TLS, route customer traffic, front authentication services, support regulated workflows, enable partner access, protect high-availability applications, process critical protocols, connect to internal services, or serve multiple downstream applications through shared application-delivery infrastructure.

·        Actor names, infrastructure references, exploit-attempt reporting, scanner fingerprints, vulnerability references, KEV status, or public proof-of-concept references may increase investigative urgency, but they should not replace local behavior-led evidence of suspicious ADC-facing activity and independent appliance, configuration, certificate, administrative, availability, outbound, traffic-path, or downstream impact.

S13 — Targets and Exposure Surface

The exposure surface includes internet-facing, partner-reachable, cloud-hosted, managed, virtual, hardware, high-availability, authentication-fronting, TLS-terminating, protocol-processing, and production ADC, load balancer, reverse-proxy, WAF-adjacent, and traffic-management appliances. It includes both control-plane and traffic-processing functions as well as the trust objects, routing state, availability functions, and downstream applications that depend on those appliances.

·        Internet-facing or partner-reachable ADC and load-balancer appliances with exposed management, API, administrative, diagnostic, authentication, telemetry, or configuration surfaces.

·        Internet-facing or partner-reachable listeners, virtual services, protocol handlers, NAT functions, ALGs, application-protocol processors, traffic-management functions, and other externally reachable processing surfaces.

·        ADC API paths and management functions capable of exposing command execution, diagnostic behavior, configuration access, authentication handling, certificate management, backup creation, or administrative-control changes.

·        Virtual services, listener ports, real-server pools, backend pools, routing policies, content-switching rules, rewrite rules, header rules, persistence profiles, health checks, NAT or ALG configuration, WAF-adjacent policies, proxy policies, and TLS-offload settings.

·        Certificate and trust material, including certificates, private keys, key stores, certificate bindings, SAML material, OIDC material, API tokens, administrative credentials, backup archives, configuration exports, packet captures, and diagnostic bundles.

·        Administrative control surfaces, including local administrative accounts, support accounts, API keys, privileged automation, backup schedules, firmware or package activity, logging settings, diagnostic settings, management-interface restrictions, access-control lists, and partner-reachable administrative paths.

·        Network and outbound communication paths surrounding ADC appliances, including DNS, HTTP, HTTPS, SSH, SMTP, raw-IP communication, file transfer, tunneling, callback-like traffic, vendor-support paths, update paths, telemetry paths, monitoring paths, syslog paths, backup paths, and internal management-service access.

·        Appliance-health and availability surfaces, including service status, process faults, watchdog events, restarts, reboots, HA transitions, failover events, resource pressure, connection resets, timeouts, service-unavailable conditions, and downstream application availability.

·        Downstream application and backend exposure, including web applications, identity services, databases, file-sharing services, storage systems, mail systems, backup repositories, deployment systems, monitoring systems, and application-administration services reachable through or adjacent to the ADC trust boundary.

·        Environments with incomplete ADC inventory, unknown management/API exposure, undocumented exposed listeners or protocol functions, weak management-plane isolation, undocumented partner access, incomplete request or protocol logging, limited appliance-health telemetry, missing configuration baselines, incomplete certificate inventories, weak outbound visibility, unclear virtual-service ownership, poor backend mapping, or insufficient downstream application review.

S14 — Sectors / Countries Affected

Sectors Affected

·        Healthcare, life sciences, public-sector, education, nonprofit, and regulated service organizations using ADCs or load balancers for portals, authentication-fronting services, public communications, application delivery, specialized protocol handling, or critical web infrastructure.

·        Financial services, insurance, legal, professional services, consulting, and business-services organizations with externally reachable customer portals, partner workflows, TLS-terminating infrastructure, high-availability services, or regulated application-delivery paths.

·        Technology, SaaS, software, telecommunications, media, marketing, hosting, managed-service, and digital-services organizations operating high-availability, customer-facing, multi-tenant, partner-facing, or protocol-intensive application-delivery infrastructure.

·        Retail, e-commerce-adjacent, hospitality, travel, transportation, logistics, and customer-facing service organizations using ADCs or reverse proxies to route customer traffic, payment-adjacent workflows, support portals, reservation systems, APIs, or public web applications.

·        Manufacturing, industrial, energy, utilities, supply-chain, and supplier-dependent organizations using ADCs for corporate applications, partner portals, remote-access-adjacent workflows, documentation platforms, supplier systems, protocol gateways, or regional application delivery.

·        Large enterprises, distributed organizations, cloud-forward organizations, franchise models, local governments, managed-hosting customers, and organizations with complex hybrid ADC, reverse-proxy, WAF-adjacent, or load-balancing deployments.

·        Organizations using ADCs for TLS termination, authentication-fronting services, WAF-adjacent enforcement, partner access, high-availability routing, backend application delivery, health-check automation, traffic rewriting, protocol processing, certificate handling, or application-layer resilience.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because ADC, load-balancer, reverse-proxy, WAF-adjacent, and traffic-management appliances are deployed globally across enterprise, public-sector, healthcare, education, finance, technology, retail, manufacturing, telecommunications, and service environments.

·        Countries with large populations of externally reachable application-delivery infrastructure, managed hosting, partner-connected services, public-sector portals, regional service providers, telecommunications infrastructure, and distributed enterprise application environments may face elevated operational exposure.

·        Country-specific impact should be assessed by management/API exposure, exposed traffic-processing functionality, internet or partner reachability, TLS termination role, protocol-processing role, downstream application sensitivity, certificate exposure risk, credential reuse, availability dependency, telemetry maturity, regulatory obligations, and incident-response capability rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate

Technical Sophistication

Adversaries require enough technical capability to identify exposed ADC, load-balancer, reverse-proxy, WAF-adjacent, or traffic-management appliances and determine whether reachable control-plane or traffic-processing functionality can be abused. Lower-complexity activity may involve broad scanning, exploit replay, commodity proof-of-concept use, public endpoint probing, automated API requests, malformed protocol traffic, source rotation, or opportunistic targeting of known appliance functions. Higher-capability activity may involve selective targeting of high-value ADCs, custom request or protocol shaping, API parameter manipulation, encoded command content, multi-stage exploitation, deliberate stress or parser triggering, configuration export review, certificate or private-key access, virtual-service manipulation, stealthy routing changes, outbound communication, log suppression, cleanup, and downstream application exploration.

Traffic-processing exploitation does not inherently require appliance command execution. Higher sophistication may instead be reflected in the ability to identify exposed protocol-processing functions, shape traffic to reach a vulnerable parser or state condition, induce controlled appliance instability, and blend activity with legitimate client or application traffic.

Infrastructure Maturity

Moderate

Infrastructure maturity varies by activity pattern. Lower-maturity activity may rely on direct scanning, cloud-hosted infrastructure, common VPS nodes, VPN providers, known scanner infrastructure, public exploit tooling, and basic callback infrastructure. Higher-maturity activity may use rotating infrastructure, residential proxies, compromised hosts, trusted geographies, segmented probing, low-and-slow request timing, separate exploit and callback infrastructure, staged outbound destinations, protocol-valid traffic carrying exploit-shaped content, and access patterns designed to blend with routine ADC administration, application traffic, vendor support, monitoring, health checks, certificate rotation, failover testing, or emergency maintenance.

Operational Scale

Single exposed ADC appliance to multi-appliance application-delivery trust-boundary exposure

Operational scale ranges from suspicious activity against one exposed ADC appliance or traffic-processing function to broader enterprise exposure when multiple ADCs, virtual services, listeners, backend pools, application clusters, high-availability pairs, disaster-recovery appliances, cloud-hosted ADCs, partner-facing load balancers, reverse proxies, WAF-adjacent devices, certificates, administrative accounts, and downstream applications are connected. Within one organization, scale can expand from one exposed control-plane or traffic-processing function into command execution, appliance instability, configuration exposure, certificate access, routing manipulation, administrative-control compromise, rare egress, availability degradation, downstream application exposure, and post-remediation trust validation.

Escalation Likelihood

Moderate to High

Escalation likelihood is moderate to high when suspicious ADC control-plane activity is followed by command execution, configuration access, backup export, diagnostic bundle creation, certificate or private-key access, virtual-service changes, backend-pool changes, routing or header manipulation, administrative account changes, API-key activity, rare outbound communication, logging degradation, internal-service access, downstream application anomalies, or post-remediation activity.

Escalation likelihood is also moderate to high when suspicious traffic-processing activity is followed by process or service faults, watchdog events, restarts, HA transitions, failover, resource exhaustion, connection disruption, sustained service unavailability, or downstream application availability impact. Escalation likelihood increases when affected appliances support customer portals, authentication-fronting services, regulated applications, partner access, payment-adjacent workflows, TLS termination, high-availability services, specialized protocols, shared backend pools, multi-region application delivery, reused credentials, weak isolation, incomplete logs, or limited appliance telemetry.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        ADCs, load balancers, reverse proxies, and WAF-adjacent appliances often sit directly on internet-facing or partner-reachable paths and may support customer-facing, partner-facing, authentication-fronting, and business-critical application workflows.

·        Management/API exposure creates attractive targeting opportunities when unauthenticated or weakly authenticated behavior can reach command endpoints, diagnostic functions, configuration objects, certificate material, administrative controls, or traffic-management functions.

·        Exposed traffic-processing functions create an additional targeting path when attacker-controlled network traffic can directly reach listeners, virtual services, protocol handlers, NAT functions, ALGs, or other packet and application-processing components.

·        Public exploit knowledge, repeatable management or protocol paths, commodity scanning, and automated exploitation can lower the barrier for opportunistic adversaries.

·        Appliance-level command execution can provide a direct path to configuration access, certificate exposure, credential access, outbound communication, traffic-path manipulation, and downstream application exposure without first compromising an employee endpoint.

·        Traffic-processing exploitation can cause material service instability or availability loss without providing command execution, making internet-facing processing functions attractive for disruption-focused or opportunistic exploitation.

·        Attackers benefit from environments where ADC asset inventory, management-interface mapping, listener and protocol inventories, API exposure records, virtual-service ownership, backend-pool mapping, certificate inventory, configuration baselines, appliance-health logging, outbound monitoring, change-management context, and downstream application review are incomplete.

·        Cloud-hosted ADCs, managed ADC services, virtual appliances, high-availability clusters, partner-reachable management paths, exposed processing functions, reused credentials, unclear administrator ownership, weak API restrictions, and inconsistent maintenance practices can make compromise harder to scope quickly.

·        Normal ADC administration, firmware updates, vendor support, protocol testing, load testing, health-check tuning, backup jobs, certificate rotation, failover testing, configuration migrations, vulnerability validation, monitoring activity, emergency remediation, red-team activity, and incident-response cleanup can make attacker-driven activity harder to classify without strong baselines.

·        Targeting probability should be assessed through ADC internet exposure, management/API reachability, exposed listeners and processing functions, access restrictions, TLS termination role, protocol-processing role, downstream application sensitivity, certificate exposure risk, credential reuse, availability dependency, telemetry maturity, and local evidence of ADC-facing activity followed by independent impact.

Most Likely Targets

·        Internet-facing, partner-reachable, cloud-hosted, managed, virtual, hardware, production, staging, disaster-recovery, and high-availability ADC or load-balancer appliances with exposed management/API or traffic-processing surfaces.

·        ADC deployments used for TLS termination, authentication-fronting services, customer portals, partner workflows, regulated applications, public web applications, support services, file-transfer paths, protocol processing, application routing, WAF-adjacent controls, and high-availability application delivery.

·        ADC management/API endpoints, diagnostic functions, administrative interfaces, authentication handlers, telemetry endpoints, configuration paths, backup functions, certificate-management functions, and support workflows.

·        Exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, application-protocol processing functions, and other traffic-facing components that accept untrusted network input.

·        Virtual services, backend pools, routing rules, rewrite rules, header rules, persistence profiles, health checks, WAF or proxy-adjacent controls, TLS-offload settings, certificate bindings, private keys, API tokens, configuration exports, backup archives, diagnostic bundles, and packet captures.

·        Organizations with exposed ADC management or traffic-processing surfaces, incomplete appliance inventory, delayed remediation, weak management-plane isolation, undocumented partner access, weak API restrictions, incomplete listener inventories, limited log retention, incomplete configuration baselines, unclear certificate ownership, weak outbound visibility, reused credentials, or incomplete downstream application mapping.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Edge ADC Discovery and Exposure Identification

The adversary identifies exposed ADC, load-balancer, reverse-proxy, WAF-adjacent, or traffic-management appliances and prioritizes targets that expose management/API, administrative, diagnostic, authentication, configuration, listener, virtual-service, protocol-processing, NAT, ALG, or related externally reachable functionality.

·        T1595 — Active Scanning.

Stage 2 — ADC Control-Plane or Traffic-Processing Exploitation

The adversary sends unauthenticated, weakly authenticated, malformed, repeated, automation-like, oversized, protocol-inconsistent, or exploit-shaped input against exposed ADC management/API or traffic-processing functionality.

·        T1190 — Exploit Public-Facing Application.

Stage 3A — Appliance-Level Command Execution

Where exploitation provides execution capability, the adversary executes commands, invokes shell or script behavior, abuses diagnostic functionality, or performs appliance-context activity outside approved administration.

·        T1059 — Command and Scripting Interpreter.

Stage 3B — Appliance Instability and Availability Impact

Where traffic-processing exploitation primarily affects appliance resilience, the adversary may trigger process or service faults, watchdog events, restart or reboot behavior, HA transitions, failover, resource exhaustion, connection disruption, or application-delivery unavailability.

·        T1499 — Endpoint Denial of Service.

Stage 4 — Configuration, Certificate, and Credential Access

Where exploitation enables access to protected appliance state, the adversary accesses configuration objects, backup archives, diagnostic bundles, API tokens, administrative credentials, TLS certificates, private keys, key stores, SAML or OIDC material, or credential-bearing appliance files.

·        T1005 — Data from Local System.

·        T1552 — Unsecured Credentials.

Stage 5 — Traffic-Path and Trust-Boundary Manipulation

The adversary modifies or abuses virtual services, backend pools, routing rules, rewrite rules, header rules, persistence profiles, NAT or ALG configuration, health checks, SSL/TLS offload settings, certificate bindings, or security-control policies to alter how application traffic is delivered, observed, authenticated, routed, or trusted.

·        T1565 — Data Manipulation.

Stage 6 — Outbound Communication

Where post-exploitation control exists, the adversary causes the ADC appliance or ADC-supporting workload to initiate unusual DNS, HTTP, HTTPS, file-transfer, tunneling, or command-and-control-like communication.

·        T1071 — Application Layer Protocol.

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

Edge ADC exploitation begins when adversaries identify exposed or insufficiently isolated ADC, load-balancer, reverse-proxy, WAF-adjacent, or traffic-management appliances with reachable control-plane or traffic-processing functionality. The attack path is not limited to management/API compromise. It can proceed through a control-plane branch that may enable appliance-level execution and trust-object manipulation, or through a traffic-processing branch that may produce appliance instability, service failure, availability disruption, or downstream application impact. Broader lateral movement, ransomware deployment, enterprise identity compromise, cloud compromise, or large-scale data theft should be treated as conditional amplification unless supporting telemetry confirms those behaviors.

Stage 1: Edge ADC Discovery and Exposure Identification

The adversary identifies exposed ADC, load-balancer, reverse-proxy, WAF-adjacent, or traffic-management appliances and prioritizes deployments exposing management/API functions, administrative paths, listeners, virtual services, protocol handlers, NAT functions, ALGs, or other traffic-processing surfaces. This may involve internet scanning, repeated appliance-path access, API endpoint probing, listener or protocol probing, version or banner discovery, source-infrastructure rotation, cloud-hosted infrastructure, VPN providers, residential proxies, scanner infrastructure, unusual geographies, or suspicious ASNs. Discovery alone does not establish compromise because edge appliances are routinely scanned.

Stage 2A: ADC Control-Plane Exploitation

The adversary sends unauthenticated, weakly authenticated, malformed, repeated, unusual, or automation-like requests against exposed ADC management/API, administrative, diagnostic, authentication, telemetry, configuration, or other control-plane functions. Observable evidence may include command-delimiter patterns, shell-control content, quote manipulation, encoded command content, malformed JSON, oversized API fields, unusual parameters, abnormal methods, repeated failed-to-success sequences, abnormal status-code patterns, response-size deviations, API-handler errors, authentication-handler errors, management-service faults, or connection resets.

This stage changes from routine exposure to possible exploitation when suspicious control-plane activity aligns with materially independent appliance execution, configuration access, certificate access, administrative activity, rare egress, traffic-path modification, or downstream application effects.

Stage 2B: ADC Traffic-Processing Exploitation

The adversary sends malicious, malformed, oversized, repeated, protocol-inconsistent, abnormal, or exploit-shaped traffic to exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or comparable processing components. Observable evidence may include unusual message size, abnormal transactions, protocol-sequence deviations, repeated invalid requests, fuzzing-like behavior, abnormal retransmission patterns, connection resets, service errors, or other processing anomalies.

This stage becomes materially significant when suspicious traffic-processing activity is followed by independent process or service faults, watchdog activity, restart or reboot, HA transition, failover, resource exhaustion, service unavailability, connection disruption, or downstream application availability impact. Traffic-processing exploitation must not be assumed to provide command execution unless separate evidence confirms execution.

Stage 3: Appliance-Level Command Execution

Where control-plane exploitation or another validated path provides execution capability, the adversary may execute commands, invoke shell or script behavior, abuse diagnostic functionality, run transfer tools, interact with appliance utilities, access package or firmware-related functions, or perform appliance-context activity outside approved administration. Observable evidence may include shell invocation, script execution, diagnostic utility abuse, short-lived process activity, unusual command lines, transfer-tool execution, archive creation, package activity, command-output files, or service-context execution.

Stage 4: Configuration, Certificate, and Credential Access

Where the adversary obtains appliance-level, API, diagnostic, or administrative access, activity may progress to ADC configuration objects, backup archives, diagnostic bundles, packet captures, API tokens, administrative credentials, TLS certificates, private keys, key stores, SAML material, OIDC material, backend credentials, or other credential-bearing appliance files. This stage increases business risk because certificate, credential, and configuration exposure can extend the incident into TLS trust, backend routing, administrative workflows, partner access, and downstream applications.

Stage 5: Traffic-Path and Trust-Boundary Manipulation

The adversary may modify or abuse virtual services, backend pools, listener configuration, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, NAT or ALG configuration, health checks, SSL/TLS offload settings, certificate bindings, WAF-adjacent policies, proxy policies, logging settings, or security controls. This stage becomes materially significant when changes occur after suspicious ADC activity and cannot be tied to approved maintenance, emergency change, vendor support, certificate rotation, failover testing, migration, or incident-response activity.

Stage 6: Outbound Communication

Where adversary-controlled execution or appliance access exists, the ADC appliance, virtual-appliance host, management host, or supporting workload may initiate unusual outbound communication. Observable evidence may include rare DNS lookups, outbound HTTP or HTTPS, raw-IP communication, SSH, SMTP, file transfer, tunneling, callback-like behavior, command-and-control-like communication, tool retrieval, repeated callbacks, or internal management-service access inconsistent with approved vendor support, updates, license validation, monitoring, NTP, DNS, syslog, backup, or integration behavior.

Stage 7: Downstream Application Exposure and Administrative-Control Risk

The adversary may use ADC trust relationships, routing control, certificate exposure, credential access, administrative control, or backend visibility to affect downstream applications, authentication flows, partner workflows, backend services, customer-facing availability, or application-delivery integrity. Observable evidence may include unexpected backend access, authentication-flow disruption, session-routing changes, header manipulation, traffic mirroring, TLS changes, unexpected plaintext backend flows, service-account use, internal API access, database access, storage access, backup access, application-administration activity, new administrative accounts, API-key changes, or access-control modifications.

Traffic-processing exploitation may also affect downstream applications through availability, connection-handling, or traffic-delivery disruption without providing administrative control.

Stage 8: Post-Remediation Trust Validation and Containment Risk

Residual risk remains when modified configuration, altered virtual services, exposed certificates, changed backend pools, administrative changes, API-key changes, weakened logging, diagnostic-artifact deletion, unauthorized management exposure, continued appliance instability, outbound communication, or downstream application anomalies persist after patching or apparent remediation. Continued suspicious behavior after isolation, configuration restoration, credential rotation, certificate review, or service recovery should be treated as a high-priority containment signal.

S19 — Attack Chain Risk Amplification Summary

Edge ADC exploitation amplifies risk because it targets infrastructure that may concentrate public application delivery, TLS termination, customer-facing availability, partner access, authentication-fronting services, WAF-adjacent enforcement, backend routing, protocol processing, certificate handling, administrative control, and downstream application trust.

·        Internet-facing or partner-reachable ADC exposure increases risk because both control-plane and traffic-processing functions may be reachable from adversary-controlled infrastructure.

·        Management/API exposure increases risk because vulnerable or weakly isolated appliance functionality may allow unauthenticated or weakly authenticated access to command execution, diagnostic functions, configuration objects, certificate material, or administrative controls.

·        Traffic-processing exposure increases risk because malformed or exploit-shaped external traffic may reach listeners, virtual services, protocol handlers, NAT functions, ALGs, or other processing components without interacting with the management plane.

·        Appliance-level command execution increases risk because compromise may move directly from external control-plane interaction into appliance-context execution without first requiring employee endpoint compromise.

·        Appliance instability increases business risk when process crashes, service faults, watchdog events, restart or reboot activity, HA transition, failover, resource exhaustion, connection disruption, or service unavailability affects critical application delivery.

·        Configuration access amplifies business impact when exposed material includes virtual services, backend pools, routing rules, rewrite rules, header rules, persistence profiles, NAT or ALG configuration, health checks, WAF-adjacent policies, logging settings, backup archives, diagnostic bundles, packet captures, API tokens, or administrative settings.

·        Certificate and private-key exposure increases business risk because affected material may undermine TLS trust, authentication flows, partner connections, backend-service confidentiality, and confidence in customer-facing application integrity.

·        Traffic-path manipulation increases exposure when virtual services, backend pools, routing behavior, header rules, rewrite rules, NAT or ALG behavior, TLS termination, persistence settings, health checks, or security-control policies change after suspicious ADC activity.

·        Administrative-control compromise increases risk when local administrative users, support accounts, API keys, privileged automation, management-interface restrictions, access-control lists, backup schedules, diagnostic settings, firmware or package state, or logging settings change without approved context.

·        Rare outbound communication increases concern when the ADC appliance initiates callback-like traffic, tool retrieval, tunneling, raw-IP communication, file-transfer behavior, suspicious HTTP or HTTPS connections, or internal management-service access.

·        Downstream application exposure amplifies impact when affected traffic paths support customer portals, authentication-fronting services, regulated applications, partner workflows, payment-adjacent processes, public web applications, support services, file-transfer paths, or high-availability services.

·        Multi-appliance environments increase scope because one behavior family may affect production ADCs, staging appliances, disaster-recovery devices, cloud-hosted ADCs, managed ADC services, high-availability pairs, reverse proxies, WAF-adjacent appliances, backend pools, and shared certificate or administrative workflows.

·        Post-remediation activity becomes a high-priority containment signal when suspicious control-plane activity, traffic-processing anomalies, appliance instability, rare egress, configuration drift, certificate access, administrative changes, logging degradation, or downstream anomalies continue after remediation.

·        Incomplete management, protocol, appliance-health, configuration, certificate, network, endpoint, or downstream application telemetry can force broader investigation because the organization cannot quickly prove whether execution, instability, trust-object exposure, routing manipulation, or downstream impact occurred.

·        Response burden increases because teams must validate ADC asset exposure, management/API isolation, traffic-processing exposure, suspicious request or protocol activity, appliance execution or instability, configuration integrity, certificate handling, virtual-service state, backend-pool mapping, administrative-account state, outbound communication, downstream application behavior, legal obligations, and executive assurance.

S20 — Tactics, Techniques, and Procedures

Figure 3

Edge ADC exploitation and application-delivery trust compromise attack-chain model showing edge ADC discovery, exposed control-plane or traffic-processing exploitation, appliance execution or instability, configuration and certificate access, traffic-path manipulation, outbound communication, downstream application exposure, and post-remediation trust validation.

Edge ADC Discovery and Exposure Identification

Adversaries may identify exposed ADC, load-balancer, reverse-proxy, WAF-adjacent, or traffic-management appliances through internet scanning, repeated appliance-path access, API endpoint probing, listener probing, protocol discovery, banner or version discovery, source-infrastructure rotation, cloud-hosted infrastructure, VPN providers, residential proxies, suspicious ASNs, unusual geographies, scanner infrastructure, or probing of known management and traffic-processing surfaces.

ADC Management/API Exploitation

Adversaries may send malformed, unusual, repeated, unauthenticated, weakly authenticated, or automation-like requests against ADC management/API, administrative, diagnostic, authentication, telemetry, configuration, or control-plane functionality. Higher-priority behavior includes command-delimiter patterns, shell-control content, quote manipulation, encoded command content, malformed JSON, oversized fields, unusual parameters, abnormal methods, repeated failed-to-success sequences, abnormal status codes, response-size deviations, API-handler errors, authentication-handler errors, management-service faults, or unexplained connection resets.

ADC Traffic-Processing Exploitation

Adversaries may send malformed, oversized, abnormal, repeated, protocol-inconsistent, fuzzing-like, or otherwise exploit-shaped traffic to ADC listeners, virtual services, protocol handlers, NAT functions, ALGs, or other processing surfaces. Higher-priority behavior occurs when this activity aligns with independent service faults, process crashes, watchdog activity, restart or reboot behavior, HA transitions, failover, resource exhaustion, connection disruption, service unavailability, or downstream application availability impact.

Traffic-processing exploitation should not be interpreted as command execution unless execution telemetry independently supports that conclusion.

Appliance-Level Command Execution

Adversaries may execute commands, invoke shell or script behavior, abuse diagnostic functions, run transfer tools, interact with appliance utilities, generate command output, or execute appliance-context activity outside approved administration. This behavior becomes materially significant when command activity follows suspicious ADC control-plane behavior and cannot be explained by approved vendor support, patch validation, firmware update, diagnostic collection, monitoring, backup activity, failover testing, emergency maintenance, or documented incident response.

Configuration, Certificate, and Credential Access

Adversaries may access ADC configuration objects, backup archives, diagnostic bundles, packet captures, API tokens, administrative credentials, TLS certificates, private keys, key stores, SAML material, OIDC material, backend credentials, or credential-bearing appliance files. This behavior becomes materially significant when sensitive-object access follows suspicious ADC activity and cannot be tied to approved backup jobs, certificate rotation, vendor support, configuration migration, troubleshooting, monitoring, emergency maintenance, or incident-response collection.

Traffic-Path and Trust-Boundary Manipulation

Adversaries may modify or abuse virtual services, backend pools, listener configuration, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, NAT or ALG configuration, health checks, SSL/TLS offload settings, certificate bindings, WAF-adjacent policies, proxy policies, logging settings, or security-control policies. This behavior becomes high risk when changes affect customer-facing services, authentication flows, partner workflows, regulated applications, backend routing, TLS termination, downstream visibility, or application-delivery integrity outside approved change windows.

Outbound Communication

Where adversary-controlled appliance execution exists, adversaries may use the ADC appliance, virtual-appliance host, management host, or supporting workload for outbound DNS, HTTP, HTTPS, SSH, SMTP, raw-IP communication, file transfer, tunneling, callback-like behavior, command-and-control-like communication, tool retrieval, repeated callbacks, or internal management-service access. This behavior becomes high risk when outbound communication follows suspicious ADC activity, reaches rare destinations, deviates from approved vendor-support or update behavior, or cannot be tied to monitoring, telemetry, license validation, backup, syslog, NTP, health-check, integration, or incident-response workflows.

Downstream Application Exposure and Administrative-Control Risk

Adversaries may use ADC trust relationships, routing control, certificate exposure, credential access, administrative control, backend visibility, or availability disruption to affect downstream applications, authentication flows, backend services, partner workflows, customer-facing availability, or application-delivery integrity. This behavior becomes high risk when downstream anomalies align with suspicious ADC activity through virtual-service, backend-pool, listener, route, source, protocol, administrative identity, destination, or bounded-time correlation.

Operational Blending With ADC Administration and Application Traffic

Adversaries may blend malicious activity into normal ADC administration, application traffic, firmware updates, vendor support, health checks, protocol testing, load testing, backup jobs, certificate rotation, failover testing, configuration migrations, vulnerability validation, monitoring activity, red-team activity, emergency remediation, or incident-response cleanup. Detection and response require correlating initiating ADC-facing activity with appliance execution, health effects, configuration state, certificate access, administrative context, outbound communication, availability, and downstream application impact rather than relying on one artifact in isolation.

Post-Remediation Access and Trust Validation Failure

Adversaries may continue accessing control-plane paths, exploiting exposed traffic-processing functions, interacting with altered configuration, using exposed certificates or administrative accounts, communicating with outbound infrastructure, or affecting downstream application paths after patching, isolation, credential rotation, certificate review, configuration restoration, or application validation. Continued suspicious behavior after remediation becomes high priority when it touches sensitive configuration or certificate material, produces instability, triggers rare egress, modifies traffic paths, causes downstream anomalies, or cannot be tied to approved business, vendor-support, or incident-response activity.

S20A — Adversary Tradecraft Summary

Edge ADC exploitation targets the trust relationship between externally reachable application-delivery functionality, appliance execution and resilience, configuration state, certificate handling, virtual services, backend routing, administrative control, outbound communication, availability, and downstream application delivery. Adversary tradecraft may follow a control-plane path that progresses into execution and trust-object manipulation or a traffic-processing path that produces appliance or service instability, connection disruption, availability degradation, or downstream application impact without requiring management/API access.

·        The core control-plane tradecraft pattern is suspicious ADC management/API activity followed by appliance execution, configuration access, certificate or private-key exposure, virtual-service manipulation, backend-pool changes, routing or header control, administrative-control changes, outbound communication, downstream application anomalies, or post-remediation activity.

·        The core traffic-processing tradecraft pattern is suspicious or exploit-shaped traffic to listeners, virtual services, protocol handlers, NAT functions, ALGs, or comparable processing components followed by process or service faults, watchdog events, restart, HA transition, failover, resource exhaustion, abnormal connection behavior, availability degradation, or downstream application impact.

·        Traffic-processing exploitation does not imply command execution, credential access, configuration theft, or administrative compromise unless independent evidence demonstrates those outcomes.

·        The activity is not dependent on a single exploit string, actor name, scanner fingerprint, request path, source IP, user agent, vendor label, API endpoint, protocol, payload, response code, vulnerable-version finding, proof-of-concept reference, KEV status, or static IOC.

·        Adversaries may use internet scanning, source rotation, cloud-hosted infrastructure, VPN providers, residential proxies, malformed API requests, malformed protocol traffic, request or message shaping, command-delimiter patterns, encoded command content, API parameter manipulation, diagnostic-function abuse, appliance-context execution, configuration export, certificate access, virtual-service manipulation, backend-pool changes, rare egress, service disruption, and downstream application probing.

·        The strongest operational risk occurs when suspicious activity affects ADCs that support customer portals, authentication-fronting services, TLS termination, partner workflows, regulated applications, payment-adjacent processes, support services, specialized protocols, file-transfer paths, high-availability applications, or multiple downstream services tied to common application-delivery infrastructure.

·        Detection requires visibility into the ADC-facing activity that begins the chain and the appliance, service-health, configuration, certificate, administrative, outbound, network, availability, and downstream application evidence that confirms or disproves impact.

Response should treat suspected ADC exploitation as an application-delivery trust, appliance-resilience, certificate-exposure, configuration-integrity, traffic-path-control, administrative-control, downstream-application, and containment-validation incident rather than a routine scanner alert, isolated appliance error, malformed protocol event, single vulnerable-version finding, or patch-management task.

S21 — Detection Strategy Overview

Detection Philosophy

Detect edge ADC, load balancer, reverse proxy, WAF-adjacent appliance, and traffic-management compromise through two parallel exploitation paths that converge on the same application-delivery trust boundary: control-plane exploitation and traffic-processing exploitation. Control-plane exploitation includes suspicious unauthenticated, weakly authenticated, or non-administrative interaction with management, API, administrative, authentication, diagnostic, configuration, or equivalent control surfaces. Traffic-processing exploitation includes suspicious or exploit-shaped interaction with externally reachable listeners, virtual services, protocol handlers, NAT functions, ALGs, or other packet- and application-processing functions. Promote confidence through correlated appliance, service-health, execution, configuration, network, certificate, routing, availability, administrative, and downstream-application evidence rather than CVE names, KEV status, vendor names, vulnerable-version status, proof-of-concept names, scanner hits, or isolated request patterns.

The durable detection model is suspicious ADC-facing activity followed by observable consequences such as appliance command execution, process or service instability, memory-corruption indicators where available, crashes, watchdog activity, restart or failover behavior, configuration access, traffic-path manipulation, TLS or certificate exposure, credential access, outbound communication, persistence-like appliance changes, administrative-control compromise, availability degradation, or downstream application impact.

Primary Detection Anchors

·        Suspicious unauthenticated, external, partner-originated, unusual, or non-administrative interaction with ADC management, API, administrative, authentication, diagnostic, telemetry, configuration, or other control-plane surfaces.

·        Suspicious externally sourced, malformed, oversized, abnormal, repeated, or protocol-inconsistent traffic directed at ADC listeners, virtual services, protocol handlers, NAT functions, ALGs, or other traffic-processing surfaces.

·        Requests targeting Progress Kemp LoadMaster API behavior, including /accessv2 where locally observable, retained as a product-specific control-plane anchor rather than a dependency of the broader detection model.

·        Requests containing command-delimiter, shell-control, quote-manipulation, encoded, malformed JSON, authentication-bypass, API-parameter manipulation, heap-shaping, oversized-field, malformed protocol-field, or other exploit-shaped characteristics appropriate to the exposed ADC function.

·        ADC appliance process, service, diagnostic, shell, script, command, utility, traffic-management, or protocol-processing behavior that is inconsistent with approved administrative, vendor-support, upgrade, backup, monitoring, health-check, failover, or application-delivery activity.

·        Suspicious ADC-facing activity followed by process or service faults, crashes, watchdog events, unexplained restarts, high-availability transitions, unexpected failover, resource exhaustion, abnormal connection behavior, or availability degradation.

·        Control-plane activity followed by command execution, configuration access, certificate or credential access, administrative activity, virtual-service modification, routing changes, outbound communication, or other post-access behavior.

·        New, modified, exported, downloaded, or accessed ADC configuration objects, virtual services, real-server or backend pools, content-switching rules, routing policies, persistence profiles, NAT or traffic-processing configuration, WAF/proxy-adjacent policies, health checks, authentication templates, or administrative settings.

·        Access to TLS certificates, private keys, key stores, SAML/OIDC material, API tokens, administrative credentials, backup archives, diagnostic bundles, configuration exports, packet captures, or other credential- or trust-bearing appliance artifacts.

·        Unexpected changes to virtual services, listeners, backend mappings, routing rules, rewrite rules, headers, persistence settings, traffic-processing configuration, SSL/TLS offload settings, certificate bindings, logging settings, or security-control policies.

·        Appliance-originated outbound DNS, HTTP, HTTPS, SSH, SMTP, raw-IP, file-transfer, tunneling, paste-site, or command-and-control-like communication after suspicious ADC activity.

·        Administrative account creation, role changes, API key creation, support-account activity, backup schedule changes, firmware or package changes, persistence-like scripts, cron behavior, log clearing, diagnostic artifact deletion, or appliance reboot behavior near suspicious activity.

·        Downstream application anomalies temporally aligned with suspicious ADC activity, including unexpected backend access, authentication-flow disruption, session-routing changes, header manipulation, TLS termination changes, traffic mirroring, connection disruption, data exposure, or availability degradation.

·        Multiple ADC or related traffic-management assets showing similar control-plane probing, traffic-processing exploit attempts, protocol anomalies, appliance instability, configuration changes, outbound behavior, or downstream impact within a bounded time window.

Detection Prioritization Model

Prioritize either of two initiating paths:

·        Suspicious control-plane interaction followed by command execution, configuration access, administrative activity, certificate or credential access, routing manipulation, outbound communication, appliance instability, or downstream application impact.

·        Suspicious traffic-processing interaction followed by process or service faults, crashes, watchdog activity, restart or failover behavior, resource exhaustion, abnormal connection behavior, availability degradation, or downstream application impact.

Treat isolated request, packet, protocol, API, scanner, or exposure telemetry as exploit-attempt or exposure evidence unless it is correlated with materially independent appliance, service-health, process, configuration, certificate, routing, administrative, outbound, availability, or downstream evidence.

Correlation Strategy (Strict Enforcement)

Do not promote a single ADC management request, malformed protocol message, unusual application transaction, vulnerable-version finding, enabled traffic-processing feature, API exposure, KEV presence, public exploit availability, scanner event, generic command-injection string, authentication failure, appliance error, process crash, service restart, failover event, or standalone network event to high-confidence compromise.

Correlate by the most appropriate identifiers available for the exploitation path, including appliance, management interface, traffic-facing interface, listener, virtual service, protocol, traffic-processing function, NAT or LSN group where applicable, API endpoint, source IP, forwarded source IP, partner path, backend pool, administrative account, session, request path, configuration object, certificate object, process or service context, destination, maintenance window, or bounded time window.

High-confidence detection requires a sequence that connects suspicious ADC-facing activity with observable appliance or trust-boundary impact.

Telemetry Prioritization

Prioritize telemetry capable of establishing the initiating exploitation path and the resulting appliance or application-delivery effect. This includes ADC management/API logs, administrative audit logs, appliance system and service-health logs, protocol or traffic-processing logs where available, configuration-change records, authentication logs, WAF logs, reverse-proxy logs, load-balancer logs, CDN logs, virtual-service and backend records, TLS and certificate-management logs, HA and failover records, diagnostic records, DNS logs, proxy logs, firewall logs, NDR or EDR telemetry where available, SIEM asset inventory, vulnerability exposure data, network-flow telemetry, downstream application logs, and incident-response appliance artifacts.

For control-plane paths, preserve request path, query-string, request-body metadata, API method, management interface, administrative identity, and source identity where available.

For traffic-processing paths, preserve protocol, listener, virtual service, source and destination addressing, traffic-processing role, appliance identity, connection state, transaction metadata, and appliance-to-application mapping where available.

Detection Design Constraints

Avoid detection designs based only on CVE identifiers, KEV status, vendor names, appliance banners, vulnerable-version status, proof-of-concept repositories, public user agents, IP addresses, file hashes, single endpoints, one exploit string, one malformed-packet pattern, or isolated scanning.

Detection must remain effective across ADC exploitation variants that differ in vendor, endpoint, exposed function, authentication model, API method, protocol, traffic-processing feature, command-injection primitive, memory-corruption primitive, exploit payload, appliance process model, configuration object, traffic-routing function, TLS behavior, logging depth, and post-exploitation or availability-impact sequence.

Current SIP ALG and Large Scale NAT behavior should be treated as a CVE-2026-19489-specific implementation example, not as a required component of the durable detection model.

Baseline and Deployment Requirements

Baseline approved ADC administrators, management sources, partner paths, internet-facing listeners, virtual services, expected application protocols, vendor-support activity, vulnerability scanners, patch-validation tools, maintenance windows, automation accounts, API clients, firmware workflows, configuration exports, certificate-management activity, health checks, normal restart and failover behavior, routing changes, approved outbound destinations, and routine appliance configuration activity.

Where locally applicable, also baseline NAT, LSN, ALG, or other specialized traffic-processing functions required by an exposed vulnerability.

Validate appliance-to-virtual-service, listener-to-protocol, appliance-to-backend, management-interface-to-control-plane, traffic-facing-interface-to-processing-function, and ADC-to-downstream-application mappings before alert promotion.

Variant Resilience Requirements

Rules should remain effective for future ADC, load balancer, reverse proxy, WAF-adjacent appliance, control-plane, and traffic-processing exploit paths that produce the same observable consequences: command execution, appliance instability, process or service faults, crashes, restart or failover behavior, configuration access, virtual-service manipulation, routing changes, TLS or certificate exposure, credential access, rare egress, administrative-control changes, persistence-like modification, availability degradation, or downstream application impact.

Operational Detection Model

Run detections in hunt mode first. Validate control-plane and traffic-processing log parsing, source attribution, interface and listener mapping, virtual-service mapping, appliance identity, downstream application mapping, normal administrative activity, expected protocol behavior, service-health baselines, restart and failover behavior, configuration normalization, certificate visibility, and network correlation.

Use escalating confidence:

·        Suspicious ADC-facing activity.

·        Suspicious activity plus abnormal appliance response or service-health degradation.

·        Suspicious activity plus crash, watchdog, restart, failover, resource-exhaustion, or availability impact.

·        Suspicious activity plus command execution.

·        Suspicious activity plus configuration, certificate, or credential access.

·        Suspicious activity plus outbound communication.

·        Suspicious activity plus administrative, routing, TLS, logging, or downstream-application impact.

Explicit Non-Deployment Guardrails

Do not deploy weak WAF-only, signature-only, malformed-packet-only, SIP-only, request-only, or crash-only detections as compromise confirmation.

Do not claim compromise from vulnerable-version status, enabled SIP ALG, LSN configuration, exposed traffic-processing functionality, management exposure, scanner traffic, public PoC availability, KEV status, common management paths, isolated API errors, isolated malformed protocol traffic, unrelated authentication failures, isolated crashes, routine restarts, expected failovers, ordinary resource pressure, cloud-only anomalies, identity-only anomalies, or network-only anomalies.

Do not attribute downstream application behavior, certificate access, credential use, routing changes, backend access, availability impact, or outbound traffic to ADC exploitation without appropriate appliance, source, interface, listener, protocol, path, API, configuration, process or service, identity, destination, or time-window linkage.

S22 — Primary Detection Signals

Primary Detection Signals

·        Unauthenticated, external, partner-originated, unusual, or non-administrative requests to ADC management, API, administrative, authentication, diagnostic, telemetry, configuration, or other control-plane surfaces.

·        Malformed, oversized, abnormal, repeated, exploit-shaped, or protocol-inconsistent traffic directed at externally reachable ADC listeners, virtual services, protocol handlers, NAT functions, ALGs, or other traffic-processing surfaces.

·        Requests to Progress Kemp LoadMaster API behavior, including /accessv2 where locally observable.

·        Control-plane requests containing command-delimiter, shell-control, quote-manipulation, encoded, malformed JSON, authentication-bypass, API-parameter manipulation, heap-shaping, oversized-field, or other exploit-shaped characteristics.

·        Traffic-processing input containing unusual message lengths, malformed protocol fields, unexpected transaction structures, repeated abnormal requests, or other deviations from locally established protocol behavior.

·        Suspicious ADC-facing activity followed by appliance process or service faults, crashes, watchdog activity, unexplained restart, high-availability state change, unexpected failover, resource exhaustion, connection disruption, or availability degradation.

·        Suspicious control-plane access followed by command execution, shell invocation, diagnostic execution, configuration activity, certificate or credential access, administrative activity, or outbound communication.

·        Access to ADC configuration exports, backups, diagnostic bundles, packet captures, virtual-service objects, backend pools, routing objects, traffic-processing configuration, authentication templates, logging settings, or administrative settings.

·        Access to TLS certificates, private keys, key stores, TLS-offload settings, certificate bindings, SAML/OIDC material, API tokens, administrative credentials, or other trust-bearing appliance artifacts.

·        New, modified, deleted, exported, or replaced virtual services, listeners, backend pools, routing rules, rewrite rules, header rules, persistence profiles, health checks, authentication profiles, traffic-processing configuration, or security-control policies.

·        Appliance-originated outbound communication to rare, suspicious, newly observed, or operationally inconsistent destinations after suspicious ADC activity.

·        Downstream application anomalies temporally aligned with suspicious ADC behavior, including unexpected backend traffic, authentication-flow disruption, session-routing changes, header manipulation, TLS changes, traffic mirroring, connection loss, data exposure, or availability degradation.

Supporting Detection Signals

·        Unusual user agents, request sizes, message sizes, content types, API methods, protocol methods, request cadence, response sizes, source geographies, source ASNs, partner paths, listener activity, or repeated attempts.

·        Scanner-like or exploit-shaped activity followed by appliance instability, command-execution evidence, service faults, configuration access, outbound communication, or traffic-path changes.

·        Abnormal HTTP or protocol response transitions, repeated retries, timeouts, connection resets, abrupt terminations, success-to-fault transitions, or repeated error states around suspicious ADC activity.

·        Administrative login from unfamiliar source IPs, devices, geographies, ASNs, partner paths, access methods, or time windows.

·        Unexpected increases in service faults, watchdog activity, process restarts, HA transitions, failovers, resource-exhaustion events, or health degradation near suspicious externally sourced traffic.

·        Configuration changes inconsistent with approved deployment activity, automation, maintenance, emergency change, failover, or vendor support.

·        Certificate or TLS-object access inconsistent with approved certificate-management workflows.

·        DNS, proxy, firewall, NDR, or EDR activity from ADC appliances inconsistent with normal updates, monitoring, vendor support, backup, integration, health-check, or application-delivery behavior.

·        Downstream web, application, identity, or backend logs showing unusual source, header, session, routing, authentication, service-access, connection-loss, or availability patterns after suspicious ADC activity.

Exploit Attempt and Instability Signals

·        Repeated or anomalous interaction with ADC management, API, authentication, diagnostic, configuration, telemetry, listener, virtual-service, NAT, ALG, or other traffic-processing functionality from external or unfamiliar sources.

·        Control-plane requests containing shell metacharacters, quote manipulation, encoded command content, JSON anomalies, unusual authentication fields, oversized values, or parameter structures inconsistent with expected clients.

·        Protocol traffic containing malformed fields, unusual message sizes, abnormal transaction structures, repeated invalid sequences, or other deviations from the locally expected traffic model.

·        Where SIP-processing functionality is locally enabled, SIP signaling that materially deviates from established source, destination, transaction, message-size, or request-pattern baselines may be used as supporting exploit-attempt evidence. This is a current CVE-2026-19489-specific example and should not become a universal ADC requirement.

·        Failed-to-success, success-to-fault, normal-to-reset, repeated-error, timeout, connection-reset, or equivalent abnormal state transitions around the same appliance, interface, endpoint, listener, virtual service, protocol, or source within a bounded window.

·        Appliance errors, service faults, traffic-processing faults, API handler exceptions, authentication-handler failures, process crashes, watchdog events, unexplained restarts, high-availability transitions, unexpected failovers, resource exhaustion, or diagnostic errors near suspicious activity.

·        Unexpected ADC-facing activity immediately preceding firmware, configuration, virtual-service, certificate, routing, logging, administrative, service-health, or HA changes.

·        Public PoC-like or exploit-shaped behavior treated only as exploit-attempt evidence unless correlated with independent appliance or downstream impact.

Outbound Communication Signals

·        ADC-originated DNS, HTTP, HTTPS, SSH, SMTP, raw-IP, file-transfer, tunneling, or other network activity to rare, newly seen, suspicious, unknown, or unapproved destinations after suspicious ADC activity.

·        Appliance processes, diagnostic functions, shell activity, service contexts, or traffic-management processes initiating unexpected outbound communication.

·        Outbound connections temporally aligned with command execution, configuration access, certificate access, diagnostic-bundle creation, appliance instability, service crash, failover, or administrative change.

·        Repeated callbacks from the same ADC appliance after suspicious activity.

·        Unexpected communication from ADC appliances to internal management, identity, database, storage, backup, deployment, or application-administration services.

Persistence and Post-Exploitation Signals (Conditional)

·        New or modified administrative users, API keys, support accounts, authentication profiles, role assignments, backup schedules, firmware packages, scripts, cron-like entries, diagnostic settings, logging settings, or appliance configuration objects.

·        Modified virtual services, backend pools, routing rules, rewrite rules, header rules, persistence profiles, NAT configuration, ALG settings, WAF/proxy-adjacent controls, health checks, or TLS-offload settings outside approved change activity.

·        New or accessed configuration exports, backup archives, diagnostic bundles, packet captures, certificate files, private keys, API tokens, credential stores, or appliance-support artifacts.

·        Log clearing, logging suppression, audit changes, diagnostic artifact deletion, configuration rollback, appliance reboot, service restart, timestamp anomalies, unexpected failover, or repeated configuration replacement.

·        Creation of alternate control paths, unauthorized management exposure, weakened authentication controls, changed ACLs, altered management-interface restrictions, or new partner-reachable administrative paths.

·        Downstream application changes indicating ADC-mediated access, including unexpected backend access, header injection, authentication-flow change, session-affinity manipulation, traffic mirroring, TLS termination modification, or unexplained availability impact.

Lateral Movement and Expansion Signals (Conditional)

·        Use of ADC-stored, appliance-accessible, or traffic-path-exposed credentials against downstream systems.

·        Appliance-originated access to backend management interfaces, internal APIs, identity services, databases, file-sharing systems, storage, backup repositories, or deployment systems.

·        Access to adjacent ADC appliances, sibling load balancers, reverse proxies, WAF-adjacent appliances, CDN configuration, DNS infrastructure, certificate-management systems, or traffic-management consoles.

·        Multiple virtual services, backend pools, applications, or edge appliances showing related exploit-attempt, protocol-anomaly, instability, configuration-access, outbound, certificate-access, or traffic-path manipulation behavior.

·        Downstream authentication anomalies, service-account use, API activity, backend data access, or application-administration activity temporally aligned with suspicious ADC behavior.

Signal Usage Constraints

Do not treat any single signal as compromise confirmation. Promote confidence only when multiple signals align through appropriate ADC context such as appliance, management interface, traffic-facing interface, listener, virtual service, protocol, traffic-processing function, NAT or LSN group where locally applicable, API endpoint, source, partner path, administrative account, backend pool, configuration object, certificate object, process or service context, destination, maintenance window, or bounded time window.

Treat KEV status, public PoC availability, vulnerable-version status, enabled vulnerable functionality, and exploitation-attempt reporting as urgency inputs, not detection proof.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

·        EDR, appliance shell logging, Linux audit, syslog, vendor diagnostic logs, command-execution logs, service-health records, process-health records, or equivalent appliance execution telemetry where available.

·        Parent process, child process, process user, command line, executable path, current directory, timestamp, hash where available, appliance identity, appliance role, management interface, traffic-facing interface, virtual-service mapping, and backend-service mapping.

·        ADC service account, appliance daemon, API handler, management service, diagnostic process, traffic-management process, protocol-processing service, health-check process, monitoring integration, vendor-support process, and script-execution mapping.

·        Shell, scripting, transfer, archive, encoding, discovery, credential-access, certificate-access, diagnostic, package-management, network, and persistence-like tooling executed from appliance context.

·        Appliance grouping for internet-exposed, partner-reachable, internal-management, disaster-recovery, lab, staging, production, cloud-hosted, managed, authentication-fronting, TLS-terminating, and specialized traffic-processing deployments.

·        Approved execution, diagnostic, backup, upgrade, monitoring, vulnerability-validation, vendor-support, restart, and maintenance exceptions.

Memory and Execution Telemetry

·        Appliance service-context execution evidence where available.

·        API handler, management service, authentication component, diagnostic service, shell, script, package, appliance daemon, traffic-management process, or protocol-processing component context where available.

·        Runtime command execution, interpreter invocation, encoded execution, child-process spawning, abnormal argument handling, abnormal service termination, unusual memory-related fault behavior, or unexpected API-driven or traffic-processing execution.

·        Process or service relationships connecting suspicious ADC-facing activity to execution, configuration access, file access, certificate access, service termination, restart behavior, or outbound communication.

·        Memory telemetry is optional and should remain conditional enrichment rather than a minimum requirement.

·        Memory-pressure, memory-allocation, access-violation, crash-artifact, or equivalent vendor-exposed memory indicators should be preserved where available.

·        Runtime execution telemetry may be unavailable on sealed, vendor-managed, hardware-only, or appliance-restricted ADC deployments.

Crash and Fault Telemetry

·        ADC appliance system logs.

·        Appliance process and service-health logs.

·        Management/API error logs.

·        Authentication-handler logs.

·        Traffic-management and protocol-processing logs where available.

·        WAF, reverse-proxy, CDN, load-balancer, listener, and virtual-service health or status telemetry.

·        Process or service crash events.

·        Watchdog events.

·        Service restart events.

·        Appliance reboot events.

·        Health-state changes.

·        High-availability and failover events.

·        Diagnostic fault records.

·        Resource-exhaustion and resource-pressure events.

·        Connection-reset, timeout, service-unavailable, repeated-retry, abnormal-response, success-to-fault, or equivalent instability patterns around suspicious ADC-facing activity.

·        Vendor-support, maintenance, monitoring, health-check, configuration-integrity, failover-testing, or incident-response context needed to distinguish malicious activity from normal operations.

Traffic-Processing and Protocol Telemetry

·        NDR, network-flow, packet-metadata, appliance, listener, virtual-service, load-balancer, reverse-proxy, WAF, or protocol telemetry capable of identifying externally sourced traffic delivered to exposed ADC traffic-processing functions.

·        Source IP, destination IP, source port, destination port, protocol, listener, virtual service, appliance interface, appliance identity, timestamp, connection state, request or message size, and transaction or session identifier where available.

·        Baselines for expected application-protocol behavior, message size, source population, destination population, request cadence, retries, connection resets, and error conditions for relevant traffic-processing functions.

·        Evidence linking abnormal protocol or traffic-processing activity to appliance service faults, watchdog events, restart behavior, failover, resource exhaustion, connection loss, or downstream availability degradation.

·        Where locally applicable to CVE-2026-19489, preserve SIP signaling metadata, SIP ALG configuration state, LSN configuration, LSN group membership, and mappings between affected traffic paths and appliance identity.

·        SIP ALG and LSN telemetry are CVE-2026-19489-specific implementation requirements and must not be treated as universal minimum telemetry for this report.

·        Equivalent protocol and traffic-processing telemetry should be substituted for future ADC vulnerabilities affecting other externally reachable processing functions.

File and Persistence Telemetry

·        File creation, modification, rename, read, write, delete, permission, ownership, timestamp, export, backup, diagnostic bundle, certificate, and configuration telemetry where available.

·        Configuration files, backup archives, diagnostic bundles, packet captures, certificate stores, private keys, logs, API tokens, support files, scripts, package locations, temporary directories, firmware artifacts, traffic-processing configuration, and appliance-specific repositories.

·        Known-good appliance configuration baselines.

·        Approved virtual-service inventory.

·        Approved listener inventory.

·        Approved real-server and backend-pool inventory.

·        Approved certificate and TLS-binding inventory.

·        Approved routing, rewrite, header, persistence, WAF/proxy-adjacent, health-check, logging, management-access, HA, and failover inventories.

·        NAT, LSN, ALG, or equivalent specialized traffic-processing configuration inventories where locally applicable.

·        Configuration-change records for administrative users, API keys, virtual services, backend pools, routing rules, content-switching rules, NAT settings, traffic-processing functions, ALG settings, TLS settings, certificate bindings, logging, backups, and management access.

·        Backup comparisons, appliance configuration exports, SIEM change records, ITSM records, vendor-support records, and incident-response collection artifacts.

Network and Outbound Communication Telemetry

·        DNS logs.

·        Proxy logs.

·        Firewall logs.

·        NDR metadata.

·        EDR network telemetry where available.

·        Appliance syslog and network telemetry.

·        NetFlow, VPC flow, cloud network flow, or data-center flow telemetry where available.

·        Source and destination IP, source and destination port, protocol, connection state, source appliance, source interface, destination interface where available, process or service context where available, timestamp, action, and reputation enrichment.

·        Approved ADC egress-destination inventory.

·        Approved vendor-support, update, telemetry, monitoring, license-validation, health-check, DNS, NTP, syslog, backup, and integration destinations.

·        Backend application, identity, database, storage, mail, monitoring, backup, management-service, listener, virtual-service, traffic-processing, and downstream mapping where available.

Web and Application Telemetry (Conditional Availability)

·        ADC management/API logs with request path, method, query-string, and request-body metadata where available.

·        ADC listener, virtual-service, protocol, and traffic-processing records where available.

·        WAF logs.

·        Reverse-proxy logs.

·        CDN logs.

·        Load-balancer logs.

·        Downstream web server access logs.

·        Downstream application logs.

·        HTTP method, URI path, query string, full URL where available, status code, response size, request size, protocol, user agent, source IP, forwarded source IP, management interface, traffic-facing interface, listener, virtual service, backend host, backend IP, timestamp, action, API method, and administrative identity where available.

·        ADC appliance inventory.

·        ADC version and patch inventory.

·        ADC management and API exposure inventory.

·        ADC externally reachable listener and protocol exposure inventory.

·        Virtual-service and backend-pool inventory.

·        Certificate and TLS-offload inventory.

·        NAT, LSN, ALG, or other specialized traffic-processing configuration where applicable.

·        Administrative audit logs and configuration database records where available.

·        Downstream application, identity, session, header, routing, availability, and backend-access telemetry.

Telemetry Availability Requirements

·        Minimum viable exploit-attempt and instability visibility requires sufficient ADC-facing request, protocol, WAF, reverse-proxy, CDN, load-balancer, network-flow, appliance, or server-side telemetry to identify suspicious interaction with the affected appliance, plus asset and exposure inventory sufficient to identify the relevant ADC, listener, virtual service, or control surface.

·        Minimum viable behavioral coverage requires the initiating suspicious activity to be correlated with at least one materially independent appliance, service-health, execution, configuration, certificate, administrative, routing, outbound, availability, or downstream signal.

·        Control-plane exploitation coverage requires management/API or equivalent control-surface telemetry joined where possible to appliance system, execution, configuration, authentication, certificate, outbound-network, administrative, and downstream context.

·        Traffic-processing exploitation coverage requires externally sourced network or protocol telemetry joined where possible to the affected listener, virtual service, processing function, appliance health, service fault, crash, restart, watchdog, failover, resource, connection, or downstream availability context.

·        Strong coverage requires multiple mutually reinforcing signals tied to the same ADC asset and exploitation window.

·        Highest confidence requires suspicious ADC-facing activity correlated with observable post-access or post-processing consequences such as command execution, appliance instability, configuration change, certificate or credential access, routing manipulation, rare egress, administrative-control change, logging degradation, restart, failover, availability degradation, or downstream application impact.

·        Managed, virtual, cloud-hosted, or sealed appliances require compensating evidence from network, WAF, reverse-proxy, CDN, load-balancer, protocol, vendor-appliance, configuration, backup, SIEM, change-management, and downstream application sources.

·        Cloud-hosted ADC environments require appliance-layer plus application-layer or traffic-processing/network-layer telemetry. Cloud control-plane telemetry alone is insufficient.

Telemetry Limitations and Gaps

·        ADC management logs may rotate quickly.

·        Traffic-processing or protocol telemetry may be unavailable, summarized, sampled, or retained only briefly.

·        Request bodies or protocol payloads may not be logged.

·        Query strings and API parameters may be absent or redacted.

·        Protocol message contents may not be retained even when connection metadata is available.

·        NAT, LSN, ALG, listener, virtual-service, and related processing configuration may not be centrally normalized or historically retained.

·        Appliance operating-system access may be restricted by vendor or support model.

·        Sealed or managed ADC deployments may not expose process, memory, file, package, shell, protocol-handler, or traffic-processing telemetry.

·        WAF, CDN, reverse-proxy, and load-balancer telemetry may hide backend identity, appliance processing path, NAT mapping, or protocol-handler context without local mapping.

·        Process crashes, restarts, watchdog events, failovers, or resource exhaustion may not preserve the initiating network transaction.

·        Configuration changes may require comparison against exports or known-good snapshots rather than native audit records.

·        Certificate and private-key access may not be logged with sufficient object detail.

·        Endpoint telemetry may be unavailable on appliance operating systems.

·        Network telemetry may not attribute activity to a specific ADC process or service.

·        HA failover, restart, crash, or resource-pressure behavior may result from maintenance, capacity conditions, software faults, hardware faults, or health-check failures and therefore requires surrounding activity and change context.

·        Cloud telemetry alone cannot prove ADC control-plane exploitation, traffic-processing exploitation, appliance command execution, memory corruption, configuration manipulation, certificate exposure, or downstream application impact.

·        Vulnerable-version status or presence of a vulnerable configuration cannot prove compromise or non-compromise.

S24 — Detection Opportunities and Gaps

Figure 4

Detection Opportunities

·        Suspicious ADC control-plane activity can be correlated with appliance instability, command execution, configuration access, virtual-service manipulation, certificate access, credential exposure, rare egress, administrative-control changes, and downstream application anomalies.

·        Suspicious traffic-processing activity can be correlated with process or service faults, crashes, watchdog events, restart behavior, high-availability transitions, failover, resource exhaustion, abnormal connection behavior, availability degradation, or downstream application impact.

·        Progress Kemp LoadMaster /accessv2 activity, where locally visible, provides a current product-specific anchor for CVE-2026-8037-related exploit-attempt review without making the detection model product-dependent.

·        ADC management/API request review may identify command-delimiter, quote-manipulation, encoded, malformed JSON, oversized, heap-shaping, authentication-bypass, or parameter-manipulation behavior associated with control-plane exploit attempts.

·        Traffic-processing telemetry may identify malformed, oversized, abnormal, repeated, or protocol-inconsistent input directed at exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or other externally reachable processing functions.

·        Where locally applicable to CVE-2026-19489, SIP signaling and LSN/SIP ALG context may provide a current implementation-specific correlation path between suspicious protocol activity and subsequent appliance instability or availability impact.

·        Appliance system and service-health logs can reveal management-service faults, traffic-processing faults, process or service crashes, watchdog activity, API or authentication-handler errors, restarts, failovers, high-availability transitions, resource exhaustion, and diagnostic instability after suspicious ADC-facing activity.

·        Configuration-change telemetry can reveal unexpected virtual-service, backend-pool, listener, routing, rewrite, header, persistence, NAT, ALG, WAF/proxy-adjacent, health-check, logging, or management-access changes.

·        Certificate and TLS-object review can identify unexpected access to certificates, private keys, key stores, TLS-offload settings, certificate bindings, or authentication material.

·        Network telemetry can identify callbacks, tool retrieval, unusual egress, tunneling, raw-IP activity, or internal service access from ADC appliances after suspicious control-plane or traffic-processing activity.

·        Downstream application logs can identify unexpected backend access, authentication-flow changes, session-routing anomalies, header manipulation, traffic-path change, connection disruption, application exposure, or availability degradation after suspicious ADC behavior.

·        WAF, CDN, reverse-proxy, load-balancer, listener, protocol, and network-flow telemetry may preserve source, forwarded-source, virtual-service, listener, protocol, backend, connection-state, and request-context evidence when appliance logs are incomplete or rotated.

·        Backup comparison and known-good configuration baselines can identify hidden configuration changes, weakened controls, unauthorized virtual-service or traffic-processing changes, certificate exposure, logging degradation, or post-remediation drift.

·        Change-management, SIEM, ITSM, vulnerability-management, asset-inventory, and vendor-support records can distinguish approved ADC administration, failover, protocol changes, maintenance, and remediation from suspicious activity.

·        Multi-appliance correlation can identify campaigns or shared exploit behavior targeting ADC control-plane or traffic-processing surfaces across internet-facing, partner-reachable, staging, disaster-recovery, and production appliances.

Detection Gaps

·        Management/API logs may not retain request bodies, API parameters, authentication fields, command content, or exploit payload structure.

·        Traffic-processing or protocol telemetry may be unavailable, sampled, summarized, or retained for only short periods.

·        ADC appliances may not expose process, memory, shell, file, package, traffic-processing, or protocol-handler telemetry to defenders.

·        Request-path, query-string, listener, protocol, NAT, or processing-function visibility may be incomplete when traffic passes through CDN, WAF, reverse-proxy, NAT, centralized logging, or other intermediary layers.

·        API, administrative, traffic-processing, or protocol exposure may be limited to partner, internal, or specialized network paths that are poorly inventoried.

·        Attackers may exploit one ADC surface and produce configuration, certificate, outbound, administrative, availability, or downstream effects through another surface.

·        A traffic-processing exploit may produce appliance instability, restart, failover, or availability degradation without exposing the precise packet, message, parser, process, or memory condition that caused the event.

·        Process crashes, watchdog events, service restarts, failovers, or resource-exhaustion conditions may occur without preserved evidence of the initiating request or network transaction.

·        NAT, LSN, ALG, listener, virtual-service, or other specialized traffic-processing configuration may not be centrally normalized or historically retained.

·        Attackers may delete diagnostic artifacts, clear logs, reboot appliances, roll back configurations, modify timestamps, or restore benign-looking configuration state after exploitation.

·        Configuration export timestamps may reflect backup, migration, failover, restoration, or maintenance activity rather than the original attacker action.

·        Legitimate patch validation, vendor support, emergency troubleshooting, configuration migration, certificate renewal, health-check tuning, backup activity, failover testing, capacity events, vulnerability validation, and incident-response cleanup may resemble suspicious behavior.

·        Certificate access, private-key exposure, routing manipulation, backend visibility, or traffic-processing impact may be difficult to prove without configuration snapshots, appliance evidence, and downstream review.

·        Cloud control-plane, identity, DNS, or flow telemetry alone cannot prove ADC control-plane or traffic-processing exploitation without appliance-layer, service-health, configuration, traffic-path, or downstream-application correlation.

·        Vulnerability scanner findings or presence of a vulnerable configuration cannot determine whether exploitation occurred or whether appliance state, credentials, certificates, virtual services, traffic-processing functions, or downstream applications were affected before remediation.

Compensating Controls

·        Use ADC management/API logs, WAF logs, CDN logs, reverse-proxy logs, load-balancer logs, listener or protocol telemetry, network-flow records, appliance health logs, and downstream application logs together to recover source, destination, request, protocol, virtual-service, backend, connection-state, and impact context.

·        Preserve appliance, WAF, CDN, reverse-proxy, load-balancer, protocol, firewall, DNS, proxy, flow, HA, failover, and downstream application telemetry before rotation during exposure review.

·        Inspect ADC configuration state, virtual services, listeners, backend pools, routing rules, header rules, rewrite rules, persistence profiles, health checks, WAF/proxy-adjacent policies, administrative users, API keys, logging settings, management exposure, and traffic-processing configuration.

·        Where locally applicable, validate NAT, LSN, ALG, and protocol-processing configuration associated with the exposed vulnerability. SIP ALG and LSN review should remain a CVE-2026-19489-specific implementation requirement rather than a universal ADC control.

·        Review certificate stores, private keys, TLS bindings, SSL/TLS offload settings, SAML/OIDC material, API tokens, diagnostic bundles, packet captures, backups, and configuration exports.

·        Compare current appliance configuration against known-good backups, configuration exports, and approved change records.

·        Restrict ADC management/API access to approved administrative networks, VPN paths, privileged access workflows, and documented partner-reachable paths.

·        Disable or isolate unnecessary ADC management interfaces, APIs, listeners, protocol handlers, ALGs, or other externally reachable processing functions where operationally feasible and supported by vendor guidance.

·        Baseline expected appliance service-health, process restart, HA transition, failover, connection-reset, resource, and availability behavior so suspicious instability can be distinguished from routine operational conditions.

·        Review appliance-originated outbound traffic for rare destinations, newly observed destinations, unexpected protocols, raw-IP access, file retrieval, tunneling, or internal management-service access.

·        Rotate administrative credentials, API keys, certificate material, backend credentials, service credentials, and reused credentials when compromise cannot be ruled out.

·        Review downstream applications for authentication-flow disruption, session-routing changes, header manipulation, traffic mirroring, data exposure, connection loss, availability impact, or unauthorized backend access.

·        Use vulnerability scanning, public PoC awareness, KEV status, affected-version state, and vulnerable-feature configuration as prioritization inputs, not standalone proof of compromise.

·        Maintain ADC appliance, version, management exposure, API exposure, listener, protocol, traffic-processing function, virtual-service, backend-pool, certificate, route, policy, administrator, approved-source, approved-maintenance, approved-egress, HA, failover, and downstream-application inventories.

Non-Coverage Conditions

·        Activity limited to vulnerable-version status or presence of a vulnerable configuration without suspicious ADC-facing activity, appliance instability, execution, configuration, certificate, outbound, administrative, traffic-path, availability, or downstream-application evidence.

·        Scanner traffic, malformed requests, unusual protocol messages, or exploit-shaped input that does not align with appliance instability, command execution, configuration access, certificate access, outbound communication, administrative change, availability degradation, or downstream impact.

·        Generic command-injection, memory-corruption, malformed-packet, or protocol-anomaly activity with no ADC appliance, control surface, traffic-processing function, interface, listener, virtual service, source, configuration object, process or service, destination, or time-window linkage.

·        Isolated process crashes, service restarts, watchdog events, HA transitions, failover, resource exhaustion, connection resets, or availability degradation without suspicious ADC-facing activity or other evidence linking the event to exploitation.

·        Unrelated ADC, load balancer, reverse proxy, WAF, firewall, VPN, or management-plane vulnerabilities that do not involve observable ADC control-plane exploitation, traffic-processing exploitation, appliance instability linked to suspicious activity, command execution, configuration manipulation, certificate exposure, routing control, availability impact, or downstream application exposure.

·        Citrix identity or session disclosure, Cisco firewall-management-plane compromise, cPanel hosting-control-plane compromise, CMS exploitation, or other adjacent behavior unless the observable activity materially intersects this report's ADC control-plane, traffic-processing, appliance-impact, or application-delivery trust model.

·        Cloud-only, identity-only, database-only, certificate-only, downstream-application-only, or network-only anomalies without ADC appliance, source, interface, listener, protocol, path, API, configuration, process or service, identity, destination, or bounded time-window correlation.

·        Benign administrative maintenance, approved patching, approved certificate renewal, approved API automation, approved virtual-service or traffic-processing changes, approved backup activity, expected failover, approved vendor support, approved vulnerability validation, capacity-management events, or approved incident-response cleanup.

S25 Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

NDR / Network Behavioral Analytics is highly viable for this behavior family because the strongest observable pattern is not a single exploit string, CVE identifier, or product name. The strongest detection path is suspicious access to an exposed ADC, load balancer, reverse proxy, WAF-adjacent appliance, or traffic-management control plane followed by appliance instability, abnormal API behavior, configuration access, virtual-service or routing manipulation, certificate or TLS-object exposure, rare outbound communication, internal service access, or downstream application anomalies. NDR is especially valuable where appliance process telemetry is limited, sealed, vendor-managed, or unavailable, because it can correlate management/API request behavior, source enrichment, destination enrichment, egress baselines, appliance identity, virtual-service mappings, backend mappings, response patterns, and downstream traffic changes.

Rule

ADC Control-Plane Exploit Attempt Followed by Appliance Instability or Rare Egress

Rule Format

NDR / Network Behavioral Analytics sequence correlation rule.

Detection Purpose

Detect suspicious external, partner-originated, or unusual ADC management/API access followed by appliance instability, abnormal control-plane response behavior, or rare outbound communication from the ADC appliance. This rule is intended to identify behavior consistent with pre-authentication or weakly authenticated ADC control-plane exploitation, including Progress Kemp LoadMaster CVE-2026-8037-like activity where locally visible, without making the detection dependent on one vendor, endpoint path, proof-of-concept string, or CVE name.

Detection Logic

Identify suspicious requests to ADC management, API, administrative, diagnostic, authentication, telemetry, or configuration endpoints where the source is external, unfamiliar, newly seen, partner-reachable, automation-like, scanner-like, or outside approved administrative paths. Increase confidence when the request includes command-delimiter, shell-control, quote-manipulation, encoded, malformed JSON, oversized, authentication-bypass, abnormal API-parameter, or unusual method behavior. Promote the event only when it is followed within a bounded window by appliance instability, abnormal HTTP status sequencing, failed-to-success transitions, abnormal response-size changes, connection resets, watchdog or restart behavior where visible, or rare ADC-originated DNS, HTTP, HTTPS, SSH, SMTP, raw-IP, file-transfer, tunneling, or command-and-control-like communication.

Required Telemetry

·        ADC management/API logs, WAF logs, reverse-proxy logs, load-balancer logs, CDN logs, or gateway logs with request path, method, query-string, request-body metadata where available, source IP, forwarded source IP, user agent, status code, response size, request size, and timestamp.

·        NDR, DNS, proxy, firewall, NetFlow, VPC flow, data-center flow, or appliance network telemetry for ADC-originated outbound communication.

·        ADC appliance inventory, management-interface mapping, API exposure inventory, virtual-service mapping, backend-pool mapping, approved administrative source inventory, approved partner path inventory, and approved maintenance-window context.

·        Destination enrichment for first-seen status, domain age, ASN, geography, reputation, destination port, protocol, proxy action, and firewall action.

·        Approved egress baselines for vendor support, updates, licensing, monitoring, telemetry, DNS, NTP, syslog, backups, integrations, health checks, and downstream application paths.

Engineering Implementation Instructions

·        Deploy first in hunt mode to validate ADC asset mapping, management-interface identification, API endpoint preservation, request-path preservation, query-string preservation, forwarded-source extraction, and ADC-originated egress attribution.

·        Tune approved administrative networks, partner-reachable paths, vulnerability scanners, patch-validation sources, vendor support sources, monitoring systems, health checks, maintenance windows, and approved ADC egress destinations before alert promotion.

·        Correlate by ADC appliance, management interface, destination host, destination IP, forwarded source IP, source network, request path, API method, virtual service, backend pool, destination domain, destination IP, and bounded time window.

·        Treat suspicious management/API access alone as exploit-attempt evidence, not confirmed compromise.

·        Promote severity when suspicious access is followed by abnormal status sequencing, appliance instability, rare egress, internal service access, or repeated callbacks from the same ADC appliance.

·        Suppress events tied only to approved scanning, patch validation, vendor support, routine health checks, approved backup activity, or documented maintenance windows.

DRI Assessment

This rule has strong detection reliability because it anchors on a sequence of exposed control-plane access followed by instability or rare appliance-originated communication rather than a single endpoint, user agent, CVE string, or payload pattern. It remains resilient across comparable ADC, load balancer, reverse proxy, WAF-adjacent appliance, and traffic-management compromise scenarios where the initial exploit primitive differs but the operational behavior produces suspicious management/API access and post-access network effects. The main reliability constraint is the quality of ADC asset inventory, request-path logging, forwarded-source preservation, and egress attribution.

DRI

8.8

TCR Assessment

Operational TCR is strong where management/API logs, NDR telemetry, DNS, proxy, firewall, approved-source lookups, and approved-egress baselines are available. Full-Telemetry TCR improves when appliance system logs, configuration-change records, virtual-service mappings, backend mappings, and downstream application context can be joined to the same event sequence.

Operational TCR

8.4

Full-Telemetry TCR

9.1

Limitations

·        This rule cannot confirm command execution without appliance process, shell, diagnostic, system, or vendor log evidence.

·        Request-body loss, query-string redaction, NAT, CDN, proxy layering, or incomplete forwarded-source preservation may reduce source and payload confidence.

·        Rare egress may be caused by approved vendor support, update retrieval, license validation, monitoring, backup, troubleshooting, or incident-response activity if exceptions are incomplete.

·        Sealed, managed, virtual, or vendor-restricted ADC deployments may not expose enough appliance telemetry to distinguish exploit success from exploit attempt.

·        Vulnerable-version status, public PoC availability, scanner traffic, or KEV status must not be used as standalone compromise confirmation.

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support ADC asset mapping, management-interface awareness, API exposure awareness, URI and query-string preservation, request-body metadata where available, HTTP status sequencing, response-size baselining, source enrichment, destination enrichment, egress baselining, maintenance-window context, approved administrative-source context, virtual-service joins, backend-pool joins, appliance identity joins, and sequence logic.

LET ADC_EDGE_ASSETS =
ENV_PUBLIC_ADC_APPLIANCES
OR ENV_PARTNER_REACHABLE_ADC_APPLIANCES
OR ENV_EDGE_LOAD_BALANCERS
OR ENV_REVERSE_PROXY_APPLIANCES
OR ENV_WAF_ADJACENT_APPLIANCES
OR ENV_TRAFFIC_MANAGEMENT_APPLIANCES
OR ENV_ADC_VIRTUAL_APPLIANCES
OR ENV_ADC_CLOUD_HOSTED_ASSETS
OR ENV_ADC_MANAGED_SERVICE_ASSETS

LET ADC_MANAGEMENT_OR_API_SURFACES =
ENV_ADC_MANAGEMENT_PATHS
OR ENV_ADC_API_PATHS
OR ENV_ADC_ADMINISTRATIVE_PATHS
OR ENV_ADC_AUTHENTICATION_PATHS
OR ENV_ADC_DIAGNOSTIC_PATHS
OR ENV_ADC_TELEMETRY_PATHS
OR ENV_ADC_CONFIGURATION_PATHS
OR ENV_ADC_CONTROL_PLANE_PATHS
OR ENV_PROGRESS_KEMP_LOADMASTER_API_PATHS
OR ENV_LOADMASTER_ACCESSV2_PATHS

LET APPROVED_ADC_SOURCE_EXCEPTIONS =
ENV_APPROVED_ADC_ADMIN_SOURCES
OR ENV_APPROVED_ADC_VPN_SOURCES
OR ENV_APPROVED_ADC_PRIVILEGED_ACCESS_SOURCES
OR ENV_APPROVED_ADC_PARTNER_ADMIN_SOURCES
OR ENV_APPROVED_ADC_SCANNERS
OR ENV_APPROVED_ADC_PATCH_VALIDATION_SOURCES
OR ENV_APPROVED_VENDOR_SUPPORT_SOURCES
OR ENV_APPROVED_ADC_MONITORING_SOURCES
OR ENV_APPROVED_ADC_AUTOMATION_SOURCES

LET APPROVED_ADC_CONTEXT_EXCEPTIONS =
ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
OR ENV_APPROVED_ADC_CHANGE_WINDOWS
OR ENV_APPROVED_ADC_PATCH_WINDOWS
OR ENV_APPROVED_ADC_CERTIFICATE_ROTATION_WINDOWS
OR ENV_APPROVED_ADC_FAILOVER_TEST_WINDOWS
OR ENV_APPROVED_ADC_BACKUP_WINDOWS
OR ENV_APPROVED_ADC_VENDOR_SUPPORT_WINDOWS
OR ENV_APPROVED_ADC_INCIDENT_RESPONSE_WINDOWS

LET ADC_CONTROL_PLANE_EXPLOIT_PATTERNS =
ENV_COMMAND_DELIMITER_PATTERNS
OR ENV_SHELL_CONTROL_PATTERNS
OR ENV_QUOTE_MANIPULATION_PATTERNS
OR ENV_ENCODED_COMMAND_PATTERNS
OR ENV_MALFORMED_JSON_PATTERNS
OR ENV_OVERSIZED_API_FIELD_PATTERNS
OR ENV_HEAP_SHAPING_REQUEST_PATTERNS
OR ENV_AUTHENTICATION_BYPASS_PATTERNS
OR ENV_API_PARAMETER_MANIPULATION_PATTERNS
OR ENV_UNUSUAL_ADC_API_METHOD_PATTERNS

LET APPROVED_ADC_EGRESS =
ENV_APPROVED_ADC_VENDOR_SUPPORT_DESTINATIONS
OR ENV_APPROVED_ADC_UPDATE_DESTINATIONS
OR ENV_APPROVED_ADC_LICENSE_DESTINATIONS
OR ENV_APPROVED_ADC_MONITORING_DESTINATIONS
OR ENV_APPROVED_ADC_TELEMETRY_DESTINATIONS
OR ENV_APPROVED_ADC_DNS_DESTINATIONS
OR ENV_APPROVED_ADC_NTP_DESTINATIONS
OR ENV_APPROVED_ADC_SYSLOG_DESTINATIONS
OR ENV_APPROVED_ADC_BACKUP_DESTINATIONS
OR ENV_APPROVED_ADC_HEALTH_CHECK_DESTINATIONS
OR ENV_APPROVED_ADC_INTEGRATION_DESTINATIONS
OR ENV_APPROVED_BUSINESS_DOMAINS

LET suspicious_adc_control_plane_request =
network_or_gateway_events
WHERE destination_host IN ADC_EDGE_ASSETS
AND request_path MATCHES_ANY ADC_MANAGEMENT_OR_API_SURFACES
AND source_ip NOT IN APPROVED_ADC_SOURCE_EXCEPTIONS
AND event_time NOT IN APPROVED_ADC_CONTEXT_EXCEPTIONS
AND (
source_first_seen_status IN ("new", "rare")
OR source_asn IN ENV_SUSPICIOUS_ASNS
OR source_network_type IN ("cloud_hosted", "residential_proxy", "vpn_provider", "scanner_infrastructure", "unknown_hosting")
OR source_geo NOT IN ENV_ADC_EXPECTED_ADMIN_SOURCE_GEOS
OR forwarded_source_ip NOT IN ENV_APPROVED_FORWARDED_ADMIN_SOURCES
OR user_agent IN ENV_RARE_OR_AUTOMATED_USER_AGENTS
OR request_method NOT IN ENV_EXPECTED_ADC_MANAGEMENT_METHODS
OR request_path MATCHES_ANY ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR request_query MATCHES_ANY ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR request_body_metadata MATCHES_ANY ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR content_type IN ("application/json", "application/octet-stream", "multipart/form-data", "text/plain", "unknown")
OR request_size > ENV_ADC_MANAGEMENT_REQUEST_SIZE_UPPER_BASELINE
OR response_size > ENV_ADC_MANAGEMENT_RESPONSE_SIZE_UPPER_BASELINE
OR response_size < ENV_ADC_MANAGEMENT_RESPONSE_SIZE_LOWER_BASELINE
OR request_timing_pattern IN ("rapid_retry", "automation_like", "low_and_slow_probe", "failed_then_successful_access", "parameter_fuzzing")
OR http_status_sequence IN ("repeated_errors", "errors_then_success", "failed_then_success", "abnormal_redirect_sequence", "control_plane_instability_sequence")
)

LET adc_appliance_instability_or_abnormal_response =
network_or_gateway_events
WHERE destination_host IN ADC_EDGE_ASSETS
AND (
request_path MATCHES_ANY ADC_MANAGEMENT_OR_API_SURFACES
OR destination_service IN ENV_ADC_MANAGEMENT_SERVICES
OR destination_interface IN ENV_ADC_MANAGEMENT_INTERFACES
)
AND event_time NOT IN APPROVED_ADC_CONTEXT_EXCEPTIONS
AND (
http_status IN (400, 401, 403, 404, 500, 502, 503, 504)
OR connection_state IN ("timeout", "reset", "closed_after_error", "service_unavailable")
OR response_size_delta > ENV_ADC_RESPONSE_SIZE_DELTA_UPPER_BASELINE
OR response_size_delta < ENV_ADC_RESPONSE_SIZE_DELTA_LOWER_BASELINE
OR http_status_sequence IN ("repeated_errors", "errors_then_success", "failed_then_success", "success_then_reset", "instability_after_api_access")
OR request_timing_pattern IN ("retry_after_error", "short_burst_after_failure", "single_probe_then_repeat", "automation_like")
OR appliance_health_event IN ("watchdog_restart", "service_restart", "management_service_fault", "api_handler_exception", "authentication_handler_error", "failover_event", "resource_exhaustion")
)

LET rare_adc_appliance_egress =
dns_proxy_firewall_or_ndr_events
WHERE (
source_host IN ADC_EDGE_ASSETS
OR source_ip IN ADC_EDGE_ASSETS
OR source_asset_id IN ADC_EDGE_ASSETS
OR source_workload_identity IN ADC_EDGE_ASSETS
OR source_interface IN ENV_ADC_APPLIANCE_INTERFACES
)
AND (
destination_domain IS NOT NULL
OR destination_ip IS NOT NULL
)
AND (
destination_domain IS NULL
OR destination_domain NOT IN APPROVED_ADC_EGRESS
)
AND (
destination_ip IS NULL
OR destination_ip NOT IN APPROVED_ADC_EGRESS
)
AND event_time NOT IN APPROVED_ADC_CONTEXT_EXCEPTIONS
AND (
destination_first_seen_status IN ("new", "rare")
OR destination_domain_age_days < ENV_NEW_DOMAIN_AGE_DAYS
OR destination_reputation IN ("unknown", "suspicious", "malicious")
OR destination_asn IN ENV_SUSPICIOUS_ASNS
OR destination_geo NOT IN ENV_ADC_EXPECTED_EGRESS_GEOS
OR destination_port IN ENV_UNUSUAL_ADC_EGRESS_PORTS
OR protocol IN ("ssh", "smtp", "raw_ip", "unknown", "tunnel", "file_transfer")
OR proxy_action IN ("allowed", "proxied", "connected")
OR firewall_action IN ("allowed", "connected")
OR ndr_behavior IN ("callback_like", "beacon_like", "tool_retrieval_like", "unusual_internal_service_access", "rare_external_connection")
)

SEQUENCE suspicious_adc_control_plane_request THEN adc_appliance_instability_or_abnormal_response
WHERE (
same_destination_host = true
OR same_destination_ip = true
OR same_adc_asset_id = true
OR same_management_interface = true
OR same_virtual_service = true
OR same_backend_pool = true
)
AND (
same_source_ip = true
OR same_forwarded_source_ip = true
OR same_source_network = true
OR same_request_path_family = true
OR same_api_method = true
)
WITHIN ENV_ADC_CONTROL_PLANE_ACCESS_TO_INSTABILITY_WINDOW

OR

SEQUENCE suspicious_adc_control_plane_request THEN rare_adc_appliance_egress
WHERE (
same_destination_host = true
OR same_destination_ip = true
OR same_adc_asset_id = true
OR same_management_interface = true
OR same_virtual_service = true
OR same_backend_pool = true
OR same_workload_identity = true
)
WITHIN ENV_ADC_CONTROL_PLANE_ACCESS_TO_EGRESS_WINDOW

OUTPUT
adc_asset_id,
adc_asset_name,
destination_host,
destination_ip,
management_interface,
virtual_service,
backend_pool,
backend_host,
request_path,
request_query,
request_method,
api_method,
source_ip,
forwarded_source_ip,
source_asn,
source_geo,
source_network_type,
user_agent,
content_type,
request_size,
response_size,
response_size_delta,
http_status,
http_status_sequence,
request_timing_pattern,
connection_state,
appliance_health_event,
egress_destination_domain,
egress_destination_ip,
egress_destination_port,
egress_destination_protocol,
egress_destination_reputation,
egress_destination_domain_age_days,
proxy_action,
firewall_action,
ndr_behavior,
first_seen,
last_seen,
time_delta

Rule

ADC Control-Plane Access Followed by Configuration, Certificate, or Traffic-Path Manipulation

Rule Format

NDR / Network Behavioral Analytics sequence correlation rule.

Detection Purpose

Detect suspicious ADC management/API access followed by evidence of configuration exposure, virtual-service manipulation, routing or header-control changes, TLS or certificate-object exposure, backup or diagnostic artifact access, or downstream traffic-path changes. This rule is intended to identify post-exploitation behavior that affects the edge application-delivery trust boundary rather than only the vulnerable appliance.

Detection Logic

Identify suspicious ADC management/API access from external, unfamiliar, partner-originated, or non-administrative sources. Correlate that activity with subsequent access to or change in virtual services, backend pools, listener ports, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, health checks, SSL/TLS offload settings, certificate bindings, configuration exports, backup archives, diagnostic bundles, packet captures, administrative settings, API keys, authentication templates, or logging settings. Increase confidence when downstream application logs show unexpected backend access, authentication-flow disruption, session-routing change, header manipulation, TLS termination change, traffic mirroring, data exposure, or availability degradation after the suspicious ADC activity.

Required Telemetry

·        ADC management/API, WAF, reverse-proxy, CDN, load-balancer, gateway, and downstream application logs with request path, method, source IP, forwarded source IP, virtual service, backend host, backend IP, status code, response size, request size, and timestamp.

·        ADC configuration-change telemetry, configuration export records, backup comparison data, administrative audit logs, certificate-management records, virtual-service inventory, backend-pool inventory, route inventory, rewrite-rule inventory, header-rule inventory, health-check inventory, and TLS binding inventory where available.

·        NDR, DNS, proxy, firewall, and flow telemetry for ADC-to-backend, ADC-to-management, ADC-to-certificate, ADC-to-storage, ADC-to-backup, and ADC-to-downstream application paths.

·        SIEM, ITSM, change-management, vendor-support, and maintenance-window context to separate approved activity from suspicious control-plane changes.

·        Asset joins connecting ADC appliance, management interface, virtual service, backend pool, downstream application, certificate object, route object, and administrative identity where available.

Engineering Implementation Instructions

·        Deploy in hunt mode until ADC configuration objects, virtual services, backend pools, certificate bindings, management interfaces, and downstream application mappings are validated.

·        Require sequence correlation before promoting to alert mode.

·        Correlate suspicious access to configuration, certificate, or traffic-path behavior by ADC appliance, management interface, API endpoint, source IP, forwarded source IP, administrative identity where available, configuration object, certificate object, virtual service, backend pool, downstream application, and bounded time window.

·        Suppress known-good certificate rotations, approved virtual-service changes, approved backend-pool changes, approved health-check tuning, approved backup jobs, approved diagnostic bundle creation, approved vendor support, approved failover testing, and approved emergency maintenance.

·        Treat downstream application anomalies as ADC-related only when they follow suspicious ADC control-plane behavior and align by virtual service, backend host, routing path, header pattern, source path, or time window.

·        Escalate when certificate or private-key exposure, backup export, diagnostic bundle creation, logging degradation, administrative-control change, or downstream application exposure occurs after suspicious management/API access.

DRI Assessment

This rule has high detection reliability because it focuses on protected trust-boundary changes that are difficult to explain through exploit scanning alone. The detection model remains useful across Progress Kemp LoadMaster and comparable ADC, load balancer, reverse proxy, WAF-adjacent, and traffic-management appliance compromise scenarios because it anchors on configuration, certificate, routing, and downstream traffic-path consequences rather than a single vulnerable endpoint. Reliability depends on configuration visibility, object normalization, virtual-service mapping, and change-management context.

DRI

8.7

TCR Assessment

Operational TCR is strong when ADC management/API logs, configuration-change records, WAF or reverse-proxy logs, NDR telemetry, and change-management records are available. Full-Telemetry TCR is highest when certificate-management records, backup comparison, administrative audit logs, downstream application logs, and virtual-service-to-backend mappings can be joined.

Operational TCR

8.2

Full-Telemetry TCR

9.0

Limitations

·        This rule may miss configuration or certificate access if the ADC appliance does not log object-level reads, exports, or administrative API actions.

·        Backup exports, diagnostic bundles, certificate rotations, emergency routing changes, failover testing, and vendor support can resemble suspicious behavior without accurate maintenance context.

·        Downstream application anomalies cannot be attributed to ADC compromise without linkage to ADC appliance, virtual service, backend mapping, request path, source, administrative action, or time window.

·        Configuration export timestamps may reflect backup, migration, restoration, failover, or maintenance rather than the original attacker action.

·        Network telemetry may show traffic-path changes without revealing the exact ADC configuration object that caused them.

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support ADC asset mapping, configuration-object awareness, virtual-service awareness, backend-pool mapping, certificate-object mapping, TLS-offload mapping, request-path preservation, source enrichment, downstream application joins, change-window context, approved administrative-source context, route and header behavior matching, and sequence logic.

LET ADC_EDGE_ASSETS =
ENV_PUBLIC_ADC_APPLIANCES
OR ENV_PARTNER_REACHABLE_ADC_APPLIANCES
OR ENV_EDGE_LOAD_BALANCERS
OR ENV_REVERSE_PROXY_APPLIANCES
OR ENV_WAF_ADJACENT_APPLIANCES
OR ENV_TRAFFIC_MANAGEMENT_APPLIANCES
OR ENV_ADC_VIRTUAL_APPLIANCES
OR ENV_ADC_CLOUD_HOSTED_ASSETS
OR ENV_ADC_MANAGED_SERVICE_ASSETS

LET ADC_MANAGEMENT_OR_API_SURFACES =
ENV_ADC_MANAGEMENT_PATHS
OR ENV_ADC_API_PATHS
OR ENV_ADC_ADMINISTRATIVE_PATHS
OR ENV_ADC_AUTHENTICATION_PATHS
OR ENV_ADC_DIAGNOSTIC_PATHS
OR ENV_ADC_TELEMETRY_PATHS
OR ENV_ADC_CONFIGURATION_PATHS
OR ENV_ADC_CONTROL_PLANE_PATHS
OR ENV_PROGRESS_KEMP_LOADMASTER_API_PATHS
OR ENV_LOADMASTER_ACCESSV2_PATHS

LET ADC_PROTECTED_CONFIGURATION_OBJECTS =
ENV_ADC_CONFIGURATION_EXPORT_OBJECTS
OR ENV_ADC_BACKUP_OBJECTS
OR ENV_ADC_DIAGNOSTIC_BUNDLE_OBJECTS
OR ENV_ADC_PACKET_CAPTURE_OBJECTS
OR ENV_ADC_VIRTUAL_SERVICE_OBJECTS
OR ENV_ADC_REAL_SERVER_POOL_OBJECTS
OR ENV_ADC_BACKEND_POOL_OBJECTS
OR ENV_ADC_LISTENER_OBJECTS
OR ENV_ADC_ROUTING_RULE_OBJECTS
OR ENV_ADC_REWRITE_RULE_OBJECTS
OR ENV_ADC_HEADER_RULE_OBJECTS
OR ENV_ADC_CONTENT_SWITCHING_OBJECTS
OR ENV_ADC_PERSISTENCE_PROFILE_OBJECTS
OR ENV_ADC_HEALTH_CHECK_OBJECTS
OR ENV_ADC_WAF_POLICY_OBJECTS
OR ENV_ADC_PROXY_POLICY_OBJECTS
OR ENV_ADC_AUTHENTICATION_TEMPLATE_OBJECTS
OR ENV_ADC_LOGGING_SETTING_OBJECTS
OR ENV_ADC_ADMINISTRATIVE_SETTING_OBJECTS

LET ADC_CERTIFICATE_AND_TLS_OBJECTS =
ENV_ADC_CERTIFICATE_OBJECTS
OR ENV_ADC_PRIVATE_KEY_OBJECTS
OR ENV_ADC_KEYSTORE_OBJECTS
OR ENV_ADC_TLS_OFFLOAD_OBJECTS
OR ENV_ADC_CERTIFICATE_BINDING_OBJECTS
OR ENV_ADC_SAML_MATERIAL_OBJECTS
OR ENV_ADC_OIDC_MATERIAL_OBJECTS
OR ENV_ADC_API_TOKEN_OBJECTS
OR ENV_ADC_CREDENTIAL_BEARING_OBJECTS

LET APPROVED_ADC_SOURCE_EXCEPTIONS =
ENV_APPROVED_ADC_ADMIN_SOURCES
OR ENV_APPROVED_ADC_VPN_SOURCES
OR ENV_APPROVED_ADC_PRIVILEGED_ACCESS_SOURCES
OR ENV_APPROVED_ADC_PARTNER_ADMIN_SOURCES
OR ENV_APPROVED_ADC_SCANNERS
OR ENV_APPROVED_ADC_PATCH_VALIDATION_SOURCES
OR ENV_APPROVED_VENDOR_SUPPORT_SOURCES
OR ENV_APPROVED_ADC_MONITORING_SOURCES
OR ENV_APPROVED_ADC_AUTOMATION_SOURCES

LET APPROVED_ADC_CONTEXT_EXCEPTIONS =
ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
OR ENV_APPROVED_ADC_CHANGE_WINDOWS
OR ENV_APPROVED_ADC_PATCH_WINDOWS
OR ENV_APPROVED_ADC_CERTIFICATE_ROTATION_WINDOWS
OR ENV_APPROVED_ADC_FAILOVER_TEST_WINDOWS
OR ENV_APPROVED_ADC_BACKUP_WINDOWS
OR ENV_APPROVED_ADC_VENDOR_SUPPORT_WINDOWS
OR ENV_APPROVED_ADC_INCIDENT_RESPONSE_WINDOWS

LET APPROVED_ADC_TRAFFIC_PATH_CHANGES =
ENV_APPROVED_ADC_VIRTUAL_SERVICE_CHANGES
OR ENV_APPROVED_ADC_BACKEND_POOL_CHANGES
OR ENV_APPROVED_ADC_ROUTING_CHANGES
OR ENV_APPROVED_ADC_REWRITE_CHANGES
OR ENV_APPROVED_ADC_HEADER_RULE_CHANGES
OR ENV_APPROVED_ADC_CERTIFICATE_BINDING_CHANGES
OR ENV_APPROVED_ADC_HEALTH_CHECK_CHANGES
OR ENV_APPROVED_ADC_PERSISTENCE_PROFILE_CHANGES
OR ENV_APPROVED_ADC_WAF_POLICY_CHANGES
OR ENV_APPROVED_ADC_PROXY_POLICY_CHANGES

LET suspicious_adc_control_plane_request =
network_or_gateway_events
WHERE destination_host IN ADC_EDGE_ASSETS
AND request_path MATCHES_ANY ADC_MANAGEMENT_OR_API_SURFACES
AND source_ip NOT IN APPROVED_ADC_SOURCE_EXCEPTIONS
AND event_time NOT IN APPROVED_ADC_CONTEXT_EXCEPTIONS
AND (
source_first_seen_status IN ("new", "rare")
OR source_asn IN ENV_SUSPICIOUS_ASNS
OR source_network_type IN ("cloud_hosted", "residential_proxy", "vpn_provider", "scanner_infrastructure", "unknown_hosting")
OR source_geo NOT IN ENV_ADC_EXPECTED_ADMIN_SOURCE_GEOS
OR forwarded_source_ip NOT IN ENV_APPROVED_FORWARDED_ADMIN_SOURCES
OR user_agent IN ENV_RARE_OR_AUTOMATED_USER_AGENTS
OR request_method NOT IN ENV_EXPECTED_ADC_MANAGEMENT_METHODS
OR request_path MATCHES_ANY ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR request_query MATCHES_ANY ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR request_body_metadata MATCHES_ANY ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR request_timing_pattern IN ("rapid_retry", "automation_like", "low_and_slow_probe", "failed_then_successful_access", "parameter_fuzzing")
OR http_status_sequence IN ("repeated_errors", "errors_then_success", "failed_then_success", "abnormal_redirect_sequence", "control_plane_instability_sequence")
)

LET adc_configuration_or_certificate_access =
network_configuration_audit_or_ndr_events
WHERE (
asset_id IN ADC_EDGE_ASSETS
OR destination_host IN ADC_EDGE_ASSETS
OR source_host IN ADC_EDGE_ASSETS
OR source_asset_id IN ADC_EDGE_ASSETS
)
AND event_time NOT IN APPROVED_ADC_CONTEXT_EXCEPTIONS
AND (
configuration_object MATCHES_ANY ADC_PROTECTED_CONFIGURATION_OBJECTS
OR certificate_object MATCHES_ANY ADC_CERTIFICATE_AND_TLS_OBJECTS
OR request_path MATCHES_ANY ADC_PROTECTED_CONFIGURATION_OBJECTS
OR request_path MATCHES_ANY ADC_CERTIFICATE_AND_TLS_OBJECTS
OR file_object MATCHES_ANY ADC_PROTECTED_CONFIGURATION_OBJECTS
OR file_object MATCHES_ANY ADC_CERTIFICATE_AND_TLS_OBJECTS
)
AND (
action IN ("read", "export", "download", "create", "modify", "delete", "replace", "bind", "unbind", "backup", "diagnostic_bundle_created", "packet_capture_created")
OR change_type IN ("virtual_service_modified", "backend_pool_modified", "routing_rule_modified", "rewrite_rule_modified", "header_rule_modified", "certificate_binding_modified", "tls_offload_modified", "logging_setting_modified", "administrative_setting_modified")
OR object_first_seen_status IN ("new", "rare")
OR object_change_source NOT IN ENV_APPROVED_ADC_CHANGE_ACTORS
)

LET downstream_traffic_path_anomaly =
network_or_gateway_events
WHERE (
adc_asset_id IN ADC_EDGE_ASSETS
OR upstream_proxy_asset IN ADC_EDGE_ASSETS
OR destination_virtual_service IN ENV_ADC_VIRTUAL_SERVICES
OR backend_host IN ENV_ADC_BACKEND_HOSTS
OR backend_pool IN ENV_ADC_BACKEND_POOLS
)
AND event_time NOT IN APPROVED_ADC_CONTEXT_EXCEPTIONS
AND event_id NOT IN APPROVED_ADC_TRAFFIC_PATH_CHANGES
AND (
backend_access_pattern IN ("new_backend_path", "rare_backend_path", "unexpected_backend_service", "unexpected_internal_service")
OR header_behavior IN ("new_header_added", "header_removed", "header_rewritten", "forwarded_for_anomaly", "host_header_anomaly")
OR session_routing_behavior IN ("new_affinity_pattern", "unexpected_route", "unexpected_backend_selection", "traffic_mirroring_suspected")
OR authentication_flow_behavior IN ("unexpected_redirect", "unexpected_bypass_pattern", "identity_provider_flow_change", "session_cookie_change")
OR tls_behavior IN ("certificate_binding_change", "tls_termination_change", "unexpected_plaintext_backend_flow", "unexpected_tls_offload_path")
OR response_behavior IN ("abnormal_response_size", "new_error_pattern", "availability_degradation", "data_exposure_like_response")
)

SEQUENCE suspicious_adc_control_plane_request THEN adc_configuration_or_certificate_access
WHERE (
same_destination_host = true
OR same_destination_ip = true
OR same_adc_asset_id = true
OR same_management_interface = true
OR same_virtual_service = true
OR same_backend_pool = true
)
AND (
same_source_ip = true
OR same_forwarded_source_ip = true
OR same_source_network = true
OR same_administrative_identity = true
OR same_api_method = true
OR same_configuration_object_family = true
OR same_certificate_object_family = true
)
WITHIN ENV_ADC_CONTROL_PLANE_ACCESS_TO_CONFIGURATION_WINDOW

OR

SEQUENCE suspicious_adc_control_plane_request THEN downstream_traffic_path_anomaly
WHERE (
same_adc_asset_id = true
OR same_virtual_service = true
OR same_backend_pool = true
OR same_backend_host = true
OR same_application_id = true
OR same_route_family = true
)
WITHIN ENV_ADC_CONTROL_PLANE_ACCESS_TO_DOWNSTREAM_IMPACT_WINDOW

OUTPUT
adc_asset_id,
adc_asset_name,
destination_host,
destination_ip,
management_interface,
virtual_service,
backend_pool,
backend_host,
backend_ip,
application_id,
request_path,
request_query,
request_method,
api_method,
source_ip,
forwarded_source_ip,
source_asn,
source_geo,
source_network_type,
user_agent,
http_status,
http_status_sequence,
configuration_object,
certificate_object,
file_object,
action,
change_type,
object_first_seen_status,
object_change_source,
backend_access_pattern,
header_behavior,
session_routing_behavior,
authentication_flow_behavior,
tls_behavior,
response_behavior,
first_seen,
last_seen,
time_delta

Rule

Multiple ADC Appliances Showing Related Control-Plane Probing, Post-Access Network Behavior, or Downstream Exposure

Rule Format

NDR / Network Behavioral Analytics campaign-correlation rule.

Detection Purpose

Detect campaign-like activity across multiple ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management appliances where similar control-plane probing, exploit-attempt behavior, appliance egress, configuration-access behavior, or downstream application anomalies appear within a bounded time window. This rule is intended to identify broader exploitation attempts or coordinated exposure review activity without assuming confirmed compromise from scanner traffic alone.

Detection Logic

Identify two or more ADC or edge traffic-management assets showing related suspicious management/API access from the same source, source network, ASN, infrastructure type, user agent, request-path family, API-method family, parameter pattern, timing pattern, or payload family. Promote confidence when at least one affected appliance also shows abnormal response sequencing, appliance instability, rare egress, configuration or certificate-object access, virtual-service or backend-pool change, administrative-control change, or downstream traffic-path anomaly. Treat multi-appliance request activity without post-access behavior as campaign exposure or exploit-attempt evidence, not confirmed compromise.

Required Telemetry

·        NDR, WAF, CDN, reverse-proxy, load-balancer, gateway, firewall, DNS, proxy, and flow telemetry across ADC and edge traffic-management assets.

·        ADC appliance inventory, internet-exposure inventory, partner-reachable path inventory, management-interface inventory, API exposure inventory, virtual-service inventory, backend-pool inventory, and downstream application mapping.

·        Source enrichment for first-seen status, ASN, geography, network type, reputation, user agent, request cadence, scanner-like behavior, infrastructure clustering, and shared source-network patterns.

·        Destination and appliance enrichment for affected ADC role, environment, virtual service, backend mapping, exposure class, appliance group, region, business unit, and criticality.

·        Approved administrative sources, scanners, vendor support sources, patch-validation sources, monitoring sources, maintenance windows, and emergency-response windows.

Engineering Implementation Instructions

·        Deploy in hunt mode to validate multi-appliance correlation thresholds and prevent approved scanners, vendor support activity, monitoring checks, and patch validation from creating false campaign alerts.

·        Require at least two ADC or traffic-management assets before campaign-correlation logic triggers.

·        Require post-access behavior from at least one appliance before promoting beyond exploit-attempt or exposure-review confidence.

·        Correlate by source IP, forwarded source IP, source network, ASN, user agent, request-path family, API-method family, parameter pattern, request timing, destination appliance group, virtual-service family, backend-pool family, and bounded time window.

·        Prioritize production, internet-facing, partner-reachable, high-availability, authentication-fronting, TLS-terminating, and critical application-delivery appliances.

·        Suppress approved enterprise vulnerability scans, vendor advisories validation, patch-verification activity, synthetic monitoring, health checks, red-team activity, and documented incident-response sweeps.

DRI Assessment

This rule has strong detection reliability for identifying coordinated exploit-attempt behavior and campaign-like targeting, but compromise confidence depends on whether post-access behavior is present. Its value is highest when organizations operate multiple ADC appliances across production, staging, disaster-recovery, partner-facing, and cloud-hosted environments. The rule is resilient because it does not rely on a single endpoint or payload; it correlates infrastructure, request behavior, appliance grouping, and post-access effects.

DRI

8.4

TCR Assessment

Operational TCR is strong where NDR, WAF, CDN, reverse-proxy, load-balancer, firewall, DNS, proxy, and ADC inventory data are available across multiple appliances. Full-Telemetry TCR improves when configuration-change records, downstream application logs, certificate records, administrative audit logs, and appliance health events can be joined to the campaign sequence.

Operational TCR

8.1

Full-Telemetry TCR

8.8

Limitations

·        Multi-appliance probing may reflect approved scanning, vendor validation, monitoring, red-team activity, or emergency patch verification if exceptions are incomplete.

·        This rule should not claim confirmed compromise unless post-access appliance, configuration, certificate, egress, administrative, or downstream application evidence is present.

·        Organizations with only one ADC appliance may receive limited value from the campaign-correlation logic.

·        CDN, proxy, NAT, and shared partner networks may obscure true source identity and inflate source-clustering confidence.

·        Similar request paths across appliances may indicate broad exposure discovery rather than successful exploitation.

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support multi-appliance ADC asset grouping, exposure classification, source clustering, source enrichment, API path family matching, request-cadence analysis, response-sequence analysis, destination enrichment, virtual-service grouping, backend-pool grouping, approved scanner context, approved vendor-support context, maintenance-window context, rare egress joins, configuration-change joins, downstream application joins, and sequence logic.

LET ADC_EDGE_ASSETS =
ENV_PUBLIC_ADC_APPLIANCES
OR ENV_PARTNER_REACHABLE_ADC_APPLIANCES
OR ENV_EDGE_LOAD_BALANCERS
OR ENV_REVERSE_PROXY_APPLIANCES
OR ENV_WAF_ADJACENT_APPLIANCES
OR ENV_TRAFFIC_MANAGEMENT_APPLIANCES
OR ENV_ADC_VIRTUAL_APPLIANCES
OR ENV_ADC_CLOUD_HOSTED_ASSETS
OR ENV_ADC_MANAGED_SERVICE_ASSETS

LET ADC_ASSET_GROUPS =
ENV_ADC_PRODUCTION_GROUPS
OR ENV_ADC_STAGING_GROUPS
OR ENV_ADC_DISASTER_RECOVERY_GROUPS
OR ENV_ADC_PARTNER_FACING_GROUPS
OR ENV_ADC_INTERNET_FACING_GROUPS
OR ENV_ADC_AUTHENTICATION_FRONTING_GROUPS
OR ENV_ADC_TLS_TERMINATING_GROUPS
OR ENV_ADC_CRITICAL_APPLICATION_DELIVERY_GROUPS
OR ENV_ADC_REGIONAL_GROUPS
OR ENV_ADC_BUSINESS_UNIT_GROUPS

LET ADC_MANAGEMENT_OR_API_SURFACES =
ENV_ADC_MANAGEMENT_PATHS
OR ENV_ADC_API_PATHS
OR ENV_ADC_ADMINISTRATIVE_PATHS
OR ENV_ADC_AUTHENTICATION_PATHS
OR ENV_ADC_DIAGNOSTIC_PATHS
OR ENV_ADC_TELEMETRY_PATHS
OR ENV_ADC_CONFIGURATION_PATHS
OR ENV_ADC_CONTROL_PLANE_PATHS
OR ENV_PROGRESS_KEMP_LOADMASTER_API_PATHS
OR ENV_LOADMASTER_ACCESSV2_PATHS

LET APPROVED_ADC_SOURCE_EXCEPTIONS =
ENV_APPROVED_ADC_ADMIN_SOURCES
OR ENV_APPROVED_ADC_VPN_SOURCES
OR ENV_APPROVED_ADC_PRIVILEGED_ACCESS_SOURCES
OR ENV_APPROVED_ADC_PARTNER_ADMIN_SOURCES
OR ENV_APPROVED_ADC_SCANNERS
OR ENV_APPROVED_ADC_PATCH_VALIDATION_SOURCES
OR ENV_APPROVED_VENDOR_SUPPORT_SOURCES
OR ENV_APPROVED_ADC_MONITORING_SOURCES
OR ENV_APPROVED_ADC_AUTOMATION_SOURCES
OR ENV_APPROVED_RED_TEAM_SOURCES
OR ENV_APPROVED_INCIDENT_RESPONSE_SOURCES

LET APPROVED_ADC_CONTEXT_EXCEPTIONS =
ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
OR ENV_APPROVED_ADC_CHANGE_WINDOWS
OR ENV_APPROVED_ADC_PATCH_WINDOWS
OR ENV_APPROVED_ADC_CERTIFICATE_ROTATION_WINDOWS
OR ENV_APPROVED_ADC_FAILOVER_TEST_WINDOWS
OR ENV_APPROVED_ADC_BACKUP_WINDOWS
OR ENV_APPROVED_ADC_VENDOR_SUPPORT_WINDOWS
OR ENV_APPROVED_ADC_INCIDENT_RESPONSE_WINDOWS
OR ENV_APPROVED_RED_TEAM_WINDOWS

LET suspicious_adc_control_plane_probe =
network_or_gateway_events
WHERE destination_host IN ADC_EDGE_ASSETS
AND request_path MATCHES_ANY ADC_MANAGEMENT_OR_API_SURFACES
AND source_ip NOT IN APPROVED_ADC_SOURCE_EXCEPTIONS
AND event_time NOT IN APPROVED_ADC_CONTEXT_EXCEPTIONS
AND (
source_first_seen_status IN ("new", "rare")
OR source_asn IN ENV_SUSPICIOUS_ASNS
OR source_network_type IN ("cloud_hosted", "residential_proxy", "vpn_provider", "scanner_infrastructure", "unknown_hosting")
OR source_geo NOT IN ENV_ADC_EXPECTED_ADMIN_SOURCE_GEOS
OR forwarded_source_ip NOT IN ENV_APPROVED_FORWARDED_ADMIN_SOURCES
OR user_agent IN ENV_RARE_OR_AUTOMATED_USER_AGENTS
OR request_method NOT IN ENV_EXPECTED_ADC_MANAGEMENT_METHODS
OR request_path MATCHES_ANY ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR request_query MATCHES_ANY ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR request_body_metadata MATCHES_ANY ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR request_timing_pattern IN ("rapid_retry", "automation_like", "low_and_slow_probe", "failed_then_successful_access", "parameter_fuzzing")
OR http_status_sequence IN ("repeated_errors", "errors_then_success", "failed_then_success", "abnormal_redirect_sequence", "control_plane_instability_sequence")
)

LET multi_adc_related_probe_cluster =
suspicious_adc_control_plane_probe
GROUP BY source_ip, forwarded_source_ip, source_network, source_asn, user_agent, request_path_family, api_method_family, request_parameter_family, request_timing_pattern
WHERE distinct_adc_asset_count >= ENV_MULTI_ADC_MINIMUM_ASSET_COUNT
AND event_time_span <= ENV_MULTI_ADC_PROBE_CLUSTER_WINDOW
AND (
distinct_adc_asset_group_count >= ENV_MULTI_ADC_MINIMUM_GROUP_COUNT
OR distinct_exposure_class_count >= ENV_MULTI_ADC_MINIMUM_EXPOSURE_CLASS_COUNT
OR affected_asset_criticality IN ("high", "critical")
)

LET adc_post_access_behavior =
dns_proxy_firewall_ndr_configuration_or_gateway_events
WHERE (
source_host IN ADC_EDGE_ASSETS
OR source_ip IN ADC_EDGE_ASSETS
OR source_asset_id IN ADC_EDGE_ASSETS
OR destination_host IN ADC_EDGE_ASSETS
OR adc_asset_id IN ADC_EDGE_ASSETS
)
AND event_time NOT IN APPROVED_ADC_CONTEXT_EXCEPTIONS
AND (
destination_first_seen_status IN ("new", "rare")
OR destination_reputation IN ("unknown", "suspicious", "malicious")
OR destination_port IN ENV_UNUSUAL_ADC_EGRESS_PORTS
OR ndr_behavior IN ("callback_like", "beacon_like", "tool_retrieval_like", "unusual_internal_service_access", "rare_external_connection")
OR http_status_sequence IN ("instability_after_api_access", "failed_then_success", "success_then_reset")
OR appliance_health_event IN ("watchdog_restart", "service_restart", "management_service_fault", "api_handler_exception", "authentication_handler_error", "failover_event", "resource_exhaustion")
OR configuration_change_type IN ("virtual_service_modified", "backend_pool_modified", "routing_rule_modified", "rewrite_rule_modified", "header_rule_modified", "certificate_binding_modified", "tls_offload_modified", "logging_setting_modified", "administrative_setting_modified")
OR downstream_behavior IN ("unexpected_backend_access", "authentication_flow_change", "session_routing_change", "header_manipulation", "traffic_mirroring_suspected", "data_exposure_like_response", "availability_degradation")
)

SEQUENCE multi_adc_related_probe_cluster THEN adc_post_access_behavior
WHERE (
same_source_ip = true
OR same_forwarded_source_ip = true
OR same_source_network = true
OR same_source_asn = true
OR same_user_agent = true
OR same_request_path_family = true
OR same_api_method_family = true
OR same_request_parameter_family = true
)
AND (
affected_adc_asset_in_cluster = true
OR affected_adc_group_in_cluster = true
OR same_virtual_service_family = true
OR same_backend_pool_family = true
OR same_exposure_class = true
)
WITHIN ENV_MULTI_ADC_PROBE_TO_POST_ACCESS_WINDOW

OUTPUT
source_ip,
forwarded_source_ip,
source_network,
source_asn,
source_geo,
source_network_type,
user_agent,
request_path_family,
api_method_family,
request_parameter_family,
request_timing_pattern,
affected_adc_asset_count,
affected_adc_assets,
affected_adc_asset_groups,
affected_exposure_classes,
affected_virtual_services,
affected_backend_pools,
affected_asset_criticality,
http_status_sequence,
appliance_health_event,
configuration_change_type,
ndr_behavior,
downstream_behavior,
egress_destination_domain,
egress_destination_ip,
egress_destination_port,
destination_reputation,
first_seen,
last_seen,
time_delta

Rule

ADC Traffic-Processing Exploit Attempt Followed by Appliance Instability or Availability Impact

Rule Format

NDR / Network Behavioral Analytics sequence correlation rule.

Detection Purpose

Detect suspicious external, partner-originated, or otherwise unusual traffic directed at ADC listeners, virtual services, protocol handlers, NAT functions, ALGs, or other externally reachable traffic-processing functions followed by appliance instability, process or service failure, restart or failover behavior, resource exhaustion, abnormal connection behavior, or downstream availability degradation. This rule establishes the traffic-processing exploitation branch independently of ADC management/API access and supports CVE-2026-19489-like behavior where local SIP ALG, LSN, and appliance-health telemetry are available.

Detection Logic

Identify traffic directed at ADC traffic-processing surfaces where the source, protocol behavior, message or request size, transaction structure, cadence, connection behavior, or other locally normalized characteristics are inconsistent with established baselines or known-good application behavior. Increase confidence when activity is malformed, oversized, repeated, protocol-inconsistent, fuzzing-like, or otherwise exploit-shaped against an exposed listener, virtual service, protocol handler, NAT function, ALG, or related ADC processing function.

Promote only when suspicious traffic-processing activity is followed within a bounded window by materially independent appliance or application-delivery impact such as process or service crash, watchdog event, service restart, appliance reboot, unexpected HA transition, failover, resource exhaustion, abnormal reset or timeout behavior, service unavailability, or downstream application availability degradation. Management/API activity is not a prerequisite.

Required Telemetry

·        NDR, packet-metadata, flow, firewall, WAF, reverse-proxy, load-balancer, listener, virtual-service, gateway, or protocol telemetry identifying traffic delivered to ADC traffic-processing surfaces.

·        ADC asset inventory with traffic-facing interfaces, listeners, virtual services, expected protocols, processing functions, backend mappings, and exposure classification.

·        Appliance system, service-health, watchdog, restart, reboot, failover, HA, resource, diagnostic, and availability telemetry where available.

·        Source IP, destination IP, source port, destination port, protocol, listener, virtual service, appliance identity, interface, request or message size, connection state, transaction identifier where available, timestamp, and downstream application mapping.

·        Approved protocol, source, health-check, monitoring, failover-testing, maintenance, load-testing, and incident-response exceptions.

·        Where locally applicable, SIP signaling metadata, SIP ALG state, LSN configuration, LSN group mapping, and LSN-managed traffic-path mapping may be used for CVE-2026-19489-specific implementation.

Engineering Implementation Instructions

·        Deploy first in hunt mode and validate ADC traffic-facing asset identification, listener mapping, virtual-service mapping, protocol normalization, source attribution, appliance-health joins, and downstream availability mapping.

·        Establish normal protocol, message-size, request-rate, transaction, reset, timeout, failover, resource, restart, and service-health baselines before alert promotion.

·        Correlate by ADC asset, traffic-facing interface, listener, virtual service, protocol, processing function, source IP, destination IP, destination port, transaction or connection identifier where available, backend service, and bounded time window.

·        For CVE-2026-19489-specific deployment, map affected NetScaler assets, LSN groups, SIP ALG-enabled processing paths, SIP-facing addresses, and corresponding system-health or failover telemetry. Keep those mappings outside the durable core logic.

·        Treat suspicious or malformed traffic alone as exploit-attempt evidence.

·        Require an appliance-health, service-health, connection, HA, resource, or downstream availability consequence before promoting to high-confidence traffic-processing exploitation.

·        Suppress approved load testing, protocol-conformance testing, vulnerability validation, vendor support, health checks, HA testing, maintenance, and incident-response activity.

DRI Assessment

This rule has strong detection reliability because it requires suspicious traffic delivered to an identified ADC processing function to align with an independent appliance or application-delivery consequence. It avoids dependence on a specific CVE, protocol, vendor, parser, packet layout, or exploit string while remaining capable of supporting current SIP ALG/LSN exploitation scenarios. Reliability depends primarily on accurate traffic-facing asset mapping, protocol baselines, appliance-health visibility, and time-window correlation.

DRI

8.8

TCR Assessment

Operational TCR is strong where NDR or equivalent traffic metadata, ADC asset mapping, listener and virtual-service context, and basic appliance-health or availability telemetry are available. Full-Telemetry TCR improves substantially when protocol metadata, service-health logs, restart and failover records, resource telemetry, downstream application availability, and traffic-processing configuration are joined.

Operational TCR

8.5

Full-Telemetry TCR

9.2

Limitations

·        The rule may not identify the precise malformed field, parser condition, memory-corruption primitive, or vulnerable function when payload visibility is limited.

·        Protocol anomalies may represent malformed legitimate traffic, interoperability problems, stress conditions, or benign client defects.

·        Appliance crashes, restarts, HA transitions, failovers, and resource exhaustion may result from maintenance, capacity pressure, software defects, or hardware faults.

·        Encrypted or proprietary protocols may limit payload-level characterization.

·        NAT, proxying, load balancing, or intermediate infrastructure may reduce source attribution.

·        Suspicious traffic-processing activity without independent appliance or availability effects remains exploit-attempt evidence rather than confirmed compromise.

Detection Query Pattern

Use this pattern as an implementation guide for NDR platforms that support ADC asset mapping, listener and virtual-service awareness, protocol metadata, behavioral baselines, appliance-health enrichment, downstream availability context, approved operational exceptions, and sequence correlation.

LET ADC_EDGE_ASSETS =

    ENV_PUBLIC_ADC_APPLIANCES

    OR ENV_PARTNER_REACHABLE_ADC_APPLIANCES

    OR ENV_EDGE_LOAD_BALANCERS

    OR ENV_REVERSE_PROXY_APPLIANCES

    OR ENV_WAF_ADJACENT_APPLIANCES

    OR ENV_TRAFFIC_MANAGEMENT_APPLIANCES

    OR ENV_ADC_VIRTUAL_APPLIANCES

    OR ENV_ADC_CLOUD_HOSTED_ASSETS

    OR ENV_ADC_MANAGED_SERVICE_ASSETS

LET ADC_TRAFFIC_PROCESSING_SURFACES =

    ENV_ADC_PUBLIC_LISTENERS

    OR ENV_ADC_PARTNER_LISTENERS

    OR ENV_ADC_VIRTUAL_SERVICES

    OR ENV_ADC_PROTOCOL_HANDLERS

    OR ENV_ADC_NAT_PROCESSING_FUNCTIONS

    OR ENV_ADC_ALG_PROCESSING_FUNCTIONS

    OR ENV_ADC_TRAFFIC_MANAGEMENT_FUNCTIONS

    OR ENV_ADC_APPLICATION_PROTOCOL_SURFACES

LET APPROVED_ADC_TRAFFIC_CONTEXT =

    ENV_APPROVED_ADC_HEALTH_CHECK_SOURCES

    OR ENV_APPROVED_ADC_MONITORING_SOURCES

    OR ENV_APPROVED_ADC_LOAD_TEST_SOURCES

    OR ENV_APPROVED_ADC_PROTOCOL_TEST_SOURCES

    OR ENV_APPROVED_ADC_VULNERABILITY_VALIDATION_SOURCES

    OR ENV_APPROVED_VENDOR_SUPPORT_SOURCES

LET APPROVED_ADC_CONTEXT_WINDOWS =

    ENV_APPROVED_ADC_MAINTENANCE_WINDOWS

    OR ENV_APPROVED_ADC_FAILOVER_TEST_WINDOWS

    OR ENV_APPROVED_ADC_LOAD_TEST_WINDOWS

    OR ENV_APPROVED_ADC_VENDOR_SUPPORT_WINDOWS

    OR ENV_APPROVED_ADC_INCIDENT_RESPONSE_WINDOWS

LET suspicious_adc_traffic_processing_activity =

    network_protocol_or_ndr_events

    WHERE destination_asset IN ADC_EDGE_ASSETS

    AND (

        destination_listener IN ADC_TRAFFIC_PROCESSING_SURFACES

        OR virtual_service IN ADC_TRAFFIC_PROCESSING_SURFACES

        OR protocol_handler IN ADC_TRAFFIC_PROCESSING_SURFACES

        OR traffic_processing_function IN ADC_TRAFFIC_PROCESSING_SURFACES

    )

    AND source_ip NOT IN APPROVED_ADC_TRAFFIC_CONTEXT

    AND event_time NOT IN APPROVED_ADC_CONTEXT_WINDOWS

    AND (

        source_first_seen_status IN ("new", "rare")

        OR source_asn IN ENV_SUSPICIOUS_ASNS

        OR source_network_type IN ("cloud_hosted", "residential_proxy", "vpn_provider", "scanner_infrastructure", "unknown_hosting")

        OR protocol_behavior IN ("malformed", "protocol_inconsistent", "unexpected_sequence", "fuzzing_like", "abnormal_transaction")

        OR request_or_message_size > ENV_ADC_PROTOCOL_MESSAGE_SIZE_UPPER_BASELINE

        OR request_or_message_size < ENV_ADC_PROTOCOL_MESSAGE_SIZE_LOWER_BASELINE

        OR request_rate > ENV_ADC_PROTOCOL_REQUEST_RATE_UPPER_BASELINE

        OR connection_behavior IN ("rapid_retry", "repeated_invalid_request", "unexpected_disconnect", "abnormal_retransmission")

        OR payload_metadata MATCHES_ANY ENV_ADC_TRAFFIC_PROCESSING_EXPLOIT_PATTERNS

    )

LET adc_instability_or_availability_impact =

    appliance_health_network_or_application_events

    WHERE adc_asset_id IN ADC_EDGE_ASSETS

    AND event_time NOT IN APPROVED_ADC_CONTEXT_WINDOWS

    AND (

        appliance_health_event IN (

            "process_crash",

            "service_crash",

            "watchdog_restart",

            "service_restart",

            "appliance_reboot",

            "unexpected_failover",

            "ha_state_change",

            "resource_exhaustion",

            "resource_pressure",

            "traffic_processing_fault"

        )

        OR connection_state IN (

            "timeout",

            "reset",

            "closed_after_error",

            "service_unavailable"

        )

        OR downstream_behavior IN (

            "availability_degradation",

            "backend_connection_loss",

            "application_unreachable",

            "unexpected_failover",

            "traffic_path_disruption"

        )

    )

SEQUENCE suspicious_adc_traffic_processing_activity

THEN adc_instability_or_availability_impact

WHERE same_adc_asset_id = true

AND (

    same_listener = true

    OR same_virtual_service = true

    OR same_protocol = true

    OR same_traffic_processing_function = true

    OR same_destination_ip = true

)

WITHIN ENV_ADC_TRAFFIC_PROCESSING_TO_INSTABILITY_WINDOW

OUTPUT

    adc_asset_id,

    adc_asset_name,

    source_ip,

    source_asn,

    source_network_type,

    destination_ip,

    destination_port,

    traffic_facing_interface,

    listener,

    virtual_service,

    protocol,

    protocol_handler,

    traffic_processing_function,

    request_or_message_size,

    protocol_behavior,

    connection_behavior,

    appliance_health_event,

    downstream_behavior,

    first_seen,

    last_seen,

    time_delta

SentinelOne

Detection Viability Assessment

SentinelOne is conditionally viable for this behavior family. Strong SentinelOne coverage is possible where the ADC appliance, virtual appliance host, appliance-adjacent Linux layer, management host, jump host, cloud-hosted ADC workload, or downstream ADC-supporting workload is protected by endpoint telemetry. SentinelOne should not be treated as universally available for sealed, vendor-managed, hardware-only, or appliance-restricted ADC deployments. Where available, SentinelOne can detect appliance-context shell execution, diagnostic utility abuse, script execution, suspicious file access, certificate or key access, transfer-tool execution, archive creation, rare outbound communication, and command activity that follows suspicious ADC management/API behavior. ADC request, WAF, CDN, reverse-proxy, load-balancer, NDR, and downstream application correlation should occur in the SIEM, XDR, or downstream investigation workflow.

Rule

ADC Appliance or Support Host Suspicious Command Execution

Rule Format

SentinelOne Deep Visibility or STAR endpoint sequence logic.

Detection Purpose

Detect suspicious shell, script, diagnostic, transfer-tool, archive, package, discovery, credential-access, certificate-access, or network utility execution from ADC appliance context, ADC virtual appliance hosts, ADC management hosts, or ADC-supporting workloads. This rule is intended to identify appliance-level command execution or post-exploitation activity that may follow pre-authentication or weakly authenticated ADC control-plane exploitation, without relying on a single CVE name, endpoint path, proof-of-concept string, or vendor product name.

Detection Logic

Identify endpoint process activity on ADC appliances, virtual appliance hosts, ADC management hosts, jump hosts, or ADC-supporting workloads where ADC service users, appliance daemons, API handlers, diagnostic processes, management services, shell processes, script interpreters, transfer tools, archive tools, package-management tools, network utilities, discovery commands, credential-access commands, or certificate-access commands execute outside approved administrative, support, upgrade, backup, monitoring, patch-validation, or maintenance workflows. Increase confidence when suspicious command execution occurs from ADC service context, management-service context, diagnostic context, temporary paths, appliance configuration paths, certificate paths, backup paths, support-bundle paths, or unusual parent-process lineage.

Required Telemetry

·        SentinelOne endpoint tags identifying ADC appliances, ADC virtual appliance hosts, ADC management hosts, jump hosts, ADC-supporting Linux workloads, cloud-hosted ADC workloads, and downstream traffic-management support systems.

·        Process telemetry with process name, parent process name, process user, command line, executable path, current directory, process start time, process lineage, and hash where available.

·        File telemetry for ADC configuration files, backup archives, diagnostic bundles, packet captures, certificate stores, private keys, API token files, credential-bearing files, logs, temporary directories, scripts, packages, and appliance support artifacts.

·        Network telemetry for endpoint-originated DNS, HTTP, HTTPS, SSH, SMTP, raw-IP, file-transfer, tunneling, or command-and-control-like communication.

·        Approved user, process, command, script, diagnostic, backup, upgrade, monitoring, vendor-support, patch-validation, and maintenance-window exceptions.

·        SIEM, XDR, NDR, WAF, CDN, reverse-proxy, load-balancer, and ADC management/API context for upstream correlation.

Engineering Implementation Instructions

·        Deploy first in hunt mode on ADC-related endpoint groups before promoting to alert mode.

·        Tag ADC appliances, virtual appliance hosts, ADC management hosts, jump hosts, cloud-hosted ADC workloads, and ADC-supporting Linux workloads before enabling rule logic.

·        Baseline approved ADC service users, appliance daemons, management services, diagnostic utilities, vendor support tools, monitoring agents, backup tools, patch-validation tools, firmware-update workflows, certificate-renewal workflows, and administrative scripts.

·        Correlate suspicious endpoint activity with ADC management/API, WAF, NDR, reverse-proxy, CDN, load-balancer, SIEM, and downstream application telemetry outside the SentinelOne rule body.

·        Suppress approved vendor support, upgrades, backups, monitoring, certificate rotation, diagnostics, vulnerability validation, failover testing, and incident-response cleanup.

·        Promote severity when suspicious command execution is followed by sensitive file access, certificate or private-key access, archive creation, diagnostic bundle creation, transfer-tool execution, rare outbound communication, or log deletion.

DRI Assessment

This rule has moderate-to-strong detection reliability where SentinelOne telemetry is available on the ADC appliance host, virtual appliance host, or ADC-supporting workload. It is resilient because it focuses on appliance-context execution behavior rather than product-specific exploit strings. Reliability is reduced in sealed, vendor-managed, hardware-only, or appliance-restricted deployments where process telemetry is unavailable or incomplete.

DRI

8.1

TCR Assessment

Operational TCR is moderate because SentinelOne can provide strong process, file, and network telemetry only when endpoint coverage exists on relevant ADC-related systems. Full-Telemetry TCR improves when SentinelOne events are joined to ADC management/API logs, NDR telemetry, configuration-change records, certificate records, WAF logs, reverse-proxy logs, and downstream application evidence.

Operational TCR

7.6

Full-Telemetry TCR

8.6

Limitations

·        This rule is not viable for hardware-only, sealed, vendor-managed, or appliance-restricted ADC deployments that do not expose endpoint telemetry.

·        SentinelOne cannot independently prove pre-authentication ADC exploitation without ADC management/API, WAF, NDR, reverse-proxy, or SIEM correlation.

·        Legitimate vendor support, diagnostics, patching, failover testing, backup activity, certificate rotation, or emergency troubleshooting may resemble suspicious command execution.

·        Endpoint telemetry may not identify the original external source, API path, virtual service, backend pool, or exploit request that preceded command execution.

·        Suspicious command activity should be treated as compromise evidence only when aligned with ADC context, appliance role, process lineage, source behavior, file access, network activity, or bounded time-window correlation.

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne Deep Visibility or STAR logic that supports endpoint tags, process telemetry, parent-process telemetry, command-line telemetry, file telemetry, network telemetry, user context, process lineage, path mapping, approved workflow exceptions, and downstream SIEM or XDR enrichment. ADC management/API request, WAF, reverse-proxy, CDN, load-balancer, NDR, configuration-change, certificate-management, and downstream application correlation should occur in the SIEM, XDR, or downstream investigation workflow.

LET ADC_RELATED_ENDPOINTS =
EndpointTags CONTAINS ANY (
"ENV_ADC_APPLIANCES",
"ENV_ADC_VIRTUAL_APPLIANCE_HOSTS",
"ENV_ADC_MANAGEMENT_HOSTS",
"ENV_ADC_JUMP_HOSTS",
"ENV_ADC_SUPPORTING_LINUX_WORKLOADS",
"ENV_ADC_CLOUD_HOSTED_WORKLOADS",
"ENV_EDGE_LOAD_BALANCER_HOSTS",
"ENV_REVERSE_PROXY_HOSTS",
"ENV_WAF_ADJACENT_HOSTS",
"ENV_TRAFFIC_MANAGEMENT_HOSTS"
)

LET ADC_SERVICE_OR_MANAGEMENT_CONTEXT =
ProcessUser IN ENV_ADC_SERVICE_USERS
OR UserName IN ENV_ADC_SERVICE_USERS
OR ParentProcessName IN ENV_ADC_DAEMON_PROCESSES
OR ParentProcessName IN ENV_ADC_MANAGEMENT_PROCESSES
OR ParentProcessName IN ENV_ADC_API_HANDLER_PROCESSES
OR ParentProcessName IN ENV_ADC_DIAGNOSTIC_PROCESSES
OR ProcessName IN ENV_ADC_MANAGEMENT_PROCESSES
OR ProcessName IN ENV_ADC_DIAGNOSTIC_PROCESSES
OR CommandLine MATCHES ENV_ADC_RUNTIME_CONTEXT_PATTERNS

LET ADC_SENSITIVE_PATH_CONTEXT =
FilePath STARTS_WITH ANY (
ENV_ADC_CONFIGURATION_PATH_PREFIXES,
ENV_ADC_BACKUP_PATH_PREFIXES,
ENV_ADC_DIAGNOSTIC_BUNDLE_PATH_PREFIXES,
ENV_ADC_PACKET_CAPTURE_PATH_PREFIXES,
ENV_ADC_CERTIFICATE_STORE_PATH_PREFIXES,
ENV_ADC_PRIVATE_KEY_PATH_PREFIXES,
ENV_ADC_API_TOKEN_PATH_PREFIXES,
ENV_ADC_CREDENTIAL_FILE_PATH_PREFIXES,
ENV_ADC_LOG_PATH_PREFIXES,
ENV_ADC_TEMP_PATH_PREFIXES,
ENV_ADC_SCRIPT_PATH_PREFIXES,
ENV_ADC_PACKAGE_PATH_PREFIXES,
ENV_ADC_SUPPORT_ARTIFACT_PATH_PREFIXES
)

LET SUSPICIOUS_ADC_CHILD_PROCESS =
ADC_SERVICE_OR_MANAGEMENT_CONTEXT = true
AND (
ProcessName IN ENV_SHELL_INTERPRETERS
OR ProcessName IN ENV_SCRIPTING_INTERPRETERS
OR ProcessName IN ENV_TRANSFER_TOOLS
OR ProcessName IN ENV_ARCHIVE_TOOLS
OR ProcessName IN ENV_NETWORK_TOOLS
OR ProcessName IN ENV_DISCOVERY_TOOLS
OR ProcessName IN ENV_PACKAGE_MANAGEMENT_TOOLS
OR ProcessName IN ENV_ENCODING_OR_OBFUSCATION_TOOLS
OR CommandLine MATCHES ENV_ADC_SUSPICIOUS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_ADC_DISCOVERY_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_ADC_CREDENTIAL_ACCESS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_ADC_CERTIFICATE_ACCESS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_ADC_CONFIGURATION_ACCESS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_ADC_LOG_DELETION_COMMAND_PATTERNS
)

LET SUSPICIOUS_ADC_FILE_ACCESS =
ADC_SENSITIVE_PATH_CONTEXT = true
AND EventType IN (
"file_opened",
"file_read",
"file_created",
"file_modified",
"file_copied",
"file_archived",
"file_deleted",
"file_renamed",
"file_written"
)
AND (
FileName MATCHES ANY (
ENV_ADC_CONFIGURATION_FILE_PATTERNS,
ENV_ADC_BACKUP_FILE_PATTERNS,
ENV_ADC_DIAGNOSTIC_BUNDLE_PATTERNS,
ENV_ADC_PACKET_CAPTURE_PATTERNS,
ENV_ADC_CERTIFICATE_FILE_PATTERNS,
ENV_ADC_PRIVATE_KEY_FILE_PATTERNS,
ENV_ADC_API_TOKEN_FILE_PATTERNS,
ENV_ADC_CREDENTIAL_FILE_PATTERNS,
ENV_ADC_LOG_FILE_PATTERNS,
ENV_ADC_SCRIPT_FILE_PATTERNS,
ENV_ADC_PACKAGE_FILE_PATTERNS
)
OR FilePath MATCHES ANY (
ENV_ADC_CONFIGURATION_FILE_PATTERNS,
ENV_ADC_BACKUP_FILE_PATTERNS,
ENV_ADC_DIAGNOSTIC_BUNDLE_PATTERNS,
ENV_ADC_PACKET_CAPTURE_PATTERNS,
ENV_ADC_CERTIFICATE_FILE_PATTERNS,
ENV_ADC_PRIVATE_KEY_FILE_PATTERNS,
ENV_ADC_API_TOKEN_FILE_PATTERNS,
ENV_ADC_CREDENTIAL_FILE_PATTERNS,
ENV_ADC_LOG_FILE_PATTERNS,
ENV_ADC_SCRIPT_FILE_PATTERNS,
ENV_ADC_PACKAGE_FILE_PATTERNS
)
)

LET RARE_ADC_ENDPOINT_EGRESS =
(
DestinationHost IS NOT NULL
OR DestinationIp IS NOT NULL
)
AND (
DestinationHost IS NULL
OR DestinationHost NOT IN ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
AND (
DestinationIp IS NULL
OR DestinationIp NOT IN ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
AND (
DestinationFirstSeenStatus IN ("new", "rare")
OR DestinationDomainAgeDays < ENV_NEW_DOMAIN_AGE_DAYS
OR DestinationReputation IN ("unknown", "suspicious", "malicious")
OR DestinationAsn IN ENV_SUSPICIOUS_ASNS
OR DestinationGeo NOT IN ENV_ADC_EXPECTED_EGRESS_GEOS
OR DestinationPort IN ENV_UNUSUAL_ADC_EGRESS_PORTS
OR NetworkAction IN ("allowed", "connected", "proxied")
)

LET APPROVED_ADC_ENDPOINT_ACTIVITY =
UserName IN ENV_APPROVED_ADC_ADMIN_USERS
OR UserName IN ENV_APPROVED_ADC_BACKUP_USERS
OR UserName IN ENV_APPROVED_ADC_VENDOR_SUPPORT_USERS
OR UserName IN ENV_APPROVED_ADC_MONITORING_USERS
OR UserName IN ENV_APPROVED_ADC_PATCH_VALIDATION_USERS
OR ProcessName IN ENV_APPROVED_ADC_MANAGEMENT_TOOLS
OR ProcessName IN ENV_APPROVED_ADC_DIAGNOSTIC_TOOLS
OR ProcessName IN ENV_APPROVED_ADC_BACKUP_TOOLS
OR ProcessName IN ENV_APPROVED_ADC_MONITORING_TOOLS
OR ProcessName IN ENV_APPROVED_ADC_UPDATE_TOOLS
OR ProcessName IN ENV_APPROVED_ADC_SECURITY_TOOLS
OR CommandLine MATCHES ENV_APPROVED_ADC_COMMAND_PATTERNS
OR EventTime IN ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
OR EventTime IN ENV_APPROVED_ADC_CHANGE_WINDOWS
OR EventTime IN ENV_APPROVED_ADC_PATCH_WINDOWS
OR EventTime IN ENV_APPROVED_ADC_CERTIFICATE_ROTATION_WINDOWS
OR EventTime IN ENV_APPROVED_ADC_VENDOR_SUPPORT_WINDOWS
OR EventTime IN ENV_APPROVED_ADC_INCIDENT_RESPONSE_WINDOWS

FROM ProcessEvents OR FileEvents OR NetworkEvents
WHERE ADC_RELATED_ENDPOINTS = true
AND APPROVED_ADC_ENDPOINT_ACTIVITY != true
AND (
SUSPICIOUS_ADC_CHILD_PROCESS = true
OR SUSPICIOUS_ADC_FILE_ACCESS = true
OR RARE_ADC_ENDPOINT_EGRESS = true
)
AND (
ADC_SERVICE_OR_MANAGEMENT_CONTEXT = true
OR (
FilePath IS NOT NULL
AND FilePath STARTS_WITH ANY ENV_ADC_SENSITIVE_PATH_PREFIXES
)
OR (
CommandLine IS NOT NULL
AND CommandLine MATCHES ENV_ADC_RUNTIME_CONTEXT_PATTERNS
)
OR (
DestinationHost IS NOT NULL
AND DestinationHost NOT IN ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
OR (
DestinationIp IS NOT NULL
AND DestinationIp NOT IN ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
)
AND (
(
FilePath IS NOT NULL
AND FilePath NOT IN ENV_APPROVED_ADC_FILE_PATHS
)
OR (
CommandLine IS NOT NULL
AND CommandLine NOT IN ENV_APPROVED_ADC_COMMAND_PATTERNS
)
OR (
DestinationHost IS NOT NULL
AND DestinationHost NOT IN ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
OR (
DestinationIp IS NOT NULL
AND DestinationIp NOT IN ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
OR (
ProcessName IS NOT NULL
AND ProcessName NOT IN ENV_APPROVED_ADC_PROCESS_BASELINE
)
)
OUTPUT
EndpointName,
EndpointTags,
UserName,
ProcessUser,
ProcessName,
ParentProcessName,
CommandLine,
FilePath,
FileName,
FileExtension,
EventType,
EventTime,
DestinationHost,
DestinationIp,
DestinationPort,
DestinationDomain,
DestinationFirstSeenStatus,
DestinationReputation,
DestinationDomainAgeDays,
DestinationAsn,
DestinationGeo,
NetworkAction

Rule

ADC Sensitive Configuration, Certificate, Backup, or Diagnostic Artifact Access

Rule Format

SentinelOne Deep Visibility or STAR file and process logic.

Detection Purpose

Detect suspicious access to ADC configuration files, backup archives, diagnostic bundles, packet captures, certificate stores, private keys, API tokens, credential-bearing files, log files, temporary files, scripts, packages, or appliance support artifacts from ADC appliance context, ADC virtual appliance hosts, ADC management hosts, or ADC-supporting workloads. This rule is intended to identify post-exploitation access to privileged appliance objects that could expose routing configuration, TLS termination, administrative credentials, downstream application trust paths, or traffic-management control.

Detection Logic

Identify sensitive ADC file or artifact access where the user, process, parent process, command line, path, file type, archive activity, read activity, copy activity, modification activity, deletion activity, or network transfer pattern is inconsistent with approved backup, configuration export, certificate rotation, diagnostic bundle generation, vendor support, monitoring, upgrade, patch validation, or incident-response workflows. Increase confidence when sensitive object access occurs from ADC service context, management service context, diagnostic process context, shell context, scripting context, transfer-tool context, archive-tool context, or unusual user context.

Required Telemetry

·        SentinelOne endpoint tags identifying ADC appliances, ADC virtual appliance hosts, ADC management hosts, ADC-supporting workloads, jump hosts, and cloud-hosted ADC workloads.

·        File telemetry for read, open, create, modify, copy, archive, rename, delete, write, permission, ownership, and timestamp activity where available.

·        Process telemetry for parent process, process name, process user, command line, executable path, current directory, and process lineage.

·        Network telemetry for transfer-tool activity, archive exfiltration, rare destination communication, internal management service access, or outbound communication after sensitive file access.

·        Approved backup, certificate renewal, configuration export, diagnostic bundle, vendor support, monitoring, upgrade, patch-validation, failover, and incident-response exceptions.

·        SIEM, XDR, NDR, ADC audit, configuration-change, certificate-management, WAF, reverse-proxy, and downstream application context for investigation enrichment.

Engineering Implementation Instructions

·        Deploy in hunt mode to validate sensitive ADC file paths, certificate paths, backup paths, diagnostic bundle paths, support artifact paths, and configuration repositories.

·        Tune approved certificate renewal, key rotation, backup jobs, configuration export jobs, diagnostic collection, vendor support, firmware updates, monitoring, and incident-response workflows before alert promotion.

·        Correlate sensitive file access with process lineage, user context, command line, archive creation, transfer-tool execution, network egress, and ADC management/API activity in downstream SIEM or XDR.

·        Prioritize private-key access, certificate store access, API token access, credential-bearing file access, backup archive creation, diagnostic bundle creation, packet capture access, configuration export access, and log deletion.

·        Suppress approved maintenance, backups, diagnostics, certificate lifecycle activity, vendor support, patch validation, and documented incident-response collection.

·        Escalate when sensitive file access is followed by archive creation, outbound communication, log clearing, script execution, command execution, or unauthorized administrative activity.

DRI Assessment

This rule has strong detection reliability where SentinelOne file and process telemetry is available because sensitive ADC configuration, certificate, backup, and diagnostic objects are high-value post-exploitation targets. The rule supports the report’s behavior-driven model by focusing on privileged appliance object access rather than a single LoadMaster endpoint or CVE name. Reliability depends on accurate ADC path mapping, approved workflow baselines, and endpoint visibility.

DRI

8.0

TCR Assessment

Operational TCR is moderate because file-level visibility on ADC-related systems varies by appliance type and support model. Full-Telemetry TCR improves when file activity is joined with process lineage, network telemetry, ADC audit records, configuration exports, certificate-management records, and NDR or SIEM correlation.

Operational TCR

7.5

Full-Telemetry TCR

8.5

Limitations

·        This rule is not viable where ADC appliances do not expose file telemetry to SentinelOne.

·        File timestamps and artifact access may be affected by approved backup, failover, migration, firmware update, configuration import, vendor support, or incident-response collection.

·        Sensitive file access alone may indicate legitimate administration unless it is linked to suspicious process, user, command, network, ADC management/API, or maintenance-window context.

·        SentinelOne may not identify the upstream exploit request, API method, virtual service, or external source that preceded file access.

·        Private-key, certificate, API token, backup, or diagnostic artifact exposure may require ADC audit logs, configuration export comparison, or downstream incident-response review to confirm impact.

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne Deep Visibility or STAR logic that supports endpoint tags, file telemetry, process telemetry, parent-process telemetry, command-line telemetry, user context, path mapping, archive detection, transfer-tool detection, approved workflow exceptions, and downstream SIEM or XDR enrichment. ADC management/API request, WAF, reverse-proxy, CDN, load-balancer, NDR, certificate-management, configuration-change, and downstream application correlation should occur in the SIEM, XDR, or downstream investigation workflow.

LET ADC_RELATED_ENDPOINTS =
EndpointTags CONTAINS ANY (
"ENV_ADC_APPLIANCES",
"ENV_ADC_VIRTUAL_APPLIANCE_HOSTS",
"ENV_ADC_MANAGEMENT_HOSTS",
"ENV_ADC_JUMP_HOSTS",
"ENV_ADC_SUPPORTING_LINUX_WORKLOADS",
"ENV_ADC_CLOUD_HOSTED_WORKLOADS",
"ENV_EDGE_LOAD_BALANCER_HOSTS",
"ENV_REVERSE_PROXY_HOSTS",
"ENV_WAF_ADJACENT_HOSTS",
"ENV_TRAFFIC_MANAGEMENT_HOSTS"
)

LET ADC_SENSITIVE_FILE_PATHS =
FilePath STARTS_WITH ANY (
ENV_ADC_CONFIGURATION_PATH_PREFIXES,
ENV_ADC_BACKUP_PATH_PREFIXES,
ENV_ADC_DIAGNOSTIC_BUNDLE_PATH_PREFIXES,
ENV_ADC_PACKET_CAPTURE_PATH_PREFIXES,
ENV_ADC_CERTIFICATE_STORE_PATH_PREFIXES,
ENV_ADC_PRIVATE_KEY_PATH_PREFIXES,
ENV_ADC_KEYSTORE_PATH_PREFIXES,
ENV_ADC_API_TOKEN_PATH_PREFIXES,
ENV_ADC_CREDENTIAL_FILE_PATH_PREFIXES,
ENV_ADC_LOG_PATH_PREFIXES,
ENV_ADC_TEMP_PATH_PREFIXES,
ENV_ADC_SCRIPT_PATH_PREFIXES,
ENV_ADC_PACKAGE_PATH_PREFIXES,
ENV_ADC_SUPPORT_ARTIFACT_PATH_PREFIXES
)

LET ADC_SENSITIVE_FILE_ACTIVITY =
ADC_SENSITIVE_FILE_PATHS = true
AND EventType IN (
"file_opened",
"file_read",
"file_created",
"file_modified",
"file_copied",
"file_archived",
"file_deleted",
"file_renamed",
"file_written",
"permission_modified",
"ownership_modified"
)
AND (
FileName MATCHES ANY (
ENV_ADC_CONFIGURATION_FILE_PATTERNS,
ENV_ADC_BACKUP_FILE_PATTERNS,
ENV_ADC_DIAGNOSTIC_BUNDLE_PATTERNS,
ENV_ADC_PACKET_CAPTURE_PATTERNS,
ENV_ADC_CERTIFICATE_FILE_PATTERNS,
ENV_ADC_PRIVATE_KEY_FILE_PATTERNS,
ENV_ADC_KEYSTORE_FILE_PATTERNS,
ENV_ADC_API_TOKEN_FILE_PATTERNS,
ENV_ADC_CREDENTIAL_FILE_PATTERNS,
ENV_ADC_LOG_FILE_PATTERNS,
ENV_ADC_SCRIPT_FILE_PATTERNS,
ENV_ADC_PACKAGE_FILE_PATTERNS,
ENV_ADC_SUPPORT_ARTIFACT_PATTERNS
)
OR FilePath MATCHES ANY (
ENV_ADC_CONFIGURATION_FILE_PATTERNS,
ENV_ADC_BACKUP_FILE_PATTERNS,
ENV_ADC_DIAGNOSTIC_BUNDLE_PATTERNS,
ENV_ADC_PACKET_CAPTURE_PATTERNS,
ENV_ADC_CERTIFICATE_FILE_PATTERNS,
ENV_ADC_PRIVATE_KEY_FILE_PATTERNS,
ENV_ADC_KEYSTORE_FILE_PATTERNS,
ENV_ADC_API_TOKEN_FILE_PATTERNS,
ENV_ADC_CREDENTIAL_FILE_PATTERNS,
ENV_ADC_LOG_FILE_PATTERNS,
ENV_ADC_SCRIPT_FILE_PATTERNS,
ENV_ADC_PACKAGE_FILE_PATTERNS,
ENV_ADC_SUPPORT_ARTIFACT_PATTERNS
)
)

LET SUSPICIOUS_ADC_ACCESS_CONTEXT =
ProcessUser NOT IN ENV_APPROVED_ADC_ADMIN_USERS
AND UserName NOT IN ENV_APPROVED_ADC_ADMIN_USERS
AND (
ParentProcessName IN ENV_ADC_DAEMON_PROCESSES
OR ParentProcessName IN ENV_ADC_MANAGEMENT_PROCESSES
OR ParentProcessName IN ENV_ADC_API_HANDLER_PROCESSES
OR ParentProcessName IN ENV_ADC_DIAGNOSTIC_PROCESSES
OR ProcessName IN ENV_SHELL_INTERPRETERS
OR ProcessName IN ENV_SCRIPTING_INTERPRETERS
OR ProcessName IN ENV_TRANSFER_TOOLS
OR ProcessName IN ENV_ARCHIVE_TOOLS
OR ProcessName IN ENV_NETWORK_TOOLS
OR ProcessName IN ENV_DISCOVERY_TOOLS
OR ProcessName IN ENV_PACKAGE_MANAGEMENT_TOOLS
OR CommandLine MATCHES ENV_ADC_SUSPICIOUS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_ADC_CONFIGURATION_ACCESS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_ADC_CERTIFICATE_ACCESS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_ADC_CREDENTIAL_ACCESS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_ADC_ARCHIVE_OR_EXFILTRATION_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_ADC_LOG_DELETION_COMMAND_PATTERNS
)

LET RARE_ADC_TRANSFER_OR_EGRESS =
(
DestinationHost IS NOT NULL
OR DestinationIp IS NOT NULL
)
AND (
DestinationHost IS NULL
OR DestinationHost NOT IN ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
AND (
DestinationIp IS NULL
OR DestinationIp NOT IN ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
AND (
DestinationFirstSeenStatus IN ("new", "rare")
OR DestinationDomainAgeDays < ENV_NEW_DOMAIN_AGE_DAYS
OR DestinationReputation IN ("unknown", "suspicious", "malicious")
OR DestinationAsn IN ENV_SUSPICIOUS_ASNS
OR DestinationGeo NOT IN ENV_ADC_EXPECTED_EGRESS_GEOS
OR DestinationPort IN ENV_UNUSUAL_ADC_EGRESS_PORTS
OR ProcessName IN ENV_TRANSFER_TOOLS
OR CommandLine MATCHES ENV_ADC_ARCHIVE_OR_EXFILTRATION_COMMAND_PATTERNS
)

LET APPROVED_ADC_SENSITIVE_FILE_ACTIVITY =
UserName IN ENV_APPROVED_ADC_ADMIN_USERS
OR UserName IN ENV_APPROVED_ADC_BACKUP_USERS
OR UserName IN ENV_APPROVED_ADC_CERTIFICATE_MANAGEMENT_USERS
OR UserName IN ENV_APPROVED_ADC_VENDOR_SUPPORT_USERS
OR UserName IN ENV_APPROVED_ADC_MONITORING_USERS
OR ProcessName IN ENV_APPROVED_ADC_BACKUP_TOOLS
OR ProcessName IN ENV_APPROVED_ADC_CERTIFICATE_MANAGEMENT_TOOLS
OR ProcessName IN ENV_APPROVED_ADC_DIAGNOSTIC_TOOLS
OR ProcessName IN ENV_APPROVED_ADC_MONITORING_TOOLS
OR ProcessName IN ENV_APPROVED_ADC_UPDATE_TOOLS
OR CommandLine MATCHES ENV_APPROVED_ADC_BACKUP_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_APPROVED_ADC_CERTIFICATE_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_APPROVED_ADC_DIAGNOSTIC_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_APPROVED_ADC_SUPPORT_COMMAND_PATTERNS
OR EventTime IN ENV_APPROVED_ADC_BACKUP_WINDOWS
OR EventTime IN ENV_APPROVED_ADC_CERTIFICATE_ROTATION_WINDOWS
OR EventTime IN ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
OR EventTime IN ENV_APPROVED_ADC_VENDOR_SUPPORT_WINDOWS
OR EventTime IN ENV_APPROVED_ADC_INCIDENT_RESPONSE_WINDOWS

FROM ProcessEvents OR FileEvents OR NetworkEvents
WHERE ADC_RELATED_ENDPOINTS = true
AND APPROVED_ADC_SENSITIVE_FILE_ACTIVITY != true
AND ADC_SENSITIVE_FILE_ACTIVITY = true
AND (
SUSPICIOUS_ADC_ACCESS_CONTEXT = true
OR RARE_ADC_TRANSFER_OR_EGRESS = true
OR (
FileName MATCHES ANY ENV_ADC_PRIVATE_KEY_FILE_PATTERNS
OR FileName MATCHES ANY ENV_ADC_CREDENTIAL_FILE_PATTERNS
OR FileName MATCHES ANY ENV_ADC_API_TOKEN_FILE_PATTERNS
OR FileName MATCHES ANY ENV_ADC_BACKUP_FILE_PATTERNS
OR FileName MATCHES ANY ENV_ADC_DIAGNOSTIC_BUNDLE_PATTERNS
)
)
AND (
(
FilePath IS NOT NULL
AND FilePath NOT IN ENV_APPROVED_ADC_FILE_PATHS
)
OR (
CommandLine IS NOT NULL
AND CommandLine NOT IN ENV_APPROVED_ADC_COMMAND_PATTERNS
)
OR (
ProcessName IS NOT NULL
AND ProcessName NOT IN ENV_APPROVED_ADC_PROCESS_BASELINE
)
OR (
DestinationHost IS NOT NULL
AND DestinationHost NOT IN ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
OR (
DestinationIp IS NOT NULL
AND DestinationIp NOT IN ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
)
OUTPUT
EndpointName,
EndpointTags,
UserName,
ProcessUser,
ProcessName,
ParentProcessName,
CommandLine,
FilePath,
FileName,
FileExtension,
EventType,
EventTime,
DestinationHost,
DestinationIp,
DestinationPort,
DestinationDomain,
DestinationFirstSeenStatus,
DestinationReputation,
DestinationDomainAgeDays,
DestinationAsn,
DestinationGeo,
NetworkAction

Splunk

Detection Viability Assessment

Splunk is highly viable for this behavior family because ADC compromise detection depends on joining management/API request behavior, WAF or reverse-proxy telemetry, appliance logs, configuration-change records, certificate-management records, DNS, proxy, firewall, NDR, endpoint telemetry where available, change-management context, and downstream application logs. Splunk should be used to detect behavior sequences rather than isolated request strings, vulnerable-version findings, CVE names, scanner hits, KEV status, or public proof-of-concept indicators alone. The strongest Splunk detections correlate suspicious ADC control-plane access with appliance instability, configuration or certificate access, virtual-service manipulation, rare egress, administrative-control change, logging degradation, or downstream application exposure.

Rule

ADC Control-Plane Access Followed by Appliance Instability or Rare Egress

Rule Format

Splunk SPL correlation search.

Detection Purpose

Detect suspicious ADC management/API, administrative, diagnostic, authentication, telemetry, or configuration access followed by appliance instability, abnormal response behavior, failed-to-success control-plane sequencing, or rare outbound communication from the ADC appliance. This rule is intended to identify behavior consistent with pre-authentication or weakly authenticated ADC control-plane exploitation, including Progress Kemp LoadMaster CVE-2026-8037-like activity where locally visible, without making detection dependent on one vendor, endpoint path, CVE name, proof-of-concept string, or scanner signature.

Detection Logic

Identify suspicious requests to ADC control-plane surfaces from external, unfamiliar, newly seen, partner-originated, scanner-like, automation-like, or non-administrative sources. Increase confidence when the request contains command-delimiter, shell-control, quote-manipulation, encoded, malformed JSON, oversized, authentication-bypass, API-parameter manipulation, abnormal method, or abnormal response-size behavior. Promote only when suspicious access is followed within a bounded time window by appliance instability, abnormal HTTP status sequencing, API handler failure, management-service fault, connection reset, timeout, watchdog or restart behavior where logged, or rare ADC-originated DNS, HTTP, HTTPS, SSH, SMTP, raw-IP, file-transfer, tunneling, or command-and-control-like communication.

Required Telemetry

·        ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, appliance syslog, and administrative audit logs where available.

·        DNS, proxy, firewall, NDR, NetFlow, VPC flow, data-center flow, or endpoint-network telemetry for ADC-originated outbound communication.

·        ADC appliance inventory, management-interface inventory, API exposure inventory, virtual-service inventory, backend-pool inventory, approved administrative source inventory, approved partner path inventory, and approved maintenance-window context.

·        Destination enrichment for first-seen status, domain age, ASN, geography, reputation, destination port, protocol, proxy action, and firewall action.

·        Splunk macros, lookups, CIM mappings, accelerated data sources, and summary indexes that normalize ADC asset identity, request paths, forwarded source, destination identity, egress baselines, and maintenance context.

Engineering Implementation Instructions

·        Deploy first in hunt mode to validate ADC log onboarding, request-path preservation, query-string preservation, forwarded-source extraction, appliance identity joins, virtual-service mapping, backend-pool mapping, and egress attribution.

·        Use macros and lookups to abstract customer-specific indexes, sourcetypes, field names, CIM mappings, accelerated data models, asset inventories, source exceptions, destination exceptions, and maintenance windows.

·        Tune approved administrative networks, partner-reachable paths, vendor support sources, vulnerability scanners, patch-validation sources, monitoring systems, health checks, backups, license validation, update destinations, and maintenance windows before alert promotion.

·        Correlate by ADC appliance, management interface, destination host, destination IP, source IP, forwarded source IP, source network, API path, API method, virtual service, backend pool, destination domain, destination IP, and bounded time window.

·        Treat suspicious management/API access alone as exploit-attempt evidence, not confirmed compromise.

·        Promote severity when suspicious access is followed by appliance instability, rare egress, repeated callbacks, internal service access, or abnormal response sequencing.

DRI Assessment

This rule has high detection reliability because it anchors on a sequence of suspicious ADC control-plane access followed by instability or rare appliance-originated communication. It is resilient across ADC, load balancer, reverse proxy, WAF-adjacent, and edge traffic-management compromise scenarios because it does not depend on a single Progress Kemp LoadMaster endpoint, public exploit string, user agent, or CVE identifier. Reliability depends on request-path visibility, forwarded-source preservation, ADC inventory quality, egress baselining, and consistent field normalization.

DRI

8.8

TCR Assessment

Operational TCR is strong where Splunk receives ADC management/API logs, WAF or reverse-proxy logs, DNS, proxy, firewall, NDR, asset inventory, source exceptions, and approved-egress lookups. Full-Telemetry TCR improves when appliance syslog, configuration-change records, certificate records, administrative audit logs, downstream application logs, and endpoint telemetry are joined to the same sequence.

Operational TCR

8.5

Full-Telemetry TCR

9.2

Limitations

·        This rule cannot confirm command execution without appliance process, shell, diagnostic, system, endpoint, or vendor log evidence.

·        Request-body loss, query-string redaction, CDN layering, NAT, proxy forwarding, or incomplete forwarded-source preservation may reduce confidence.

·        Rare egress may reflect approved vendor support, update retrieval, license validation, backup, monitoring, troubleshooting, or incident-response activity if exception lookups are incomplete.

·        Appliance instability may result from benign patching, failover testing, resource exhaustion, configuration error, or maintenance activity.

·        Vulnerable-version status, public PoC availability, scanner traffic, or KEV status must not be treated as standalone compromise confirmation.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS, proxy, firewall, NDR, flow telemetry, ADC asset mapping, management-interface awareness, API exposure awareness, URI and query-string preservation, forwarded-source extraction, status sequencing, response-size baselining, source enrichment, destination enrichment, egress baselining, maintenance-window context, virtual-service joins, backend-pool joins, and appliance identity joins. Customer-specific indexes, sourcetypes, field names, CIM mappings, macros, accelerated data sources, summary indexes, and local enrichment should be abstracted behind macros and lookups.

adc_control_plane_and_network_events
| eval normalized_time=coalesce(_time, event_time, EventTime, timestamp)
| eval normalized_adc_asset=coalesce(adc_asset_id, asset_id, dest_asset_id, device_id, host, dest, dest_host, destination_host, appliance_name)
| eval normalized_destination_host=coalesce(dest_host, destination_host, url_domain, host, dvc, device_name)
| eval normalized_destination_ip=coalesce(dest_ip, destination_ip, daddr, dst, dest)
| eval normalized_management_interface=coalesce(management_interface, interface, listener, local_interface, dest_interface)
| eval normalized_virtual_service=coalesce(virtual_service, vip, listener_name, service_name, app_service, frontend_name)
| eval normalized_backend_pool=coalesce(backend_pool, pool_name, real_server_pool, target_group, backend_service)
| eval normalized_backend_host=coalesce(backend_host, real_server, target_host, upstream_host, server_name)
| eval normalized_request_path=coalesce(uri_path, url_path, request_path, cs_uri_stem, path)
| eval normalized_request_query=coalesce(uri_query, query_string, request_query, cs_uri_query)
| eval normalized_request_method=coalesce(http_method, method, request_method, cs_method)
| eval normalized_user_agent=coalesce(user_agent, http_user_agent, cs_user_agent)
| eval normalized_source_ip=coalesce(src_ip, source_ip, client_ip, c_ip, src)
| eval normalized_forwarded_source_ip=coalesce(x_forwarded_for, forwarded_for, true_client_ip, original_client_ip)
| eval normalized_source_asn=coalesce(src_asn, source_asn, client_asn)
| eval normalized_source_geo=coalesce(src_geo, source_geo, client_geo, src_country)
| eval normalized_source_network_type=coalesce(source_network_type, src_network_type, client_network_type)
| eval normalized_status=coalesce(status, http_status, sc_status, response_status)
| eval normalized_response_size=coalesce(bytes_out, response_size, sc_bytes, bytes)
| eval normalized_request_size=coalesce(bytes_in, request_size, cs_bytes, request_bytes)
| eval normalized_dest_domain=coalesce(dest_domain, destination_domain, query, domain, url_domain)
| eval normalized_egress_ip=coalesce(dest_ip, destination_ip, daddr, dst)
| eval normalized_egress_port=coalesce(dest_port, destination_port, dpt)
| eval normalized_protocol=coalesce(protocol, transport, app_protocol)
| eval normalized_network_action=coalesce(action, firewall_action, proxy_action, verdict)
| lookup ENV_ADC_EDGE_ASSETS normalized_adc_asset OUTPUT adc_asset_match adc_asset_id adc_asset_role exposure_class asset_criticality
| lookup ENV_ADC_EDGE_ASSETS normalized_destination_host OUTPUT adc_destination_match adc_destination_asset_id
| lookup ENV_ADC_MANAGEMENT_OR_API_SURFACES normalized_request_path OUTPUT adc_management_path_match api_path_family
| lookup ENV_APPROVED_ADC_SOURCE_EXCEPTIONS normalized_source_ip OUTPUT approved_source_ip
| lookup ENV_APPROVED_ADC_SOURCE_EXCEPTIONS normalized_forwarded_source_ip OUTPUT approved_forwarded_source_ip
| lookup ENV_APPROVED_ADC_CONTEXT_EXCEPTIONS normalized_time OUTPUT approved_context_window
| lookup ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS normalized_request_path OUTPUT path_exploit_pattern_match path_exploit_family
| lookup ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS normalized_request_query OUTPUT query_exploit_pattern_match query_exploit_family
| lookup ENV_APPROVED_ADC_EGRESS normalized_dest_domain OUTPUT approved_dest_domain
| lookup ENV_APPROVED_ADC_EGRESS normalized_egress_ip OUTPUT approved_dest_ip
| lookup ENV_DESTINATION_ENRICHMENT normalized_dest_domain OUTPUT destination_first_seen_status destination_domain_age_days destination_reputation destination_asn destination_geo
| lookup ENV_DESTINATION_ENRICHMENT normalized_egress_ip OUTPUT ip_first_seen_status ip_reputation ip_asn ip_geo
| where adc_asset_match="true" OR adc_destination_match="true"
| where approved_context_window!="true"
| eval suspicious_adc_control_plane_request=if(adc_management_path_match="true" AND approved_source_ip!="true" AND approved_forwarded_source_ip!="true" AND (destination_first_seen_status IN ("new","rare") OR normalized_source_asn IN ENV_SUSPICIOUS_ASNS OR normalized_source_network_type IN ("cloud_hosted","residential_proxy","vpn_provider","scanner_infrastructure","unknown_hosting") OR normalized_source_geo NOT IN ENV_ADC_EXPECTED_ADMIN_SOURCE_GEOS OR normalized_user_agent IN ENV_RARE_OR_AUTOMATED_USER_AGENTS OR normalized_request_method NOT IN ENV_EXPECTED_ADC_MANAGEMENT_METHODS OR path_exploit_pattern_match="true" OR query_exploit_pattern_match="true" OR normalized_request_size > ENV_ADC_MANAGEMENT_REQUEST_SIZE_UPPER_BASELINE OR normalized_response_size > ENV_ADC_MANAGEMENT_RESPONSE_SIZE_UPPER_BASELINE OR normalized_response_size < ENV_ADC_MANAGEMENT_RESPONSE_SIZE_LOWER_BASELINE), "true", "false")
| streamstats window=20 values(normalized_status) as status_sequence values(normalized_response_size) as response_size_sequence by normalized_adc_asset normalized_source_ip normalized_request_path
| eval adc_instability_or_abnormal_response=if(normalized_status IN (400,401,403,404,500,502,503,504) OR match(mvjoin(status_sequence, ","), ENV_ADC_FAILED_THEN_SUCCESS_STATUS_PATTERN) OR match(mvjoin(status_sequence, ","), ENV_ADC_INSTABILITY_STATUS_PATTERN) OR normalized_network_action IN ("timeout","reset","closed_after_error","service_unavailable") OR response_size_delta > ENV_ADC_RESPONSE_SIZE_DELTA_UPPER_BASELINE OR response_size_delta < ENV_ADC_RESPONSE_SIZE_DELTA_LOWER_BASELINE, "true", "false")
| eval rare_adc_appliance_egress=if((isnotnull(normalized_dest_domain) OR isnotnull(normalized_egress_ip)) AND (isnull(normalized_dest_domain) OR approved_dest_domain!="true") AND (isnull(normalized_egress_ip) OR approved_dest_ip!="true") AND (destination_first_seen_status IN ("new","rare") OR ip_first_seen_status IN ("new","rare") OR destination_domain_age_days < ENV_NEW_DOMAIN_AGE_DAYS OR destination_reputation IN ("unknown","suspicious","malicious") OR ip_reputation IN ("unknown","suspicious","malicious") OR destination_asn IN ENV_SUSPICIOUS_ASNS OR ip_asn IN ENV_SUSPICIOUS_ASNS OR destination_geo NOT IN ENV_ADC_EXPECTED_EGRESS_GEOS OR ip_geo NOT IN ENV_ADC_EXPECTED_EGRESS_GEOS OR normalized_egress_port IN ENV_UNUSUAL_ADC_EGRESS_PORTS OR normalized_protocol IN ("ssh","smtp","raw_ip","unknown","tunnel","file_transfer") OR normalized_network_action IN ("allowed","connected","proxied")), "true", "false")
| eventstats min(eval(if(suspicious_adc_control_plane_request="true", normalized_time, null()))) as first_suspicious_control_plane_time by normalized_adc_asset normalized_source_ip
| eval post_access_instability=if(adc_instability_or_abnormal_response="true" AND normalized_time>=first_suspicious_control_plane_time AND normalized_time<=first_suspicious_control_plane_time+ENV_ADC_CONTROL_PLANE_ACCESS_TO_INSTABILITY_WINDOW, "true", "false")
| eval post_access_egress=if(rare_adc_appliance_egress="true" AND normalized_time>=first_suspicious_control_plane_time AND normalized_time<=first_suspicious_control_plane_time+ENV_ADC_CONTROL_PLANE_ACCESS_TO_EGRESS_WINDOW, "true", "false")
| where suspicious_adc_control_plane_request="true" OR post_access_instability="true" OR post_access_egress="true"
| stats min(normalized_time) as first_seen max(normalized_time) as last_seen values(normalized_destination_host) as destination_host values(normalized_destination_ip) as destination_ip values(normalized_management_interface) as management_interface values(normalized_virtual_service) as virtual_service values(normalized_backend_pool) as backend_pool values(normalized_backend_host) as backend_host values(normalized_request_path) as request_path values(normalized_request_query) as request_query values(normalized_request_method) as request_method values(api_path_family) as api_path_family values(normalized_source_ip) as source_ip values(normalized_forwarded_source_ip) as forwarded_source_ip values(normalized_source_asn) as source_asn values(normalized_source_geo) as source_geo values(normalized_source_network_type) as source_network_type values(normalized_user_agent) as user_agent values(normalized_status) as http_status values(status_sequence) as http_status_sequence values(normalized_request_size) as request_size values(normalized_response_size) as response_size values(normalized_dest_domain) as egress_destination_domain values(normalized_egress_ip) as egress_destination_ip values(normalized_egress_port) as egress_destination_port values(normalized_protocol) as egress_destination_protocol values(destination_reputation) as egress_destination_reputation values(destination_domain_age_days) as egress_destination_domain_age_days values(normalized_network_action) as network_action values(suspicious_adc_control_plane_request) as suspicious_adc_control_plane_request values(post_access_instability) as post_access_instability values(post_access_egress) as post_access_egress by normalized_adc_asset adc_asset_id adc_asset_role exposure_class asset_criticality
| where mvfind(suspicious_adc_control_plane_request,"true")>=0 AND (mvfind(post_access_instability,"true")>=0 OR mvfind(post_access_egress,"true")>=0)
| eval event_kind="adc_control_plane_access_followed_by_instability_or_rare_egress"
| table first_seen last_seen normalized_adc_asset adc_asset_id adc_asset_role exposure_class asset_criticality destination_host destination_ip management_interface virtual_service backend_pool backend_host request_path request_query request_method api_path_family source_ip forwarded_source_ip source_asn source_geo source_network_type user_agent http_status http_status_sequence request_size response_size egress_destination_domain egress_destination_ip egress_destination_port egress_destination_protocol egress_destination_reputation egress_destination_domain_age_days network_action suspicious_adc_control_plane_request post_access_instability post_access_egress event_kind

Rule

ADC Control-Plane Access Followed by Configuration, Certificate, or Traffic-Path Manipulation

Rule Format

Splunk SPL correlation search.

Detection Purpose

Detect suspicious ADC management/API access followed by configuration exposure, configuration change, virtual-service manipulation, backend-pool modification, routing or header-control changes, TLS or certificate-object access, backup or diagnostic artifact access, administrative-control change, logging degradation, or downstream application traffic-path anomalies. This rule is intended to identify compromise behavior affecting the edge application-delivery trust boundary rather than only the vulnerable appliance.

Detection Logic

Identify suspicious control-plane access to ADC management, API, administrative, diagnostic, authentication, telemetry, or configuration surfaces. Correlate that access with subsequent configuration-object access, virtual-service modification, backend-pool modification, route or rewrite change, header manipulation, persistence-profile change, health-check change, SSL/TLS offload change, certificate binding change, private-key access, backup export, diagnostic bundle creation, packet capture creation, API token access, administrative setting modification, logging change, or downstream application anomaly. Promote only when post-access behavior aligns by ADC appliance, management interface, source, virtual service, backend pool, configuration object, certificate object, downstream application, or bounded time window.

Required Telemetry

·        ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, appliance syslog, administrative audit logs, and configuration-change records.

·        Certificate-management records, TLS binding records, configuration export records, backup records, diagnostic bundle records, packet capture records, administrative-user records, API key records, and logging-setting records where available.

·        Downstream web server logs, downstream application logs, identity logs, backend service logs, WAF logs, proxy logs, NDR, DNS, proxy, firewall, and flow telemetry.

·        ADC appliance inventory, virtual-service inventory, backend-pool inventory, certificate inventory, TLS-offload inventory, route inventory, header-rule inventory, rewrite-rule inventory, approved change records, and maintenance-window context.

·        Splunk macros, lookups, CIM mappings, accelerated data sources, and summary indexes that normalize ADC objects, protected configuration families, certificate families, downstream application identity, approved changes, and approved administrative workflows.

Engineering Implementation Instructions

·        Deploy first in hunt mode until ADC configuration-object normalization, certificate-object mapping, virtual-service mapping, backend-pool mapping, downstream application mapping, and approved change lookups are validated.

·        Require sequence correlation before alert promotion.

·        Correlate suspicious access with configuration, certificate, traffic-path, administrative, logging, or downstream behavior by ADC appliance, management interface, API endpoint, source IP, forwarded source IP, administrative identity where available, configuration object, certificate object, virtual service, backend pool, downstream application, and bounded time window.

·        Suppress known-good certificate rotation, key rotation, virtual-service changes, backend-pool changes, routing changes, health-check tuning, backup jobs, diagnostic collection, vendor support, failover testing, monitoring activity, emergency maintenance, and documented incident-response collection.

·        Treat downstream application anomalies as ADC-related only when they follow suspicious ADC control-plane behavior and align by virtual service, backend host, route, header behavior, source path, source identity, or time window.

·        Escalate when certificate or private-key access, backup export, diagnostic bundle creation, configuration export, logging degradation, administrative-control change, traffic mirroring, or downstream application exposure follows suspicious management/API access.

DRI Assessment

This rule has high detection reliability because it focuses on protected ADC trust-boundary objects and downstream consequences that are difficult to explain through scanner traffic alone. It remains reusable across ADC, load balancer, reverse proxy, WAF-adjacent, and edge traffic-management compromise scenarios because it anchors on configuration, certificate, routing, and traffic-path manipulation rather than a single vendor endpoint. Reliability depends on configuration visibility, object normalization, virtual-service mapping, certificate records, and approved change context.

DRI

8.7

TCR Assessment

Operational TCR is strong when Splunk receives ADC management/API logs, configuration-change records, WAF or reverse-proxy logs, asset inventory, approved change records, and NDR telemetry. Full-Telemetry TCR improves when certificate-management records, backup comparison, administrative audit logs, endpoint telemetry, downstream application logs, and virtual-service-to-backend mappings are available.

Operational TCR

8.3

Full-Telemetry TCR

9.1

Limitations

·        This rule may miss object-level access if ADC appliances do not log configuration reads, certificate reads, private-key access, backup creation, diagnostic bundle creation, or administrative API actions.

·        Approved backup, certificate renewal, vendor support, emergency routing changes, failover testing, patch validation, and incident-response collection may resemble suspicious post-access behavior.

·        Downstream application anomalies cannot be attributed to ADC compromise without linkage to ADC appliance, virtual service, backend mapping, request path, source, administrative action, or time window.

·        Configuration export timestamps may reflect backup, migration, restoration, failover, or maintenance rather than the original attacker action.

·        Splunk correlation quality depends on field normalization, asset mapping, configuration object mapping, and reliable approved-change lookups.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, administrative audit logs, configuration-change records, certificate-management records, downstream application logs, DNS, proxy, firewall, NDR, flow telemetry, ADC asset mapping, configuration-object awareness, certificate-object awareness, virtual-service awareness, backend-pool mapping, TLS-offload mapping, route and header behavior matching, approved workflow exceptions, maintenance-window context, and downstream application joins. Customer-specific indexes, sourcetypes, field names, CIM mappings, macros, accelerated data sources, summary indexes, and local enrichment should be abstracted behind macros and lookups.

adc_control_plane_configuration_and_downstream_events
| eval normalized_time=coalesce(_time, event_time, EventTime, timestamp)
| eval normalized_adc_asset=coalesce(adc_asset_id, asset_id, dest_asset_id, device_id, host, dest, dest_host, destination_host, appliance_name)
| eval normalized_destination_host=coalesce(dest_host, destination_host, url_domain, host, dvc, device_name)
| eval normalized_destination_ip=coalesce(dest_ip, destination_ip, daddr, dst, dest)
| eval normalized_management_interface=coalesce(management_interface, interface, listener, local_interface, dest_interface)
| eval normalized_virtual_service=coalesce(virtual_service, vip, listener_name, service_name, app_service, frontend_name)
| eval normalized_backend_pool=coalesce(backend_pool, pool_name, real_server_pool, target_group, backend_service)
| eval normalized_backend_host=coalesce(backend_host, real_server, target_host, upstream_host, server_name)
| eval normalized_application_id=coalesce(application_id, app, app_id, service_id, site_id)
| eval normalized_request_path=coalesce(uri_path, url_path, request_path, cs_uri_stem, path)
| eval normalized_request_query=coalesce(uri_query, query_string, request_query, cs_uri_query)
| eval normalized_request_method=coalesce(http_method, method, request_method, cs_method)
| eval normalized_source_ip=coalesce(src_ip, source_ip, client_ip, c_ip, src)
| eval normalized_forwarded_source_ip=coalesce(x_forwarded_for, forwarded_for, true_client_ip, original_client_ip)
| eval normalized_user_agent=coalesce(user_agent, http_user_agent, cs_user_agent)
| eval normalized_status=coalesce(status, http_status, sc_status, response_status)
| eval normalized_configuration_object=coalesce(configuration_object, object, object_name, resource, resource_name, config_path)
| eval normalized_certificate_object=coalesce(certificate_object, cert_name, certificate_name, key_name, tls_object, binding_name)
| eval normalized_action=coalesce(action, operation, event_action, change_action)
| eval normalized_change_type=coalesce(change_type, event_type, EventType, signature, operation_type)
| eval normalized_admin_identity=coalesce(user, username, admin_user, account, actor)
| eval normalized_header_behavior=coalesce(header_behavior, header_change, header_action)
| eval normalized_route_behavior=coalesce(route_behavior, routing_behavior, route_change)
| eval normalized_tls_behavior=coalesce(tls_behavior, tls_change, certificate_behavior)
| eval normalized_downstream_behavior=coalesce(downstream_behavior, application_behavior, backend_behavior, app_anomaly)
| lookup ENV_ADC_EDGE_ASSETS normalized_adc_asset OUTPUT adc_asset_match adc_asset_id adc_asset_role exposure_class asset_criticality
| lookup ENV_ADC_EDGE_ASSETS normalized_destination_host OUTPUT adc_destination_match adc_destination_asset_id
| lookup ENV_ADC_MANAGEMENT_OR_API_SURFACES normalized_request_path OUTPUT adc_management_path_match api_path_family
| lookup ENV_APPROVED_ADC_SOURCE_EXCEPTIONS normalized_source_ip OUTPUT approved_source_ip
| lookup ENV_APPROVED_ADC_SOURCE_EXCEPTIONS normalized_forwarded_source_ip OUTPUT approved_forwarded_source_ip
| lookup ENV_APPROVED_ADC_CONTEXT_EXCEPTIONS normalized_time OUTPUT approved_context_window
| lookup ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS normalized_request_path OUTPUT path_exploit_pattern_match path_exploit_family
| lookup ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS normalized_request_query OUTPUT query_exploit_pattern_match query_exploit_family
| lookup ENV_ADC_PROTECTED_CONFIGURATION_OBJECTS normalized_configuration_object OUTPUT protected_configuration_match configuration_object_family
| lookup ENV_ADC_CERTIFICATE_AND_TLS_OBJECTS normalized_certificate_object OUTPUT protected_certificate_match certificate_object_family
| lookup ENV_APPROVED_ADC_TRAFFIC_PATH_CHANGES normalized_adc_asset normalized_virtual_service normalized_backend_pool normalized_change_type normalized_time OUTPUT approved_traffic_path_change
| lookup ENV_APPROVED_ADC_CHANGE_ACTORS normalized_admin_identity OUTPUT approved_change_actor
| where adc_asset_match="true" OR adc_destination_match="true"
| where approved_context_window!="true"
| eval suspicious_adc_control_plane_request=if(adc_management_path_match="true" AND approved_source_ip!="true" AND approved_forwarded_source_ip!="true" AND (path_exploit_pattern_match="true" OR query_exploit_pattern_match="true" OR normalized_source_ip NOT IN ENV_APPROVED_ADC_ADMIN_SOURCES OR normalized_user_agent IN ENV_RARE_OR_AUTOMATED_USER_AGENTS OR normalized_request_method NOT IN ENV_EXPECTED_ADC_MANAGEMENT_METHODS OR normalized_status IN (400,401,403,404,500,502,503,504)), "true", "false")
| eval adc_configuration_or_certificate_access=if((protected_configuration_match="true" OR protected_certificate_match="true") AND approved_change_actor!="true" AND normalized_action IN ("read","export","download","create","modify","delete","replace","bind","unbind","backup","diagnostic_bundle_created","packet_capture_created"), "true", "false")
| eval adc_traffic_path_or_admin_change=if(approved_traffic_path_change!="true" AND (normalized_change_type IN ("virtual_service_modified","backend_pool_modified","routing_rule_modified","rewrite_rule_modified","header_rule_modified","certificate_binding_modified","tls_offload_modified","persistence_profile_modified","health_check_modified","logging_setting_modified","administrative_setting_modified","api_key_created","admin_user_created","admin_role_modified") OR normalized_header_behavior IN ("new_header_added","header_removed","header_rewritten","forwarded_for_anomaly","host_header_anomaly") OR normalized_route_behavior IN ("unexpected_route","unexpected_backend_selection","traffic_mirroring_suspected") OR normalized_tls_behavior IN ("certificate_binding_change","tls_termination_change","unexpected_plaintext_backend_flow","unexpected_tls_offload_path")), "true", "false")
| eval downstream_traffic_path_anomaly=if(normalized_downstream_behavior IN ("unexpected_backend_access","authentication_flow_change","session_routing_change","header_manipulation","traffic_mirroring_suspected","data_exposure_like_response","availability_degradation") OR normalized_header_behavior IN ("forwarded_for_anomaly","host_header_anomaly","header_rewritten") OR normalized_route_behavior IN ("unexpected_backend_selection","unexpected_route","traffic_mirroring_suspected"), "true", "false")
| eventstats min(eval(if(suspicious_adc_control_plane_request="true", normalized_time, null()))) as first_suspicious_control_plane_time by normalized_adc_asset normalized_source_ip normalized_forwarded_source_ip
| eval post_access_configuration_or_certificate=if(adc_configuration_or_certificate_access="true" AND normalized_time>=first_suspicious_control_plane_time AND normalized_time<=first_suspicious_control_plane_time+ENV_ADC_CONTROL_PLANE_ACCESS_TO_CONFIGURATION_WINDOW, "true", "false")
| eval post_access_traffic_path_or_admin_change=if(adc_traffic_path_or_admin_change="true" AND normalized_time>=first_suspicious_control_plane_time AND normalized_time<=first_suspicious_control_plane_time+ENV_ADC_CONTROL_PLANE_ACCESS_TO_TRAFFIC_PATH_WINDOW, "true", "false")
| eval post_access_downstream_anomaly=if(downstream_traffic_path_anomaly="true" AND normalized_time>=first_suspicious_control_plane_time AND normalized_time<=first_suspicious_control_plane_time+ENV_ADC_CONTROL_PLANE_ACCESS_TO_DOWNSTREAM_IMPACT_WINDOW, "true", "false")
| where suspicious_adc_control_plane_request="true" OR post_access_configuration_or_certificate="true" OR post_access_traffic_path_or_admin_change="true" OR post_access_downstream_anomaly="true"
| stats min(normalized_time) as first_seen max(normalized_time) as last_seen values(normalized_destination_host) as destination_host values(normalized_destination_ip) as destination_ip values(normalized_management_interface) as management_interface values(normalized_virtual_service) as virtual_service values(normalized_backend_pool) as backend_pool values(normalized_backend_host) as backend_host values(normalized_application_id) as application_id values(normalized_request_path) as request_path values(normalized_request_query) as request_query values(normalized_request_method) as request_method values(api_path_family) as api_path_family values(normalized_source_ip) as source_ip values(normalized_forwarded_source_ip) as forwarded_source_ip values(normalized_user_agent) as user_agent values(normalized_status) as http_status values(normalized_configuration_object) as configuration_object values(configuration_object_family) as configuration_object_family values(normalized_certificate_object) as certificate_object values(certificate_object_family) as certificate_object_family values(normalized_action) as action values(normalized_change_type) as change_type values(normalized_admin_identity) as admin_identity values(normalized_header_behavior) as header_behavior values(normalized_route_behavior) as route_behavior values(normalized_tls_behavior) as tls_behavior values(normalized_downstream_behavior) as downstream_behavior values(suspicious_adc_control_plane_request) as suspicious_adc_control_plane_request values(post_access_configuration_or_certificate) as post_access_configuration_or_certificate values(post_access_traffic_path_or_admin_change) as post_access_traffic_path_or_admin_change values(post_access_downstream_anomaly) as post_access_downstream_anomaly by normalized_adc_asset adc_asset_id adc_asset_role exposure_class asset_criticality
| where mvfind(suspicious_adc_control_plane_request,"true")>=0 AND (mvfind(post_access_configuration_or_certificate,"true")>=0 OR mvfind(post_access_traffic_path_or_admin_change,"true")>=0 OR mvfind(post_access_downstream_anomaly,"true")>=0)
| eval event_kind="adc_control_plane_access_followed_by_configuration_certificate_or_traffic_path_manipulation"
| table first_seen last_seen normalized_adc_asset adc_asset_id adc_asset_role exposure_class asset_criticality destination_host destination_ip management_interface virtual_service backend_pool backend_host application_id request_path request_query request_method api_path_family source_ip forwarded_source_ip user_agent http_status configuration_object configuration_object_family certificate_object certificate_object_family action change_type admin_identity header_behavior route_behavior tls_behavior downstream_behavior suspicious_adc_control_plane_request post_access_configuration_or_certificate post_access_traffic_path_or_admin_change post_access_downstream_anomaly event_kind

Rule

Multiple ADC Assets Showing Related Control-Plane Probing or Post-Access Behavior

Rule Format

Splunk SPL campaign-correlation search.

Detection Purpose

Detect campaign-like activity across multiple ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management assets where related control-plane probing, exploit-attempt behavior, instability, rare egress, configuration access, certificate access, virtual-service changes, or downstream anomalies appear within a bounded time window. This rule is intended to identify coordinated targeting or exposure review without assuming confirmed compromise from multi-asset scanner traffic alone.

Detection Logic

Identify two or more ADC or edge traffic-management assets showing similar suspicious management/API access from the same source, forwarded source, source network, ASN, user agent, request-path family, API-method family, parameter family, timing pattern, or payload family. Promote confidence when at least one affected appliance also shows appliance instability, rare egress, configuration or certificate access, administrative-control change, virtual-service or backend-pool modification, logging degradation, or downstream traffic-path anomaly. Treat related multi-asset request activity without post-access behavior as exploit-attempt or exposure-review evidence, not confirmed compromise.

Required Telemetry

·        Splunk ingestion from ADC management/API logs, WAF logs, CDN logs, reverse-proxy logs, load-balancer logs, gateway logs, firewall logs, DNS logs, proxy logs, NDR, flow telemetry, appliance syslog, configuration-change logs, and downstream application logs.

·        ADC appliance inventory, internet-exposure inventory, partner-reachable path inventory, management-interface inventory, API exposure inventory, virtual-service inventory, backend-pool inventory, asset criticality, exposure class, and downstream application mapping.

·        Source enrichment for first-seen status, ASN, geography, network type, user agent, request cadence, scanner-like behavior, infrastructure clustering, shared source-network patterns, and reputation where available.

·        Approved scanners, approved administrative sources, vendor support sources, patch-validation sources, monitoring systems, synthetic checks, red-team sources, incident-response sources, and maintenance-window lookups.

·        Splunk macros, lookups, CIM mappings, accelerated data sources, and summary indexes that normalize multi-asset grouping, source clustering, request families, post-access behavior, and approved exception context.

Engineering Implementation Instructions

·        Deploy first in hunt mode to validate multi-asset thresholds, request-family normalization, source clustering, and exception handling.

·        Require at least two ADC or traffic-management assets before campaign-correlation logic triggers.

·        Require post-access behavior from at least one appliance before promoting beyond exploit-attempt or exposure-review confidence.

·        Correlate by source IP, forwarded source IP, source network, ASN, user agent, request-path family, API-method family, parameter pattern, request timing, ADC asset group, exposure class, virtual-service family, backend-pool family, and bounded time window.

·        Prioritize production, internet-facing, partner-reachable, authentication-fronting, TLS-terminating, high-availability, and critical application-delivery appliances.

·        Suppress approved enterprise vulnerability scanning, vendor advisory validation, patch verification, synthetic monitoring, health checks, red-team activity, and documented incident-response sweeps.

DRI Assessment

This rule has strong reliability for identifying coordinated exploit-attempt behavior and campaign-like targeting, but compromise confidence depends on post-access evidence. The rule is useful across ADC, load balancer, reverse proxy, WAF-adjacent, and traffic-management assets because it correlates source behavior, request families, exposure classes, affected appliance groups, and post-access effects instead of a single payload or CVE identifier. Reliability depends on multi-asset inventory quality, source normalization, and exception tuning.

DRI

8.5

TCR Assessment

Operational TCR is strong where Splunk receives WAF, CDN, reverse-proxy, load-balancer, ADC, DNS, proxy, firewall, NDR, flow, source-enrichment, and inventory data across multiple appliances. Full-Telemetry TCR improves when configuration-change records, certificate records, administrative audit logs, downstream application logs, appliance health events, and endpoint telemetry can be joined to campaign clusters.

Operational TCR

8.3

Full-Telemetry TCR

9.0

Limitations

·        Multi-asset probing may reflect approved scanning, vendor validation, synthetic monitoring, patch verification, red-team activity, or incident-response review if exceptions are incomplete.

·        This rule should not claim confirmed compromise unless post-access appliance, configuration, certificate, egress, administrative, or downstream application evidence is present.

·        Organizations with only one ADC appliance may receive limited value from this campaign-correlation logic.

·        CDN, NAT, proxy, and partner network paths may obscure true source identity or inflate source-clustering confidence.

·        Similar request paths across appliances may indicate exposure discovery rather than successful exploitation.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support multi-appliance ADC asset grouping, WAF logs, CDN logs, reverse-proxy logs, load-balancer logs, appliance logs, DNS, proxy, firewall, NDR, flow telemetry, source clustering, request-family matching, exposure classification, ADC asset inventory, virtual-service grouping, backend-pool grouping, source enrichment, approved scanner context, approved vendor-support context, red-team context, maintenance-window context, rare egress joins, configuration-change joins, certificate-object joins, downstream application joins, and campaign-correlation logic. Customer-specific indexes, sourcetypes, field names, CIM mappings, macros, accelerated data sources, summary indexes, and local enrichment should be abstracted behind macros and lookups.

adc_multi_asset_control_plane_events
| eval normalized_time=coalesce(_time, event_time, EventTime, timestamp)
| eval normalized_adc_asset=coalesce(adc_asset_id, asset_id, dest_asset_id, device_id, host, dest, dest_host, destination_host, appliance_name)
| eval normalized_destination_host=coalesce(dest_host, destination_host, url_domain, host, dvc, device_name)
| eval normalized_destination_ip=coalesce(dest_ip, destination_ip, daddr, dst, dest)
| eval normalized_source_ip=coalesce(src_ip, source_ip, client_ip, c_ip, src)
| eval normalized_forwarded_source_ip=coalesce(x_forwarded_for, forwarded_for, true_client_ip, original_client_ip)
| eval normalized_source_network=coalesce(source_network, src_network, cidr, src_cidr)
| eval normalized_source_asn=coalesce(src_asn, source_asn, client_asn)
| eval normalized_source_geo=coalesce(src_geo, source_geo, client_geo, src_country)
| eval normalized_source_network_type=coalesce(source_network_type, src_network_type, client_network_type)
| eval normalized_user_agent=coalesce(user_agent, http_user_agent, cs_user_agent)
| eval normalized_request_path=coalesce(uri_path, url_path, request_path, cs_uri_stem, path)
| eval normalized_request_query=coalesce(uri_query, query_string, request_query, cs_uri_query)
| eval normalized_request_method=coalesce(http_method, method, request_method, cs_method)
| eval normalized_status=coalesce(status, http_status, sc_status, response_status)
| eval normalized_dest_domain=coalesce(dest_domain, destination_domain, query, domain, url_domain)
| eval normalized_egress_ip=coalesce(dest_ip, destination_ip, daddr, dst)
| eval normalized_egress_port=coalesce(dest_port, destination_port, dpt)
| eval normalized_configuration_object=coalesce(configuration_object, object, object_name, resource, resource_name, config_path)
| eval normalized_certificate_object=coalesce(certificate_object, cert_name, certificate_name, key_name, tls_object, binding_name)
| eval normalized_change_type=coalesce(change_type, event_type, EventType, signature, operation_type)
| eval normalized_downstream_behavior=coalesce(downstream_behavior, application_behavior, backend_behavior, app_anomaly)
| lookup ENV_ADC_EDGE_ASSETS normalized_adc_asset OUTPUT adc_asset_match adc_asset_id adc_asset_role exposure_class asset_criticality adc_asset_group
| lookup ENV_ADC_EDGE_ASSETS normalized_destination_host OUTPUT adc_destination_match adc_destination_asset_id
| lookup ENV_ADC_MANAGEMENT_OR_API_SURFACES normalized_request_path OUTPUT adc_management_path_match request_path_family
| lookup ENV_ADC_API_METHOD_FAMILIES normalized_request_method OUTPUT api_method_family
| lookup ENV_ADC_PARAMETER_FAMILIES normalized_request_query OUTPUT request_parameter_family
| lookup ENV_APPROVED_ADC_SOURCE_EXCEPTIONS normalized_source_ip OUTPUT approved_source_ip
| lookup ENV_APPROVED_ADC_SOURCE_EXCEPTIONS normalized_forwarded_source_ip OUTPUT approved_forwarded_source_ip
| lookup ENV_APPROVED_ADC_CONTEXT_EXCEPTIONS normalized_time OUTPUT approved_context_window
| lookup ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS normalized_request_path OUTPUT path_exploit_pattern_match path_exploit_family
| lookup ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS normalized_request_query OUTPUT query_exploit_pattern_match query_exploit_family
| lookup ENV_APPROVED_ADC_EGRESS normalized_dest_domain OUTPUT approved_dest_domain
| lookup ENV_APPROVED_ADC_EGRESS normalized_egress_ip OUTPUT approved_dest_ip
| lookup ENV_ADC_PROTECTED_CONFIGURATION_OBJECTS normalized_configuration_object OUTPUT protected_configuration_match configuration_object_family
| lookup ENV_ADC_CERTIFICATE_AND_TLS_OBJECTS normalized_certificate_object OUTPUT protected_certificate_match certificate_object_family
| lookup ENV_DESTINATION_ENRICHMENT normalized_dest_domain OUTPUT destination_first_seen_status destination_domain_age_days destination_reputation destination_asn destination_geo
| lookup ENV_DESTINATION_ENRICHMENT normalized_egress_ip OUTPUT ip_first_seen_status ip_reputation ip_asn ip_geo
| where adc_asset_match="true" OR adc_destination_match="true"
| where approved_context_window!="true"
| eval suspicious_adc_control_plane_probe=if(adc_management_path_match="true" AND approved_source_ip!="true" AND approved_forwarded_source_ip!="true" AND (normalized_source_asn IN ENV_SUSPICIOUS_ASNS OR normalized_source_network_type IN ("cloud_hosted","residential_proxy","vpn_provider","scanner_infrastructure","unknown_hosting") OR normalized_source_geo NOT IN ENV_ADC_EXPECTED_ADMIN_SOURCE_GEOS OR normalized_user_agent IN ENV_RARE_OR_AUTOMATED_USER_AGENTS OR path_exploit_pattern_match="true" OR query_exploit_pattern_match="true" OR normalized_status IN (400,401,403,404,500,502,503,504)), "true", "false")
| eval request_cluster_key=coalesce(normalized_source_ip, normalized_forwarded_source_ip, normalized_source_network) . "|" . coalesce(normalized_source_asn,"unknown_asn") . "|" . coalesce(normalized_user_agent,"unknown_user_agent") . "|" . coalesce(request_path_family,"unknown_path_family") . "|" . coalesce(api_method_family,"unknown_api_method") . "|" . coalesce(request_parameter_family,"unknown_parameter_family")
| eval rare_adc_egress=if((isnotnull(normalized_dest_domain) OR isnotnull(normalized_egress_ip)) AND (isnull(normalized_dest_domain) OR approved_dest_domain!="true") AND (isnull(normalized_egress_ip) OR approved_dest_ip!="true") AND (destination_first_seen_status IN ("new","rare") OR ip_first_seen_status IN ("new","rare") OR destination_domain_age_days < ENV_NEW_DOMAIN_AGE_DAYS OR destination_reputation IN ("unknown","suspicious","malicious") OR ip_reputation IN ("unknown","suspicious","malicious") OR destination_asn IN ENV_SUSPICIOUS_ASNS OR ip_asn IN ENV_SUSPICIOUS_ASNS OR destination_geo NOT IN ENV_ADC_EXPECTED_EGRESS_GEOS OR ip_geo NOT IN ENV_ADC_EXPECTED_EGRESS_GEOS OR normalized_egress_port IN ENV_UNUSUAL_ADC_EGRESS_PORTS), "true", "false")
| eval post_access_behavior=if(rare_adc_egress="true" OR protected_configuration_match="true" OR protected_certificate_match="true" OR normalized_change_type IN ("virtual_service_modified","backend_pool_modified","routing_rule_modified","rewrite_rule_modified","header_rule_modified","certificate_binding_modified","tls_offload_modified","logging_setting_modified","administrative_setting_modified","api_key_created","admin_user_created","admin_role_modified") OR normalized_status IN (500,502,503,504) OR normalized_downstream_behavior IN ("unexpected_backend_access","authentication_flow_change","session_routing_change","header_manipulation","traffic_mirroring_suspected","data_exposure_like_response","availability_degradation"), "true", "false")
| stats min(normalized_time) as first_seen max(normalized_time) as last_seen dc(normalized_adc_asset) as affected_adc_asset_count dc(adc_asset_group) as affected_adc_asset_group_count dc(exposure_class) as affected_exposure_class_count values(normalized_adc_asset) as affected_adc_assets values(adc_asset_group) as affected_adc_asset_groups values(exposure_class) as affected_exposure_classes values(asset_criticality) as affected_asset_criticality values(normalized_destination_host) as destination_host values(normalized_destination_ip) as destination_ip values(normalized_source_ip) as source_ip values(normalized_forwarded_source_ip) as forwarded_source_ip values(normalized_source_network) as source_network values(normalized_source_asn) as source_asn values(normalized_source_geo) as source_geo values(normalized_source_network_type) as source_network_type values(normalized_user_agent) as user_agent values(request_path_family) as request_path_family values(api_method_family) as api_method_family values(request_parameter_family) as request_parameter_family values(normalized_status) as http_status values(rare_adc_egress) as rare_adc_egress values(protected_configuration_match) as protected_configuration_match values(protected_certificate_match) as protected_certificate_match values(normalized_change_type) as change_type values(normalized_downstream_behavior) as downstream_behavior values(post_access_behavior) as post_access_behavior by request_cluster_key
| where affected_adc_asset_count>=ENV_MULTI_ADC_MINIMUM_ASSET_COUNT
| where affected_adc_asset_group_count>=ENV_MULTI_ADC_MINIMUM_GROUP_COUNT OR affected_exposure_class_count>=ENV_MULTI_ADC_MINIMUM_EXPOSURE_CLASS_COUNT OR mvfind(affected_asset_criticality,"critical")>=0 OR mvfind(affected_asset_criticality,"high")>=0
| where mvfind(post_access_behavior,"true")>=0
| eval event_kind="multiple_adc_assets_showing_related_control_plane_probing_or_post_access_behavior"
| table first_seen last_seen request_cluster_key affected_adc_asset_count affected_adc_asset_group_count affected_exposure_class_count affected_adc_assets affected_adc_asset_groups affected_exposure_classes affected_asset_criticality destination_host destination_ip source_ip forwarded_source_ip source_network source_asn source_geo source_network_type user_agent request_path_family api_method_family request_parameter_family http_status rare_adc_egress protected_configuration_match protected_certificate_match change_type downstream_behavior post_access_behavior event_kind

Rule

ADC Traffic-Processing Activity Followed by Appliance Instability or Availability Impact

Rule Format

Splunk SPL correlation search.

Detection Purpose

Detect suspicious traffic delivered to ADC listeners, virtual services, protocol handlers, NAT functions, ALGs, or other externally reachable traffic-processing functions followed by appliance instability, process or service failure, restart or failover behavior, resource exhaustion, abnormal connection behavior, or downstream availability degradation. This rule provides a traffic-processing exploitation path independent of ADC management/API activity.

Detection Logic

Normalize ADC traffic-facing network, protocol, appliance-health, and downstream-application events. Identify abnormal or exploit-shaped traffic through source rarity, malformed or protocol-inconsistent behavior, abnormal message size, abnormal transaction patterns, repeated invalid requests, unusual cadence, or locally maintained traffic-processing exploit patterns.

Correlate suspicious traffic-processing activity with subsequent appliance crash, watchdog event, service restart, appliance reboot, unexpected HA transition, failover, resource exhaustion, connection reset, timeout, service unavailability, or downstream application availability degradation. Require the suspicious initiating activity and independent impact before alert promotion.

Required Telemetry

·        ADC listener, virtual-service, WAF, reverse-proxy, load-balancer, gateway, NDR, firewall, flow, or protocol telemetry.

·        ADC appliance syslog, system-health, service-health, watchdog, restart, reboot, HA, failover, diagnostic, or resource telemetry.

·        ADC appliance, listener, virtual-service, traffic-processing function, protocol, backend, and downstream application inventory.

·        Source and destination addressing, protocol, message or request size, connection state, timestamp, and traffic-processing context where available.

·        Splunk lookups or macros for asset identity, traffic-processing surfaces, expected protocol behavior, approved sources, approved maintenance, and downstream mappings.

Engineering Implementation Instructions

·        Deploy in hunt mode until traffic-facing ADC fields, asset identities, listener mappings, protocol fields, system-health fields, and downstream mappings are normalized.

·        Abstract local indexes, sourcetypes, CIM mappings, field names, asset lookups, protocol baselines, and maintenance windows through macros and lookups.

·        Require independent appliance-health or downstream availability evidence before alert promotion.

·        Preserve current management/API rules separately; do not merge the control-plane and traffic-processing initiators.

·        For CVE-2026-19489-specific use, populate local lookups identifying NetScaler assets, SIP-facing listeners or addresses, SIP ALG-enabled configuration, LSN groups, and associated appliance-health telemetry.

DRI Assessment

This rule has high detection reliability because the SPL requires temporal correlation between suspicious ADC traffic-processing activity and independent appliance or availability effects. It remains useful across protocol and vendor changes because the rule is built around normalized traffic-processing behavior rather than a specific exploit signature.

DRI

8.9

TCR Assessment

Operational TCR is strong where Splunk receives network or protocol telemetry plus basic appliance-health or availability telemetry. Full-Telemetry TCR is highest when service-health, HA, failover, resource, listener, virtual-service, downstream application, and traffic-processing configuration data are normalized and joined.

Operational TCR

8.6

Full-Telemetry TCR

9.3

Limitations

·        Payload or protocol metadata may be incomplete.

·        Appliance-health events may not preserve the triggering connection.

·        NAT, reverse proxies, or upstream load balancing may obscure the originating source.

·        Legitimate protocol errors, load testing, maintenance, failover testing, or capacity events may resemble malicious activity.

·        The rule detects correlated behavior and cannot independently prove the precise memory-corruption mechanism.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments with normalized ADC traffic-facing network, protocol, appliance-health, HA, resource, and downstream availability telemetry. Local indexes, sourcetypes, macros, field names, CIM mappings, and lookups must be adapted to the environment.

adc_traffic_processing_and_health_events

| eval normalized_time=coalesce(_time,event_time,EventTime,timestamp)

| eval normalized_adc_asset=coalesce(adc_asset_id,asset_id,dest_asset_id,device_id,host,dest_host,destination_host,appliance_name)

| eval normalized_source_ip=coalesce(src_ip,source_ip,client_ip,c_ip,src)

| eval normalized_destination_ip=coalesce(dest_ip,destination_ip,daddr,dst)

| eval normalized_destination_port=coalesce(dest_port,destination_port,dpt)

| eval normalized_interface=coalesce(traffic_facing_interface,listener_interface,local_interface,dest_interface,interface)

| eval normalized_listener=coalesce(listener,listener_name,frontend_listener,service_listener)

| eval normalized_virtual_service=coalesce(virtual_service,vip,service_name,frontend_name,app_service)

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

| eval normalized_protocol_handler=coalesce(protocol_handler,parser,application_handler,traffic_handler)

| eval normalized_processing_function=coalesce(traffic_processing_function,nat_function,alg_function,processing_module)

| eval normalized_message_size=coalesce(message_size,request_size,bytes_in,packet_payload_size)

| eval normalized_protocol_behavior=coalesce(protocol_behavior,message_behavior,transaction_behavior,parser_behavior)

| eval normalized_connection_state=coalesce(connection_state,network_action,session_state)

| eval normalized_health_event=coalesce(appliance_health_event,health_event,system_event,service_event,ha_event)

| eval normalized_downstream_behavior=coalesce(downstream_behavior,application_behavior,availability_behavior)

| lookup ENV_ADC_EDGE_ASSETS normalized_adc_asset OUTPUT adc_asset_match adc_asset_id adc_asset_role exposure_class asset_criticality

| lookup ENV_ADC_TRAFFIC_PROCESSING_SURFACES normalized_listener OUTPUT listener_match traffic_processing_family

| lookup ENV_ADC_TRAFFIC_PROCESSING_SURFACES normalized_virtual_service OUTPUT virtual_service_match

| lookup ENV_APPROVED_ADC_TRAFFIC_SOURCES normalized_source_ip OUTPUT approved_source

| lookup ENV_APPROVED_ADC_CONTEXT_WINDOWS normalized_time OUTPUT approved_context_window

| lookup ENV_ADC_SOURCE_ENRICHMENT normalized_source_ip OUTPUT source_first_seen_status source_asn source_geo source_network_type

| where adc_asset_match="true" AND approved_context_window!="true"

| eval suspicious_traffic_processing_activity=if(

    approved_source!="true"

    AND (

        listener_match="true"

        OR virtual_service_match="true"

        OR isnotnull(normalized_processing_function)

    )

    AND (

        source_first_seen_status IN ("new","rare")

        OR source_asn IN ENV_SUSPICIOUS_ASNS

        OR source_network_type IN ("cloud_hosted","residential_proxy","vpn_provider","scanner_infrastructure","unknown_hosting")

        OR normalized_protocol_behavior IN ("malformed","protocol_inconsistent","unexpected_sequence","fuzzing_like","abnormal_transaction")

        OR normalized_message_size > ENV_ADC_PROTOCOL_MESSAGE_SIZE_UPPER_BASELINE

        OR normalized_message_size < ENV_ADC_PROTOCOL_MESSAGE_SIZE_LOWER_BASELINE

        OR normalized_connection_state IN ("rapid_retry","repeated_invalid_request","unexpected_disconnect","abnormal_retransmission")

    ),

    "true","false"

)

| eval adc_instability_or_availability_impact=if(

    normalized_health_event IN (

        "process_crash","service_crash","watchdog_restart","service_restart",

        "appliance_reboot","unexpected_failover","ha_state_change",

        "resource_exhaustion","resource_pressure","traffic_processing_fault"

    )

    OR normalized_connection_state IN ("timeout","reset","closed_after_error","service_unavailable")

    OR normalized_downstream_behavior IN (

        "availability_degradation","backend_connection_loss",

        "application_unreachable","traffic_path_disruption"

    ),

    "true","false"

)

| eventstats min(eval(if(suspicious_traffic_processing_activity="true",normalized_time,null()))) as first_suspicious_traffic_time by normalized_adc_asset normalized_listener normalized_virtual_service normalized_protocol

| eval post_processing_impact=if(

    adc_instability_or_availability_impact="true"

    AND normalized_time>=first_suspicious_traffic_time

    AND normalized_time<=first_suspicious_traffic_time+ENV_ADC_TRAFFIC_PROCESSING_TO_INSTABILITY_WINDOW,

    "true","false"

)

| where suspicious_traffic_processing_activity="true" OR post_processing_impact="true"

| stats min(normalized_time) as first_seen max(normalized_time) as last_seen

    values(normalized_source_ip) as source_ip

    values(normalized_destination_ip) as destination_ip

    values(normalized_destination_port) as destination_port

    values(normalized_interface) as traffic_facing_interface

    values(normalized_listener) as listener

    values(normalized_virtual_service) as virtual_service

    values(normalized_protocol) as protocol

    values(normalized_protocol_handler) as protocol_handler

    values(normalized_processing_function) as traffic_processing_function

    values(normalized_message_size) as message_size

    values(normalized_protocol_behavior) as protocol_behavior

    values(normalized_connection_state) as connection_state

    values(normalized_health_event) as appliance_health_event

    values(normalized_downstream_behavior) as downstream_behavior

    values(suspicious_traffic_processing_activity) as suspicious_traffic_processing_activity

    values(post_processing_impact) as post_processing_impact

    by normalized_adc_asset adc_asset_id adc_asset_role exposure_class asset_criticality

| where mvfind(suspicious_traffic_processing_activity,"true")>=0

    AND mvfind(post_processing_impact,"true")>=0

| eval event_kind="adc_traffic_processing_activity_followed_by_instability_or_availability_impact"

Elastic

Detection Viability Assessment

Elastic is highly viable for this behavior family when ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS, proxy, firewall, NDR, endpoint telemetry where available, configuration-change records, certificate-management records, and downstream application logs are normalized into searchable data streams. Elastic should be used to correlate behavior sequences rather than isolated request strings, vulnerable-version findings, CVE names, scanner hits, KEV status, or public proof-of-concept indicators alone. The strongest Elastic detections correlate suspicious ADC control-plane access with appliance instability, configuration or certificate access, virtual-service manipulation, rare egress, administrative-control change, logging degradation, or downstream application exposure.

Rule

ADC Control-Plane Access Followed by Appliance Instability or Rare Egress

Rule Format

Elastic EQL or correlation rule.

Detection Purpose

Detect suspicious ADC management/API, administrative, diagnostic, authentication, telemetry, or configuration access followed by appliance instability, abnormal response behavior, failed-to-success control-plane sequencing, or rare outbound communication from the ADC appliance. This rule is intended to identify behavior consistent with pre-authentication or weakly authenticated ADC control-plane exploitation, including Progress Kemp LoadMaster CVE-2026-8037-like activity where locally visible, without making detection dependent on one vendor, endpoint path, CVE name, proof-of-concept string, or scanner signature.

Detection Logic

Identify suspicious requests to ADC control-plane surfaces from external, unfamiliar, newly seen, partner-originated, scanner-like, automation-like, or non-administrative sources. Increase confidence when the request contains command-delimiter, shell-control, quote-manipulation, encoded, malformed JSON, oversized, authentication-bypass, API-parameter manipulation, abnormal method, or abnormal response-size behavior. Promote only when suspicious access is followed within a bounded time window by appliance instability, abnormal HTTP status sequencing, API handler failure, management-service fault, connection reset, timeout, watchdog or restart behavior where logged, or rare ADC-originated DNS, HTTP, HTTPS, SSH, SMTP, raw-IP, file-transfer, tunneling, or command-and-control-like communication.

Required Telemetry

·        ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, appliance syslog, and administrative audit logs where available.

·        DNS, proxy, firewall, NDR, NetFlow, VPC flow, data-center flow, or endpoint-network telemetry for ADC-originated outbound communication.

·        ADC appliance inventory, management-interface inventory, API exposure inventory, virtual-service inventory, backend-pool inventory, approved administrative source inventory, approved partner path inventory, and approved maintenance-window context.

·        Destination enrichment for first-seen status, domain age, ASN, geography, reputation, destination port, protocol, proxy action, and firewall action.

·        Elastic enrich policies, value lists, exception lists, transforms, data views, ECS mappings, runtime fields, and local normalized fields for ADC asset identity, request paths, forwarded source, destination identity, egress baselines, and maintenance context.

Engineering Implementation Instructions

·        Deploy first in hunt mode to validate ADC log onboarding, request-path preservation, query-string preservation, forwarded-source extraction, appliance identity joins, virtual-service mapping, backend-pool mapping, and egress attribution.

·        Use enrich policies, value lists, exception lists, transforms, data views, and local runtime fields to abstract customer-specific data streams, index names, field names, ECS mappings, asset inventories, source exceptions, destination exceptions, and maintenance windows.

·        Tune approved administrative networks, partner-reachable paths, vendor support sources, vulnerability scanners, patch-validation sources, monitoring systems, health checks, backups, license validation, update destinations, and maintenance windows before alert promotion.

·        Correlate by ADC appliance, management interface, destination host, destination IP, source IP, forwarded source IP, source network, API path, API method, virtual service, backend pool, destination domain, destination IP, and bounded time window.

·        Treat suspicious management/API access alone as exploit-attempt evidence, not confirmed compromise.

·        Promote severity when suspicious access is followed by appliance instability, rare egress, repeated callbacks, internal service access, or abnormal response sequencing.

DRI Assessment

This rule has high detection reliability because it anchors on a sequence of suspicious ADC control-plane access followed by instability or rare appliance-originated communication. It is resilient across ADC, load balancer, reverse proxy, WAF-adjacent, and edge traffic-management compromise scenarios because it does not depend on a single Progress Kemp LoadMaster endpoint, public exploit string, user agent, or CVE identifier. Reliability depends on request-path visibility, forwarded-source preservation, ADC inventory quality, egress baselining, and consistent field normalization.

DRI

8.7

TCR Assessment

Operational TCR is strong where Elastic receives ADC management/API logs, WAF or reverse-proxy logs, DNS, proxy, firewall, NDR, asset inventory, source exceptions, and approved-egress enrichments. Full-Telemetry TCR improves when appliance syslog, configuration-change records, certificate records, administrative audit logs, downstream application logs, and endpoint telemetry are joined to the same sequence.

Operational TCR

8.4

Full-Telemetry TCR

9.1

Limitations

·        This rule cannot confirm command execution without appliance process, shell, diagnostic, system, endpoint, or vendor log evidence.

·        Request-body loss, query-string redaction, CDN layering, NAT, proxy forwarding, or incomplete forwarded-source preservation may reduce confidence.

·        Rare egress may reflect approved vendor support, update retrieval, license validation, backup, monitoring, troubleshooting, or incident-response activity if exception lists are incomplete.

·        Appliance instability may result from benign patching, failover testing, resource exhaustion, configuration error, or maintenance activity.

·        Vulnerable-version status, public PoC availability, scanner traffic, or KEV status must not be treated as standalone compromise confirmation.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS, proxy, firewall, NDR, flow telemetry, ADC asset mapping, management-interface awareness, API exposure awareness, URI and query-string preservation, forwarded-source extraction, status sequencing, response-size baselining, source enrichment, destination enrichment, egress baselining, maintenance-window context, virtual-service joins, backend-pool joins, and appliance identity joins. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

sequence by adc.asset.id with maxspan=ENV_ADC_CONTROL_PLANE_ACCESS_TO_EGRESS_WINDOW
[any where
event.dataset : ENV_ADC_CONTROL_PLANE_DATASET_PATTERN and
adc.asset.edge == true and
exception.approved_adc_context != true and
exception.approved_adc_source != true and
url.path : ENV_ADC_MANAGEMENT_OR_API_SURFACES and
(
source.first_seen.status in ("new", "rare") or
source.as.number in ENV_SUSPICIOUS_ASNS or
source.network.type in ("cloud_hosted", "residential_proxy", "vpn_provider", "scanner_infrastructure", "unknown_hosting") or
baseline.adc.expected_admin_source_geo_match != true or
http.request.method not in ENV_EXPECTED_ADC_MANAGEMENT_METHODS or
user_agent.original in ENV_RARE_OR_AUTOMATED_USER_AGENTS or
url.path : ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS or
url.query : ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS or
http.request.body.content : ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS or
http.request.bytes > ENV_ADC_MANAGEMENT_REQUEST_SIZE_UPPER_BASELINE or
http.response.bytes > ENV_ADC_MANAGEMENT_RESPONSE_SIZE_UPPER_BASELINE or
http.response.bytes < ENV_ADC_MANAGEMENT_RESPONSE_SIZE_LOWER_BASELINE or
http.response.status_code in (400, 401, 403, 404, 500, 502, 503, 504) or
adc.http.status_sequence in ("repeated_errors", "errors_then_success", "failed_then_success", "abnormal_redirect_sequence", "control_plane_instability_sequence") or
adc.request.timing_pattern in ("rapid_retry", "automation_like", "low_and_slow_probe", "failed_then_successful_access", "parameter_fuzzing")
)
]
[any where
event.dataset : ENV_ADC_NETWORK_OR_APPLIANCE_DATASET_PATTERN and
adc.asset.edge == true and
exception.approved_adc_context != true and
(
(
url.path : ENV_ADC_MANAGEMENT_OR_API_SURFACES and
(
http.response.status_code in (400, 401, 403, 404, 500, 502, 503, 504) or
network.action in ("timeout", "reset", "closed_after_error", "service_unavailable") or
adc.http.status_sequence in ("repeated_errors", "errors_then_success", "failed_then_success", "success_then_reset", "instability_after_api_access") or
adc.appliance.health_event in ("watchdog_restart", "service_restart", "management_service_fault", "api_handler_exception", "authentication_handler_error", "failover_event", "resource_exhaustion")
)
) or
(
(
destination.domain != null or
destination.ip != null
) and
(
destination.domain == null or
destination.domain not in ENV_APPROVED_ADC_EGRESS_DESTINATIONS
) and
(
destination.ip == null or
destination.ip not in ENV_APPROVED_ADC_EGRESS_DESTINATIONS
) and
(
destination.first_seen.status in ("new", "rare") or
destination.domain.age_days < ENV_NEW_DOMAIN_AGE_DAYS or
destination.reputation in ("unknown", "suspicious", "malicious") or
destination.as.number in ENV_SUSPICIOUS_ASNS or
baseline.adc.expected_destination_geo_match != true or
destination.port in ENV_UNUSUAL_ADC_EGRESS_PORTS or
network.protocol in ("ssh", "smtp", "raw_ip", "unknown", "tunnel", "file_transfer") or
network.action in ("allowed", "connected", "proxied")
)
)
)
]

Rule

ADC Control-Plane Access Followed by Configuration, Certificate, or Traffic-Path Manipulation

Rule Format

Elastic EQL or correlation rule.

Detection Purpose

Detect suspicious ADC management/API access followed by configuration exposure, configuration change, virtual-service manipulation, backend-pool modification, routing or header-control changes, TLS or certificate-object access, backup or diagnostic artifact access, administrative-control change, logging degradation, or downstream application traffic-path anomalies. This rule is intended to identify compromise behavior affecting the edge application-delivery trust boundary rather than only the vulnerable appliance.

Detection Logic

Identify suspicious control-plane access to ADC management, API, administrative, diagnostic, authentication, telemetry, or configuration surfaces. Correlate that access with subsequent configuration-object access, virtual-service modification, backend-pool modification, route or rewrite change, header manipulation, persistence-profile change, health-check change, SSL/TLS offload change, certificate binding change, private-key access, backup export, diagnostic bundle creation, packet capture creation, API token access, administrative setting modification, logging change, or downstream application anomaly. Promote only when post-access behavior aligns by ADC appliance, management interface, source, virtual service, backend pool, configuration object, certificate object, downstream application, or bounded time window.

Required Telemetry

·        ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, appliance syslog, administrative audit logs, and configuration-change records.

·        Certificate-management records, TLS binding records, configuration export records, backup records, diagnostic bundle records, packet capture records, administrative-user records, API key records, and logging-setting records where available.

·        Downstream web server logs, downstream application logs, identity logs, backend service logs, WAF logs, proxy logs, NDR, DNS, proxy, firewall, and flow telemetry.

·        ADC appliance inventory, virtual-service inventory, backend-pool inventory, certificate inventory, TLS-offload inventory, route inventory, header-rule inventory, rewrite-rule inventory, approved change records, and maintenance-window context.

·        Elastic enrich policies, value lists, exception lists, transforms, data views, ECS mappings, runtime fields, and local normalized fields for ADC objects, protected configuration families, certificate families, downstream application identity, approved changes, and approved administrative workflows.

Engineering Implementation Instructions

·        Deploy first in hunt mode until ADC configuration-object normalization, certificate-object mapping, virtual-service mapping, backend-pool mapping, downstream application mapping, and approved change exception lists are validated.

·        Require sequence correlation before alert promotion.

·        Correlate suspicious access with configuration, certificate, traffic-path, administrative, logging, or downstream behavior by ADC appliance, management interface, API endpoint, source IP, forwarded source IP, administrative identity where available, configuration object, certificate object, virtual service, backend pool, downstream application, and bounded time window.

·        Suppress known-good certificate rotation, key rotation, virtual-service changes, backend-pool changes, routing changes, health-check tuning, backup jobs, diagnostic collection, vendor support, failover testing, monitoring activity, emergency maintenance, and documented incident-response collection.

·        Treat downstream application anomalies as ADC-related only when they follow suspicious ADC control-plane behavior and align by virtual service, backend host, route, header behavior, source path, source identity, or time window.

·        Escalate when certificate or private-key access, backup export, diagnostic bundle creation, configuration export, logging degradation, administrative-control change, traffic mirroring, or downstream application exposure follows suspicious management/API access.

DRI Assessment

This rule has high detection reliability because it focuses on protected ADC trust-boundary objects and downstream consequences that are difficult to explain through scanner traffic alone. It remains reusable across ADC, load balancer, reverse proxy, WAF-adjacent, and edge traffic-management compromise scenarios because it anchors on configuration, certificate, routing, and traffic-path manipulation rather than a single vendor endpoint. Reliability depends on configuration visibility, object normalization, virtual-service mapping, certificate records, and approved change context.

DRI

8.6

TCR Assessment

Operational TCR is strong when Elastic receives ADC management/API logs, configuration-change records, WAF or reverse-proxy logs, asset inventory, approved change records, and NDR telemetry. Full-Telemetry TCR improves when certificate-management records, backup comparison, administrative audit logs, endpoint telemetry, downstream application logs, and virtual-service-to-backend mappings are available.

Operational TCR

8.2

Full-Telemetry TCR

9.0

Limitations

·        This rule may miss object-level access if ADC appliances do not log configuration reads, certificate reads, private-key access, backup creation, diagnostic bundle creation, or administrative API actions.

·        Approved backup, certificate renewal, vendor support, emergency routing changes, failover testing, patch validation, and incident-response collection may resemble suspicious post-access behavior.

·        Downstream application anomalies cannot be attributed to ADC compromise without linkage to ADC appliance, virtual service, backend mapping, request path, source, administrative action, or time window.

·        Configuration export timestamps may reflect backup, migration, restoration, failover, or maintenance rather than the original attacker action.

·        Elastic correlation quality depends on field normalization, asset mapping, configuration object mapping, and reliable approved-change exception lists.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, administrative audit logs, configuration-change records, certificate-management records, downstream application logs, DNS, proxy, firewall, NDR, flow telemetry, ADC asset mapping, configuration-object awareness, certificate-object awareness, virtual-service awareness, backend-pool mapping, TLS-offload mapping, route and header behavior matching, approved workflow exceptions, maintenance-window context, and downstream application joins. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

sequence by adc.asset.id with maxspan=ENV_ADC_CONTROL_PLANE_ACCESS_TO_DOWNSTREAM_IMPACT_WINDOW
[any where
event.dataset : ENV_ADC_CONTROL_PLANE_DATASET_PATTERN and
adc.asset.edge == true and
exception.approved_adc_context != true and
exception.approved_adc_source != true and
url.path : ENV_ADC_MANAGEMENT_OR_API_SURFACES and
(
url.path : ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS or
url.query : ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS or
http.request.body.content : ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS or
source.first_seen.status in ("new", "rare") or
source.as.number in ENV_SUSPICIOUS_ASNS or
source.network.type in ("cloud_hosted", "residential_proxy", "vpn_provider", "scanner_infrastructure", "unknown_hosting") or
baseline.adc.expected_admin_source_geo_match != true or
user_agent.original in ENV_RARE_OR_AUTOMATED_USER_AGENTS or
http.request.method not in ENV_EXPECTED_ADC_MANAGEMENT_METHODS or
http.response.status_code in (400, 401, 403, 404, 500, 502, 503, 504)
)
]
[any where
event.dataset : ENV_ADC_CONFIGURATION_CERTIFICATE_OR_DOWNSTREAM_DATASET_PATTERN and
adc.asset.edge == true and
exception.approved_adc_context != true and
(
(
adc.configuration.object.protected == true and
event.action in ("read", "export", "download", "create", "modify", "delete", "replace", "backup")
) or
(
adc.certificate.object.protected == true and
event.action in ("read", "export", "download", "bind", "unbind", "modify", "delete")
) or
(
adc.backup.object == true and
event.action in ("create", "export", "download", "archive")
) or
(
adc.diagnostic.bundle == true and
event.action in ("create", "export", "download")
) or
(
adc.packet_capture == true and
event.action in ("create", "read", "export", "download")
) or
(
adc.traffic_path.change_type in ("virtual_service_modified", "backend_pool_modified", "routing_rule_modified", "rewrite_rule_modified", "header_rule_modified", "certificate_binding_modified", "tls_offload_modified", "persistence_profile_modified", "health_check_modified", "logging_setting_modified", "administrative_setting_modified", "api_key_created", "admin_user_created", "admin_role_modified")
) or
(
adc.header.behavior in ("new_header_added", "header_removed", "header_rewritten", "forwarded_for_anomaly", "host_header_anomaly")
) or
(
adc.route.behavior in ("unexpected_route", "unexpected_backend_selection", "traffic_mirroring_suspected")
) or
(
adc.tls.behavior in ("certificate_binding_change", "tls_termination_change", "unexpected_plaintext_backend_flow", "unexpected_tls_offload_path")
) or
(
downstream.application.behavior in ("unexpected_backend_access", "authentication_flow_change", "session_routing_change", "header_manipulation", "traffic_mirroring_suspected", "data_exposure_like_response", "availability_degradation")
)
) and
exception.approved_adc_change_actor != true and
exception.approved_adc_traffic_path_change != true
]

Rule

Multiple ADC Assets Showing Related Control-Plane Probing or Post-Access Behavior

Rule Format

Elastic EQL or threshold correlation rule.

Detection Purpose

Detect campaign-like activity across multiple ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management assets where related control-plane probing, exploit-attempt behavior, instability, rare egress, configuration access, certificate access, virtual-service changes, or downstream anomalies appear within a bounded time window. This rule is intended to identify coordinated targeting or exposure review without assuming confirmed compromise from multi-asset scanner traffic alone.

Detection Logic

Identify two or more ADC or edge traffic-management assets showing similar suspicious management/API access from the same source, forwarded source, source network, ASN, user agent, request-path family, API-method family, parameter family, timing pattern, or payload family. Promote confidence when at least one affected appliance also shows appliance instability, rare egress, configuration or certificate access, administrative-control change, virtual-service or backend-pool modification, logging degradation, or downstream traffic-path anomaly. Treat related multi-asset request activity without post-access behavior as exploit-attempt or exposure-review evidence, not confirmed compromise.

Required Telemetry

·        Elastic ingestion from ADC management/API logs, WAF logs, CDN logs, reverse-proxy logs, load-balancer logs, gateway logs, firewall logs, DNS logs, proxy logs, NDR, flow telemetry, appliance syslog, configuration-change logs, and downstream application logs.

·        ADC appliance inventory, internet-exposure inventory, partner-reachable path inventory, management-interface inventory, API exposure inventory, virtual-service inventory, backend-pool inventory, asset criticality, exposure class, and downstream application mapping.

·        Source enrichment for first-seen status, ASN, geography, network type, user agent, request cadence, scanner-like behavior, infrastructure clustering, shared source-network patterns, and reputation where available.

·        Approved scanners, approved administrative sources, vendor support sources, patch-validation sources, monitoring systems, synthetic checks, red-team sources, incident-response sources, and maintenance-window exception lists.

·        Elastic enrich policies, value lists, exception lists, transforms, data views, ECS mappings, runtime fields, and local normalized fields for multi-asset grouping, source clustering, request families, post-access behavior, and approved exception context.

Engineering Implementation Instructions

·        Deploy first in hunt mode to validate multi-asset thresholds, request-family normalization, source clustering, and exception handling.

·        Require at least two ADC or traffic-management assets before campaign-correlation logic triggers.

·        Require post-access behavior from at least one appliance before promoting beyond exploit-attempt or exposure-review confidence.

·        Correlate by source IP, forwarded source IP, source network, ASN, user agent, request-path family, API-method family, parameter pattern, request timing, ADC asset group, exposure class, virtual-service family, backend-pool family, and bounded time window.

·        Prioritize production, internet-facing, partner-reachable, authentication-fronting, TLS-terminating, high-availability, and critical application-delivery appliances.

·        Suppress approved enterprise vulnerability scanning, vendor advisory validation, patch verification, synthetic monitoring, health checks, red-team activity, and documented incident-response sweeps.

DRI Assessment

This rule has strong reliability for identifying coordinated exploit-attempt behavior and campaign-like targeting, but compromise confidence depends on post-access evidence. The rule is useful across ADC, load balancer, reverse proxy, WAF-adjacent, and traffic-management assets because it correlates source behavior, request families, exposure classes, affected appliance groups, and post-access effects instead of a single payload or CVE identifier. Reliability depends on multi-asset inventory quality, source normalization, and exception tuning.

DRI

8.4

TCR Assessment

Operational TCR is strong where Elastic receives WAF, CDN, reverse-proxy, load-balancer, ADC, DNS, proxy, firewall, NDR, flow, source-enrichment, and inventory data across multiple appliances. Full-Telemetry TCR improves when configuration-change records, certificate records, administrative audit logs, downstream application logs, appliance health events, and endpoint telemetry can be joined to campaign clusters.

Operational TCR

8.2

Full-Telemetry TCR

8.9

Limitations

·        Multi-asset probing may reflect approved scanning, vendor validation, synthetic monitoring, patch verification, red-team activity, or incident-response review if exception lists are incomplete.

·        This rule should not claim confirmed compromise unless post-access appliance, configuration, certificate, egress, administrative, or downstream application evidence is present.

·        Organizations with only one ADC appliance may receive limited value from this campaign-correlation logic.

·        CDN, NAT, proxy, and partner network paths may obscure true source identity or inflate source-clustering confidence.

·        Similar request paths across appliances may indicate exposure discovery rather than successful exploitation.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support multi-appliance ADC asset grouping, WAF logs, CDN logs, reverse-proxy logs, load-balancer logs, appliance logs, DNS, proxy, firewall, NDR, flow telemetry, source clustering, request-family matching, exposure classification, ADC asset inventory, virtual-service grouping, backend-pool grouping, source enrichment, approved scanner context, approved vendor-support context, red-team context, maintenance-window context, rare egress joins, configuration-change joins, certificate-object joins, downstream application joins, and campaign-correlation logic. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

any where
event.dataset : ENV_ADC_MULTI_ASSET_CONTROL_PLANE_DATASET_PATTERN and
adc.asset.edge == true and
exception.approved_adc_context != true and
exception.approved_adc_source != true and
url.path : ENV_ADC_MANAGEMENT_OR_API_SURFACES and
(
source.as.number in ENV_SUSPICIOUS_ASNS or
source.network.type in ("cloud_hosted", "residential_proxy", "vpn_provider", "scanner_infrastructure", "unknown_hosting") or
baseline.adc.expected_admin_source_geo_match != true or
user_agent.original in ENV_RARE_OR_AUTOMATED_USER_AGENTS or
url.path : ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS or
url.query : ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS or
http.response.status_code in (400, 401, 403, 404, 500, 502, 503, 504)
) and
adc.campaign.related_asset_count >= ENV_MULTI_ADC_MINIMUM_ASSET_COUNT and
(
adc.campaign.related_asset_group_count >= ENV_MULTI_ADC_MINIMUM_GROUP_COUNT or
adc.campaign.related_exposure_class_count >= ENV_MULTI_ADC_MINIMUM_EXPOSURE_CLASS_COUNT or
adc.asset.criticality in ("high", "critical")
) and
(
network.adc.rare_egress == true or
adc.configuration.object.protected == true or
adc.certificate.object.protected == true or
adc.traffic_path.change_type in ("virtual_service_modified", "backend_pool_modified", "routing_rule_modified", "rewrite_rule_modified", "header_rule_modified", "certificate_binding_modified", "tls_offload_modified", "logging_setting_modified", "administrative_setting_modified", "api_key_created", "admin_user_created", "admin_role_modified") or
adc.appliance.health_event in ("watchdog_restart", "service_restart", "management_service_fault", "api_handler_exception", "authentication_handler_error", "failover_event", "resource_exhaustion") or
downstream.application.behavior in ("unexpected_backend_access", "authentication_flow_change", "session_routing_change", "header_manipulation", "traffic_mirroring_suspected", "data_exposure_like_response", "availability_degradation")
)

Rule

ADC Traffic-Processing Activity Followed by Appliance Instability or Availability Impact

Rule Format

Elastic EQL correlation rule.

Detection Purpose

Detect suspicious external traffic against ADC listeners, virtual services, protocol handlers, NAT functions, ALGs, or other traffic-processing functions followed by appliance process or service faults, watchdog events, restart or failover behavior, resource exhaustion, connection disruption, or downstream availability degradation.

Detection Logic

Identify network or protocol events involving ADC traffic-processing surfaces where source characteristics or protocol behavior are anomalous, malformed, oversized, repeated, fuzzing-like, or otherwise inconsistent with established application behavior. Correlate those events by ADC asset and relevant listener, virtual service, protocol, or processing function with subsequent appliance-health or downstream-availability events.

Management/API activity must not be required for this rule.

Required Telemetry

·        Elastic-normalized network, protocol, WAF, reverse-proxy, load-balancer, NDR, firewall, or flow events.

·        ADC appliance system, service-health, restart, watchdog, reboot, HA, failover, resource, and diagnostic events.

·        ADC asset, listener, virtual-service, protocol, traffic-processing function, and downstream application fields.

·        Environment-specific exception and baseline fields.

Engineering Implementation Instructions

·        Normalize ADC fields into ECS-compatible or consistent custom namespaces before deployment.

·        Validate sequence joins using adc.asset.id, listener or virtual-service identifiers, protocol, interface, and bounded time.

·        Use runtime fields, enrich processors, transforms, or lookup indices for ADC inventories and approved operational context.

·        Keep SIP ALG and LSN enrichment optional and local.

·        Require an independent instability or availability event after suspicious traffic-processing activity.

DRI Assessment

This rule has high detection reliability where ADC traffic-facing and system-health events are normalized into Elastic because EQL can enforce a clear temporal relationship between exploit-shaped input and resulting appliance impact.

DRI

8.8

TCR Assessment

Operational TCR is strong with normalized network and appliance-health telemetry. Full-Telemetry TCR improves with listener, virtual-service, protocol, processing-function, HA, resource, and downstream application enrichment.

Operational TCR

8.5

Full-Telemetry TCR

9.2

Limitations

·        EQL effectiveness depends on consistent ADC asset identity across network and appliance-health streams.

·        Payload-level evidence may be unavailable.

·        Appliance faults may have benign operational causes.

·        Sealed appliances may provide only limited health telemetry.

·        The rule does not prove a specific memory-corruption primitive.

Detection Query Pattern

Use this EQL pattern as the implementation baseline after local ADC asset, listener, protocol, processing-function, and operational-exception fields are normalized.

sequence by adc.asset.id with maxspan=ENV_ADC_TRAFFIC_PROCESSING_TO_INSTABILITY_WINDOW

  [network where

      adc.asset.id != null and

      adc.exposure.type in ("internet_facing", "partner_reachable") and

      exception.approved_adc_context != true and

      (

        adc.listener.id != null or

        adc.virtual_service.id != null or

        adc.traffic_processing.function != null

      ) and

      (

        source.first_seen_status in ("new", "rare") or

        source.as.number in ENV_SUSPICIOUS_ASNS or

        source.network.type in (

          "cloud_hosted",

          "residential_proxy",

          "vpn_provider",

          "scanner_infrastructure",

          "unknown_hosting"

        ) or

        network.protocol_behavior in (

          "malformed",

          "protocol_inconsistent",

          "unexpected_sequence",

          "fuzzing_like",

          "abnormal_transaction"

        ) or

        adc.request.message_size > ENV_ADC_PROTOCOL_MESSAGE_SIZE_UPPER_BASELINE or

        adc.connection.behavior in (

          "rapid_retry",

          "repeated_invalid_request",

          "unexpected_disconnect",

          "abnormal_retransmission"

        )

      )

  ]

  [any where

      adc.asset.id != null and

      exception.approved_adc_context != true and

      (

        adc.appliance.health_event in (

          "process_crash",

          "service_crash",

          "watchdog_restart",

          "service_restart",

          "appliance_reboot",

          "unexpected_failover",

          "ha_state_change",

          "resource_exhaustion",

          "resource_pressure",

          "traffic_processing_fault"

        ) or

        network.connection_state in (

          "timeout",

          "reset",

          "closed_after_error",

          "service_unavailable"

        ) or

        downstream.application.behavior in (

          "availability_degradation",

          "backend_connection_loss",

          "application_unreachable",

          "traffic_path_disruption"

        )

      )

  ]

QRadar

Detection Viability Assessment

QRadar is highly viable for this behavior family when ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS, proxy, firewall, NDR, flow telemetry, configuration-change records, certificate-management records, administrative audit logs, and downstream application logs are mapped into normalized DSM fields, custom properties, reference sets, reference maps, and building blocks. QRadar should be used to correlate exposed ADC control-plane access with post-access behavior, not to alert on CVE names, scanner traffic, vulnerable-version status, KEV status, public proof-of-concept indicators, or isolated request strings alone. The strongest QRadar offenses should require suspicious ADC management/API activity followed by appliance instability, rare ADC-originated egress, configuration or certificate access, virtual-service manipulation, administrative-control change, logging degradation, or downstream application exposure.

Rule

ADC Control-Plane Access Followed by Appliance Instability or Rare Egress

Rule Format

QRadar building-block correlation rule.

Detection Purpose

Detect suspicious ADC management/API, administrative, diagnostic, authentication, telemetry, or configuration access followed by appliance instability, abnormal control-plane response behavior, failed-to-success sequencing, or rare outbound communication from the ADC appliance. This rule is intended to identify behavior consistent with pre-authentication or weakly authenticated ADC control-plane exploitation, including Progress Kemp LoadMaster CVE-2026-8037-like activity where locally visible, without making detection dependent on one vendor, endpoint path, CVE name, proof-of-concept string, or scanner signature.

Detection Logic

Identify suspicious access to ADC control-plane surfaces from external, unfamiliar, newly seen, partner-originated, scanner-like, automation-like, or non-administrative sources. Increase confidence when the request includes command-delimiter, shell-control, quote-manipulation, encoded, malformed JSON, oversized, authentication-bypass, abnormal API-parameter, abnormal method, abnormal response-size, repeated error, failed-to-success, or control-plane instability behavior. Generate an offense only when suspicious access is followed within a bounded time window by appliance instability, abnormal response sequencing, management-service fault, API handler failure, watchdog or restart behavior where logged, connection reset, timeout, or rare ADC-originated DNS, HTTP, HTTPS, SSH, SMTP, raw-IP, file-transfer, tunneling, or command-and-control-like communication.

Required Telemetry

·        ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, appliance syslog, and administrative audit logs where available.

·        DNS, proxy, firewall, NDR, NetFlow, VPC flow, data-center flow, or endpoint-network telemetry for ADC-originated outbound communication.

·        QRadar DSM fields, custom properties, building blocks, reference sets, reference maps, asset profiles, offense rules, and time windows for ADC asset identity, request paths, forwarded source, management interfaces, egress destinations, and appliance response behavior.

·        ADC appliance inventory, management-interface inventory, API exposure inventory, virtual-service inventory, backend-pool inventory, approved administrative source inventory, approved partner path inventory, and approved maintenance-window context.

·        Destination enrichment for first-seen status, domain age, ASN, geography, reputation, destination port, protocol, proxy action, and firewall action.

Engineering Implementation Instructions

·        Deploy first in hunt mode using building blocks before enabling offense generation.

·        Map ADC management/API events, WAF events, proxy events, CDN events, load-balancer events, firewall events, DNS events, NDR events, flow events, appliance syslog, and administrative audit records into consistent QRadar custom properties.

·        Tune approved administrative networks, partner-reachable paths, vendor support sources, vulnerability scanners, patch-validation sources, monitoring systems, health checks, backups, license validation, update destinations, and maintenance windows before alert promotion.

·        Correlate by ADC appliance, management interface, destination host, destination IP, source IP, forwarded source IP, source network, API path, API method, virtual service, backend pool, destination domain, destination IP, and bounded time window.

·        Treat suspicious management/API access alone as exploit-attempt evidence, not confirmed compromise.

·        Promote severity when suspicious access is followed by appliance instability, rare egress, repeated callbacks, internal service access, or abnormal response sequencing.

DRI Assessment

This rule has high detection reliability because it requires a sequence of suspicious ADC control-plane access followed by appliance instability or rare appliance-originated communication. It remains resilient across ADC, load balancer, reverse proxy, WAF-adjacent, and edge traffic-management compromise scenarios because it does not depend on a single Progress Kemp LoadMaster endpoint, public exploit string, user agent, or CVE identifier. Reliability depends on DSM parsing quality, custom property accuracy, ADC asset mapping, forwarded-source preservation, egress baselining, and reference-set tuning.

DRI

8.7

TCR Assessment

Operational TCR is strong where QRadar receives ADC management/API logs, WAF or reverse-proxy logs, DNS, proxy, firewall, NDR, flow data, asset inventory, source exceptions, and approved-egress reference sets. Full-Telemetry TCR improves when appliance syslog, configuration-change records, certificate records, administrative audit logs, downstream application logs, and endpoint telemetry are joined to the same offense sequence.

Operational TCR

8.4

Full-Telemetry TCR

9.1

Limitations

·        This rule cannot confirm command execution without appliance process, shell, diagnostic, system, endpoint, or vendor log evidence.

·        Request-body loss, query-string redaction, CDN layering, NAT, proxy forwarding, or incomplete forwarded-source preservation may reduce confidence.

·        Rare egress may reflect approved vendor support, update retrieval, license validation, backup, monitoring, troubleshooting, or incident-response activity if reference sets are incomplete.

·        Appliance instability may result from benign patching, failover testing, resource exhaustion, configuration error, or maintenance activity.

·        Vulnerable-version status, public PoC availability, scanner traffic, or KEV status must not be treated as standalone compromise confirmation.

Detection Query Pattern

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

BUILDING BLOCK 1: Suspicious ADC Control-Plane Access

WHEN events are detected for the same ADC_Asset_ID, same ADC_Appliance, same Management_Interface, same Destination_Host, same Destination_IP, same Virtual_Service, same Backend_Pool, same Source_IP, same Forwarded_Source_IP, same Source_Network, same API_Path_Family, or equivalent normalized ADC asset lineage
WITHIN ENV_ADC_CONTROL_PLANE_HUNT_WINDOW
AND ADC_Asset_ID is not null
AND ADC_Appliance is contained in reference set ENV_ADC_EDGE_ASSETS
AND Request_Path is contained in reference set ENV_ADC_MANAGEMENT_OR_API_SURFACES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_ADMIN_SOURCES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_SCANNER_SOURCES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_VENDOR_SUPPORT_SOURCES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_PATCH_VALIDATION_SOURCES
AND Forwarded_Source_IP is not contained in reference set ENV_APPROVED_FORWARDED_ADC_ADMIN_SOURCES
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_CHANGE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_PATCH_WINDOWS
AND (
Source_First_Seen_Status is contained in reference set ENV_NEW_OR_RARE_SOURCE_STATES
OR Source_ASN is contained in reference set ENV_SUSPICIOUS_ASNS
OR Source_Network_Type is contained in reference set ENV_SUSPICIOUS_SOURCE_NETWORK_TYPES
OR Source_Geo is not contained in reference map ENV_ADC_EXPECTED_ADMIN_SOURCE_GEOS for ADC_Asset_ID
OR User_Agent is contained in reference set ENV_RARE_OR_AUTOMATED_USER_AGENTS
OR HTTP_Method is not contained in reference set ENV_EXPECTED_ADC_MANAGEMENT_METHODS
OR Request_Path matches reference set ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR Request_Query matches reference set ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR Request_Body_Metadata matches reference set ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR Content_Type is contained in reference set ENV_ADC_UNUSUAL_CONTROL_PLANE_CONTENT_TYPES
OR Request_Size is greater than reference map ENV_ADC_MANAGEMENT_REQUEST_SIZE_UPPER_BASELINE for ADC_Asset_ID
OR Response_Size is greater than reference map ENV_ADC_MANAGEMENT_RESPONSE_SIZE_UPPER_BASELINE for ADC_Asset_ID
OR Response_Size is less than reference map ENV_ADC_MANAGEMENT_RESPONSE_SIZE_LOWER_BASELINE for ADC_Asset_ID
OR Request_Timing_Pattern is contained in reference set ENV_SUSPICIOUS_ADC_REQUEST_TIMING_PATTERNS
OR HTTP_Status_Sequence is contained in reference set ENV_ADC_ABNORMAL_STATUS_SEQUENCES
)
THEN mark event as Building_Block_ADC_Suspicious_Control_Plane_Access

BUILDING BLOCK 2: ADC Appliance Instability After Control-Plane Access

WHEN events are detected for the same ADC_Asset_ID, same ADC_Appliance, same Management_Interface, same Destination_Host, same Destination_IP, same Virtual_Service, same Backend_Pool, same Source_IP, same Forwarded_Source_IP, same Source_Network, same API_Path_Family, or equivalent normalized ADC asset lineage
WITHIN ENV_ADC_CONTROL_PLANE_ACCESS_TO_INSTABILITY_WINDOW
AND Building_Block_ADC_Suspicious_Control_Plane_Access occurred before ADC_Instability_Time
AND ADC_Instability_Time occurs within ENV_ADC_CONTROL_PLANE_ACCESS_TO_INSTABILITY_WINDOW after Suspicious_Control_Plane_Access_Time
AND ADC_Asset_ID is not null
AND ADC_Appliance is contained in reference set ENV_ADC_EDGE_ASSETS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_CHANGE_WINDOWS
AND (
Request_Path is contained in reference set ENV_ADC_MANAGEMENT_OR_API_SURFACES
OR Destination_Service is contained in reference set ENV_ADC_MANAGEMENT_SERVICES
OR Destination_Interface is contained in reference set ENV_ADC_MANAGEMENT_INTERFACES
)
AND (
HTTP_Status_Code is contained in reference set ENV_ADC_INSTABILITY_STATUS_CODES
OR Connection_State is contained in reference set ENV_ADC_ABNORMAL_CONNECTION_STATES
OR HTTP_Status_Sequence is contained in reference set ENV_ADC_ABNORMAL_STATUS_SEQUENCES
OR Request_Timing_Pattern is contained in reference set ENV_ADC_RETRY_OR_AUTOMATION_TIMING_PATTERNS
OR Appliance_Health_Event is contained in reference set ENV_ADC_APPLIANCE_HEALTH_FAULT_EVENTS
OR API_Handler_Event is contained in reference set ENV_ADC_API_HANDLER_FAULT_EVENTS
OR Management_Service_Event is contained in reference set ENV_ADC_MANAGEMENT_SERVICE_FAULT_EVENTS
OR Authentication_Handler_Event is contained in reference set ENV_ADC_AUTHENTICATION_HANDLER_FAULT_EVENTS
OR Failover_Event is contained in reference set ENV_ADC_FAILOVER_OR_WATCHDOG_EVENTS
OR Response_Size_Delta is greater than reference map ENV_ADC_RESPONSE_SIZE_DELTA_UPPER_BASELINE for ADC_Asset_ID
OR Response_Size_Delta is less than reference map ENV_ADC_RESPONSE_SIZE_DELTA_LOWER_BASELINE for ADC_Asset_ID
)
AND (
ADC_Asset_ID equals Prior_Control_Plane_ADC_Asset_ID
OR ADC_Appliance equals Prior_Control_Plane_ADC_Appliance
OR Management_Interface equals Prior_Control_Plane_Management_Interface
OR Destination_Host equals Prior_Control_Plane_Destination_Host
OR Destination_IP equals Prior_Control_Plane_Destination_IP
OR Virtual_Service equals Prior_Control_Plane_Virtual_Service
OR Backend_Pool equals Prior_Control_Plane_Backend_Pool
OR Source_IP equals Prior_Control_Plane_Source_IP
OR Forwarded_Source_IP equals Prior_Control_Plane_Forwarded_Source_IP
OR Source_Network equals Prior_Control_Plane_Source_Network
OR API_Path_Family equals Prior_Control_Plane_API_Path_Family
)
THEN mark event as Building_Block_ADC_Appliance_Instability_After_Control_Plane_Access

BUILDING BLOCK 3: ADC Rare Egress After Control-Plane Access

WHEN events are detected for the same ADC_Asset_ID, same ADC_Appliance, same Source_Host, same Source_IP, same Source_Asset_ID, same Source_Interface, same Workload_ID, same Destination_Domain, same Destination_IP, same Destination_Port, or equivalent normalized ADC asset lineage
WITHIN ENV_ADC_CONTROL_PLANE_ACCESS_TO_EGRESS_WINDOW
AND Building_Block_ADC_Suspicious_Control_Plane_Access occurred before ADC_Egress_Time
AND ADC_Egress_Time occurs within ENV_ADC_CONTROL_PLANE_ACCESS_TO_EGRESS_WINDOW after Suspicious_Control_Plane_Access_Time
AND ADC_Asset_ID is not null
AND (
ADC_Appliance is contained in reference set ENV_ADC_EDGE_ASSETS
OR Source_Host is contained in reference set ENV_ADC_EDGE_ASSETS
OR Source_IP is contained in reference set ENV_ADC_APPLIANCE_IPS
OR Source_Asset_ID is contained in reference set ENV_ADC_ASSET_IDS
OR Source_Interface is contained in reference set ENV_ADC_APPLIANCE_INTERFACES
OR Workload_ID is contained in reference set ENV_ADC_WORKLOAD_IDS
)
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_CHANGE_WINDOWS
AND (
Destination_Domain is not null
OR Destination_IP is not null
)
AND (
Destination_Domain is null
OR Destination_Domain is not contained in reference set ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
AND (
Destination_IP is null
OR Destination_IP is not contained in reference set ENV_APPROVED_ADC_EGRESS_DESTINATIONS
)
AND (
Destination_First_Seen_Status is contained in reference set ENV_NEW_OR_RARE_DESTINATION_STATES
OR Destination_Domain_Age_Days is less than ENV_NEW_DOMAIN_AGE_DAYS
OR Destination_Reputation is contained in reference set ENV_SUSPICIOUS_OR_MALICIOUS_DESTINATION_REPUTATION
OR Destination_ASN is contained in reference set ENV_SUSPICIOUS_ASNS
OR Destination_Geo is not contained in reference map ENV_ADC_EXPECTED_DESTINATION_GEOS for ADC_Asset_ID
OR Destination_Port is contained in reference set ENV_UNUSUAL_ADC_EGRESS_PORTS
OR Network_Protocol is contained in reference set ENV_UNUSUAL_ADC_EGRESS_PROTOCOLS
OR Proxy_Action is contained in reference set ENV_ALLOWED_PROXY_CONNECTION_ACTIONS
OR Firewall_Action is contained in reference set ENV_ALLOWED_FIREWALL_CONNECTION_ACTIONS
OR NDR_Behavior is contained in reference set ENV_ADC_CALLBACK_OR_TOOL_RETRIEVAL_BEHAVIORS
)
AND (
ADC_Asset_ID equals Prior_Control_Plane_ADC_Asset_ID
OR ADC_Appliance equals Prior_Control_Plane_ADC_Appliance
OR Source_Host equals Prior_Control_Plane_ADC_Appliance
OR Source_IP equals Prior_Control_Plane_Destination_IP
OR Source_Asset_ID equals Prior_Control_Plane_ADC_Asset_ID
OR Workload_ID equals Prior_Control_Plane_Workload_ID
OR Source_Interface equals Prior_Control_Plane_Management_Interface
)
AND NOT (
Destination_Domain is contained in reference set ENV_APPROVED_ADC_VENDOR_SUPPORT_DESTINATIONS
OR Destination_Domain is contained in reference set ENV_APPROVED_ADC_UPDATE_DESTINATIONS
OR Destination_Domain is contained in reference set ENV_APPROVED_ADC_LICENSE_DESTINATIONS
OR Destination_Domain is contained in reference set ENV_APPROVED_ADC_MONITORING_DESTINATIONS
OR Destination_Domain is contained in reference set ENV_APPROVED_ADC_TELEMETRY_DESTINATIONS
OR Destination_IP is contained in reference set ENV_APPROVED_ADC_VENDOR_SUPPORT_DESTINATIONS
OR Destination_IP is contained in reference set ENV_APPROVED_ADC_UPDATE_DESTINATIONS
OR Destination_IP is contained in reference set ENV_APPROVED_ADC_LICENSE_DESTINATIONS
OR Destination_IP is contained in reference set ENV_APPROVED_ADC_MONITORING_DESTINATIONS
OR Destination_IP is contained in reference set ENV_APPROVED_ADC_TELEMETRY_DESTINATIONS
OR Event_Time is contained in reference set ENV_APPROVED_ADC_BACKUP_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_ADC_VENDOR_SUPPORT_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_ADC_INCIDENT_RESPONSE_WINDOWS
)
THEN generate offense with context:
ADC_Asset_ID,
ADC_Appliance,
Management_Interface,
Destination_Host,
Destination_IP,
Virtual_Service,
Backend_Pool,
Source_IP,
Forwarded_Source_IP,
Source_Network,
Source_ASN,
Source_Geo,
Source_Network_Type,
User_Agent,
HTTP_Method,
Request_Path,
Request_Query,
HTTP_Status_Code,
Request_Size,
Response_Size,
Request_Timing_Pattern,
HTTP_Status_Sequence,
Suspicious_Control_Plane_Access_Time,
ADC_Instability_Time,
ADC_Egress_Time,
Appliance_Health_Event,
API_Handler_Event,
Management_Service_Event,
Authentication_Handler_Event,
Failover_Event,
Connection_State,
Response_Size_Delta,
Destination_Domain,
Destination_Port,
Destination_Reputation,
Destination_First_Seen_Status,
Destination_Domain_Age_Days,
Destination_ASN,
Destination_Geo,
Network_Protocol,
Proxy_Action,
Firewall_Action,
NDR_Behavior,
Building_Block_ADC_Suspicious_Control_Plane_Access,
Building_Block_ADC_Appliance_Instability_After_Control_Plane_Access

Rule

ADC Control-Plane Access Followed by Configuration, Certificate, or Traffic-Path Manipulation

Rule Format

QRadar building-block correlation rule.

Detection Purpose

Detect suspicious ADC management/API access followed by configuration exposure, configuration change, virtual-service manipulation, backend-pool modification, routing or header-control changes, TLS or certificate-object access, backup or diagnostic artifact access, administrative-control change, logging degradation, or downstream application traffic-path anomalies. This rule is intended to identify compromise behavior affecting the edge application-delivery trust boundary rather than only the vulnerable appliance.

Detection Logic

Identify suspicious control-plane access to ADC management, API, administrative, diagnostic, authentication, telemetry, or configuration surfaces. Correlate that access with subsequent configuration-object access, virtual-service modification, backend-pool modification, route or rewrite change, header manipulation, persistence-profile change, health-check change, SSL/TLS offload change, certificate binding change, private-key access, backup export, diagnostic bundle creation, packet capture creation, API token access, administrative setting modification, logging change, or downstream application anomaly. Promote only when post-access behavior aligns by ADC appliance, management interface, source, virtual service, backend pool, configuration object, certificate object, downstream application, or bounded time window.

Required Telemetry

·        ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, appliance syslog, administrative audit logs, and configuration-change records.

·        Certificate-management records, TLS binding records, configuration export records, backup records, diagnostic bundle records, packet capture records, administrative-user records, API key records, and logging-setting records where available.

·        Downstream web server logs, downstream application logs, identity logs, backend service logs, WAF logs, proxy logs, NDR, DNS, proxy, firewall, and flow telemetry.

·        ADC appliance inventory, virtual-service inventory, backend-pool inventory, certificate inventory, TLS-offload inventory, route inventory, header-rule inventory, rewrite-rule inventory, approved change records, and maintenance-window context.

·        QRadar DSM fields, custom properties, building blocks, reference sets, reference maps, asset profiles, offense rules, and time windows for ADC configuration objects, certificate objects, downstream application identity, traffic-path behavior, and approved administrative workflows.

Engineering Implementation Instructions

·        Deploy first in hunt mode until ADC configuration-object custom properties, certificate-object mapping, virtual-service mapping, backend-pool mapping, downstream application mapping, and approved change reference sets are validated.

·        Require sequence correlation before offense generation.

·        Correlate suspicious access with configuration, certificate, traffic-path, administrative, logging, or downstream behavior by ADC appliance, management interface, API endpoint, source IP, forwarded source IP, administrative identity where available, configuration object, certificate object, virtual service, backend pool, downstream application, and bounded time window.

·        Suppress known-good certificate rotation, key rotation, virtual-service changes, backend-pool changes, routing changes, health-check tuning, backup jobs, diagnostic collection, vendor support, failover testing, monitoring activity, emergency maintenance, and documented incident-response collection.

·        Treat downstream application anomalies as ADC-related only when they follow suspicious ADC control-plane behavior and align by virtual service, backend host, route, header behavior, source path, source identity, or time window.

·        Escalate when certificate or private-key access, backup export, diagnostic bundle creation, configuration export, logging degradation, administrative-control change, traffic mirroring, or downstream application exposure follows suspicious management/API access.

DRI Assessment

This rule has high detection reliability because it focuses on protected ADC trust-boundary objects and downstream consequences that are difficult to explain through scanner traffic alone. It remains reusable across ADC, load balancer, reverse proxy, WAF-adjacent, and edge traffic-management compromise scenarios because it anchors on configuration, certificate, routing, and traffic-path manipulation rather than a single vendor endpoint. Reliability depends on DSM parsing quality, custom property coverage, configuration visibility, object normalization, virtual-service mapping, certificate records, and approved change context.

DRI

8.6

TCR Assessment

Operational TCR is strong when QRadar receives ADC management/API logs, configuration-change records, WAF or reverse-proxy logs, asset inventory, approved change records, and NDR telemetry. Full-Telemetry TCR improves when certificate-management records, backup comparison, administrative audit logs, endpoint telemetry, downstream application logs, and virtual-service-to-backend mappings are available.

Operational TCR

8.2

Full-Telemetry TCR

9.0

Limitations

·        This rule may miss object-level access if ADC appliances do not log configuration reads, certificate reads, private-key access, backup creation, diagnostic bundle creation, or administrative API actions.

·        Approved backup, certificate renewal, vendor support, emergency routing changes, failover testing, patch validation, and incident-response collection may resemble suspicious post-access behavior.

·        Downstream application anomalies cannot be attributed to ADC compromise without linkage to ADC appliance, virtual service, backend mapping, request path, source, administrative action, or time window.

·        Configuration export timestamps may reflect backup, migration, restoration, failover, or maintenance rather than the original attacker action.

·        QRadar correlation quality depends on DSM parsing, custom property extraction, asset mapping, configuration object mapping, and reliable approved-change reference sets.

Detection Query Pattern

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

BUILDING BLOCK 1: Suspicious ADC Control-Plane Access

WHEN events are detected for the same ADC_Asset_ID, same ADC_Appliance, same Management_Interface, same Destination_Host, same Destination_IP, same Virtual_Service, same Backend_Pool, same Source_IP, same Forwarded_Source_IP, same Source_Network, same API_Path_Family, or equivalent normalized ADC asset lineage
WITHIN ENV_ADC_CONTROL_PLANE_HUNT_WINDOW
AND ADC_Asset_ID is not null
AND ADC_Appliance is contained in reference set ENV_ADC_EDGE_ASSETS
AND Request_Path is contained in reference set ENV_ADC_MANAGEMENT_OR_API_SURFACES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_ADMIN_SOURCES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_SCANNER_SOURCES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_VENDOR_SUPPORT_SOURCES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_PATCH_VALIDATION_SOURCES
AND Forwarded_Source_IP is not contained in reference set ENV_APPROVED_FORWARDED_ADC_ADMIN_SOURCES
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_CHANGE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_PATCH_WINDOWS
AND (
Source_First_Seen_Status is contained in reference set ENV_NEW_OR_RARE_SOURCE_STATES
OR Source_ASN is contained in reference set ENV_SUSPICIOUS_ASNS
OR Source_Network_Type is contained in reference set ENV_SUSPICIOUS_SOURCE_NETWORK_TYPES
OR Source_Geo is not contained in reference map ENV_ADC_EXPECTED_ADMIN_SOURCE_GEOS for ADC_Asset_ID
OR User_Agent is contained in reference set ENV_RARE_OR_AUTOMATED_USER_AGENTS
OR HTTP_Method is not contained in reference set ENV_EXPECTED_ADC_MANAGEMENT_METHODS
OR Request_Path matches reference set ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR Request_Query matches reference set ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR Request_Body_Metadata matches reference set ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR Content_Type is contained in reference set ENV_ADC_UNUSUAL_CONTROL_PLANE_CONTENT_TYPES
OR Request_Size is greater than reference map ENV_ADC_MANAGEMENT_REQUEST_SIZE_UPPER_BASELINE for ADC_Asset_ID
OR Response_Size is greater than reference map ENV_ADC_MANAGEMENT_RESPONSE_SIZE_UPPER_BASELINE for ADC_Asset_ID
OR Response_Size is less than reference map ENV_ADC_MANAGEMENT_RESPONSE_SIZE_LOWER_BASELINE for ADC_Asset_ID
OR Request_Timing_Pattern is contained in reference set ENV_SUSPICIOUS_ADC_REQUEST_TIMING_PATTERNS
OR HTTP_Status_Sequence is contained in reference set ENV_ADC_ABNORMAL_STATUS_SEQUENCES
)
THEN mark event as Building_Block_ADC_Suspicious_Control_Plane_Access

BUILDING BLOCK 2: ADC Configuration, Certificate, or Protected Object Access After Control-Plane Access

WHEN events are detected for the same ADC_Asset_ID, same ADC_Appliance, same Management_Interface, same Destination_Host, same Destination_IP, same Virtual_Service, same Backend_Pool, same Configuration_Object, same Certificate_Object, same Administrative_Identity, or equivalent normalized ADC object lineage
WITHIN ENV_ADC_CONTROL_PLANE_ACCESS_TO_CONFIGURATION_WINDOW
AND Building_Block_ADC_Suspicious_Control_Plane_Access occurred before ADC_Object_Access_Time
AND ADC_Object_Access_Time occurs within ENV_ADC_CONTROL_PLANE_ACCESS_TO_CONFIGURATION_WINDOW after Suspicious_Control_Plane_Access_Time
AND ADC_Asset_ID is not null
AND ADC_Appliance is contained in reference set ENV_ADC_EDGE_ASSETS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_CHANGE_WINDOWS
AND Administrative_Identity is not contained in reference set ENV_APPROVED_ADC_CHANGE_ACTORS
AND (
Configuration_Object is contained in reference set ENV_ADC_PROTECTED_CONFIGURATION_OBJECTS
OR Certificate_Object is contained in reference set ENV_ADC_CERTIFICATE_AND_TLS_OBJECTS
OR Request_Path is contained in reference set ENV_ADC_PROTECTED_CONFIGURATION_OBJECTS
OR Request_Path is contained in reference set ENV_ADC_CERTIFICATE_AND_TLS_OBJECTS
OR File_Object is contained in reference set ENV_ADC_PROTECTED_CONFIGURATION_OBJECTS
OR File_Object is contained in reference set ENV_ADC_CERTIFICATE_AND_TLS_OBJECTS
)
AND (
Object_Action is contained in reference set ENV_ADC_PROTECTED_OBJECT_ACCESS_ACTIONS
OR Change_Type is contained in reference set ENV_ADC_PROTECTED_OBJECT_CHANGE_TYPES
OR Object_First_Seen_Status is contained in reference set ENV_NEW_OR_RARE_OBJECT_STATES
OR Certificate_Action is contained in reference set ENV_ADC_CERTIFICATE_ACCESS_ACTIONS
OR Backup_Action is contained in reference set ENV_ADC_BACKUP_EXPORT_ACTIONS
OR Diagnostic_Action is contained in reference set ENV_ADC_DIAGNOSTIC_BUNDLE_ACTIONS
OR Packet_Capture_Action is contained in reference set ENV_ADC_PACKET_CAPTURE_ACTIONS
)
AND (
ADC_Asset_ID equals Prior_Control_Plane_ADC_Asset_ID
OR ADC_Appliance equals Prior_Control_Plane_ADC_Appliance
OR Management_Interface equals Prior_Control_Plane_Management_Interface
OR Destination_Host equals Prior_Control_Plane_Destination_Host
OR Destination_IP equals Prior_Control_Plane_Destination_IP
OR Virtual_Service equals Prior_Control_Plane_Virtual_Service
OR Backend_Pool equals Prior_Control_Plane_Backend_Pool
OR Source_IP equals Prior_Control_Plane_Source_IP
OR Forwarded_Source_IP equals Prior_Control_Plane_Forwarded_Source_IP
OR Source_Network equals Prior_Control_Plane_Source_Network
OR API_Path_Family equals Prior_Control_Plane_API_Path_Family
)
THEN mark event as Building_Block_ADC_Configuration_Certificate_Or_Protected_Object_Access_After_Control_Plane_Access

BUILDING BLOCK 3: ADC Traffic-Path or Downstream Anomaly After Control-Plane Access

WHEN events are detected for the same ADC_Asset_ID, same ADC_Appliance, same Virtual_Service, same Backend_Pool, same Backend_Host, same Application_ID, same Route_Family, same Header_Family, same TLS_Object, same Administrative_Identity, or equivalent normalized ADC traffic-path lineage
WITHIN ENV_ADC_CONTROL_PLANE_ACCESS_TO_DOWNSTREAM_IMPACT_WINDOW
AND Building_Block_ADC_Suspicious_Control_Plane_Access occurred before ADC_Traffic_Path_Or_Downstream_Time
AND ADC_Traffic_Path_Or_Downstream_Time occurs within ENV_ADC_CONTROL_PLANE_ACCESS_TO_DOWNSTREAM_IMPACT_WINDOW after Suspicious_Control_Plane_Access_Time
AND ADC_Asset_ID is not null
AND ADC_Appliance is contained in reference set ENV_ADC_EDGE_ASSETS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_CHANGE_WINDOWS
AND Event_ID is not contained in reference set ENV_APPROVED_ADC_TRAFFIC_PATH_CHANGES
AND (
Traffic_Path_Change_Type is contained in reference set ENV_ADC_TRAFFIC_PATH_CHANGE_TYPES
OR Virtual_Service_Change is contained in reference set ENV_ADC_VIRTUAL_SERVICE_CHANGE_TYPES
OR Backend_Pool_Change is contained in reference set ENV_ADC_BACKEND_POOL_CHANGE_TYPES
OR Routing_Change is contained in reference set ENV_ADC_ROUTING_CHANGE_TYPES
OR Rewrite_Change is contained in reference set ENV_ADC_REWRITE_CHANGE_TYPES
OR Header_Behavior is contained in reference set ENV_ADC_HEADER_MANIPULATION_BEHAVIORS
OR Persistence_Profile_Change is contained in reference set ENV_ADC_PERSISTENCE_PROFILE_CHANGE_TYPES
OR Health_Check_Change is contained in reference set ENV_ADC_HEALTH_CHECK_CHANGE_TYPES
OR TLS_Behavior is contained in reference set ENV_ADC_TLS_OR_CERTIFICATE_BINDING_BEHAVIORS
OR Logging_Change is contained in reference set ENV_ADC_LOGGING_DEGRADATION_BEHAVIORS
OR Administrative_Control_Change is contained in reference set ENV_ADC_ADMINISTRATIVE_CONTROL_CHANGE_TYPES
OR Downstream_Application_Behavior is contained in reference set ENV_ADC_DOWNSTREAM_APPLICATION_ANOMALIES
)
AND (
ADC_Asset_ID equals Prior_Control_Plane_ADC_Asset_ID
OR ADC_Appliance equals Prior_Control_Plane_ADC_Appliance
OR Virtual_Service equals Prior_Control_Plane_Virtual_Service
OR Backend_Pool equals Prior_Control_Plane_Backend_Pool
OR Backend_Host equals Prior_Control_Plane_Backend_Host
OR Application_ID equals Prior_Control_Plane_Application_ID
OR Route_Family equals Prior_Control_Plane_Route_Family
OR Administrative_Identity equals Prior_Control_Plane_Administrative_Identity
)
AND NOT (
Administrative_Identity is contained in reference set ENV_APPROVED_ADC_CHANGE_ACTORS
OR Event_ID is contained in reference set ENV_APPROVED_ADC_TRAFFIC_PATH_CHANGES
OR Event_Time is contained in reference set ENV_APPROVED_ADC_CERTIFICATE_ROTATION_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_ADC_BACKUP_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_ADC_VENDOR_SUPPORT_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_ADC_INCIDENT_RESPONSE_WINDOWS
)
THEN generate offense with context:
ADC_Asset_ID,
ADC_Appliance,
Management_Interface,
Destination_Host,
Destination_IP,
Virtual_Service,
Backend_Pool,
Backend_Host,
Application_ID,
Source_IP,
Forwarded_Source_IP,
Source_Network,
User_Agent,
HTTP_Method,
Request_Path,
Request_Query,
HTTP_Status_Code,
Suspicious_Control_Plane_Access_Time,
ADC_Object_Access_Time,
ADC_Traffic_Path_Or_Downstream_Time,
Configuration_Object,
Certificate_Object,
File_Object,
Object_Action,
Change_Type,
Certificate_Action,
Backup_Action,
Diagnostic_Action,
Packet_Capture_Action,
Traffic_Path_Change_Type,
Virtual_Service_Change,
Backend_Pool_Change,
Routing_Change,
Rewrite_Change,
Header_Behavior,
Persistence_Profile_Change,
Health_Check_Change,
TLS_Behavior,
Logging_Change,
Administrative_Control_Change,
Downstream_Application_Behavior,
Administrative_Identity,
Building_Block_ADC_Suspicious_Control_Plane_Access,
Building_Block_ADC_Configuration_Certificate_Or_Protected_Object_Access_After_Control_Plane_Access

Rule

Multiple ADC Assets Showing Related Control-Plane Probing or Post-Access Behavior

Rule Format

QRadar campaign-correlation offense rule.

Detection Purpose

Detect campaign-like activity across multiple ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management assets where related control-plane probing, exploit-attempt behavior, instability, rare egress, configuration access, certificate access, virtual-service changes, or downstream anomalies appear within a bounded time window. This rule is intended to identify coordinated targeting or exposure review without assuming confirmed compromise from multi-asset scanner traffic alone.

Detection Logic

Identify two or more ADC or edge traffic-management assets showing similar suspicious management/API access from the same source, forwarded source, source network, ASN, user agent, request-path family, API-method family, parameter family, timing pattern, or payload family. Promote confidence when at least one affected appliance also shows appliance instability, rare egress, configuration or certificate access, administrative-control change, virtual-service or backend-pool modification, logging degradation, or downstream traffic-path anomaly. Treat related multi-asset request activity without post-access behavior as exploit-attempt or exposure-review evidence, not confirmed compromise.

Required Telemetry

·        QRadar ingestion from ADC management/API logs, WAF logs, CDN logs, reverse-proxy logs, load-balancer logs, gateway logs, firewall logs, DNS logs, proxy logs, NDR, flow telemetry, appliance syslog, configuration-change logs, and downstream application logs.

·        ADC appliance inventory, internet-exposure inventory, partner-reachable path inventory, management-interface inventory, API exposure inventory, virtual-service inventory, backend-pool inventory, asset criticality, exposure class, and downstream application mapping.

·        Source enrichment for first-seen status, ASN, geography, network type, user agent, request cadence, scanner-like behavior, infrastructure clustering, shared source-network patterns, and reputation where available.

·        Approved scanners, approved administrative sources, vendor support sources, patch-validation sources, monitoring systems, synthetic checks, red-team sources, incident-response sources, and maintenance-window reference sets.

·        QRadar DSM fields, custom properties, building blocks, reference sets, reference maps, asset profiles, offense rules, and time windows for multi-asset grouping, source clustering, request families, post-access behavior, and approved exception context.

Engineering Implementation Instructions

·        Deploy first in hunt mode to validate multi-asset thresholds, request-family normalization, source clustering, and exception handling.

·        Require at least two ADC or traffic-management assets before campaign-correlation logic triggers.

·        Require post-access behavior from at least one appliance before promoting beyond exploit-attempt or exposure-review confidence.

·        Correlate by source IP, forwarded source IP, source network, ASN, user agent, request-path family, API-method family, parameter pattern, request timing, ADC asset group, exposure class, virtual-service family, backend-pool family, and bounded time window.

·        Prioritize production, internet-facing, partner-reachable, authentication-fronting, TLS-terminating, high-availability, and critical application-delivery appliances.

·        Suppress approved enterprise vulnerability scanning, vendor advisory validation, patch verification, synthetic monitoring, health checks, red-team activity, and documented incident-response sweeps.

DRI Assessment

This rule has strong reliability for identifying coordinated exploit-attempt behavior and campaign-like targeting, but compromise confidence depends on post-access evidence. The rule is useful across ADC, load balancer, reverse proxy, WAF-adjacent, and traffic-management assets because it correlates source behavior, request families, exposure classes, affected appliance groups, and post-access effects instead of a single payload or CVE identifier. Reliability depends on multi-asset inventory quality, DSM parsing, custom property normalization, source clustering, and exception tuning.

DRI

8.4

TCR Assessment

Operational TCR is strong where QRadar receives WAF, CDN, reverse-proxy, load-balancer, ADC, DNS, proxy, firewall, NDR, flow, source-enrichment, and inventory data across multiple appliances. Full-Telemetry TCR improves when configuration-change records, certificate records, administrative audit logs, downstream application logs, appliance health events, and endpoint telemetry can be joined to campaign clusters.

Operational TCR

8.2

Full-Telemetry TCR

8.9

Limitations

·        Multi-asset probing may reflect approved scanning, vendor validation, synthetic monitoring, patch verification, red-team activity, or incident-response review if reference sets are incomplete.

·        This rule should not claim confirmed compromise unless post-access appliance, configuration, certificate, egress, administrative, or downstream application evidence is present.

·        Organizations with only one ADC appliance may receive limited value from this campaign-correlation logic.

·        CDN, NAT, proxy, and partner network paths may obscure true source identity or inflate source-clustering confidence.

·        Similar request paths across appliances may indicate exposure discovery rather than successful exploitation.

Detection Query Pattern

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

BUILDING BLOCK 1: Related Multi-Asset ADC Control-Plane Probing

WHEN events are detected for the same Source_IP, same Forwarded_Source_IP, same Source_Network, same Source_ASN, same User_Agent, same API_Path_Family, same API_Method_Family, same Request_Parameter_Family, same Request_Timing_Pattern, or equivalent normalized source and request lineage
WITHIN ENV_MULTI_ADC_PROBE_CLUSTER_WINDOW
AND ADC_Asset_ID is not null
AND ADC_Appliance is contained in reference set ENV_ADC_EDGE_ASSETS
AND ADC_Asset_Group is contained in reference set ENV_ADC_ASSET_GROUPS
AND Request_Path is contained in reference set ENV_ADC_MANAGEMENT_OR_API_SURFACES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_ADMIN_SOURCES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_SCANNER_SOURCES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_VENDOR_SUPPORT_SOURCES
AND Source_IP is not contained in reference set ENV_APPROVED_ADC_PATCH_VALIDATION_SOURCES
AND Source_IP is not contained in reference set ENV_APPROVED_RED_TEAM_SOURCES
AND Forwarded_Source_IP is not contained in reference set ENV_APPROVED_FORWARDED_ADC_ADMIN_SOURCES
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_CHANGE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_RED_TEAM_WINDOWS
AND (
Source_ASN is contained in reference set ENV_SUSPICIOUS_ASNS
OR Source_Network_Type is contained in reference set ENV_SUSPICIOUS_SOURCE_NETWORK_TYPES
OR Source_Geo is not contained in reference map ENV_ADC_EXPECTED_ADMIN_SOURCE_GEOS for ADC_Asset_ID
OR User_Agent is contained in reference set ENV_RARE_OR_AUTOMATED_USER_AGENTS
OR Request_Path matches reference set ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR Request_Query matches reference set ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR Request_Body_Metadata matches reference set ENV_ADC_CONTROL_PLANE_EXPLOIT_PATTERNS
OR HTTP_Status_Code is contained in reference set ENV_ADC_CONTROL_PLANE_PROBE_STATUS_CODES
OR Request_Timing_Pattern is contained in reference set ENV_SUSPICIOUS_ADC_REQUEST_TIMING_PATTERNS
)
AND Distinct_ADC_Asset_Count is greater than or equal to ENV_MULTI_ADC_MINIMUM_ASSET_COUNT
AND (
Distinct_ADC_Asset_Group_Count is greater than or equal to ENV_MULTI_ADC_MINIMUM_GROUP_COUNT
OR Distinct_Exposure_Class_Count is greater than or equal to ENV_MULTI_ADC_MINIMUM_EXPOSURE_CLASS_COUNT
OR Asset_Criticality is contained in reference set ENV_HIGH_OR_CRITICAL_ASSET_CRITICALITY
)
THEN mark event as Building_Block_ADC_Related_Multi_Asset_Control_Plane_Probing

BUILDING BLOCK 2: ADC Post-Access Behavior Within Multi-Asset Cluster

WHEN events are detected for the same ADC_Asset_ID, same ADC_Appliance, same ADC_Asset_Group, same Virtual_Service, same Backend_Pool, same Backend_Host, same Exposure_Class, same Source_IP, same Forwarded_Source_IP, same Source_Network, same API_Path_Family, or equivalent normalized ADC campaign lineage
WITHIN ENV_MULTI_ADC_PROBE_TO_POST_ACCESS_WINDOW
AND Building_Block_ADC_Related_Multi_Asset_Control_Plane_Probing occurred before ADC_Post_Access_Time
AND ADC_Post_Access_Time occurs within ENV_MULTI_ADC_PROBE_TO_POST_ACCESS_WINDOW after Multi_Asset_Probe_Cluster_Time
AND ADC_Asset_ID is not null
AND ADC_Appliance is contained in reference set ENV_ADC_EDGE_ASSETS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
AND Event_Time is not contained in reference set ENV_APPROVED_ADC_CHANGE_WINDOWS
AND (
Destination_First_Seen_Status is contained in reference set ENV_NEW_OR_RARE_DESTINATION_STATES
OR Destination_Reputation is contained in reference set ENV_SUSPICIOUS_OR_MALICIOUS_DESTINATION_REPUTATION
OR Destination_Port is contained in reference set ENV_UNUSUAL_ADC_EGRESS_PORTS
OR NDR_Behavior is contained in reference set ENV_ADC_CALLBACK_OR_TOOL_RETRIEVAL_BEHAVIORS
OR HTTP_Status_Sequence is contained in reference set ENV_ADC_ABNORMAL_STATUS_SEQUENCES
OR Appliance_Health_Event is contained in reference set ENV_ADC_APPLIANCE_HEALTH_FAULT_EVENTS
OR Configuration_Change_Type is contained in reference set ENV_ADC_PROTECTED_OBJECT_CHANGE_TYPES
OR Certificate_Action is contained in reference set ENV_ADC_CERTIFICATE_ACCESS_ACTIONS
OR Traffic_Path_Change_Type is contained in reference set ENV_ADC_TRAFFIC_PATH_CHANGE_TYPES
OR Administrative_Control_Change is contained in reference set ENV_ADC_ADMINISTRATIVE_CONTROL_CHANGE_TYPES
OR Downstream_Application_Behavior is contained in reference set ENV_ADC_DOWNSTREAM_APPLICATION_ANOMALIES
)
AND (
Source_IP equals Prior_Multi_Asset_Probe_Source_IP
OR Forwarded_Source_IP equals Prior_Multi_Asset_Probe_Forwarded_Source_IP
OR Source_Network equals Prior_Multi_Asset_Probe_Source_Network
OR Source_ASN equals Prior_Multi_Asset_Probe_Source_ASN
OR User_Agent equals Prior_Multi_Asset_Probe_User_Agent
OR API_Path_Family equals Prior_Multi_Asset_Probe_API_Path_Family
OR API_Method_Family equals Prior_Multi_Asset_Probe_API_Method_Family
OR Request_Parameter_Family equals Prior_Multi_Asset_Probe_Request_Parameter_Family
OR ADC_Asset_ID is contained in Prior_Multi_Asset_Probe_Affected_ADC_Assets
OR ADC_Asset_Group is contained in Prior_Multi_Asset_Probe_Affected_ADC_Asset_Groups
OR Exposure_Class is contained in Prior_Multi_Asset_Probe_Affected_Exposure_Classes
)
AND NOT (
Source_IP is contained in reference set ENV_APPROVED_ADC_SCANNER_SOURCES
OR Source_IP is contained in reference set ENV_APPROVED_ADC_VENDOR_SUPPORT_SOURCES
OR Source_IP is contained in reference set ENV_APPROVED_ADC_PATCH_VALIDATION_SOURCES
OR Source_IP is contained in reference set ENV_APPROVED_RED_TEAM_SOURCES
OR Event_Time is contained in reference set ENV_APPROVED_ADC_MAINTENANCE_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_ADC_VENDOR_SUPPORT_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_RED_TEAM_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_ADC_INCIDENT_RESPONSE_WINDOWS
)
THEN generate offense with context:
Source_IP,
Forwarded_Source_IP,
Source_Network,
Source_ASN,
Source_Geo,
Source_Network_Type,
User_Agent,
API_Path_Family,
API_Method_Family,
Request_Parameter_Family,
Request_Timing_Pattern,
ADC_Asset_ID,
ADC_Appliance,
ADC_Asset_Group,
Exposure_Class,
Asset_Criticality,
Distinct_ADC_Asset_Count,
Distinct_ADC_Asset_Group_Count,
Distinct_Exposure_Class_Count,
Affected_ADC_Assets,
Affected_ADC_Asset_Groups,
Affected_Exposure_Classes,
Virtual_Service,
Backend_Pool,
Backend_Host,
HTTP_Status_Code,
HTTP_Status_Sequence,
Appliance_Health_Event,
Destination_Domain,
Destination_IP,
Destination_Port,
Destination_Reputation,
Destination_First_Seen_Status,
NDR_Behavior,
Configuration_Change_Type,
Certificate_Action,
Traffic_Path_Change_Type,
Administrative_Control_Change,
Downstream_Application_Behavior,
Multi_Asset_Probe_Cluster_Time,
ADC_Post_Access_Time,
Building_Block_ADC_Related_Multi_Asset_Control_Plane_Probing

Rule

ADC Traffic-Processing Exploit Activity Followed by Appliance Instability or Availability Impact

Rule Format

QRadar CRE-style correlation rule.

Detection Purpose

Detect suspicious traffic against externally reachable ADC traffic-processing functions followed by appliance instability, service failure, restart, failover, resource exhaustion, abnormal connection behavior, or downstream availability degradation without requiring prior management/API access.

Detection Logic

Create a dedicated traffic-processing building block that identifies events targeting ADC listeners, virtual services, protocol handlers, NAT functions, ALGs, or related processing surfaces where source or protocol behavior is anomalous. Create a separate appliance-instability building block for crashes, watchdog events, restarts, reboots, HA transitions, failover, resource exhaustion, connection resets, service unavailability, or downstream availability degradation.

Generate an offense only when the suspicious traffic-processing building block is followed by the instability or availability building block for the same ADC asset and compatible listener, virtual-service, protocol, traffic-processing function, or destination context within the configured correlation window.

Required Telemetry

·        QRadar DSM or custom-property mappings for ADC traffic-facing network, protocol, WAF, reverse-proxy, load-balancer, NDR, firewall, or flow events.

·        Appliance-health, syslog, restart, watchdog, HA, failover, resource, and diagnostic events.

·        Reference sets or maps for ADC assets, listeners, virtual services, exposed protocols, traffic-processing functions, approved sources, maintenance windows, and expected operational activity.

·        Custom properties for protocol behavior, message size, listener, virtual service, ADC asset ID, processing function, appliance-health event, and downstream availability behavior.

Engineering Implementation Instructions

·        Create Building_Block_ADC_Suspicious_Traffic_Processing_Activity.

·        Create Building_Block_ADC_Appliance_Instability_Or_Availability_Impact.

·        Keep Building_Block_ADC_Suspicious_Control_Plane_Access separate and do not use it as a prerequisite.

·        Correlate the new building blocks by ADC asset ID and, where available, listener, virtual service, protocol, processing function, destination IP, or traffic-facing interface.

·        Tune approved load testing, protocol testing, vendor support, health checking, failover testing, maintenance, and incident-response activity through reference sets and building-block exclusions.

·        Escalate offense magnitude only when independent appliance or availability impact follows suspicious traffic-processing activity.

DRI Assessment

This rule has strong detection reliability because QRadar CRE can explicitly separate the traffic-processing initiator from appliance-health consequences and require temporal correlation before creating an offense.

DRI

8.7

TCR Assessment

Operational TCR is strong when relevant network and appliance-health events are correctly normalized into QRadar. Full-Telemetry TCR improves with richer listener, virtual-service, protocol, HA, resource, downstream application, and traffic-processing configuration mappings.

Operational TCR

8.4

Full-Telemetry TCR

9.1

Limitations

·        DSM parsing or custom-property gaps may prevent reliable asset or protocol correlation.

·        Flow telemetry may show the connection but not malformed application-layer content.

·        Appliance-health events may not include the network transaction that triggered them.

·        Legitimate failover, resource pressure, maintenance, or vendor troubleshooting may resemble exploitation effects.

·        The rule cannot establish the exact memory-corruption mechanism without vendor or appliance diagnostic evidence.

Detection Query Pattern

Use this CRE-style pattern as the implementation guide for QRadar building blocks, reference data, and offense correlation.

BUILDING BLOCK Building_Block_ADC_Suspicious_Traffic_Processing_Activity

WHEN

    Destination_Asset IN Reference_Set_ADC_Edge_Assets

AND (

    ADC_Listener IN Reference_Set_ADC_Public_Or_Partner_Listeners

    OR ADC_Virtual_Service IN Reference_Set_ADC_Virtual_Services

    OR ADC_Traffic_Processing_Function IN Reference_Set_ADC_Traffic_Processing_Functions

)

AND Source_IP NOT IN Reference_Set_Approved_ADC_Traffic_Sources

AND Event_Time NOT IN Reference_Set_Approved_ADC_Context_Windows

AND (

    Source_First_Seen_Status IN ("new", "rare")

    OR Source_ASN IN Reference_Set_Suspicious_ASNs

    OR Source_Network_Type IN (

        "cloud_hosted",

        "residential_proxy",

        "vpn_provider",

        "scanner_infrastructure",

        "unknown_hosting"

    )

    OR Protocol_Behavior IN (

        "malformed",

        "protocol_inconsistent",

        "unexpected_sequence",

        "fuzzing_like",

        "abnormal_transaction"

    )

    OR Message_Size > Reference_Value_ADC_Protocol_Message_Size_Upper_Baseline

    OR Connection_Behavior IN (

        "rapid_retry",

        "repeated_invalid_request",

        "unexpected_disconnect",

        "abnormal_retransmission"

    )

)

BUILDING BLOCK Building_Block_ADC_Appliance_Instability_Or_Availability_Impact

WHEN

    ADC_Asset_ID IN Reference_Set_ADC_Edge_Assets

AND Event_Time NOT IN Reference_Set_Approved_ADC_Context_Windows

AND (

    Appliance_Health_Event IN (

        "process_crash",

        "service_crash",

        "watchdog_restart",

        "service_restart",

        "appliance_reboot",

        "unexpected_failover",

        "ha_state_change",

        "resource_exhaustion",

        "resource_pressure",

        "traffic_processing_fault"

    )

    OR Connection_State IN (

        "timeout",

        "reset",

        "closed_after_error",

        "service_unavailable"

    )

    OR Downstream_Application_Behavior IN (

        "availability_degradation",

        "backend_connection_loss",

        "application_unreachable",

        "traffic_path_disruption"

    )

)

RULE ADC_Traffic_Processing_Exploit_Activity_Followed_By_Appliance_Instability_Or_Availability_Impact

WHEN

    Building_Block_ADC_Suspicious_Traffic_Processing_Activity

FOLLOWED BY

    Building_Block_ADC_Appliance_Instability_Or_Availability_Impact

WITHIN

    ENV_ADC_TRAFFIC_PROCESSING_TO_INSTABILITY_WINDOW

AND Same_ADC_Asset_ID = true

AND (

    Same_ADC_Listener = true

    OR Same_ADC_Virtual_Service = true

    OR Same_Protocol = true

    OR Same_ADC_Traffic_Processing_Function = true

    OR Same_Destination_IP = true

)

CREATE OFFENSE

WITH

    ADC_Asset_ID,

    ADC_Asset_Name,

    Source_IP,

    Destination_IP,

    Destination_Port,

    Traffic_Facing_Interface,

    ADC_Listener,

    ADC_Virtual_Service,

    Protocol,

    ADC_Traffic_Processing_Function,

    Protocol_Behavior,

    Message_Size,

    Connection_Behavior,

    Appliance_Health_Event,

    Downstream_Application_Behavior

SIGMA

Detection Viability Assessment

SIGMA is viable as a portable event-rule template for this behavior family when ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS, proxy, firewall, NDR, flow telemetry, configuration-change records, certificate-management records, and downstream application logs are locally enriched before rule evaluation. SIGMA is not the strongest system for raw multi-source sequence construction by itself because backend SIEMs vary in correlation, joins, windows, and enrichment support. Its best use is to express portable, backend-mappable detection logic for suspicious ADC control-plane access, post-access instability, rare ADC egress, configuration or certificate manipulation, traffic-path change, and multi-asset probing where the required correlation flags are created in the target SIEM.

Rule

ADC Control-Plane Access With Instability or Rare Egress Indicators

Rule Format

SIGMA event-rule template.

Detection Purpose

Detect locally enriched ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management control-plane access correlated with appliance instability, abnormal response behavior, failed-to-success sequencing, or rare ADC-originated egress. This rule is intended to identify behavior consistent with pre-authentication or weakly authenticated ADC control-plane exploitation, including Progress Kemp LoadMaster CVE-2026-8037-like activity where locally visible, without making detection dependent on one vendor, endpoint path, CVE name, proof-of-concept string, or scanner signature.

Detection Logic

Identify suspicious ADC control-plane access where the target asset is an edge ADC or traffic-management appliance, the request targets a management/API surface, and the activity occurs inside a locally defined control-plane-to-impact correlation window. Increase confidence when the source is new, rare, geographically unexpected, scanner-like, automation-like, or outside approved administrative context. Promote when local enrichment indicates appliance instability, abnormal status sequencing, management-service fault, API handler fault, watchdog or restart behavior, abnormal connection state, rare egress, suspicious destination, unusual destination port, or destination geo deviation. Exclude approved administration, scanning, vendor support, patch validation, monitoring, maintenance, backup, certificate rotation, and incident-response workflows.

Required Telemetry

·        ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, appliance syslog, and administrative audit logs where available.

·        DNS, proxy, firewall, NDR, NetFlow, VPC flow, data-center flow, or endpoint-network telemetry for ADC-originated outbound communication.

·        Locally enriched fields for ADC asset scope, management/API surface match, source risk, status sequence, appliance health event, request timing, response-size baseline, rare egress, destination reputation, destination age, approved source, approved egress, and approved maintenance context.

·        ADC appliance inventory, management-interface inventory, API exposure inventory, virtual-service inventory, backend-pool inventory, approved administrative source inventory, approved partner path inventory, and approved maintenance-window context.

·        Backend SIEM correlation fields showing same ADC asset, same source, same forwarded source, same API path family, and active control-plane-to-impact window.

Engineering Implementation Instructions

·        Deploy first as a portable event-rule template and map all local fields to the target SIEM before production alerting.

·        Use the target SIEM to create local enrichment fields for control-plane access, post-access instability, rare egress, source risk, destination risk, approved exception context, and same-asset lineage.

·        Treat suspicious management/API access alone as exploit-attempt evidence, not confirmed compromise.

·        Require local correlation fields before promoting to alert mode.

·        Suppress approved administrative sources, approved scanners, vendor support, monitoring, patch validation, backup, license validation, update retrieval, certificate rotation, and documented maintenance windows.

·        Promote severity when suspicious control-plane activity is correlated with appliance instability, rare egress, repeated callbacks, internal service access, abnormal status sequencing, or suspicious destination behavior.

DRI Assessment

This rule has moderate-to-strong portable detection reliability because it relies on locally enriched behavior flags instead of raw backend-specific sequence syntax. It remains reusable across ADC, load balancer, reverse proxy, WAF-adjacent, and edge traffic-management compromise scenarios because it does not depend on a single Progress Kemp LoadMaster endpoint, CVE identifier, public exploit string, or user agent. Reliability depends on whether the target SIEM can accurately enrich ADC asset scope, management/API access, exception context, post-access instability, and rare egress.

DRI

8.0

TCR Assessment

Operational TCR is moderate-to-strong where the target SIEM can enrich ADC management/API logs, WAF or reverse-proxy logs, DNS, proxy, firewall, NDR, asset inventory, source exceptions, and approved egress. Full-Telemetry TCR improves when appliance syslog, configuration-change records, certificate records, administrative audit logs, downstream application logs, and endpoint telemetry are mapped into the backend correlation workflow.

Operational TCR

7.7

Full-Telemetry TCR

8.5

Limitations

·        SIGMA should not be treated as the final backend implementation without local field mapping, enrichment, translation, and tuning.

·        This rule cannot confirm command execution without appliance process, shell, diagnostic, system, endpoint, or vendor log evidence.

·        Request-body loss, query-string redaction, CDN layering, NAT, proxy forwarding, or incomplete forwarded-source preservation may reduce confidence.

·        Rare egress may reflect approved vendor support, update retrieval, license validation, backup, monitoring, troubleshooting, or incident-response activity if exception enrichment is incomplete.

·        Vulnerable-version status, public PoC availability, scanner traffic, or KEV status must not be treated as standalone compromise confirmation.

Detection Query Pattern

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

title: ADC Control-Plane Access With Instability Or Rare Egress Indicators
id: 6f7d4e8a-30d3-4c43-a8e1-5d5d8d8d5b31
status: experimental
description: Detects locally enriched ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management control-plane access correlated with appliance instability, abnormal response behavior, failed-to-success sequencing, or rare ADC-originated egress.
references:

·        Internal CyberDax detection model for ADC control-plane compromise and edge traffic-management abuse
author: CyberDax
date: 2026-07-08
logsource:
product: webserver
service: adc
detection:
scope_adc_edge_asset:
adc.asset.edge: true
scope_adc_asset_context:
adc.asset.id_present: true
scope_control_plane_to_impact_window:
adc.correlation.control_plane_to_impact_window_active: true
suspicious_control_plane_access_seen:
adc.correlation.control_plane_access_seen: true
suspicious_control_plane_surface:
adc.request.management_or_api_surface: true
suspicious_loadmaster_accessv2_surface:
adc.vendor.progress_kemp.loadmaster.accessv2_surface: true
suspicious_generic_admin_or_api_surface:
adc.request.surface_family:

o   management

o   api

o   administrative

o   diagnostic

o   authentication

o   telemetry

o   configuration

o   control_plane
source_new_or_rare:
source.first_seen.status:

o   new

o   rare
source_suspicious_network_type:
source.network.type:

o   cloud_hosted

o   residential_proxy

o   vpn_provider

o   scanner_infrastructure

o   unknown_hosting
source_geo_deviation:
baseline.adc.expected_admin_source_geo_match: false
suspicious_user_agent:
user_agent.risk:

o   rare

o   automated

o   scanner_like
suspicious_request_method:
adc.request.method_risk:

o   unexpected_for_management

o   unusual_for_api
suspicious_control_plane_payload_pattern:
adc.request.pattern_match:

o   command_delimiter

o   shell_control

o   quote_manipulation

o   encoded_command

o   malformed_json

o   oversized_api_field

o   authentication_bypass_pattern

o   api_parameter_manipulation

o   unusual_adc_api_method
request_size_high:
adc.request.size_above_management_baseline: true
response_size_high:
adc.response.size_above_management_baseline: true
response_size_low:
adc.response.size_below_management_baseline: true
request_timing_suspicious:
adc.request.timing_pattern:

o   rapid_retry

o   automation_like

o   low_and_slow_probe

o   failed_then_successful_access

o   parameter_fuzzing
control_plane_status_sequence_abnormal:
adc.http.status_sequence:

o   repeated_errors

o   errors_then_success

o   failed_then_success

o   abnormal_redirect_sequence

o   control_plane_instability_sequence
appliance_instability_after_access:
adc.correlation.appliance_instability_after_control_plane_access: true
appliance_health_fault:
adc.appliance.health_event:

o   watchdog_restart

o   service_restart

o   management_service_fault

o   api_handler_exception

o   authentication_handler_error

o   failover_event

o   resource_exhaustion
abnormal_connection_state:
network.action:

o   timeout

o   reset

o   closed_after_error

o   service_unavailable
rare_adc_egress_after_access:
adc.correlation.rare_egress_after_control_plane_access: true
rare_adc_egress:
adc.network.rare_egress: true
suspicious_destination:
destination.reputation:

o   unknown

o   suspicious

o   malicious
destination_new_or_rare:
destination.first_seen.status:

o   new

o   rare
destination_domain_new:
destination.domain.age_category:

o   new

o   very_new
destination_geo_deviation:
baseline.adc.expected_destination_geo_match: false
unusual_egress_port:
destination.port.risk: unusual_for_adc
unusual_egress_protocol:
network.protocol.risk:

o   unusual_for_adc

o   raw_ip

o   tunnel

o   file_transfer
same_adc_or_source_context:
correlation.same_adc_or_source_context: true
same_control_plane_to_impact_lineage:
correlation.same_control_plane_to_impact_lineage: true
filter_approved_adc_admin_source:
exception.approved_adc_admin_source: true
filter_approved_forwarded_adc_admin_source:
exception.approved_forwarded_adc_admin_source: true
filter_approved_adc_scanner:
exception.approved_adc_scanner: true
filter_approved_adc_vendor_support:
exception.approved_adc_vendor_support_source: true
filter_approved_adc_patch_validation:
exception.approved_adc_patch_validation_source: true
filter_approved_adc_monitoring:
exception.approved_adc_monitoring_source: true
filter_approved_adc_egress:
exception.approved_adc_egress_destination: true
filter_approved_adc_vendor_egress:
exception.approved_adc_vendor_support_destination: true
filter_approved_adc_update_egress:
exception.approved_adc_update_destination: true
filter_approved_adc_license_egress:
exception.approved_adc_license_destination: true
filter_approved_adc_maintenance:
exception.approved_adc_maintenance_window: true
filter_approved_adc_change:
exception.approved_adc_change_window: true
filter_approved_adc_patch:
exception.approved_adc_patch_window: true
filter_approved_adc_backup:
exception.approved_adc_backup_window: true
filter_approved_adc_incident_response:
exception.approved_adc_incident_response_window: true
condition: scope_adc_edge_asset and scope_adc_asset_context and scope_control_plane_to_impact_window and suspicious_control_plane_access_seen and same_adc_or_source_context and same_control_plane_to_impact_lineage and (suspicious_control_plane_surface or suspicious_loadmaster_accessv2_surface or suspicious_generic_admin_or_api_surface) and (1 of source_* or suspicious_user_agent or suspicious_request_method or suspicious_control_plane_payload_pattern or 1 of request_* or 1 of response_* or request_timing_suspicious or control_plane_status_sequence_abnormal or appliance_instability_after_access or appliance_health_fault or abnormal_connection_state or rare_adc_egress_after_access or rare_adc_egress or suspicious_destination or destination_new_or_rare or destination_domain_new or destination_geo_deviation or unusual_egress_port or unusual_egress_protocol) and not 1 of filter_
fields:

·        adc.asset.id

·        adc.asset.name

·        adc.asset.edge

·        adc.asset.role

·        adc.management.interface

·        adc.virtual_service

·        adc.backend_pool

·        source.ip

·        source.forwarded_ip

·        source.geo.country_name

·        source.as.number

·        source.network.type

·        user_agent.original

·        http.request.method

·        url.path

·        url.query

·        http.response.status_code

·        http.request.bytes

·        http.response.bytes

·        adc.request.surface_family

·        adc.request.pattern_match

·        adc.request.timing_pattern

·        adc.http.status_sequence

·        adc.appliance.health_event

·        network.action

·        destination.domain

·        destination.ip

·        destination.port

·        destination.reputation

·        destination.first_seen.status

·        destination.domain.age_days

·        destination.as.number

·        destination.geo.country_name

·        network.protocol

·        adc.correlation.control_plane_access_seen

·        adc.correlation.appliance_instability_after_control_plane_access

·        adc.correlation.rare_egress_after_control_plane_access

·        adc.correlation.control_plane_to_impact_window_active

·        correlation.same_adc_or_source_context

·        correlation.same_control_plane_to_impact_lineage
falsepositives:

·        Approved ADC administration, monitoring, health-checking, troubleshooting, or failover testing

·        Approved vulnerability validation, scanner activity, or emergency patch verification

·        Approved vendor support, license validation, update retrieval, telemetry, or managed-service workflow

·        Approved backup, certificate rotation, configuration export, diagnostic collection, or incident-response workflow

·        Approved egress to known ADC business, vendor, update, DNS, NTP, syslog, monitoring, backup, or integration destinations
level: high

Rule

ADC Control-Plane Access With Configuration, Certificate, Or Traffic-Path Manipulation Indicators

Rule Format

SIGMA event-rule template.

Detection Purpose

Detect locally enriched ADC control-plane access correlated with configuration exposure, configuration change, virtual-service manipulation, backend-pool modification, routing or header-control changes, TLS or certificate-object access, backup or diagnostic artifact access, administrative-control change, logging degradation, or downstream application traffic-path anomalies. This rule is intended to identify compromise behavior affecting the edge application-delivery trust boundary rather than only the vulnerable appliance.

Detection Logic

Identify suspicious control-plane access to ADC management, API, administrative, diagnostic, authentication, telemetry, or configuration surfaces. Promote when local enrichment indicates protected configuration access, certificate or TLS-object access, private-key access, backup export, diagnostic bundle creation, packet capture creation, virtual-service change, backend-pool change, routing change, header manipulation, TLS offload change, administrative-control change, logging degradation, or downstream application anomaly. Require same-asset, same-object, same-virtual-service, or same-control-plane-to-impact lineage before alerting.

Required Telemetry

·        ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, appliance syslog, administrative audit logs, and configuration-change records.

·        Certificate-management records, TLS binding records, configuration export records, backup records, diagnostic bundle records, packet capture records, administrative-user records, API key records, and logging-setting records where available.

·        Downstream web server logs, downstream application logs, identity logs, backend service logs, WAF logs, proxy logs, NDR, DNS, proxy, firewall, and flow telemetry.

·        Locally enriched fields for ADC protected configuration objects, certificate objects, private-key material, backups, diagnostic artifacts, packet captures, traffic-path change, header behavior, route behavior, TLS behavior, downstream application behavior, approved change actors, and approved traffic-path changes.

·        Backend SIEM correlation fields showing same ADC asset, same management interface, same source, same virtual service, same backend pool, same configuration object, same certificate object, or same downstream application lineage.

Engineering Implementation Instructions

·        Deploy first as a portable event-rule template and map all local fields to the target SIEM before production alerting.

·        Use the target SIEM to create local enrichment fields for protected object access, configuration change, certificate access, traffic-path manipulation, downstream anomalies, approved changes, and same-asset lineage.

·        Require control-plane-to-object or control-plane-to-downstream correlation before promoting to alert mode.

·        Suppress known-good certificate rotation, key rotation, virtual-service changes, backend-pool changes, routing changes, health-check tuning, backup jobs, diagnostic collection, vendor support, failover testing, monitoring activity, emergency maintenance, and documented incident-response collection.

·        Treat downstream application anomalies as ADC-related only when local correlation aligns them to suspicious ADC control-plane behavior.

·        Escalate when certificate or private-key access, backup export, diagnostic bundle creation, configuration export, logging degradation, administrative-control change, traffic mirroring, or downstream application exposure follows suspicious management/API access.

DRI Assessment

This rule has moderate-to-strong portable detection reliability because it focuses on protected ADC trust-boundary objects and downstream consequences rather than scanner traffic alone. It remains reusable across ADC, load balancer, reverse proxy, WAF-adjacent, and traffic-management compromise scenarios because it anchors on configuration, certificate, routing, and traffic-path manipulation instead of a single vendor endpoint. Reliability depends on local object enrichment, approved change context, and backend SIEM correlation quality.

DRI

8.0

TCR Assessment

Operational TCR is moderate-to-strong when the target SIEM can enrich ADC management/API logs, configuration-change records, WAF or reverse-proxy logs, asset inventory, approved changes, and NDR telemetry. Full-Telemetry TCR improves when certificate-management records, backup comparison, administrative audit logs, endpoint telemetry, downstream application logs, and virtual-service-to-backend mappings are available.

Operational TCR

7.7

Full-Telemetry TCR

8.6

Limitations

·        SIGMA should not be treated as the final backend implementation without local field mapping, enrichment, translation, and tuning.

·        This rule may miss object-level access if ADC appliances do not log configuration reads, certificate reads, private-key access, backup creation, diagnostic bundle creation, or administrative API actions.

·        Approved backup, certificate renewal, vendor support, emergency routing changes, failover testing, patch validation, and incident-response collection may resemble suspicious post-access behavior.

·        Downstream application anomalies cannot be attributed to ADC compromise without local linkage to ADC appliance, virtual service, backend mapping, request path, source, administrative action, or time window.

·        Configuration export timestamps may reflect backup, migration, restoration, failover, or maintenance rather than attacker action.

Detection Query Pattern

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

title: ADC Control-Plane Access With Configuration Certificate Or Traffic-Path Manipulation Indicators
id: 97f1ccec-4fd8-4e6f-a6f2-fc13ec8d76f9
status: experimental
description: Detects locally enriched ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management control-plane access correlated with protected configuration access, certificate or TLS-object access, backup export, diagnostic artifact access, traffic-path manipulation, administrative-control change, logging degradation, or downstream application anomalies.
references:

·        Internal CyberDax detection model for ADC control-plane compromise and edge application-delivery trust-boundary abuse
author: CyberDax
date: 2026-07-08
logsource:
product: webserver
service: adc
detection:
scope_adc_edge_asset:
adc.asset.edge: true
scope_adc_asset_context:
adc.asset.id_present: true
scope_control_plane_to_object_window:
adc.correlation.control_plane_to_object_window_active: true
suspicious_control_plane_access_seen:
adc.correlation.control_plane_access_seen: true
suspicious_control_plane_surface:
adc.request.management_or_api_surface: true
suspicious_generic_admin_or_api_surface:
adc.request.surface_family:

o   management

o   api

o   administrative

o   diagnostic

o   authentication

o   telemetry

o   configuration

o   control_plane
source_new_or_rare:
source.first_seen.status:

o   new

o   rare
source_suspicious_network_type:
source.network.type:

o   cloud_hosted

o   residential_proxy

o   vpn_provider

o   scanner_infrastructure

o   unknown_hosting
source_geo_deviation:
baseline.adc.expected_admin_source_geo_match: false
suspicious_user_agent:
user_agent.risk:

o   rare

o   automated

o   scanner_like
suspicious_control_plane_payload_pattern:
adc.request.pattern_match:

o   command_delimiter

o   shell_control

o   quote_manipulation

o   encoded_command

o   malformed_json

o   oversized_api_field

o   authentication_bypass_pattern

o   api_parameter_manipulation

o   unusual_adc_api_method
protected_configuration_access:
adc.configuration.object.protected: true
protected_configuration_action:
adc.configuration.action:

o   read

o   export

o   download

o   create

o   modify

o   delete

o   replace

o   backup
certificate_or_tls_object_access:
adc.certificate.object.protected: true
certificate_or_tls_action:
adc.certificate.action:

o   read

o   export

o   download

o   bind

o   unbind

o   modify

o   delete
private_key_or_credential_material:
adc.credential_material.access:

o   private_key

o   keystore

o   api_token

o   credential_bearing_file

o   saml_material

o   oidc_material
backup_export_or_download:
adc.backup.action:

o   create

o   export

o   download

o   archive
diagnostic_artifact_access:
adc.diagnostic.action:

o   create

o   export

o   download
packet_capture_access:
adc.packet_capture.action:

o   create

o   read

o   export

o   download
traffic_path_change:
adc.traffic_path.change_type:

o   virtual_service_modified

o   backend_pool_modified

o   routing_rule_modified

o   rewrite_rule_modified

o   header_rule_modified

o   certificate_binding_modified

o   tls_offload_modified

o   persistence_profile_modified

o   health_check_modified

o   logging_setting_modified

o   administrative_setting_modified

o   api_key_created

o   admin_user_created

o   admin_role_modified
header_behavior:
adc.header.behavior:

o   new_header_added

o   header_removed

o   header_rewritten

o   forwarded_for_anomaly

o   host_header_anomaly
route_behavior:
adc.route.behavior:

o   unexpected_route

o   unexpected_backend_selection

o   traffic_mirroring_suspected
tls_behavior:
adc.tls.behavior:

o   certificate_binding_change

o   tls_termination_change

o   unexpected_plaintext_backend_flow

o   unexpected_tls_offload_path
downstream_application_behavior:
downstream.application.behavior:

o   unexpected_backend_access

o   authentication_flow_change

o   session_routing_change

o   header_manipulation

o   traffic_mirroring_suspected

o   data_exposure_like_response

o   availability_degradation
same_adc_or_source_context:
correlation.same_adc_or_source_context: true
same_control_plane_to_object_lineage:
correlation.same_control_plane_to_object_lineage: true
same_control_plane_to_downstream_lineage:
correlation.same_control_plane_to_downstream_lineage: true
filter_approved_adc_admin_source:
exception.approved_adc_admin_source: true
filter_approved_forwarded_adc_admin_source:
exception.approved_forwarded_adc_admin_source: true
filter_approved_adc_scanner:
exception.approved_adc_scanner: true
filter_approved_adc_vendor_support:
exception.approved_adc_vendor_support_source: true
filter_approved_adc_patch_validation:
exception.approved_adc_patch_validation_source: true
filter_approved_adc_change_actor:
exception.approved_adc_change_actor: true
filter_approved_adc_traffic_path_change:
exception.approved_adc_traffic_path_change: true
filter_approved_adc_certificate_rotation:
exception.approved_adc_certificate_rotation_window: true
filter_approved_adc_backup:
exception.approved_adc_backup_window: true
filter_approved_adc_maintenance:
exception.approved_adc_maintenance_window: true
filter_approved_adc_change:
exception.approved_adc_change_window: true
filter_approved_adc_incident_response:
exception.approved_adc_incident_response_window: true
condition: scope_adc_edge_asset and scope_adc_asset_context and scope_control_plane_to_object_window and suspicious_control_plane_access_seen and same_adc_or_source_context and (same_control_plane_to_object_lineage or same_control_plane_to_downstream_lineage) and (suspicious_control_plane_surface or suspicious_generic_admin_or_api_surface) and (1 of source_* or suspicious_user_agent or suspicious_control_plane_payload_pattern or protected_configuration_access or protected_configuration_action or certificate_or_tls_object_access or certificate_or_tls_action or private_key_or_credential_material or backup_export_or_download or diagnostic_artifact_access or packet_capture_access or traffic_path_change or header_behavior or route_behavior or tls_behavior or downstream_application_behavior) and not 1 of filter_
fields:

·        adc.asset.id

·        adc.asset.name

·        adc.asset.edge

·        adc.asset.role

·        adc.management.interface

·        adc.virtual_service

·        adc.backend_pool

·        adc.backend_host

·        source.ip

·        source.forwarded_ip

·        source.geo.country_name

·        source.as.number

·        source.network.type

·        user_agent.original

·        http.request.method

·        url.path

·        url.query

·        http.response.status_code

·        adc.request.surface_family

·        adc.request.pattern_match

·        adc.configuration.object.name

·        adc.configuration.object.protected

·        adc.configuration.action

·        adc.certificate.object.name

·        adc.certificate.object.protected

·        adc.certificate.action

·        adc.credential_material.access

·        adc.backup.action

·        adc.diagnostic.action

·        adc.packet_capture.action

·        adc.traffic_path.change_type

·        adc.header.behavior

·        adc.route.behavior

·        adc.tls.behavior

·        downstream.application.behavior

·        adc.correlation.control_plane_access_seen

·        adc.correlation.control_plane_to_object_window_active

·        correlation.same_adc_or_source_context

·        correlation.same_control_plane_to_object_lineage

·        correlation.same_control_plane_to_downstream_lineage
falsepositives:

·        Approved ADC administration, configuration export, certificate rotation, key rotation, backup, diagnostic collection, or packet capture collection

·        Approved virtual-service, backend-pool, routing, rewrite, header, persistence-profile, health-check, TLS, or WAF policy change

·        Approved vendor support, patch validation, failover testing, monitoring activity, emergency maintenance, or incident-response collection

·        Approved downstream application deployment, troubleshooting, migration, or maintenance workflow
level: high

Rule

Multiple ADC Assets With Related Control-Plane Probing Or Post-Access Indicators

Rule Format

SIGMA event-rule template.

Detection Purpose

Detect locally enriched campaign-like activity across multiple ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management assets where related control-plane probing, exploit-attempt behavior, instability, rare egress, configuration access, certificate access, virtual-service changes, or downstream anomalies appear within a bounded time window. This rule is intended to identify coordinated targeting or exposure review without assuming confirmed compromise from multi-asset scanner traffic alone.

Detection Logic

Identify related control-plane probing across two or more ADC or edge traffic-management assets using local enrichment for source clustering, request-path family, API-method family, parameter family, timing pattern, asset group, exposure class, and asset criticality. Promote only when at least one affected appliance also shows post-access evidence such as instability, rare egress, configuration or certificate access, administrative-control change, traffic-path manipulation, logging degradation, or downstream application anomaly.

Required Telemetry

·        ADC management/API logs, WAF logs, CDN logs, reverse-proxy logs, load-balancer logs, gateway logs, firewall logs, DNS logs, proxy logs, NDR, flow telemetry, appliance syslog, configuration-change logs, and downstream application logs.

·        ADC appliance inventory, internet-exposure inventory, partner-reachable path inventory, management-interface inventory, API exposure inventory, virtual-service inventory, backend-pool inventory, asset criticality, exposure class, and downstream application mapping.

·        Locally enriched fields for multi-asset cluster count, asset group count, exposure class count, source clustering, request family, API method family, parameter family, timing pattern, post-access behavior, and approved exception context.

·        Approved scanners, approved administrative sources, vendor support sources, patch-validation sources, monitoring systems, synthetic checks, red-team sources, incident-response sources, and maintenance-window exceptions.

·        Backend SIEM correlation fields showing same source, same forwarded source, same source network, same ASN, same user agent, same API path family, same request parameter family, same affected asset cluster, or same exposure class.

Engineering Implementation Instructions

·        Deploy first as a portable event-rule template and map all local fields to the target SIEM before production alerting.

·        Use the target SIEM to create local enrichment fields for multi-asset clustering, source clustering, request-family grouping, exposure class, asset criticality, post-access behavior, and approved exception context.

·        Require at least two ADC or traffic-management assets before campaign-correlation logic triggers.

·        Require post-access behavior from at least one appliance before promoting beyond exploit-attempt or exposure-review confidence.

·        Suppress approved enterprise vulnerability scanning, vendor advisory validation, patch verification, synthetic monitoring, health checks, red-team activity, and documented incident-response sweeps.

·        Prioritize production, internet-facing, partner-reachable, authentication-fronting, TLS-terminating, high-availability, and critical application-delivery appliances.

DRI Assessment

This rule has moderate-to-strong portable detection reliability for campaign-like targeting, but compromise confidence depends on post-access evidence. It remains reusable across ADC, load balancer, reverse proxy, WAF-adjacent, and traffic-management assets because it correlates source behavior, request families, exposure classes, affected appliance groups, and post-access effects instead of a single payload or CVE identifier. Reliability depends on multi-asset enrichment quality, backend clustering, exception tuning, and whether post-access behavior is accurately joined to the affected cluster.

DRI

7.9

TCR Assessment

Operational TCR is moderate-to-strong where WAF, CDN, reverse-proxy, load-balancer, ADC, DNS, proxy, firewall, NDR, flow, source-enrichment, and inventory data are locally enriched across multiple appliances. Full-Telemetry TCR improves when configuration-change records, certificate records, administrative audit logs, downstream application logs, appliance health events, and endpoint telemetry can be joined to campaign clusters.

Operational TCR

7.6

Full-Telemetry TCR

8.5

Limitations

·        SIGMA should not be treated as the final backend implementation without local field mapping, enrichment, translation, and tuning.

·        Multi-asset probing may reflect approved scanning, vendor validation, synthetic monitoring, patch verification, red-team activity, or incident-response review if exception enrichment is incomplete.

·        This rule should not claim confirmed compromise unless post-access appliance, configuration, certificate, egress, administrative, or downstream application evidence is present.

·        Organizations with only one ADC appliance may receive limited value from this campaign-correlation logic.

·        CDN, NAT, proxy, and partner network paths may obscure true source identity or inflate source-clustering confidence.

Detection Query Pattern

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

title: Multiple ADC Assets With Related Control-Plane Probing Or Post-Access Indicators
id: c54ef67e-7f7b-4d43-8ff1-0a3426a0d89f
status: experimental
description: Detects locally enriched campaign-like activity across multiple ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management assets with related control-plane probing and at least one post-access behavior indicator.
references:

·        Internal CyberDax detection model for coordinated ADC control-plane probing and edge traffic-management compromise review
author: CyberDax
date: 2026-07-08
logsource:
product: webserver
service: adc
detection:
scope_adc_edge_asset:
adc.asset.edge: true
scope_adc_asset_context:
adc.asset.id_present: true
scope_multi_adc_cluster_window:
adc.correlation.multi_asset_probe_cluster_window_active: true
related_multi_asset_probe_seen:
adc.correlation.related_multi_asset_probe_seen: true
related_asset_count_threshold:
adc.campaign.related_asset_count_threshold_met: true
related_asset_group_threshold:
adc.campaign.related_asset_group_threshold_met: true
related_exposure_class_threshold:
adc.campaign.related_exposure_class_threshold_met: true
high_or_critical_asset_in_cluster:
adc.campaign.high_or_critical_asset_in_cluster: true
suspicious_control_plane_surface:
adc.request.management_or_api_surface: true
suspicious_generic_admin_or_api_surface:
adc.request.surface_family:

o   management

o   api

o   administrative

o   diagnostic

o   authentication

o   telemetry

o   configuration

o   control_plane
source_suspicious_network_type:
source.network.type:

o   cloud_hosted

o   residential_proxy

o   vpn_provider

o   scanner_infrastructure

o   unknown_hosting
source_geo_deviation:
baseline.adc.expected_admin_source_geo_match: false
suspicious_user_agent:
user_agent.risk:

o   rare

o   automated

o   scanner_like
suspicious_control_plane_payload_pattern:
adc.request.pattern_match:

o   command_delimiter

o   shell_control

o   quote_manipulation

o   encoded_command

o   malformed_json

o   oversized_api_field

o   authentication_bypass_pattern

o   api_parameter_manipulation

o   unusual_adc_api_method
request_timing_suspicious:
adc.request.timing_pattern:

o   rapid_retry

o   automation_like

o   low_and_slow_probe

o   failed_then_successful_access

o   parameter_fuzzing
control_plane_status_sequence_abnormal:
adc.http.status_sequence:

o   repeated_errors

o   errors_then_success

o   failed_then_success

o   abnormal_redirect_sequence

o   control_plane_instability_sequence
post_access_behavior_seen:
adc.correlation.post_access_behavior_seen: true
rare_adc_egress:
adc.network.rare_egress: true
appliance_health_fault:
adc.appliance.health_event:

o   watchdog_restart

o   service_restart

o   management_service_fault

o   api_handler_exception

o   authentication_handler_error

o   failover_event

o   resource_exhaustion
protected_configuration_access:
adc.configuration.object.protected: true
certificate_or_tls_object_access:
adc.certificate.object.protected: true
traffic_path_change:
adc.traffic_path.change_type:

o   virtual_service_modified

o   backend_pool_modified

o   routing_rule_modified

o   rewrite_rule_modified

o   header_rule_modified

o   certificate_binding_modified

o   tls_offload_modified

o   logging_setting_modified

o   administrative_setting_modified

o   api_key_created

o   admin_user_created

o   admin_role_modified
downstream_application_behavior:
downstream.application.behavior:

o   unexpected_backend_access

o   authentication_flow_change

o   session_routing_change

o   header_manipulation

o   traffic_mirroring_suspected

o   data_exposure_like_response

o   availability_degradation
same_source_or_request_cluster:
correlation.same_source_or_request_cluster: true
same_adc_campaign_lineage:
correlation.same_adc_campaign_lineage: true
filter_approved_adc_admin_source:
exception.approved_adc_admin_source: true
filter_approved_forwarded_adc_admin_source:
exception.approved_forwarded_adc_admin_source: true
filter_approved_adc_scanner:
exception.approved_adc_scanner: true
filter_approved_adc_vendor_support:
exception.approved_adc_vendor_support_source: true
filter_approved_adc_patch_validation:
exception.approved_adc_patch_validation_source: true
filter_approved_red_team:
exception.approved_red_team_source: true
filter_approved_adc_monitoring:
exception.approved_adc_monitoring_source: true
filter_approved_adc_maintenance:
exception.approved_adc_maintenance_window: true
filter_approved_adc_change:
exception.approved_adc_change_window: true
filter_approved_red_team_window:
exception.approved_red_team_window: true
filter_approved_adc_incident_response:
exception.approved_adc_incident_response_window: true
condition: scope_adc_edge_asset and scope_adc_asset_context and scope_multi_adc_cluster_window and related_multi_asset_probe_seen and related_asset_count_threshold and (related_asset_group_threshold or related_exposure_class_threshold or high_or_critical_asset_in_cluster) and same_source_or_request_cluster and same_adc_campaign_lineage and (suspicious_control_plane_surface or suspicious_generic_admin_or_api_surface) and (source_suspicious_network_type or source_geo_deviation or suspicious_user_agent or suspicious_control_plane_payload_pattern or request_timing_suspicious or control_plane_status_sequence_abnormal) and post_access_behavior_seen and (rare_adc_egress or appliance_health_fault or protected_configuration_access or certificate_or_tls_object_access or traffic_path_change or downstream_application_behavior) and not 1 of filter_
fields:

·        adc.asset.id

·        adc.asset.name

·        adc.asset.edge

·        adc.asset.role

·        adc.asset.group

·        adc.asset.criticality

·        adc.exposure.class

·        adc.management.interface

·        adc.virtual_service

·        adc.backend_pool

·        source.ip

·        source.forwarded_ip

·        source.geo.country_name

·        source.as.number

·        source.network.type

·        user_agent.original

·        http.request.method

·        url.path

·        url.query

·        http.response.status_code

·        adc.request.surface_family

·        adc.request.pattern_match

·        adc.request.timing_pattern

·        adc.http.status_sequence

·        adc.campaign.related_asset_count

·        adc.campaign.related_asset_group_count

·        adc.campaign.related_exposure_class_count

·        adc.correlation.related_multi_asset_probe_seen

·        adc.correlation.post_access_behavior_seen

·        adc.network.rare_egress

·        adc.appliance.health_event

·        adc.configuration.object.protected

·        adc.certificate.object.protected

·        adc.traffic_path.change_type

·        downstream.application.behavior

·        correlation.same_source_or_request_cluster

·        correlation.same_adc_campaign_lineage
falsepositives:

·        Approved enterprise vulnerability scanning, external attack-surface management, synthetic monitoring, or patch validation

·        Approved vendor advisory validation, vendor support investigation, or managed-service health checking

·        Approved red-team activity, incident-response sweep, emergency exposure review, or post-patch verification

·        Large-scale benign internet scanning that does not produce post-access appliance, configuration, certificate, egress, administrative, or downstream application evidence
level: high

Rule

ADC Traffic-Processing Activity With Appliance Instability Indicators

Rule Format

SIGMA YAML event-rule template.

Detection Purpose

Detect a backend-correlated ADC traffic-processing exploitation sequence in which suspicious or exploit-shaped interaction with an exposed listener, virtual service, protocol handler, NAT function, ALG, or other traffic-processing function is followed by independent appliance instability or availability impact for the same ADC asset within a bounded time window. This rule consumes normalized correlation flags created by the target SIEM and must not alert on malformed traffic, appliance faults, restart behavior, failover, resource exhaustion, or availability degradation independently.

Detection Logic

Require two normalized conditions that have already been correlated by the target SIEM or enrichment pipeline: suspicious ADC traffic-processing activity and independent appliance-instability or availability impact. Both conditions must refer to the same ADC asset and must have occurred within the locally defined correlation window before the normalized correlation flags are set.

The SIGMA rule should consume the correlated result rather than attempt to treat either initiating traffic or appliance instability as sufficient by itself.

Required Telemetry

·        Normalized ADC asset identity.

·        Backend-generated adc_traffic_processing_suspicious correlation flag.

·        Backend-generated adc_instability_or_availability_impact correlation flag.

·        Traffic-facing listener, virtual-service, protocol, source, destination, processing-function, and protocol-behavior context for investigation.

·        Appliance-health, crash, restart, watchdog, HA, failover, resource, connection-state, and downstream availability context.

·        Approved maintenance and operational exception fields.

Engineering Implementation Instructions

·        Normalize traffic-processing and appliance-health events in the target SIEM before SIGMA evaluation.

·        Set adc_traffic_processing_suspicious=true only when traffic is associated with a recognized ADC asset and traffic-processing surface and meets locally validated suspicious-behavior criteria.

·        Set adc_instability_or_availability_impact=true only when an independent appliance-health, connection, HA, resource, or downstream availability condition is observed.

·        Require the two flags to refer to the same ADC asset within ENV_ADC_TRAFFIC_PROCESSING_TO_INSTABILITY_WINDOW.

·        Keep SIP, SIP ALG, and LSN mappings optional and environment-specific.

·        Do not generate either correlation flag from vulnerable-version status, feature enablement, malformed traffic, appliance crash, or failover alone.

·        Suppress approved health checks, load testing, protocol testing, vulnerability validation, vendor support, maintenance, failover testing, capacity-management activity, and incident-response workflows before the correlated flags are created.

DRI Assessment

This rule has moderate-to-strong detection reliability as a portable representation of an already correlated traffic-processing exploitation sequence. Reliability is materially stronger than an event-only SIGMA rule because both the suspicious initiating activity and independent appliance or availability consequence must exist before the rule can match. Reliability depends on the quality of upstream normalization, same-asset correlation, and operational exclusions.

DRI

8.3

TCR Assessment

Operational TCR is moderate because SIGMA portability varies by backend and the prerequisite correlation flags must be created upstream. Full-Telemetry TCR is strong when the backend can correlate protocol, appliance-health, HA, resource, network, and downstream availability events by ADC asset within a bounded window.

Operational TCR

7.9

Full-Telemetry TCR

8.9

Limitations

·        SIGMA does not independently perform the underlying cross-source correlation in this implementation.

·        Local SIEM logic must reliably generate both prerequisite correlation flags.

·        Inaccurate asset mapping can create false correlation between unrelated traffic and health events.

·        The rule cannot identify the precise exploit primitive or memory-corruption mechanism.

·        Missing appliance-health or downstream telemetry may prevent the second correlation flag from being generated even when exploitation occurred.

Detection Query Pattern

Use this SIGMA YAML as the portable representation of a backend-correlated traffic-processing exploitation sequence. The target SIEM must establish same-asset, bounded-window correlation before setting both required flags.

title: ADC Traffic-Processing Activity With Appliance Instability Indicators

id: ENV_ADC_TRAFFIC_PROCESSING_INSTABILITY_RULE_ID

status: experimental

description: >

  Detects a backend-correlated ADC traffic-processing exploitation sequence

  where suspicious traffic-processing activity is followed by independent

  appliance instability or availability impact for the same ADC asset within

  a bounded time window.

logsource:

  category: network

  product: adc

detection:

  adc_asset:

    adc_asset_type:

      - adc

      - load_balancer

      - reverse_proxy

      - waf_adjacent_appliance

      - traffic_management_appliance

  correlated_traffic_processing_exploitation:

    adc_traffic_processing_suspicious: true

    adc_instability_or_availability_impact: true

  approved_context:

    approved_adc_context: true

  condition: adc_asset and correlated_traffic_processing_exploitation and not approved_context

fields:

  - adc_asset_id

  - adc_asset_name

  - source_ip

  - destination_ip

  - destination_port

  - traffic_facing_interface

  - adc_listener

  - adc_virtual_service

  - protocol

  - adc_traffic_processing_function

  - protocol_behavior

  - connection_behavior

  - appliance_health_event

  - downstream_behavior

  - traffic_processing_event_time

  - instability_event_time

  - correlation_time_delta

falsepositives:

  - Approved ADC health checks

  - Approved load or protocol testing

  - Approved vulnerability validation

  - Vendor support activity

  - Planned maintenance

  - Approved HA or failover testing

  - Capacity-management activity

  - Incident-response testing or collection

level: high

YARA

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report’s detection model is behavioral, sequence-based, control-plane driven, web-telemetry driven, SIEM-correlation based, appliance-context based, egress-correlation based, configuration-change based, certificate-object based, and downstream-impact based rather than static-file, malware-signature, or artifact-matching based.

YARA may provide limited supporting value only if a confirmed malicious appliance artifact, webshell body, encoded payload, loader, dropper, script artifact, archive artifact, memory artifact, configuration implant, certificate-theft artifact, credential-harvesting artifact, diagnostic-bundle payload, or reusable malware family artifact is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

AWS

Detection Viability Assessment

AWS is conditionally viable for this behavior family when the affected ADC, load balancer, reverse proxy, WAF-adjacent component, traffic-management appliance, protected backend application, or supporting management path is deployed in AWS or when AWS telemetry can be correlated with ADC control-plane behavior observed elsewhere. AWS telemetry should not be treated as primary proof of ADC exploitation by itself unless it is joined to ADC management/API access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, or downstream application exposure. AWS detections are strongest when CloudTrail, GuardDuty, Security Hub, AWS Config, VPC Flow Logs, Route 53 Resolver logs, WAF logs, ALB/NLB logs, S3 access logs, Secrets Manager events, KMS events, IAM activity, and normalized ADC cloud-context telemetry are correlated in a SIEM or cloud analytics layer.

Rule

ADC Cloud Context Followed by Suspicious AWS Identity, Network, or Resource Activity

Rule Format

AWS correlation rule.

Detection Purpose

Detect suspicious AWS identity, network, security-control, logging, compute, storage, secret, key, or resource activity following ADC control-plane compromise indicators. This rule is intended for environments where an ADC, traffic-management appliance, reverse proxy, WAF-adjacent service, or protected backend application is hosted in AWS or where AWS resources are reachable through the compromised edge application-delivery path.

Detection Logic

Correlate ADC control-plane compromise context with suspicious AWS management-plane, network-plane, and resource-plane activity. Promote when ADC context such as suspicious management/API access, appliance instability, rare egress, configuration access, certificate access, virtual-service manipulation, downstream application exposure, or multi-asset probing is followed by unusual AWS API activity from related accounts, roles, instances, workloads, source IPs, backend hosts, load balancers, secrets, keys, buckets, security groups, snapshots, images, or network resources. Exclude approved automation, CI/CD, infrastructure-as-code, security tooling, break-glass, vendor support, managed-service, and incident-response activity unless sensitive resources or high-risk events require review.

Required Telemetry

·        CloudTrail management events, CloudTrail data events, GuardDuty findings, Security Hub findings, AWS Config events, IAM Identity Center events, Organizations events, VPC Flow Logs, Route 53 Resolver logs, WAF logs, ALB logs, NLB logs, S3 access events, Secrets Manager events, KMS events, and EC2/ECS/EKS workload inventory.

·        Normalized ADC cloud-context telemetry derived from ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, configuration-change records, certificate records, downstream application logs, asset inventory, AWS account mapping, role mapping, and source-enrichment context.

·        AWS account inventory, workload inventory, role inventory, access-key baselines, administrative source baselines, expected region baselines, expected user-agent baselines, sensitive resource inventories, approved automation identities, approved CI/CD identities, approved security tooling identities, approved break-glass identities, and approved incident-response identities.

·        Resource mappings between ADC assets, AWS accounts, EC2 instances, load balancers, target groups, WAF associations, Route 53 zones, S3 buckets, Secrets Manager secrets, KMS keys, IAM roles, backend workloads, and protected applications.

Engineering Implementation Instructions

·        Deploy first in hunt mode until ADC cloud-context mapping is validated.

·        Do not alert on AWS activity alone unless it is correlated with ADC control-plane compromise context, protected backend exposure, or a high-risk AWS event requiring independent review.

·        Map ADC assets to AWS accounts, regions, roles, instances, load balancers, target groups, WAF resources, backend workloads, secrets, keys, buckets, snapshots, and protected applications.

·        Tune approved automation, CI/CD, infrastructure-as-code, security tooling, vendor support, managed-service, break-glass, monitoring, backup, and incident-response workflows.

·        Escalate when ADC compromise context is followed by IAM privilege escalation, access-key creation, security-control modification, logging modification, unusual federated access, sensitive data access, secrets access, KMS access, snapshot or image export, security group exposure, route modification, suspicious VPC flow behavior, suspicious DNS resolution, or GuardDuty/Security Hub findings.

DRI Assessment

This rule has moderate-to-strong reliability when ADC cloud-context telemetry is accurately joined to AWS account, role, workload, network, and resource activity. It is behavior-driven and reusable because it does not depend on a single ADC vendor, CVE identifier, request path, or exploit string. Reliability depends on asset-to-account mapping, role mapping, workload mapping, time-window tuning, CloudTrail coverage, data-event coverage, VPC Flow Log coverage, Route 53 Resolver coverage, and exception quality.

DRI

8.0

TCR Assessment

Operational TCR is moderate where CloudTrail management events, GuardDuty, Security Hub, AWS Config, VPC Flow Logs, Route 53 Resolver logs, load balancer logs, WAF logs, AWS inventory, and ADC cloud-context telemetry are available. Full-Telemetry TCR improves when CloudTrail data events, S3 access events, Secrets Manager events, KMS events, IAM Identity Center events, Organizations events, downstream application logs, appliance syslog, certificate records, and backend workload telemetry are joined.

Operational TCR

7.8

Full-Telemetry TCR

8.7

Limitations

·        AWS telemetry cannot prove ADC exploitation unless it is correlated with ADC control-plane behavior, protected backend exposure, or post-access appliance evidence.

·        CloudTrail management events may miss data-plane access, application-layer effects, appliance-level command execution, or ADC-local configuration activity.

·        VPC Flow Logs and Route 53 Resolver logs may show traffic patterns but not payload content or command execution.

·        Approved automation, CI/CD, managed-service operations, break-glass use, emergency response, or security tooling may resemble suspicious AWS activity if exception lists are incomplete.

·        This rule is not applicable when the ADC and protected application path have no AWS-hosted component or AWS-reachable trust relationship.

Detection Query Pattern

Use this pattern as implementation-ready AWS correlation pseudologic and map all CloudTrail fields, GuardDuty fields, Security Hub fields, AWS Config fields, IAM Identity Center fields, Organizations fields, VPC Flow Log fields, Route 53 Resolver fields, WAF fields, load-balancer fields, S3 data-event fields, Secrets Manager fields, KMS fields, ADC cloud-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, and time windows to the target AWS analytics or SIEM environment before deployment.

adc_cloud_context represents a normalized correlation view derived from ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, configuration-change records, certificate-management records, downstream application logs, AWS workload inventory, AWS account mapping, AWS role mapping, AWS resource mapping, ADC asset mapping, virtual-service mapping, backend-pool mapping, protected-application mapping, and source-enrichment context. Local teams must create, map, or enrich this view before deploying the AWS correlation pattern.

FROM aws_cloudtrail_management_events,
aws_cloudtrail_data_events,
aws_iam_identity_center_events,
aws_guardduty_findings,
aws_securityhub_findings,
aws_config_events,
aws_organizations_events,
aws_vpc_flow_logs,
aws_route53_resolver_logs,
aws_waf_logs,
aws_alb_access_logs,
aws_nlb_flow_logs,
aws_s3_access_events,
aws_secretsmanager_events,
aws_kms_events,
adc_cloud_context
WHERE aws.account_id IS NOT NULL
AND adc_cloud_context.event_time IS NOT NULL
AND aws.event_time BETWEEN adc_cloud_context.event_time AND adc_cloud_context.event_time + ENV_ADC_TO_AWS_IMPACT_WINDOW
AND adc_cloud_context.adc_asset_id IS NOT NULL
AND adc_cloud_context.aws_account_id = aws.account_id
AND (
adc_cloud_context.instance_id = aws.resource_id
OR adc_cloud_context.instance_id = aws.ec2_instance_id
OR adc_cloud_context.container_id = aws.container_id
OR adc_cloud_context.workload_id = aws.workload_id
OR adc_cloud_context.role_arn = aws.role_arn
OR adc_cloud_context.assumed_role_arn = aws.assumed_role_arn
OR adc_cloud_context.source_ip = aws.source_ip
OR adc_cloud_context.destination_ip = aws.source_ip
OR adc_cloud_context.adc_public_ip = aws.source_ip
OR adc_cloud_context.adc_private_ip = aws.source_ip
OR adc_cloud_context.backend_host = aws.host_name
OR adc_cloud_context.load_balancer_arn = aws.load_balancer_arn
OR adc_cloud_context.target_group_arn = aws.target_group_arn
OR adc_cloud_context.waf_web_acl_id = aws.waf_web_acl_id
OR adc_cloud_context.s3_bucket = aws.s3_bucket
OR adc_cloud_context.secret_id = aws.secret_id
OR adc_cloud_context.kms_key_id = aws.kms_key_id
)
AND adc_cloud_context.type IN (
"suspicious_adc_control_plane_access",
"adc_appliance_instability_after_control_plane_access",
"adc_rare_egress_after_control_plane_access",
"adc_configuration_or_certificate_access",
"adc_backup_or_diagnostic_export",
"adc_virtual_service_or_backend_pool_change",
"adc_routing_or_header_manipulation",
"adc_tls_or_certificate_binding_change",
"adc_administrative_control_change",
"adc_logging_degradation",
"adc_downstream_application_exposure",
"multi_adc_control_plane_probe_cluster",
"adc_post_access_behavior_within_cluster"
)
AND (
aws.event_name IN ENV_SUSPICIOUS_AWS_FEDERATED_ACCESS_EVENTS
OR aws.event_name IN ENV_SUSPICIOUS_AWS_ADMIN_EVENTS
OR aws.event_name IN ENV_AWS_IAM_PRIVILEGE_ESCALATION_EVENTS
OR aws.event_name IN ENV_AWS_ACCESS_KEY_EVENTS
OR aws.event_name IN ENV_AWS_SECURITY_CONTROL_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_LOGGING_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_SENSITIVE_DATA_ACCESS_EVENTS
OR aws.event_name IN ENV_AWS_S3_ENUMERATION_OR_EXFILTRATION_EVENTS
OR aws.event_name IN ENV_AWS_SECRETS_OR_KMS_ACCESS_EVENTS
OR aws.event_name IN ENV_AWS_COMPUTE_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_NETWORK_EXPOSURE_EVENTS
OR aws.event_name IN ENV_AWS_SNAPSHOT_OR_IMAGE_EXPORT_EVENTS
OR aws.event_name IN ENV_AWS_LOAD_BALANCER_OR_WAF_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_ROUTE53_OR_DNS_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_ORGANIZATIONS_ADMIN_EVENTS
OR aws.event_name IN ENV_AWS_IAM_IDENTITY_CENTER_ADMIN_EVENTS
OR aws.guardduty_finding_type IN ENV_RELEVANT_GUARDDUTY_FINDINGS
OR aws.securityhub_finding_type IN ENV_RELEVANT_SECURITYHUB_FINDINGS
OR aws.vpc_flow_anomaly_type IN ENV_RELEVANT_VPC_FLOW_ANOMALIES
OR aws.route53_query_risk IN ENV_RELEVANT_ROUTE53_QUERY_RISKS
OR aws.waf_behavior IN ENV_RELEVANT_AWS_WAF_BEHAVIORS
OR aws.load_balancer_behavior IN ENV_RELEVANT_AWS_LOAD_BALANCER_BEHAVIORS
)
AND (
aws.source_ip NOT IN ENV_APPROVED_AWS_ADMIN_SOURCE_IPS
OR aws.user_agent NOT IN ENV_EXPECTED_AWS_USER_AGENTS_BY_ROLE
OR aws.aws_region NOT IN ENV_EXPECTED_AWS_REGIONS_BY_ROLE
OR aws.role_arn NOT IN ENV_EXPECTED_AWS_ROLES_BY_USER
OR aws.account_id NOT IN ENV_EXPECTED_AWS_ACCOUNTS_BY_USER
OR aws.access_key_id IS NEW_FOR aws.normalized_user_id WITHIN ENV_ACCESS_KEY_NOVELTY_WINDOW
OR aws.event_name IN ENV_HIGH_RISK_AWS_EVENTS_REQUIRING_REVIEW
OR aws.resource_id IN ENV_SENSITIVE_AWS_RESOURCES
OR aws.resource_arn IN ENV_SENSITIVE_AWS_RESOURCE_ARNS
OR aws.load_balancer_arn IN ENV_SENSITIVE_AWS_LOAD_BALANCERS
OR aws.waf_web_acl_id IN ENV_SENSITIVE_AWS_WAF_RESOURCES
OR aws.s3_bucket IN ENV_SENSITIVE_AWS_S3_BUCKETS
OR aws.secret_id IN ENV_SENSITIVE_AWS_SECRETS
OR aws.kms_key_id IN ENV_SENSITIVE_AWS_KMS_KEYS
)
AND NOT (
aws.user_identity_arn IN ENV_APPROVED_AWS_AUTOMATION_IDENTITIES
AND aws.source_ip IN ENV_APPROVED_AWS_AUTOMATION_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_AWS_AUTOMATION_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
aws.role_arn IN ENV_APPROVED_CICD_OR_IAC_ROLES
AND aws.source_ip IN ENV_APPROVED_CICD_OR_IAC_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_CICD_OR_IAC_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
aws.user_identity_arn IN ENV_APPROVED_BREAK_GLASS_IDENTITIES
AND aws.source_ip IN ENV_APPROVED_BREAK_GLASS_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_BREAK_GLASS_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
aws.user_identity_arn IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES
AND aws.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_SECURITY_TOOLING_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
aws.user_identity_arn IN ENV_APPROVED_INCIDENT_RESPONSE_IDENTITIES
AND aws.source_ip IN ENV_APPROVED_INCIDENT_RESPONSE_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_INCIDENT_RESPONSE_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
aws.role_arn IN ENV_APPROVED_MANAGED_SERVICE_OR_PLATFORM_ROLES
AND aws.source_ip IN ENV_APPROVED_MANAGED_SERVICE_OR_PLATFORM_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_MANAGED_SERVICE_OR_PLATFORM_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND aws.user_identity_arn NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS
GROUP BY aws.account_id,
aws.normalized_user_id,
aws.user_identity_arn,
aws.role_arn,
aws.source_ip,
aws.user_agent,
aws.aws_region,
aws.event_name,
aws.resource_id,
aws.resource_arn,
aws.load_balancer_arn,
aws.waf_web_acl_id,
aws.s3_bucket,
aws.secret_id,
aws.kms_key_id,
adc_cloud_context.adc_asset_id,
adc_cloud_context.virtual_service,
adc_cloud_context.backend_pool,
adc_cloud_context.type
EMIT alert WHEN
count_distinct(aws.event_name) >= ENV_MIN_DISTINCT_AWS_RISK_EVENTS
OR aws.event_name IN ENV_HIGH_RISK_AWS_EVENTS_REQUIRING_REVIEW
OR aws.access_key_id IS NEW_FOR aws.normalized_user_id WITHIN ENV_ACCESS_KEY_NOVELTY_WINDOW
OR aws.guardduty_finding_type IN ENV_RELEVANT_GUARDDUTY_FINDINGS
OR aws.securityhub_finding_type IN ENV_RELEVANT_SECURITYHUB_FINDINGS
OR aws.vpc_flow_anomaly_type IN ENV_RELEVANT_VPC_FLOW_ANOMALIES
OR aws.route53_query_risk IN ENV_RELEVANT_ROUTE53_QUERY_RISKS

Rule

AWS Network Exposure or Rare Egress Linked to ADC Cloud Context

Rule Format

AWS correlation rule.

Detection Purpose

Detect suspicious AWS network exposure, routing, security group, load balancer, WAF, DNS, or rare egress behavior linked to ADC compromise context. This rule is intended to identify cloud-side network and application-delivery changes that may follow ADC control-plane access, traffic-path manipulation, or downstream application exposure.

Detection Logic

Correlate ADC cloud-context indicators with AWS network-plane and application-delivery telemetry. Promote when suspicious ADC control-plane behavior is followed by security group exposure, route-table modification, network ACL modification, load balancer listener change, target group change, WAF rule modification, Route 53 change, unusual VPC flow behavior, rare DNS resolution, unexpected outbound traffic, or sensitive backend exposure. Exclude approved infrastructure-as-code, CI/CD, security tooling, managed-service, monitoring, vendor support, break-glass, and incident-response workflows unless sensitive resources or high-risk exposure changes require review.

Required Telemetry

·        CloudTrail management events, AWS Config events, VPC Flow Logs, Route 53 Resolver logs, WAF logs, ALB logs, NLB logs, GuardDuty findings, Security Hub findings, EC2 inventory, ELB inventory, WAF inventory, Route 53 inventory, security group inventory, subnet inventory, route-table inventory, target-group inventory, and backend workload inventory.

·        Normalized ADC cloud-context telemetry for suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, virtual-service change, backend-pool change, route or header manipulation, TLS behavior, downstream application exposure, and multi-asset probing.

·        Approved security group changes, approved route changes, approved load balancer changes, approved WAF changes, approved DNS changes, approved CI/CD roles, approved IaC roles, approved automation identities, approved security tooling identities, approved managed-service identities, and approved incident-response identities.

·        Resource mappings between ADC assets, AWS accounts, load balancers, listeners, target groups, WAF resources, security groups, subnets, route tables, Route 53 records, backend workloads, and protected applications.

Engineering Implementation Instructions

·        Deploy first in hunt mode to validate ADC-to-AWS resource mapping and network-change baselines.

·        Correlate by AWS account, region, role, source IP, user agent, load balancer, target group, WAF resource, security group, subnet, route table, Route 53 record, backend workload, protected application, ADC asset, virtual service, backend pool, and bounded time window.

·        Require ADC cloud-context linkage before treating AWS network changes as part of this report’s behavior family.

·        Suppress approved IaC, CI/CD, change-management, security tooling, monitoring, managed-service, vendor support, emergency maintenance, and incident-response workflows.

·        Escalate when ADC compromise context is followed by internet exposure, backend exposure, WAF weakening, listener or target group modification, DNS redirection, suspicious VPC flow behavior, rare egress, or GuardDuty/Security Hub findings.

DRI Assessment

This rule has moderate reliability because AWS network and application-delivery telemetry can identify exposure changes, WAF changes, routing changes, and unusual flow behavior after ADC compromise context. It is less definitive than direct ADC appliance telemetry because cloud-side changes can result from normal infrastructure automation or authorized change activity. Reliability depends on resource mapping, change baselines, approved workflow exceptions, and the strength of ADC cloud-context linkage.

DRI

7.8

TCR Assessment

Operational TCR is moderate where CloudTrail, AWS Config, VPC Flow Logs, Route 53 Resolver logs, WAF logs, load balancer logs, GuardDuty, Security Hub, AWS inventory, approved change context, and ADC cloud-context telemetry are available. Full-Telemetry TCR improves when downstream application logs, appliance syslog, certificate records, configuration-change records, endpoint telemetry, data events, and backend workload telemetry are available.

Operational TCR

7.6

Full-Telemetry TCR

8.5

Limitations

·        This rule cannot confirm ADC command execution or appliance compromise without ADC appliance, management/API, or endpoint-context evidence.

·        Infrastructure-as-code, CI/CD, change windows, managed-service activity, security tooling, and incident-response workflows may resemble suspicious network modification.

·        VPC Flow Logs do not provide payload visibility and may not distinguish benign backend traffic from exploitation effects without context.

·        AWS network changes may be unrelated to ADC compromise unless linked by account, resource, workload, source, virtual service, backend pool, protected application, or time window.

·        This rule has limited value when no ADC, protected backend, or application-delivery resource is hosted in AWS.

Detection Query Pattern

Use this pattern as implementation-ready AWS correlation pseudologic and map all CloudTrail fields, AWS Config fields, GuardDuty fields, Security Hub fields, VPC Flow Log fields, Route 53 Resolver fields, WAF fields, load-balancer fields, ADC cloud-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, network-change baselines, and time windows to the target AWS analytics or SIEM environment before deployment.

adc_cloud_context represents a normalized correlation view derived from ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, configuration-change records, certificate-management records, downstream application logs, AWS workload inventory, AWS account mapping, AWS load-balancer mapping, AWS WAF mapping, AWS network-resource mapping, ADC asset mapping, virtual-service mapping, backend-pool mapping, protected-application mapping, and source-enrichment context. Local teams must create, map, or enrich this view before deploying the AWS network correlation pattern.

FROM aws_cloudtrail_management_events,
aws_config_events,
aws_guardduty_findings,
aws_securityhub_findings,
aws_vpc_flow_logs,
aws_route53_resolver_logs,
aws_waf_logs,
aws_alb_access_logs,
aws_nlb_flow_logs,
adc_cloud_context
WHERE aws.account_id IS NOT NULL
AND adc_cloud_context.event_time IS NOT NULL
AND aws.event_time BETWEEN adc_cloud_context.event_time AND adc_cloud_context.event_time + ENV_ADC_TO_AWS_NETWORK_IMPACT_WINDOW
AND adc_cloud_context.adc_asset_id IS NOT NULL
AND adc_cloud_context.aws_account_id = aws.account_id
AND (
adc_cloud_context.load_balancer_arn = aws.load_balancer_arn
OR adc_cloud_context.target_group_arn = aws.target_group_arn
OR adc_cloud_context.waf_web_acl_id = aws.waf_web_acl_id
OR adc_cloud_context.security_group_id = aws.security_group_id
OR adc_cloud_context.route_table_id = aws.route_table_id
OR adc_cloud_context.hosted_zone_id = aws.hosted_zone_id
OR adc_cloud_context.instance_id = aws.ec2_instance_id
OR adc_cloud_context.workload_id = aws.workload_id
OR adc_cloud_context.backend_host = aws.host_name
OR adc_cloud_context.backend_ip = aws.destination_ip
OR adc_cloud_context.adc_public_ip = aws.source_ip
OR adc_cloud_context.adc_private_ip = aws.source_ip
OR adc_cloud_context.destination_ip = aws.source_ip
)
AND adc_cloud_context.type IN (
"suspicious_adc_control_plane_access",
"adc_appliance_instability_after_control_plane_access",
"adc_rare_egress_after_control_plane_access",
"adc_virtual_service_or_backend_pool_change",
"adc_routing_or_header_manipulation",
"adc_tls_or_certificate_binding_change",
"adc_downstream_application_exposure",
"multi_adc_control_plane_probe_cluster",
"adc_post_access_behavior_within_cluster"
)
AND (
aws.event_name IN ENV_AWS_NETWORK_EXPOSURE_EVENTS
OR aws.event_name IN ENV_AWS_SECURITY_GROUP_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_NETWORK_ACL_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_ROUTE_TABLE_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_LOAD_BALANCER_OR_LISTENER_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_TARGET_GROUP_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_WAF_WEAKENING_OR_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_ROUTE53_OR_DNS_MODIFICATION_EVENTS
OR aws.guardduty_finding_type IN ENV_RELEVANT_NETWORK_GUARDDUTY_FINDINGS
OR aws.securityhub_finding_type IN ENV_RELEVANT_NETWORK_SECURITYHUB_FINDINGS
OR aws.vpc_flow_anomaly_type IN ENV_RELEVANT_VPC_FLOW_ANOMALIES
OR aws.route53_query_risk IN ENV_RELEVANT_ROUTE53_QUERY_RISKS
OR aws.waf_behavior IN ENV_RELEVANT_AWS_WAF_BEHAVIORS
OR aws.load_balancer_behavior IN ENV_RELEVANT_AWS_LOAD_BALANCER_BEHAVIORS
)
AND (
aws.source_ip NOT IN ENV_APPROVED_AWS_ADMIN_SOURCE_IPS
OR aws.user_agent NOT IN ENV_EXPECTED_AWS_USER_AGENTS_BY_ROLE
OR aws.aws_region NOT IN ENV_EXPECTED_AWS_REGIONS_BY_ROLE
OR aws.role_arn NOT IN ENV_EXPECTED_AWS_ROLES_BY_USER
OR aws.security_group_id IN ENV_SENSITIVE_AWS_SECURITY_GROUPS
OR aws.route_table_id IN ENV_SENSITIVE_AWS_ROUTE_TABLES
OR aws.load_balancer_arn IN ENV_SENSITIVE_AWS_LOAD_BALANCERS
OR aws.target_group_arn IN ENV_SENSITIVE_AWS_TARGET_GROUPS
OR aws.waf_web_acl_id IN ENV_SENSITIVE_AWS_WAF_RESOURCES
OR aws.hosted_zone_id IN ENV_SENSITIVE_AWS_HOSTED_ZONES
OR aws.vpc_flow_anomaly_type IN ENV_HIGH_RISK_VPC_FLOW_ANOMALIES
OR aws.route53_query_risk IN ENV_HIGH_RISK_ROUTE53_QUERY_RISKS
OR aws.event_name IN ENV_HIGH_RISK_AWS_NETWORK_EVENTS_REQUIRING_REVIEW
)
AND NOT (
aws.role_arn IN ENV_APPROVED_CICD_OR_IAC_ROLES
AND aws.source_ip IN ENV_APPROVED_CICD_OR_IAC_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_CICD_OR_IAC_NETWORK_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
aws.user_identity_arn IN ENV_APPROVED_AWS_AUTOMATION_IDENTITIES
AND aws.source_ip IN ENV_APPROVED_AWS_AUTOMATION_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_AWS_AUTOMATION_NETWORK_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
aws.user_identity_arn IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES
AND aws.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_SECURITY_TOOLING_NETWORK_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
aws.user_identity_arn IN ENV_APPROVED_INCIDENT_RESPONSE_IDENTITIES
AND aws.source_ip IN ENV_APPROVED_INCIDENT_RESPONSE_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_INCIDENT_RESPONSE_NETWORK_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
aws.role_arn IN ENV_APPROVED_MANAGED_SERVICE_OR_PLATFORM_ROLES
AND aws.source_ip IN ENV_APPROVED_MANAGED_SERVICE_OR_PLATFORM_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_MANAGED_SERVICE_OR_PLATFORM_NETWORK_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)
AND aws.user_identity_arn NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS
GROUP BY aws.account_id,
aws.normalized_user_id,
aws.user_identity_arn,
aws.role_arn,
aws.source_ip,
aws.user_agent,
aws.aws_region,
aws.event_name,
aws.resource_id,
aws.security_group_id,
aws.route_table_id,
aws.load_balancer_arn,
aws.target_group_arn,
aws.waf_web_acl_id,
aws.hosted_zone_id,
adc_cloud_context.adc_asset_id,
adc_cloud_context.virtual_service,
adc_cloud_context.backend_pool,
adc_cloud_context.type
EMIT alert WHEN
count_distinct(aws.event_name) >= ENV_MIN_DISTINCT_AWS_NETWORK_RISK_EVENTS
OR aws.event_name IN ENV_HIGH_RISK_AWS_NETWORK_EVENTS_REQUIRING_REVIEW
OR aws.guardduty_finding_type IN ENV_RELEVANT_NETWORK_GUARDDUTY_FINDINGS
OR aws.securityhub_finding_type IN ENV_RELEVANT_NETWORK_SECURITYHUB_FINDINGS
OR aws.vpc_flow_anomaly_type IN ENV_HIGH_RISK_VPC_FLOW_ANOMALIES
OR aws.route53_query_risk IN ENV_HIGH_RISK_ROUTE53_QUERY_RISKS

Azure

Detection Viability Assessment

Azure is conditionally viable for this behavior family when the affected ADC, load balancer, reverse proxy, WAF-adjacent component, traffic-management appliance, protected backend application, or supporting management path is deployed in Azure or when Azure telemetry can be correlated with ADC control-plane behavior observed elsewhere. Azure telemetry should not be treated as primary proof of ADC exploitation by itself unless it is joined to ADC management/API access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, or downstream application exposure. Azure detections are strongest when Azure Activity logs, Entra ID sign-in logs, Entra ID audit logs, service-principal activity, managed-identity activity, Defender for Cloud alerts, Sentinel incidents, Azure Resource Manager activity, Key Vault logs, Storage logs, Network Security Group flow logs, Application Gateway or Front Door logs, Azure Firewall logs, diagnostic-setting events, policy events, and normalized ADC Azure-context telemetry are correlated in Sentinel, a SIEM, a data lake, or another analytics layer.

Rule

ADC Azure Context Followed by Suspicious Azure Identity, Control-Plane, or Resource Activity

Rule Format

Azure correlation rule.

Detection Purpose

Detect suspicious Azure identity, control-plane, service-principal, managed-identity, security-control, diagnostic-setting, compute, storage, Key Vault, network, or resource activity following ADC control-plane compromise indicators. This rule is intended for environments where an ADC, traffic-management appliance, reverse proxy, WAF-adjacent service, or protected backend application is hosted in Azure or where Azure resources are reachable through the compromised edge application-delivery path.

Detection Logic

Correlate ADC control-plane compromise context with suspicious Azure control-plane, identity-plane, resource-plane, and network-plane activity. Promote when ADC context such as suspicious management/API access, appliance instability, rare egress, configuration access, certificate access, virtual-service manipulation, downstream application exposure, or multi-asset probing is followed by unusual Azure activity from related tenants, subscriptions, identities, service principals, managed identities, resources, VMs, App Services, container workloads, storage accounts, Key Vaults, network resources, Application Gateway resources, Front Door resources, or WAF policies. Exclude approved automation, CI/CD, infrastructure-as-code, security tooling, break-glass, vendor support, platform support, managed-service, and incident-response activity unless sensitive resources or high-risk events require review.

Required Telemetry

·        Azure Activity logs, Entra ID sign-in logs, Entra ID audit logs, Azure Resource Manager activity, service-principal activity, managed-identity activity, Azure role assignment events, Key Vault logs, Storage logs, Defender for Cloud alerts, Sentinel incidents, Azure Policy events, diagnostic-setting events, Network Security Group flow logs, Azure Firewall logs, Application Gateway logs, Front Door logs, WAF logs, VM activity, App Service activity, container workload activity, and Azure workload inventory.

·        Normalized ADC Azure-context telemetry derived from ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, configuration-change records, certificate records, downstream application logs, Azure tenant mapping, subscription mapping, resource mapping, identity mapping, ADC asset mapping, virtual-service mapping, backend-pool mapping, protected-application mapping, and source-enrichment context.

·        Azure tenant inventory, subscription inventory, workload inventory, role inventory, service-principal baselines, managed-identity baselines, administrative source baselines, expected user-agent baselines, expected tenant and subscription baselines, sensitive resource inventories, approved automation identities, approved CI/CD identities, approved security tooling identities, approved break-glass identities, approved platform-support identities, and approved incident-response identities.

·        Resource mappings between ADC assets, Azure tenants, subscriptions, resource groups, VMs, App Services, container workloads, Application Gateway resources, Front Door resources, WAF policies, Storage accounts, Key Vaults, managed identities, service principals, backend workloads, and protected applications.

Engineering Implementation Instructions

·        Deploy first in hunt mode until ADC Azure-context mapping is validated.

·        Do not alert on Azure activity alone unless it is correlated with ADC control-plane compromise context, protected backend exposure, or a high-risk Azure event requiring independent review.

·        Map ADC assets to Azure tenants, subscriptions, resource groups, identities, service principals, managed identities, VMs, App Services, container workloads, Application Gateway resources, Front Door resources, WAF policies, storage accounts, Key Vaults, backend workloads, and protected applications.

·        Tune approved automation, CI/CD, infrastructure-as-code, security tooling, vendor support, platform support, managed-service, break-glass, monitoring, backup, and incident-response workflows.

·        Escalate when ADC compromise context is followed by Azure role assignment or privilege activity, service-principal or application modification, managed-identity novelty, security-control modification, diagnostic-setting modification, policy modification, Key Vault access, storage enumeration or access, sensitive resource access, compute modification, App Service modification, container workload activity, network security modification, Defender for Cloud alerts, or Sentinel incidents.

DRI Assessment

This rule has moderate-to-strong reliability when ADC Azure-context telemetry is accurately joined to Azure tenant, subscription, identity, workload, network, and resource activity. It is behavior-driven and reusable because it does not depend on a single ADC vendor, CVE identifier, request path, or exploit string. Reliability depends on tenant-to-subscription mapping, identity mapping, resource mapping, workload mapping, time-window tuning, Azure Activity coverage, Entra ID coverage, resource diagnostic coverage, Defender for Cloud coverage, Sentinel coverage, and exception quality.

DRI

8.0

TCR Assessment

Operational TCR is moderate where Azure Activity logs, Entra ID logs, Defender for Cloud alerts, Sentinel incidents, diagnostic-setting events, Network Security Group flow logs, Application Gateway logs, Front Door logs, WAF logs, Azure Firewall logs, Azure inventory, and ADC Azure-context telemetry are available. Full-Telemetry TCR improves when Key Vault logs, Storage logs, service-principal activity, managed-identity activity, downstream application logs, appliance syslog, certificate records, configuration-change records, endpoint telemetry, and backend workload telemetry are joined.

Operational TCR

7.8

Full-Telemetry TCR

8.7

Limitations

·        Azure telemetry cannot prove ADC exploitation unless it is correlated with ADC control-plane behavior, protected backend exposure, or post-access appliance evidence.

·        Azure Activity and Entra ID logs may miss application-layer effects, appliance-level command execution, ADC-local configuration activity, or data-plane access without diagnostic logging.

·        Network Security Group flow logs and Azure Firewall logs may show traffic patterns but not payload content or command execution.

·        Approved automation, CI/CD, managed-service operations, break-glass use, emergency response, platform support, or security tooling may resemble suspicious Azure activity if exception lists are incomplete.

·        This rule is not applicable when the ADC and protected application path have no Azure-hosted component or Azure-reachable trust relationship.

Detection Query Pattern

Use this pattern as implementation-ready Azure control-plane and resource-access correlation pseudologic and map all Azure Activity fields, Entra ID fields, service-principal fields, managed-identity fields, resource fields, Key Vault fields, Storage fields, Defender for Cloud fields, Sentinel fields, Application Gateway fields, Front Door fields, WAF fields, Azure Firewall fields, Network Security Group flow fields, ADC Azure-context fields, approved-workflow lookups, automation allowlists, source baselines, role baselines, resource baselines, subscription baselines, and time windows to the target Sentinel, SIEM, data-lake, or analytics environment before deployment.

adc_azure_context represents a normalized correlation view derived from ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, configuration-change records, certificate-management records, downstream application logs, Azure workload inventory, Azure tenant mapping, Azure subscription mapping, Azure resource mapping, Azure identity mapping, ADC asset mapping, virtual-service mapping, backend-pool mapping, protected-application mapping, and source-enrichment context.

azure_control_plane_activity represents a normalized Azure control-plane and resource-access view derived from Azure Activity logs, Entra ID sign-in logs, Entra ID audit logs, Azure Resource Manager activity, Azure role assignment events, Key Vault logs, Storage logs, Defender for Cloud alerts, Sentinel incidents, Azure Policy events, diagnostic-setting events, service-principal activity, managed-identity activity, Application Gateway logs, Front Door logs, WAF logs, Azure Firewall logs, Network Security Group flow logs, App Service activity, VM activity, container workload activity, identity context, network context, proxy context, endpoint context, and source-enrichment context.

Local teams must create, map, or enrich both views before deploying the Azure control-plane correlation pattern.

FROM azure_control_plane_activity,
adc_azure_context
WHERE azure_control_plane_activity.normalized_identity_id IS NOT NULL
AND adc_azure_context.event_time IS NOT NULL
AND azure_control_plane_activity.event_time BETWEEN adc_azure_context.event_time AND adc_azure_context.event_time + ENV_ADC_TO_AZURE_CONTROL_PLANE_WINDOW
AND adc_azure_context.adc_asset_id IS NOT NULL
AND adc_azure_context.tenant_id = azure_control_plane_activity.tenant_id
AND adc_azure_context.subscription_id = azure_control_plane_activity.subscription_id
AND (
adc_azure_context.resource_id = azure_control_plane_activity.resource_id
OR adc_azure_context.vm_id = azure_control_plane_activity.vm_id
OR adc_azure_context.app_service_id = azure_control_plane_activity.app_service_id
OR adc_azure_context.container_workload_id = azure_control_plane_activity.container_workload_id
OR adc_azure_context.application_id = azure_control_plane_activity.application_id
OR adc_azure_context.service_principal_id = azure_control_plane_activity.service_principal_id
OR adc_azure_context.managed_identity_id = azure_control_plane_activity.managed_identity_id
OR adc_azure_context.source_ip = azure_control_plane_activity.source_ip
OR adc_azure_context.destination_ip = azure_control_plane_activity.source_ip
OR adc_azure_context.adc_public_ip = azure_control_plane_activity.source_ip
OR adc_azure_context.adc_private_ip = azure_control_plane_activity.source_ip
OR adc_azure_context.backend_host = azure_control_plane_activity.host_name
OR adc_azure_context.application_gateway_id = azure_control_plane_activity.application_gateway_id
OR adc_azure_context.front_door_profile_id = azure_control_plane_activity.front_door_profile_id
OR adc_azure_context.waf_policy_id = azure_control_plane_activity.waf_policy_id
OR adc_azure_context.storage_account_name = azure_control_plane_activity.storage_account_name
OR adc_azure_context.key_vault_name = azure_control_plane_activity.key_vault_name
OR adc_azure_context.correlation_id = azure_control_plane_activity.correlation_id
)
AND adc_azure_context.type IN (
"suspicious_adc_control_plane_access",
"adc_appliance_instability_after_control_plane_access",
"adc_rare_egress_after_control_plane_access",
"adc_configuration_or_certificate_access",
"adc_backup_or_diagnostic_export",
"adc_virtual_service_or_backend_pool_change",
"adc_routing_or_header_manipulation",
"adc_tls_or_certificate_binding_change",
"adc_administrative_control_change",
"adc_logging_degradation",
"adc_downstream_application_exposure",
"multi_adc_control_plane_probe_cluster",
"adc_post_access_behavior_within_cluster"
)
AND (
azure_control_plane_activity.event_name IN ENV_SUSPICIOUS_AZURE_FEDERATED_ACCESS_EVENTS
OR azure_control_plane_activity.event_name IN ENV_SUSPICIOUS_AZURE_ADMIN_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_ROLE_ASSIGNMENT_OR_PRIVILEGE_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_SERVICE_PRINCIPAL_OR_APP_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_MANAGED_IDENTITY_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_SECURITY_CONTROL_MODIFICATION_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_LOGGING_OR_DIAGNOSTIC_MODIFICATION_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_POLICY_MODIFICATION_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_NETWORK_SECURITY_MODIFICATION_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_KEY_VAULT_ACCESS_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_STORAGE_ENUMERATION_OR_ACCESS_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_SENSITIVE_RESOURCE_ACCESS_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_COMPUTE_MODIFICATION_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_APP_SERVICE_MODIFICATION_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_CONTAINER_WORKLOAD_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_APPLICATION_GATEWAY_OR_WAF_MODIFICATION_EVENTS
OR azure_control_plane_activity.event_name IN ENV_AZURE_FRONT_DOOR_OR_CDN_MODIFICATION_EVENTS
OR azure_control_plane_activity.defender_for_cloud_alert_type IN ENV_RELEVANT_DEFENDER_FOR_CLOUD_ALERTS
OR azure_control_plane_activity.sentinel_incident_type IN ENV_RELEVANT_SENTINEL_INCIDENT_TYPES
OR azure_control_plane_activity.network_flow_anomaly_type IN ENV_RELEVANT_AZURE_NETWORK_FLOW_ANOMALIES
OR azure_control_plane_activity.dns_query_risk IN ENV_RELEVANT_AZURE_DNS_QUERY_RISKS
)
AND (
azure_control_plane_activity.source_ip NOT IN ENV_APPROVED_AZURE_ADMIN_SOURCE_IPS
OR azure_control_plane_activity.user_agent NOT IN ENV_EXPECTED_AZURE_USER_AGENTS_BY_ROLE
OR azure_control_plane_activity.tenant_id NOT IN ENV_EXPECTED_TENANTS_BY_USER_OR_APP
OR azure_control_plane_activity.subscription_id NOT IN ENV_EXPECTED_SUBSCRIPTIONS_BY_USER_OR_APP
OR azure_control_plane_activity.role_definition_id NOT IN ENV_EXPECTED_AZURE_ROLES_BY_IDENTITY
OR azure_control_plane_activity.application_id NOT IN ENV_EXPECTED_AZURE_APPS_BY_IDENTITY
OR azure_control_plane_activity.service_principal_id NOT IN ENV_EXPECTED_SERVICE_PRINCIPALS_BY_IDENTITY
OR azure_control_plane_activity.managed_identity_id IS NEW_FOR azure_control_plane_activity.normalized_identity_id WITHIN ENV_AZURE_MANAGED_IDENTITY_NOVELTY_WINDOW
OR azure_control_plane_activity.event_name IN ENV_HIGH_RISK_AZURE_EVENTS_REQUIRING_REVIEW
OR azure_control_plane_activity.resource_id IN ENV_SENSITIVE_AZURE_RESOURCES
OR azure_control_plane_activity.resource_group IN ENV_SENSITIVE_AZURE_RESOURCE_GROUPS
OR azure_control_plane_activity.application_gateway_id IN ENV_SENSITIVE_AZURE_APPLICATION_GATEWAYS
OR azure_control_plane_activity.front_door_profile_id IN ENV_SENSITIVE_AZURE_FRONT_DOOR_PROFILES
OR azure_control_plane_activity.waf_policy_id IN ENV_SENSITIVE_AZURE_WAF_POLICIES
OR azure_control_plane_activity.key_vault_name IN ENV_SENSITIVE_KEY_VAULTS
OR azure_control_plane_activity.storage_account_name IN ENV_SENSITIVE_STORAGE_ACCOUNTS
)
AND NOT (
azure_control_plane_activity.normalized_identity_id IN ENV_APPROVED_AZURE_AUTOMATION_IDENTITIES
AND azure_control_plane_activity.source_ip IN ENV_APPROVED_AZURE_AUTOMATION_SOURCE_IPS
AND azure_control_plane_activity.event_name IN ENV_APPROVED_AZURE_AUTOMATION_EVENTS
AND azure_control_plane_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
azure_control_plane_activity.service_principal_id IN ENV_APPROVED_CICD_OR_IAC_SERVICE_PRINCIPALS
AND azure_control_plane_activity.source_ip IN ENV_APPROVED_CICD_OR_IAC_SOURCE_IPS
AND azure_control_plane_activity.event_name IN ENV_APPROVED_CICD_OR_IAC_AZURE_EVENTS
AND azure_control_plane_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
azure_control_plane_activity.normalized_identity_id IN ENV_APPROVED_BREAK_GLASS_IDENTITIES
AND azure_control_plane_activity.source_ip IN ENV_APPROVED_BREAK_GLASS_SOURCE_IPS
AND azure_control_plane_activity.event_name IN ENV_APPROVED_BREAK_GLASS_AZURE_EVENTS
AND azure_control_plane_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
azure_control_plane_activity.normalized_identity_id IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES
AND azure_control_plane_activity.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS
AND azure_control_plane_activity.event_name IN ENV_APPROVED_SECURITY_TOOLING_AZURE_EVENTS
AND azure_control_plane_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
azure_control_plane_activity.normalized_identity_id IN ENV_APPROVED_INCIDENT_RESPONSE_IDENTITIES
AND azure_control_plane_activity.source_ip IN ENV_APPROVED_INCIDENT_RESPONSE_SOURCE_IPS
AND azure_control_plane_activity.event_name IN ENV_APPROVED_INCIDENT_RESPONSE_AZURE_EVENTS
AND azure_control_plane_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
azure_control_plane_activity.normalized_identity_id IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_IDENTITIES
AND azure_control_plane_activity.source_ip IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_SOURCE_IPS
AND azure_control_plane_activity.event_name IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_AZURE_EVENTS
AND azure_control_plane_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND azure_control_plane_activity.normalized_identity_id NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS
GROUP BY azure_control_plane_activity.tenant_id,
azure_control_plane_activity.subscription_id,
azure_control_plane_activity.resource_group,
azure_control_plane_activity.normalized_identity_id,
azure_control_plane_activity.source_ip,
azure_control_plane_activity.user_agent,
azure_control_plane_activity.application_id,
azure_control_plane_activity.service_principal_id,
azure_control_plane_activity.managed_identity_id,
azure_control_plane_activity.role_definition_id,
azure_control_plane_activity.event_name,
azure_control_plane_activity.resource_id,
azure_control_plane_activity.application_gateway_id,
azure_control_plane_activity.front_door_profile_id,
azure_control_plane_activity.waf_policy_id,
azure_control_plane_activity.key_vault_name,
azure_control_plane_activity.storage_account_name,
adc_azure_context.adc_asset_id,
adc_azure_context.virtual_service,
adc_azure_context.backend_pool,
adc_azure_context.type
EMIT alert WHEN
count_distinct(azure_control_plane_activity.event_name) >= ENV_MIN_DISTINCT_AZURE_CONTROL_PLANE_RISK_EVENTS
OR azure_control_plane_activity.event_name IN ENV_HIGH_RISK_AZURE_EVENTS_REQUIRING_REVIEW
OR azure_control_plane_activity.managed_identity_id IS NEW_FOR azure_control_plane_activity.normalized_identity_id WITHIN ENV_AZURE_MANAGED_IDENTITY_NOVELTY_WINDOW
OR azure_control_plane_activity.defender_for_cloud_alert_type IN ENV_RELEVANT_DEFENDER_FOR_CLOUD_ALERTS
OR azure_control_plane_activity.sentinel_incident_type IN ENV_RELEVANT_SENTINEL_INCIDENT_TYPES
OR azure_control_plane_activity.network_flow_anomaly_type IN ENV_RELEVANT_AZURE_NETWORK_FLOW_ANOMALIES
OR azure_control_plane_activity.dns_query_risk IN ENV_RELEVANT_AZURE_DNS_QUERY_RISKS

Rule

Azure Network Exposure or Resource-Access Activity Linked to ADC Azure Context

Rule Format

Azure correlation rule.

Detection Purpose

Detect suspicious Azure network exposure, network security modification, Application Gateway or Front Door modification, WAF weakening, DNS change, Key Vault access, Storage access, or rare egress behavior linked to ADC compromise context. This rule is intended to identify Azure-side network, application-delivery, and resource-access changes that may follow ADC control-plane access, traffic-path manipulation, or downstream application exposure.

Detection Logic

Correlate ADC Azure-context indicators with Azure network-plane, application-delivery, and resource-access telemetry. Promote when suspicious ADC control-plane behavior is followed by network security group exposure, route-table modification, Azure Firewall policy change, Application Gateway listener or backend-pool change, Front Door routing change, WAF policy weakening, DNS change, Key Vault access, Storage enumeration or access, unusual flow behavior, rare DNS resolution, unexpected outbound traffic, or sensitive backend exposure. Exclude approved infrastructure-as-code, CI/CD, security tooling, managed-service, monitoring, platform support, vendor support, break-glass, and incident-response workflows unless sensitive resources or high-risk exposure changes require review.

Required Telemetry

·        Azure Activity logs, Azure Resource Manager events, Azure Policy events, diagnostic-setting events, Defender for Cloud alerts, Sentinel incidents, Network Security Group flow logs, Azure Firewall logs, Application Gateway logs, Front Door logs, WAF logs, DNS logs, Key Vault logs, Storage logs, VM activity, App Service activity, container workload activity, and Azure workload inventory.

·        Normalized ADC Azure-context telemetry for suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, virtual-service change, backend-pool change, route or header manipulation, TLS behavior, downstream application exposure, and multi-asset probing.

·        Approved network security group changes, approved route changes, approved Application Gateway changes, approved Front Door changes, approved WAF changes, approved DNS changes, approved Key Vault workflows, approved Storage workflows, approved CI/CD identities, approved IaC identities, approved automation identities, approved security tooling identities, approved platform-support identities, approved managed-service identities, and approved incident-response identities.

·        Resource mappings between ADC assets, Azure tenants, subscriptions, resource groups, Application Gateway resources, Front Door resources, WAF policies, network security groups, subnets, route tables, DNS zones, Key Vaults, Storage accounts, backend workloads, and protected applications.

Engineering Implementation Instructions

·        Deploy first in hunt mode to validate ADC-to-Azure resource mapping and network-change baselines.

·        Correlate by tenant, subscription, resource group, identity, service principal, managed identity, source IP, user agent, Application Gateway, Front Door profile, WAF policy, network security group, subnet, route table, DNS zone, Key Vault, Storage account, backend workload, protected application, ADC asset, virtual service, backend pool, and bounded time window.

·        Require ADC Azure-context linkage before treating Azure network or resource-access changes as part of this report’s behavior family.

·        Suppress approved IaC, CI/CD, change-management, security tooling, monitoring, managed-service, platform support, vendor support, emergency maintenance, and incident-response workflows.

·        Escalate when ADC compromise context is followed by internet exposure, backend exposure, WAF weakening, Application Gateway modification, Front Door modification, DNS redirection, Key Vault access, Storage enumeration, suspicious flow behavior, rare egress, Defender for Cloud alerts, or Sentinel incidents.

DRI Assessment

This rule has moderate reliability because Azure network, application-delivery, and resource-access telemetry can identify exposure changes, WAF changes, routing changes, and unusual resource access after ADC compromise context. It is less definitive than direct ADC appliance telemetry because Azure-side changes can result from normal infrastructure automation or authorized change activity. Reliability depends on resource mapping, change baselines, approved workflow exceptions, diagnostic logging, and the strength of ADC Azure-context linkage.

DRI

7.8

TCR Assessment

Operational TCR is moderate where Azure Activity logs, Network Security Group flow logs, Azure Firewall logs, Application Gateway logs, Front Door logs, WAF logs, Defender for Cloud alerts, Sentinel incidents, Azure inventory, approved change context, and ADC Azure-context telemetry are available. Full-Telemetry TCR improves when Key Vault logs, Storage logs, downstream application logs, appliance syslog, certificate records, configuration-change records, endpoint telemetry, diagnostic logs, and backend workload telemetry are available.

Operational TCR

7.6

Full-Telemetry TCR

8.5

Limitations

·        This rule cannot confirm ADC command execution or appliance compromise without ADC appliance, management/API, or endpoint-context evidence.

·        Infrastructure-as-code, CI/CD, change windows, managed-service activity, platform support, security tooling, and incident-response workflows may resemble suspicious network or resource modification.

·        Network Security Group flow logs and Azure Firewall logs do not provide full payload visibility and may not distinguish benign backend traffic from exploitation effects without context.

·        Azure network or resource-access changes may be unrelated to ADC compromise unless linked by tenant, subscription, resource, workload, source, virtual service, backend pool, protected application, or time window.

·        This rule has limited value when no ADC, protected backend, or application-delivery resource is hosted in Azure.

Detection Query Pattern

Use this pattern as implementation-ready Azure network, application-delivery, and resource-access correlation pseudologic and map all Azure Activity fields, Azure Resource Manager fields, Defender for Cloud fields, Sentinel fields, Network Security Group flow fields, Azure Firewall fields, Application Gateway fields, Front Door fields, WAF fields, DNS fields, Key Vault fields, Storage fields, ADC Azure-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, network-change baselines, and time windows to the target Sentinel, SIEM, data-lake, or analytics environment before deployment.

adc_azure_context represents a normalized correlation view derived from ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, configuration-change records, certificate-management records, downstream application logs, Azure workload inventory, Azure tenant mapping, Azure subscription mapping, Azure application-delivery mapping, Azure network-resource mapping, ADC asset mapping, virtual-service mapping, backend-pool mapping, protected-application mapping, and source-enrichment context.

azure_network_resource_activity represents a normalized Azure network, application-delivery, and resource-access view derived from Azure Activity logs, Azure Resource Manager events, Azure Policy events, diagnostic-setting events, Defender for Cloud alerts, Sentinel incidents, Network Security Group flow logs, Azure Firewall logs, Application Gateway logs, Front Door logs, WAF logs, DNS logs, Key Vault logs, Storage logs, VM activity, App Service activity, container workload activity, identity context, network context, proxy context, endpoint context, and source-enrichment context.

Local teams must create, map, or enrich both views before deploying the Azure network and resource-access correlation pattern.

FROM azure_network_resource_activity,
adc_azure_context
WHERE azure_network_resource_activity.normalized_identity_id IS NOT NULL
AND adc_azure_context.event_time IS NOT NULL
AND azure_network_resource_activity.event_time BETWEEN adc_azure_context.event_time AND adc_azure_context.event_time + ENV_ADC_TO_AZURE_NETWORK_RESOURCE_WINDOW
AND adc_azure_context.adc_asset_id IS NOT NULL
AND adc_azure_context.tenant_id = azure_network_resource_activity.tenant_id
AND adc_azure_context.subscription_id = azure_network_resource_activity.subscription_id
AND (
adc_azure_context.application_gateway_id = azure_network_resource_activity.application_gateway_id
OR adc_azure_context.front_door_profile_id = azure_network_resource_activity.front_door_profile_id
OR adc_azure_context.waf_policy_id = azure_network_resource_activity.waf_policy_id
OR adc_azure_context.network_security_group_id = azure_network_resource_activity.network_security_group_id
OR adc_azure_context.route_table_id = azure_network_resource_activity.route_table_id
OR adc_azure_context.dns_zone_id = azure_network_resource_activity.dns_zone_id
OR adc_azure_context.vm_id = azure_network_resource_activity.vm_id
OR adc_azure_context.app_service_id = azure_network_resource_activity.app_service_id
OR adc_azure_context.container_workload_id = azure_network_resource_activity.container_workload_id
OR adc_azure_context.backend_host = azure_network_resource_activity.host_name
OR adc_azure_context.backend_ip = azure_network_resource_activity.destination_ip
OR adc_azure_context.adc_public_ip = azure_network_resource_activity.source_ip
OR adc_azure_context.adc_private_ip = azure_network_resource_activity.source_ip
OR adc_azure_context.destination_ip = azure_network_resource_activity.source_ip
OR adc_azure_context.key_vault_name = azure_network_resource_activity.key_vault_name
OR adc_azure_context.storage_account_name = azure_network_resource_activity.storage_account_name
)
AND adc_azure_context.type IN (
"suspicious_adc_control_plane_access",
"adc_appliance_instability_after_control_plane_access",
"adc_rare_egress_after_control_plane_access",
"adc_virtual_service_or_backend_pool_change",
"adc_routing_or_header_manipulation",
"adc_tls_or_certificate_binding_change",
"adc_downstream_application_exposure",
"multi_adc_control_plane_probe_cluster",
"adc_post_access_behavior_within_cluster"
)
AND (
azure_network_resource_activity.event_name IN ENV_AZURE_NETWORK_SECURITY_MODIFICATION_EVENTS
OR azure_network_resource_activity.event_name IN ENV_AZURE_ROUTE_TABLE_MODIFICATION_EVENTS
OR azure_network_resource_activity.event_name IN ENV_AZURE_FIREWALL_OR_POLICY_MODIFICATION_EVENTS
OR azure_network_resource_activity.event_name IN ENV_AZURE_APPLICATION_GATEWAY_OR_LISTENER_MODIFICATION_EVENTS
OR azure_network_resource_activity.event_name IN ENV_AZURE_BACKEND_POOL_MODIFICATION_EVENTS
OR azure_network_resource_activity.event_name IN ENV_AZURE_FRONT_DOOR_OR_CDN_MODIFICATION_EVENTS
OR azure_network_resource_activity.event_name IN ENV_AZURE_WAF_WEAKENING_OR_MODIFICATION_EVENTS
OR azure_network_resource_activity.event_name IN ENV_AZURE_DNS_MODIFICATION_EVENTS
OR azure_network_resource_activity.event_name IN ENV_AZURE_KEY_VAULT_ACCESS_EVENTS
OR azure_network_resource_activity.event_name IN ENV_AZURE_STORAGE_ENUMERATION_OR_ACCESS_EVENTS
OR azure_network_resource_activity.defender_for_cloud_alert_type IN ENV_RELEVANT_NETWORK_DEFENDER_FOR_CLOUD_ALERTS
OR azure_network_resource_activity.sentinel_incident_type IN ENV_RELEVANT_NETWORK_SENTINEL_INCIDENT_TYPES
OR azure_network_resource_activity.network_flow_anomaly_type IN ENV_RELEVANT_AZURE_NETWORK_FLOW_ANOMALIES
OR azure_network_resource_activity.dns_query_risk IN ENV_RELEVANT_AZURE_DNS_QUERY_RISKS
OR azure_network_resource_activity.waf_behavior IN ENV_RELEVANT_AZURE_WAF_BEHAVIORS
OR azure_network_resource_activity.application_delivery_behavior IN ENV_RELEVANT_AZURE_APPLICATION_DELIVERY_BEHAVIORS
)
AND (
azure_network_resource_activity.source_ip NOT IN ENV_APPROVED_AZURE_ADMIN_SOURCE_IPS
OR azure_network_resource_activity.user_agent NOT IN ENV_EXPECTED_AZURE_USER_AGENTS_BY_ROLE
OR azure_network_resource_activity.tenant_id NOT IN ENV_EXPECTED_TENANTS_BY_USER_OR_APP
OR azure_network_resource_activity.subscription_id NOT IN ENV_EXPECTED_SUBSCRIPTIONS_BY_USER_OR_APP
OR azure_network_resource_activity.role_definition_id NOT IN ENV_EXPECTED_AZURE_ROLES_BY_IDENTITY
OR azure_network_resource_activity.network_security_group_id IN ENV_SENSITIVE_AZURE_NETWORK_SECURITY_GROUPS
OR azure_network_resource_activity.route_table_id IN ENV_SENSITIVE_AZURE_ROUTE_TABLES
OR azure_network_resource_activity.application_gateway_id IN ENV_SENSITIVE_AZURE_APPLICATION_GATEWAYS
OR azure_network_resource_activity.front_door_profile_id IN ENV_SENSITIVE_AZURE_FRONT_DOOR_PROFILES
OR azure_network_resource_activity.waf_policy_id IN ENV_SENSITIVE_AZURE_WAF_POLICIES
OR azure_network_resource_activity.dns_zone_id IN ENV_SENSITIVE_AZURE_DNS_ZONES
OR azure_network_resource_activity.key_vault_name IN ENV_SENSITIVE_KEY_VAULTS
OR azure_network_resource_activity.storage_account_name IN ENV_SENSITIVE_STORAGE_ACCOUNTS
OR azure_network_resource_activity.network_flow_anomaly_type IN ENV_HIGH_RISK_AZURE_NETWORK_FLOW_ANOMALIES
OR azure_network_resource_activity.dns_query_risk IN ENV_HIGH_RISK_AZURE_DNS_QUERY_RISKS
OR azure_network_resource_activity.event_name IN ENV_HIGH_RISK_AZURE_NETWORK_RESOURCE_EVENTS_REQUIRING_REVIEW
)
AND NOT (
azure_network_resource_activity.service_principal_id IN ENV_APPROVED_CICD_OR_IAC_SERVICE_PRINCIPALS
AND azure_network_resource_activity.source_ip IN ENV_APPROVED_CICD_OR_IAC_SOURCE_IPS
AND azure_network_resource_activity.event_name IN ENV_APPROVED_CICD_OR_IAC_AZURE_NETWORK_EVENTS
AND azure_network_resource_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
azure_network_resource_activity.normalized_identity_id IN ENV_APPROVED_AZURE_AUTOMATION_IDENTITIES
AND azure_network_resource_activity.source_ip IN ENV_APPROVED_AZURE_AUTOMATION_SOURCE_IPS
AND azure_network_resource_activity.event_name IN ENV_APPROVED_AZURE_AUTOMATION_NETWORK_EVENTS
AND azure_network_resource_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
azure_network_resource_activity.normalized_identity_id IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES
AND azure_network_resource_activity.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS
AND azure_network_resource_activity.event_name IN ENV_APPROVED_SECURITY_TOOLING_AZURE_NETWORK_EVENTS
AND azure_network_resource_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
azure_network_resource_activity.normalized_identity_id IN ENV_APPROVED_INCIDENT_RESPONSE_IDENTITIES
AND azure_network_resource_activity.source_ip IN ENV_APPROVED_INCIDENT_RESPONSE_SOURCE_IPS
AND azure_network_resource_activity.event_name IN ENV_APPROVED_INCIDENT_RESPONSE_AZURE_NETWORK_EVENTS
AND azure_network_resource_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
azure_network_resource_activity.normalized_identity_id IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_IDENTITIES
AND azure_network_resource_activity.source_ip IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_SOURCE_IPS
AND azure_network_resource_activity.event_name IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_AZURE_NETWORK_EVENTS
AND azure_network_resource_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)
AND azure_network_resource_activity.normalized_identity_id NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS
GROUP BY azure_network_resource_activity.tenant_id,
azure_network_resource_activity.subscription_id,
azure_network_resource_activity.resource_group,
azure_network_resource_activity.normalized_identity_id,
azure_network_resource_activity.source_ip,
azure_network_resource_activity.user_agent,
azure_network_resource_activity.application_id,
azure_network_resource_activity.service_principal_id,
azure_network_resource_activity.managed_identity_id,
azure_network_resource_activity.role_definition_id,
azure_network_resource_activity.event_name,
azure_network_resource_activity.resource_id,
azure_network_resource_activity.network_security_group_id,
azure_network_resource_activity.route_table_id,
azure_network_resource_activity.application_gateway_id,
azure_network_resource_activity.front_door_profile_id,
azure_network_resource_activity.waf_policy_id,
azure_network_resource_activity.dns_zone_id,
azure_network_resource_activity.key_vault_name,
azure_network_resource_activity.storage_account_name,
adc_azure_context.adc_asset_id,
adc_azure_context.virtual_service,
adc_azure_context.backend_pool,
adc_azure_context.type
EMIT alert WHEN
count_distinct(azure_network_resource_activity.event_name) >= ENV_MIN_DISTINCT_AZURE_NETWORK_RESOURCE_RISK_EVENTS
OR azure_network_resource_activity.event_name IN ENV_HIGH_RISK_AZURE_NETWORK_RESOURCE_EVENTS_REQUIRING_REVIEW
OR azure_network_resource_activity.defender_for_cloud_alert_type IN ENV_RELEVANT_NETWORK_DEFENDER_FOR_CLOUD_ALERTS
OR azure_network_resource_activity.sentinel_incident_type IN ENV_RELEVANT_NETWORK_SENTINEL_INCIDENT_TYPES
OR azure_network_resource_activity.network_flow_anomaly_type IN ENV_HIGH_RISK_AZURE_NETWORK_FLOW_ANOMALIES
OR azure_network_resource_activity.dns_query_risk IN ENV_HIGH_RISK_AZURE_DNS_QUERY_RISKS

GCP

Detection Viability Assessment

GCP is conditionally viable for this behavior family when the affected ADC, load balancer, reverse proxy, WAF-adjacent component, traffic-management appliance, protected backend application, or supporting management path is deployed in Google Cloud or when Google Cloud telemetry can be correlated with ADC control-plane behavior observed elsewhere. GCP telemetry should not be treated as primary proof of ADC exploitation by itself unless it is joined to ADC management/API access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, or downstream application exposure. GCP detections are strongest when Google Cloud Admin Activity logs, Data Access logs, IAM logs, service-account logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Security Command Center findings, Cloud Identity logs, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, external Application Load Balancer logs, Chronicle context, and normalized ADC GCP-context telemetry are correlated in Chronicle, a SIEM, a data lake, or another analytics layer.

Rule

ADC GCP Context Followed by Suspicious Google Cloud Identity, Control-Plane, or Resource Activity

Rule Format

GCP correlation rule.

Detection Purpose

Detect suspicious Google Cloud identity, IAM, service-account, workload identity, security-control, logging, monitoring, compute, storage, Secret Manager, KMS, network, or resource activity following ADC control-plane compromise indicators. This rule is intended for environments where an ADC, traffic-management appliance, reverse proxy, WAF-adjacent service, or protected backend application is hosted in Google Cloud or where Google Cloud resources are reachable through the compromised edge application-delivery path.

Detection Logic

Correlate ADC control-plane compromise context with suspicious Google Cloud control-plane, identity-plane, resource-plane, and network-plane activity. Promote when ADC context such as suspicious management/API access, appliance instability, rare egress, configuration access, certificate access, virtual-service manipulation, downstream application exposure, or multi-asset probing is followed by unusual Google Cloud activity from related organizations, folders, projects, identities, service accounts, workload identities, resources, Compute Engine instances, GKE clusters, Cloud Run services, App Engine services, Cloud Storage buckets, Secret Manager secrets, KMS keys, network resources, Cloud Armor policies, load balancers, or Security Command Center findings. Exclude approved automation, CI/CD, infrastructure-as-code, security tooling, break-glass, platform support, managed-service, and incident-response activity unless sensitive resources or high-risk methods require review.

Required Telemetry

·        Google Cloud Admin Activity logs, Data Access logs, IAM logs, service-account logs, Cloud Identity logs, Security Command Center findings, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, external Application Load Balancer logs, Compute Engine activity, GKE activity, Cloud Run activity, App Engine activity, logging and monitoring configuration activity, project activity, folder activity, organization activity, and Google Cloud workload inventory.

·        Normalized ADC GCP-context telemetry derived from ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, configuration-change records, certificate records, downstream application logs, Google Cloud organization mapping, folder mapping, project mapping, resource mapping, service-account mapping, identity mapping, ADC asset mapping, virtual-service mapping, backend-pool mapping, protected-application mapping, and source-enrichment context.

·        Google Cloud organization inventory, folder inventory, project inventory, workload inventory, role inventory, service-account baselines, workload-identity baselines, administrative source baselines, expected user-agent baselines, expected organization and project baselines, sensitive resource inventories, approved automation identities, approved CI/CD identities, approved security tooling identities, approved break-glass identities, approved platform-support identities, and approved incident-response identities.

·        Resource mappings between ADC assets, Google Cloud organizations, folders, projects, Compute Engine instances, GKE clusters, Cloud Run services, App Engine services, load balancers, Cloud Armor policies, Cloud Storage buckets, Secret Manager secrets, KMS keys, service accounts, workload identities, backend workloads, and protected applications.

Engineering Implementation Instructions

·        Deploy first in hunt mode until ADC GCP-context mapping is validated.

·        Do not alert on Google Cloud activity alone unless it is correlated with ADC control-plane compromise context, protected backend exposure, or a high-risk Google Cloud method requiring independent review.

·        Map ADC assets to Google Cloud organizations, folders, projects, identities, service accounts, workload identities, Compute Engine instances, GKE clusters, Cloud Run services, App Engine services, load balancers, Cloud Armor policies, storage buckets, Secret Manager secrets, KMS keys, backend workloads, and protected applications.

·        Tune approved automation, CI/CD, infrastructure-as-code, security tooling, platform support, managed-service, break-glass, monitoring, backup, and incident-response workflows.

·        Escalate when ADC compromise context is followed by IAM policy or role changes, service-account credential activity, service-account impersonation, workload identity changes, workforce identity federation changes, security-control modification, logging or monitoring modification, Security Command Center suppression, Secret Manager access, Cloud Storage enumeration or access, KMS activity, network exposure changes, compute modification, GKE modification, Cloud Run modification, App Engine modification, project or organization administration, or Security Command Center findings.

DRI Assessment

This rule has moderate-to-strong reliability when ADC GCP-context telemetry is accurately joined to Google Cloud organization, project, identity, workload, network, and resource activity. It is behavior-driven and reusable because it does not depend on a single ADC vendor, CVE identifier, request path, or exploit string. Reliability depends on organization-to-project mapping, identity mapping, service-account mapping, workload mapping, time-window tuning, Admin Activity coverage, Data Access coverage, VPC Flow Log coverage, Cloud DNS coverage, Security Command Center coverage, and exception quality.

DRI

8.0

TCR Assessment

Operational TCR is moderate where Admin Activity logs, IAM logs, service-account logs, Security Command Center findings, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, load-balancer logs, Google Cloud inventory, and ADC GCP-context telemetry are available. Full-Telemetry TCR improves when Data Access logs, Cloud Storage logs, Secret Manager logs, KMS logs, Cloud Identity logs, downstream application logs, appliance syslog, certificate records, configuration-change records, endpoint telemetry, and backend workload telemetry are joined.

Operational TCR

7.8

Full-Telemetry TCR

8.7

Limitations

·        Google Cloud telemetry cannot prove ADC exploitation unless it is correlated with ADC control-plane behavior, protected backend exposure, or post-access appliance evidence.

·        Admin Activity logs and IAM logs may miss application-layer effects, appliance-level command execution, ADC-local configuration activity, or data-plane access without Data Access and diagnostic coverage.

·        VPC Flow Logs and Cloud DNS logs may show traffic patterns but not payload content or command execution.

·        Approved automation, CI/CD, managed-service operations, break-glass use, emergency response, platform support, or security tooling may resemble suspicious Google Cloud activity if exception lists are incomplete.

·        This rule is not applicable when the ADC and protected application path have no Google Cloud-hosted component or Google Cloud-reachable trust relationship.

Detection Query Pattern

Use this pattern as implementation-ready Google Cloud correlation pseudologic and map all Google Cloud audit fields, identity fields, service-account fields, cloud-resource fields, Cloud Storage fields, Secret Manager fields, KMS fields, Security Command Center fields, Cloud Identity fields, VPC Flow Log fields, Cloud DNS fields, Cloud Armor fields, load-balancer fields, ADC Google Cloud-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, project baselines, organization baselines, service-account baselines, and time windows to the target Chronicle, SIEM, data-lake, or analytics environment before deployment.

adc_gcp_context represents a normalized correlation view derived from ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, configuration-change records, certificate-management records, downstream application logs, Google Cloud workload inventory, Google Cloud organization mapping, Google Cloud folder mapping, Google Cloud project mapping, Google Cloud resource mapping, Google Cloud service-account mapping, Google Cloud identity mapping, ADC asset mapping, virtual-service mapping, backend-pool mapping, protected-application mapping, and source-enrichment context.

gcp_cloud_activity represents a normalized Google Cloud activity view derived from Google Cloud Admin Activity logs, Data Access logs, IAM logs, service-account logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Security Command Center events, Cloud Identity logs, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, external Application Load Balancer logs, Chronicle context, identity context, network context, proxy context, endpoint context, and source-enrichment context.

Local teams must create, map, or enrich both views before deploying the Google Cloud correlation pattern.

FROM gcp_cloud_activity,
adc_gcp_context
WHERE gcp_cloud_activity.principal_email IS NOT NULL
AND adc_gcp_context.event_time IS NOT NULL
AND gcp_cloud_activity.event_time BETWEEN adc_gcp_context.event_time AND adc_gcp_context.event_time + ENV_ADC_TO_GCP_CLOUD_WINDOW
AND adc_gcp_context.adc_asset_id IS NOT NULL
AND adc_gcp_context.organization_id = gcp_cloud_activity.organization_id
AND adc_gcp_context.project_id = gcp_cloud_activity.project_id
AND (
adc_gcp_context.resource_name = gcp_cloud_activity.resource_name
OR adc_gcp_context.compute_instance_id = gcp_cloud_activity.compute_instance_id
OR adc_gcp_context.gke_cluster_id = gcp_cloud_activity.gke_cluster_id
OR adc_gcp_context.cloud_run_service_name = gcp_cloud_activity.cloud_run_service_name
OR adc_gcp_context.app_engine_service_name = gcp_cloud_activity.app_engine_service_name
OR adc_gcp_context.service_account_id = gcp_cloud_activity.service_account_id
OR adc_gcp_context.workload_identity_subject = gcp_cloud_activity.workload_identity_subject
OR adc_gcp_context.source_ip = gcp_cloud_activity.source_ip
OR adc_gcp_context.destination_ip = gcp_cloud_activity.source_ip
OR adc_gcp_context.adc_public_ip = gcp_cloud_activity.source_ip
OR adc_gcp_context.adc_private_ip = gcp_cloud_activity.source_ip
OR adc_gcp_context.backend_host = gcp_cloud_activity.host_name
OR adc_gcp_context.load_balancer_name = gcp_cloud_activity.load_balancer_name
OR adc_gcp_context.cloud_armor_policy_name = gcp_cloud_activity.cloud_armor_policy_name
OR adc_gcp_context.storage_bucket_name = gcp_cloud_activity.storage_bucket_name
OR adc_gcp_context.secret_name = gcp_cloud_activity.secret_name
OR adc_gcp_context.kms_key_name = gcp_cloud_activity.kms_key_name
OR adc_gcp_context.correlation_id = gcp_cloud_activity.correlation_id
)
AND adc_gcp_context.type IN (
"suspicious_adc_control_plane_access",
"adc_appliance_instability_after_control_plane_access",
"adc_rare_egress_after_control_plane_access",
"adc_configuration_or_certificate_access",
"adc_backup_or_diagnostic_export",
"adc_virtual_service_or_backend_pool_change",
"adc_routing_or_header_manipulation",
"adc_tls_or_certificate_binding_change",
"adc_administrative_control_change",
"adc_logging_degradation",
"adc_downstream_application_exposure",
"multi_adc_control_plane_probe_cluster",
"adc_post_access_behavior_within_cluster"
)
AND (
gcp_cloud_activity.method_name IN ENV_SUSPICIOUS_GCP_ADMIN_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_IAM_POLICY_OR_ROLE_CHANGE_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_SERVICE_ACCOUNT_CREDENTIAL_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_SERVICE_ACCOUNT_IMPERSONATION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_WORKLOAD_IDENTITY_CHANGE_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_WORKFORCE_IDENTITY_FEDERATION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_STORAGE_RISK_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_SECRET_MANAGER_RISK_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_KMS_RISK_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_LOGGING_OR_MONITORING_MODIFICATION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_SECURITY_CONTROL_MODIFICATION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_SECURITY_COMMAND_CENTER_SUPPRESSION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_NETWORK_EXPOSURE_CHANGE_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_COMPUTE_MODIFICATION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_GKE_MODIFICATION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_CLOUD_RUN_MODIFICATION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_APP_ENGINE_MODIFICATION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_LOAD_BALANCER_OR_CLOUD_ARMOR_MODIFICATION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_PROJECT_OR_ORGANIZATION_ADMIN_METHODS
OR gcp_cloud_activity.security_command_center_finding_type IN ENV_RELEVANT_SECURITY_COMMAND_CENTER_FINDINGS
OR gcp_cloud_activity.vpc_flow_anomaly_type IN ENV_RELEVANT_GCP_VPC_FLOW_ANOMALIES
OR gcp_cloud_activity.dns_query_risk IN ENV_RELEVANT_GCP_DNS_QUERY_RISKS
)
AND (
gcp_cloud_activity.source_ip NOT IN ENV_APPROVED_GCP_ADMIN_SOURCE_IPS
OR gcp_cloud_activity.user_agent NOT IN ENV_EXPECTED_GCP_USER_AGENTS_BY_ROLE
OR gcp_cloud_activity.organization_id NOT IN ENV_EXPECTED_GCP_ORGANIZATIONS_BY_USER_OR_ROLE
OR gcp_cloud_activity.project_id NOT IN ENV_EXPECTED_GCP_PROJECTS_BY_USER_OR_ROLE
OR gcp_cloud_activity.resource_name NOT IN ENV_EXPECTED_GCP_RESOURCES_BY_USER_OR_ROLE
OR gcp_cloud_activity.role_name NOT IN ENV_EXPECTED_GCP_ROLES_BY_USER_OR_ROLE
OR gcp_cloud_activity.service_account_id NOT IN ENV_EXPECTED_GCP_SERVICE_ACCOUNTS_BY_USER_OR_ROLE
OR gcp_cloud_activity.workload_identity_subject NOT IN ENV_EXPECTED_GCP_WORKLOAD_IDENTITIES_BY_USER_OR_ROLE
OR gcp_cloud_activity.service_account_key_id IS NEW_FOR gcp_cloud_activity.normalized_user_id WITHIN ENV_GCP_SERVICE_ACCOUNT_KEY_NOVELTY_WINDOW
OR gcp_cloud_activity.resource_name IN ENV_SENSITIVE_GCP_RESOURCES
OR gcp_cloud_activity.load_balancer_name IN ENV_SENSITIVE_GCP_LOAD_BALANCERS
OR gcp_cloud_activity.cloud_armor_policy_name IN ENV_SENSITIVE_GCP_CLOUD_ARMOR_POLICIES
OR gcp_cloud_activity.storage_bucket_name IN ENV_SENSITIVE_GCP_STORAGE_BUCKETS
OR gcp_cloud_activity.secret_name IN ENV_SENSITIVE_GCP_SECRETS
OR gcp_cloud_activity.kms_key_name IN ENV_SENSITIVE_GCP_KMS_KEYS
OR gcp_cloud_activity.method_name IN ENV_HIGH_RISK_GCP_METHODS_REQUIRING_REVIEW
)
AND NOT (
gcp_cloud_activity.principal_email IN ENV_APPROVED_GCP_AUTOMATION_IDENTITIES
AND gcp_cloud_activity.source_ip IN ENV_APPROVED_GCP_AUTOMATION_SOURCE_IPS
AND gcp_cloud_activity.method_name IN ENV_APPROVED_GCP_AUTOMATION_METHODS
AND gcp_cloud_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
gcp_cloud_activity.service_account_id IN ENV_APPROVED_GCP_SERVICE_ACCOUNTS
AND gcp_cloud_activity.source_ip IN ENV_APPROVED_GCP_SERVICE_ACCOUNT_SOURCE_IPS
AND gcp_cloud_activity.method_name IN ENV_APPROVED_GCP_SERVICE_ACCOUNT_METHODS
AND gcp_cloud_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
gcp_cloud_activity.principal_email IN ENV_APPROVED_CICD_OR_IAC_IDENTITIES
AND gcp_cloud_activity.source_ip IN ENV_APPROVED_CICD_OR_IAC_SOURCE_IPS
AND gcp_cloud_activity.method_name IN ENV_APPROVED_CICD_OR_IAC_GCP_METHODS
AND gcp_cloud_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
gcp_cloud_activity.principal_email IN ENV_APPROVED_BREAK_GLASS_IDENTITIES
AND gcp_cloud_activity.source_ip IN ENV_APPROVED_BREAK_GLASS_SOURCE_IPS
AND gcp_cloud_activity.method_name IN ENV_APPROVED_BREAK_GLASS_GCP_METHODS
AND gcp_cloud_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
gcp_cloud_activity.principal_email IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES
AND gcp_cloud_activity.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS
AND gcp_cloud_activity.method_name IN ENV_APPROVED_SECURITY_TOOLING_GCP_METHODS
AND gcp_cloud_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
gcp_cloud_activity.principal_email IN ENV_APPROVED_INCIDENT_RESPONSE_IDENTITIES
AND gcp_cloud_activity.source_ip IN ENV_APPROVED_INCIDENT_RESPONSE_SOURCE_IPS
AND gcp_cloud_activity.method_name IN ENV_APPROVED_INCIDENT_RESPONSE_GCP_METHODS
AND gcp_cloud_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
gcp_cloud_activity.principal_email IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_IDENTITIES
AND gcp_cloud_activity.source_ip IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_SOURCE_IPS
AND gcp_cloud_activity.method_name IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_GCP_METHODS
AND gcp_cloud_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND gcp_cloud_activity.principal_email NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS
GROUP BY gcp_cloud_activity.organization_id,
gcp_cloud_activity.folder_id,
gcp_cloud_activity.project_id,
gcp_cloud_activity.normalized_user_id,
gcp_cloud_activity.principal_email,
gcp_cloud_activity.service_account_id,
gcp_cloud_activity.workload_identity_subject,
gcp_cloud_activity.source_ip,
gcp_cloud_activity.user_agent,
gcp_cloud_activity.method_name,
gcp_cloud_activity.resource_name,
gcp_cloud_activity.load_balancer_name,
gcp_cloud_activity.cloud_armor_policy_name,
gcp_cloud_activity.storage_bucket_name,
gcp_cloud_activity.secret_name,
gcp_cloud_activity.kms_key_name,
adc_gcp_context.adc_asset_id,
adc_gcp_context.virtual_service,
adc_gcp_context.backend_pool,
adc_gcp_context.type
EMIT alert WHEN
count_distinct(gcp_cloud_activity.method_name) >= ENV_MIN_DISTINCT_GCP_RISK_METHODS
OR gcp_cloud_activity.method_name IN ENV_HIGH_RISK_GCP_METHODS_REQUIRING_REVIEW
OR gcp_cloud_activity.method_name IN ENV_GCP_SECURITY_CONTROL_MODIFICATION_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_SECRET_MANAGER_RISK_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_STORAGE_RISK_METHODS
OR gcp_cloud_activity.method_name IN ENV_GCP_SERVICE_ACCOUNT_CREDENTIAL_METHODS
OR gcp_cloud_activity.service_account_key_id IS NEW_FOR gcp_cloud_activity.normalized_user_id WITHIN ENV_GCP_SERVICE_ACCOUNT_KEY_NOVELTY_WINDOW
OR gcp_cloud_activity.security_command_center_finding_type IN ENV_RELEVANT_SECURITY_COMMAND_CENTER_FINDINGS
OR gcp_cloud_activity.vpc_flow_anomaly_type IN ENV_RELEVANT_GCP_VPC_FLOW_ANOMALIES
OR gcp_cloud_activity.dns_query_risk IN ENV_RELEVANT_GCP_DNS_QUERY_RISKS

Rule

GCP Network Exposure or Resource-Access Activity Linked to ADC GCP Context

Rule Format

GCP correlation rule.

Detection Purpose

Detect suspicious Google Cloud network exposure, firewall or routing modification, load balancer or Cloud Armor modification, DNS change, Secret Manager access, Cloud Storage access, KMS access, or rare egress behavior linked to ADC compromise context. This rule is intended to identify Google Cloud-side network, application-delivery, and resource-access changes that may follow ADC control-plane access, traffic-path manipulation, or downstream application exposure.

Detection Logic

Correlate ADC GCP-context indicators with Google Cloud network-plane, application-delivery, and resource-access telemetry. Promote when suspicious ADC control-plane behavior is followed by firewall exposure, route modification, load balancer change, Cloud Armor weakening, DNS change, Secret Manager access, Cloud Storage enumeration or access, KMS activity, unusual VPC flow behavior, rare DNS resolution, unexpected outbound traffic, or sensitive backend exposure. Exclude approved infrastructure-as-code, CI/CD, security tooling, managed-service, monitoring, platform support, break-glass, and incident-response workflows unless sensitive resources or high-risk exposure changes require review.

Required Telemetry

·        Google Cloud Admin Activity logs, Data Access logs, Security Command Center findings, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, external Application Load Balancer logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Compute Engine activity, GKE activity, Cloud Run activity, App Engine activity, firewall policy activity, route activity, logging and monitoring activity, and Google Cloud workload inventory.

·        Normalized ADC GCP-context telemetry for suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, virtual-service change, backend-pool change, route or header manipulation, TLS behavior, downstream application exposure, and multi-asset probing.

·        Approved firewall changes, approved route changes, approved load balancer changes, approved Cloud Armor changes, approved DNS changes, approved Secret Manager workflows, approved Cloud Storage workflows, approved KMS workflows, approved CI/CD identities, approved IaC identities, approved automation identities, approved security tooling identities, approved platform-support identities, approved managed-service identities, and approved incident-response identities.

·        Resource mappings between ADC assets, Google Cloud organizations, folders, projects, load balancers, Cloud Armor policies, firewall policies, VPC networks, routes, DNS zones, Cloud Storage buckets, Secret Manager secrets, KMS keys, backend workloads, and protected applications.

Engineering Implementation Instructions

·        Deploy first in hunt mode to validate ADC-to-GCP resource mapping and network-change baselines.

·        Correlate by organization, folder, project, identity, service account, workload identity, source IP, user agent, load balancer, Cloud Armor policy, firewall policy, VPC network, route, DNS zone, Secret Manager secret, Cloud Storage bucket, KMS key, backend workload, protected application, ADC asset, virtual service, backend pool, and bounded time window.

·        Require ADC GCP-context linkage before treating Google Cloud network or resource-access changes as part of this report’s behavior family.

·        Suppress approved IaC, CI/CD, change-management, security tooling, monitoring, managed-service, platform support, emergency maintenance, and incident-response workflows.

·        Escalate when ADC compromise context is followed by internet exposure, backend exposure, Cloud Armor weakening, load balancer modification, DNS redirection, Secret Manager access, Cloud Storage enumeration, KMS activity, suspicious VPC flow behavior, rare egress, or Security Command Center findings.

DRI Assessment

This rule has moderate reliability because Google Cloud network, application-delivery, and resource-access telemetry can identify exposure changes, Cloud Armor changes, routing changes, and unusual resource access after ADC compromise context. It is less definitive than direct ADC appliance telemetry because Google Cloud-side changes can result from normal infrastructure automation or authorized change activity. Reliability depends on resource mapping, change baselines, approved workflow exceptions, diagnostic logging, Data Access coverage, and the strength of ADC GCP-context linkage.

DRI

7.8

TCR Assessment

Operational TCR is moderate where Admin Activity logs, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, external Application Load Balancer logs, Security Command Center findings, Google Cloud inventory, approved change context, and ADC GCP-context telemetry are available. Full-Telemetry TCR improves when Data Access logs, Cloud Storage logs, Secret Manager logs, KMS logs, downstream application logs, appliance syslog, certificate records, configuration-change records, endpoint telemetry, and backend workload telemetry are available.

Operational TCR

7.6

Full-Telemetry TCR

8.5

Limitations

·        This rule cannot confirm ADC command execution or appliance compromise without ADC appliance, management/API, or endpoint-context evidence.

·        Infrastructure-as-code, CI/CD, change windows, managed-service activity, platform support, security tooling, and incident-response workflows may resemble suspicious network or resource modification.

·        VPC Flow Logs and Cloud DNS logs do not provide full payload visibility and may not distinguish benign backend traffic from exploitation effects without context.

·        Google Cloud network or resource-access changes may be unrelated to ADC compromise unless linked by organization, project, resource, workload, source, virtual service, backend pool, protected application, or time window.

·        This rule has limited value when no ADC, protected backend, or application-delivery resource is hosted in Google Cloud.

Detection Query Pattern

Use this pattern as implementation-ready Google Cloud network, application-delivery, and resource-access correlation pseudologic and map all Google Cloud audit fields, cloud-resource fields, Cloud Storage fields, Secret Manager fields, KMS fields, Security Command Center fields, VPC Flow Log fields, Cloud DNS fields, Cloud Armor fields, load-balancer fields, ADC Google Cloud-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, network-change baselines, project baselines, organization baselines, service-account baselines, and time windows to the target Chronicle, SIEM, data-lake, or analytics environment before deployment.

adc_gcp_context represents a normalized correlation view derived from ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, configuration-change records, certificate-management records, downstream application logs, Google Cloud workload inventory, Google Cloud organization mapping, Google Cloud folder mapping, Google Cloud project mapping, Google Cloud application-delivery mapping, Google Cloud network-resource mapping, ADC asset mapping, virtual-service mapping, backend-pool mapping, protected-application mapping, and source-enrichment context.

gcp_network_resource_activity represents a normalized Google Cloud network, application-delivery, and resource-access view derived from Google Cloud Admin Activity logs, Data Access logs, Security Command Center events, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, external Application Load Balancer logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Compute Engine activity, GKE activity, Cloud Run activity, App Engine activity, firewall policy activity, route activity, logging and monitoring activity, identity context, network context, proxy context, endpoint context, and source-enrichment context.

Local teams must create, map, or enrich both views before deploying the Google Cloud network and resource-access correlation pattern.

FROM gcp_network_resource_activity,
adc_gcp_context
WHERE gcp_network_resource_activity.principal_email IS NOT NULL
AND adc_gcp_context.event_time IS NOT NULL
AND gcp_network_resource_activity.event_time BETWEEN adc_gcp_context.event_time AND adc_gcp_context.event_time + ENV_ADC_TO_GCP_NETWORK_RESOURCE_WINDOW
AND adc_gcp_context.adc_asset_id IS NOT NULL
AND adc_gcp_context.organization_id = gcp_network_resource_activity.organization_id
AND adc_gcp_context.project_id = gcp_network_resource_activity.project_id
AND (
adc_gcp_context.load_balancer_name = gcp_network_resource_activity.load_balancer_name
OR adc_gcp_context.cloud_armor_policy_name = gcp_network_resource_activity.cloud_armor_policy_name
OR adc_gcp_context.firewall_policy_name = gcp_network_resource_activity.firewall_policy_name
OR adc_gcp_context.vpc_network_name = gcp_network_resource_activity.vpc_network_name
OR adc_gcp_context.route_name = gcp_network_resource_activity.route_name
OR adc_gcp_context.dns_zone_name = gcp_network_resource_activity.dns_zone_name
OR adc_gcp_context.compute_instance_id = gcp_network_resource_activity.compute_instance_id
OR adc_gcp_context.gke_cluster_id = gcp_network_resource_activity.gke_cluster_id
OR adc_gcp_context.cloud_run_service_name = gcp_network_resource_activity.cloud_run_service_name
OR adc_gcp_context.app_engine_service_name = gcp_network_resource_activity.app_engine_service_name
OR adc_gcp_context.backend_host = gcp_network_resource_activity.host_name
OR adc_gcp_context.backend_ip = gcp_network_resource_activity.destination_ip
OR adc_gcp_context.adc_public_ip = gcp_network_resource_activity.source_ip
OR adc_gcp_context.adc_private_ip = gcp_network_resource_activity.source_ip
OR adc_gcp_context.destination_ip = gcp_network_resource_activity.source_ip
OR adc_gcp_context.storage_bucket_name = gcp_network_resource_activity.storage_bucket_name
OR adc_gcp_context.secret_name = gcp_network_resource_activity.secret_name
OR adc_gcp_context.kms_key_name = gcp_network_resource_activity.kms_key_name
)
AND adc_gcp_context.type IN (
"suspicious_adc_control_plane_access",
"adc_appliance_instability_after_control_plane_access",
"adc_rare_egress_after_control_plane_access",
"adc_virtual_service_or_backend_pool_change",
"adc_routing_or_header_manipulation",
"adc_tls_or_certificate_binding_change",
"adc_downstream_application_exposure",
"multi_adc_control_plane_probe_cluster",
"adc_post_access_behavior_within_cluster"
)
AND (
gcp_network_resource_activity.method_name IN ENV_GCP_NETWORK_EXPOSURE_CHANGE_METHODS
OR gcp_network_resource_activity.method_name IN ENV_GCP_FIREWALL_OR_POLICY_MODIFICATION_METHODS
OR gcp_network_resource_activity.method_name IN ENV_GCP_ROUTE_MODIFICATION_METHODS
OR gcp_network_resource_activity.method_name IN ENV_GCP_LOAD_BALANCER_MODIFICATION_METHODS
OR gcp_network_resource_activity.method_name IN ENV_GCP_CLOUD_ARMOR_WEAKENING_OR_MODIFICATION_METHODS
OR gcp_network_resource_activity.method_name IN ENV_GCP_DNS_MODIFICATION_METHODS
OR gcp_network_resource_activity.method_name IN ENV_GCP_SECRET_MANAGER_RISK_METHODS
OR gcp_network_resource_activity.method_name IN ENV_GCP_STORAGE_RISK_METHODS
OR gcp_network_resource_activity.method_name IN ENV_GCP_KMS_RISK_METHODS
OR gcp_network_resource_activity.security_command_center_finding_type IN ENV_RELEVANT_NETWORK_SECURITY_COMMAND_CENTER_FINDINGS
OR gcp_network_resource_activity.vpc_flow_anomaly_type IN ENV_RELEVANT_GCP_VPC_FLOW_ANOMALIES
OR gcp_network_resource_activity.dns_query_risk IN ENV_RELEVANT_GCP_DNS_QUERY_RISKS
OR gcp_network_resource_activity.cloud_armor_behavior IN ENV_RELEVANT_GCP_CLOUD_ARMOR_BEHAVIORS
OR gcp_network_resource_activity.application_delivery_behavior IN ENV_RELEVANT_GCP_APPLICATION_DELIVERY_BEHAVIORS
)
AND (
gcp_network_resource_activity.source_ip NOT IN ENV_APPROVED_GCP_ADMIN_SOURCE_IPS
OR gcp_network_resource_activity.user_agent NOT IN ENV_EXPECTED_GCP_USER_AGENTS_BY_ROLE
OR gcp_network_resource_activity.organization_id NOT IN ENV_EXPECTED_GCP_ORGANIZATIONS_BY_USER_OR_ROLE
OR gcp_network_resource_activity.project_id NOT IN ENV_EXPECTED_GCP_PROJECTS_BY_USER_OR_ROLE
OR gcp_network_resource_activity.resource_name NOT IN ENV_EXPECTED_GCP_RESOURCES_BY_USER_OR_ROLE
OR gcp_network_resource_activity.role_name NOT IN ENV_EXPECTED_GCP_ROLES_BY_USER_OR_ROLE
OR gcp_network_resource_activity.firewall_policy_name IN ENV_SENSITIVE_GCP_FIREWALL_POLICIES
OR gcp_network_resource_activity.vpc_network_name IN ENV_SENSITIVE_GCP_VPC_NETWORKS
OR gcp_network_resource_activity.route_name IN ENV_SENSITIVE_GCP_ROUTES
OR gcp_network_resource_activity.load_balancer_name IN ENV_SENSITIVE_GCP_LOAD_BALANCERS
OR gcp_network_resource_activity.cloud_armor_policy_name IN ENV_SENSITIVE_GCP_CLOUD_ARMOR_POLICIES
OR gcp_network_resource_activity.dns_zone_name IN ENV_SENSITIVE_GCP_DNS_ZONES
OR gcp_network_resource_activity.storage_bucket_name IN ENV_SENSITIVE_GCP_STORAGE_BUCKETS
OR gcp_network_resource_activity.secret_name IN ENV_SENSITIVE_GCP_SECRETS
OR gcp_network_resource_activity.kms_key_name IN ENV_SENSITIVE_GCP_KMS_KEYS
OR gcp_network_resource_activity.vpc_flow_anomaly_type IN ENV_HIGH_RISK_GCP_VPC_FLOW_ANOMALIES
OR gcp_network_resource_activity.dns_query_risk IN ENV_HIGH_RISK_GCP_DNS_QUERY_RISKS
OR gcp_network_resource_activity.method_name IN ENV_HIGH_RISK_GCP_NETWORK_RESOURCE_METHODS_REQUIRING_REVIEW
)
AND NOT (
gcp_network_resource_activity.principal_email IN ENV_APPROVED_CICD_OR_IAC_IDENTITIES
AND gcp_network_resource_activity.source_ip IN ENV_APPROVED_CICD_OR_IAC_SOURCE_IPS
AND gcp_network_resource_activity.method_name IN ENV_APPROVED_CICD_OR_IAC_GCP_NETWORK_METHODS
AND gcp_network_resource_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
gcp_network_resource_activity.principal_email IN ENV_APPROVED_GCP_AUTOMATION_IDENTITIES
AND gcp_network_resource_activity.source_ip IN ENV_APPROVED_GCP_AUTOMATION_SOURCE_IPS
AND gcp_network_resource_activity.method_name IN ENV_APPROVED_GCP_AUTOMATION_NETWORK_METHODS
AND gcp_network_resource_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
gcp_network_resource_activity.principal_email IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES
AND gcp_network_resource_activity.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS
AND gcp_network_resource_activity.method_name IN ENV_APPROVED_SECURITY_TOOLING_GCP_NETWORK_METHODS
AND gcp_network_resource_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
gcp_network_resource_activity.principal_email IN ENV_APPROVED_INCIDENT_RESPONSE_IDENTITIES
AND gcp_network_resource_activity.source_ip IN ENV_APPROVED_INCIDENT_RESPONSE_SOURCE_IPS
AND gcp_network_resource_activity.method_name IN ENV_APPROVED_INCIDENT_RESPONSE_GCP_NETWORK_METHODS
AND gcp_network_resource_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND NOT (
gcp_network_resource_activity.principal_email IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_IDENTITIES
AND gcp_network_resource_activity.source_ip IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_SOURCE_IPS
AND gcp_network_resource_activity.method_name IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_GCP_NETWORK_METHODS
AND gcp_network_resource_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)
AND gcp_network_resource_activity.principal_email NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS
GROUP BY gcp_network_resource_activity.organization_id,
gcp_network_resource_activity.folder_id,
gcp_network_resource_activity.project_id,
gcp_network_resource_activity.normalized_user_id,
gcp_network_resource_activity.principal_email,
gcp_network_resource_activity.service_account_id,
gcp_network_resource_activity.source_ip,
gcp_network_resource_activity.user_agent,
gcp_network_resource_activity.method_name,
gcp_network_resource_activity.resource_name,
gcp_network_resource_activity.firewall_policy_name,
gcp_network_resource_activity.vpc_network_name,
gcp_network_resource_activity.route_name,
gcp_network_resource_activity.load_balancer_name,
gcp_network_resource_activity.cloud_armor_policy_name,
gcp_network_resource_activity.dns_zone_name,
gcp_network_resource_activity.storage_bucket_name,
gcp_network_resource_activity.secret_name,
gcp_network_resource_activity.kms_key_name,
adc_gcp_context.adc_asset_id,
adc_gcp_context.virtual_service,
adc_gcp_context.backend_pool,
adc_gcp_context.type
EMIT alert WHEN
count_distinct(gcp_network_resource_activity.method_name) >= ENV_MIN_DISTINCT_GCP_NETWORK_RESOURCE_RISK_METHODS
OR gcp_network_resource_activity.method_name IN ENV_HIGH_RISK_GCP_NETWORK_RESOURCE_METHODS_REQUIRING_REVIEW
OR gcp_network_resource_activity.security_command_center_finding_type IN ENV_RELEVANT_NETWORK_SECURITY_COMMAND_CENTER_FINDINGS
OR gcp_network_resource_activity.vpc_flow_anomaly_type IN ENV_HIGH_RISK_GCP_VPC_FLOW_ANOMALIES
OR gcp_network_resource_activity.dns_query_risk IN ENV_HIGH_RISK_GCP_DNS_QUERY_RISKS

S26 Threat-to-Rule Traceability Matrix

Traceability Purpose

This section maps the primary behavioral threat conditions in this report to the S25 detection coverage developed across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, and GCP.

The traceability model is behavior-led. It does not rely on a single CVE label, vendor name, appliance name, exploit name, request path, protocol, source IP, user-agent value, payload string, command string, scanner signature, public proof-of-concept reference, campaign name, actor branding, tool name, or static indicator as the basis for coverage.

Coverage Scope

The S25 rule set provides coverage for two parallel ADC exploitation paths: suspicious control-plane access and suspicious traffic-processing activity. Those paths converge on observable appliance, application-delivery, and downstream effects including appliance instability, service or process faults, restart or failover behavior, resource exhaustion, rare ADC-originated egress, configuration access, certificate or TLS-object access, backup or diagnostic export, virtual-service modification, backend-pool modification, routing, header, persistence, TLS, NAT, ALG, or logging change, administrative-control change, availability degradation, downstream application exposure, conditional downstream cloud activity, and multi-asset control-plane probing.

Coverage is strongest where ADC management/API logs, listener and virtual-service telemetry, protocol and traffic-processing telemetry, appliance syslog, service-health records, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, administrative audit logs, configuration-change records, certificate-management records, HA and failover records, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, endpoint telemetry where available, downstream application logs, SIEM correlation, and cloud telemetry can be joined into bounded behavioral sequences.

Primary Coverage Areas

·        Suspicious ADC management/API or other control-plane access involving unusual source infrastructure, abnormal request timing, abnormal request size, abnormal response size, abnormal status sequence, suspicious control-plane payload patterns, unexpected administrative or diagnostic surface access, Progress Kemp LoadMaster /accessv2 access where locally visible, or generic control-plane behavior tied to ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management appliances.

·        Suspicious traffic-processing activity involving exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or other ADC processing surfaces where protocol behavior, message size, transaction structure, cadence, connection behavior, or source characteristics deviate materially from established baselines.

·        Appliance instability after suspicious ADC-facing activity, including watchdog restart, process or service crash, management-service fault, API handler exception, authentication-handler error, traffic-processing fault, failover event, service restart, appliance reboot, abnormal connection state, resource exhaustion, or availability degradation.

·        Rare ADC-originated egress, suspicious destination behavior, new or rare domain access, unusual destination geography, unusual destination port, suspicious ASN, proxy action, firewall action, destination reputation signal, or unusual protocol behavior after suspicious ADC activity.

·        Configuration access, configuration export, backup creation, backup download, diagnostic bundle creation, diagnostic export, packet capture creation, packet capture export, certificate or TLS-object access, private-key access, keystore access, API-token access, or credential-bearing artifact access after suspicious ADC activity.

·        Virtual-service modification, backend-pool modification, routing-rule modification, rewrite-rule modification, header-rule modification, persistence-profile modification, TLS offload change, certificate binding change, health-check modification, NAT or ALG configuration change, logging-setting modification, administrative-setting modification, API-key creation, administrator creation, or role modification after suspicious ADC activity.

·        Multi-asset ADC control-plane probing involving related source infrastructure, request-family behavior, management/API surface access, abnormal status sequencing, suspicious payload patterns, source clustering, asset-group clustering, exposure-class clustering, or post-access behavior affecting one or more ADC assets.

·        Downstream AWS, Azure, and GCP activity where normalized upstream ADC context can be joined to independently suspicious cloud activity. Upstream ADC context may originate from suspicious control-plane activity, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, downstream application exposure, or, where forwarded and normalized by the analytics environment, suspicious traffic-processing activity.

Traceability Mapping

Suspicious ADC Control-Plane Access

This behavior is covered where ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, source-enrichment telemetry, request timing, response size, status sequence, user agent, management-interface inventory, and SIEM telemetry can be correlated around internet-facing, partner-reachable, or management-exposed ADC assets.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage for suspicious ADC control-plane access, management/API surface activity, unusual source infrastructure, source-to-asset deviation, abnormal request timing, abnormal request size, abnormal response size, suspicious status sequencing, suspicious payload patterns, and control-plane-to-impact sequencing.

·        Splunk, Elastic, QRadar, and SIGMA coverage for suspicious ADC control-plane access where ADC asset ID, management interface, virtual service, backend pool, source, forwarded source, request path, query string, method, status, request size, response size, source risk, and timing fields are normalized or enriched.

·        SentinelOne supporting coverage where suspicious ADC control-plane access can be joined to appliance-support-host behavior, service-context command execution, sensitive artifact access, diagnostic bundle access, backup access, certificate access, or rare egress from an ADC-adjacent host.

·        AWS, Azure, and GCP downstream coverage only when suspicious ADC control-plane access can be joined to later cloud activity through workload, identity, source, host, resource, load balancer, WAF, storage, secret, KMS, service account, managed identity, role, account, subscription, project, or correlation context.

Coverage Qualification

·        A single management/API request is not sufficient.

·        A single request path is not sufficient.

·        A single /accessv2 access event is not sufficient.

·        A single source IP is not sufficient.

·        A single user-agent value is not sufficient.

·        A single scanner hit is not sufficient.

·        A single vulnerable-version observation is not sufficient.

·        Reliable ADC asset, management-interface, source, forwarded-source, request-family, timing, status-sequence, response-size, appliance-health, configuration, certificate, egress, administrative, downstream application, or cloud-context linkage must exist.

·        Approved administrators, scanners, vendor support, managed-service sources, monitoring systems, patch-validation sources, backup workflows, certificate-rotation workflows, emergency maintenance, incident-response collection, and known change windows require suppression or downgrade when expected context aligns.

Suspicious ADC Traffic-Processing Activity

This behavior is covered where network, protocol, listener, virtual-service, load-balancer, WAF, NDR, firewall, flow, or appliance telemetry identifies suspicious interaction with an externally reachable ADC traffic-processing function and can be correlated with independent appliance or availability effects.

Mapped Coverage

·        NDR / Network Behavioral Analytics primary coverage for malformed, oversized, abnormal, repeated, protocol-inconsistent, fuzzing-like, or otherwise exploit-shaped traffic directed at ADC listeners, virtual services, protocol handlers, NAT functions, ALGs, or other processing surfaces.

·        Splunk, Elastic, and QRadar primary correlation coverage where network or protocol activity can be joined to appliance-health, service-fault, restart, HA, failover, resource, connection-state, or downstream availability telemetry.

·        SIGMA portable coverage where the target backend creates same-asset, bounded-window correlation flags for suspicious traffic-processing activity and independent appliance or availability impact.

·        SentinelOne supporting coverage only where traffic-processing exploitation produces endpoint-visible execution, service-context activity, file access, or other host-visible consequences on a monitored ADC-related system.

·        AWS, Azure, and GCP may consume traffic-processing exploitation as forwarded upstream ADC context only where the context is normalized and joined to independently suspicious cloud activity. The cloud rules do not independently establish the traffic-processing exploit.

Coverage Qualification

·        Malformed traffic alone is not sufficient.

·        A protocol anomaly alone is not sufficient.

·        A large or unusual message alone is not sufficient.

·        A SIP transaction alone is not sufficient.

·        Enabled SIP ALG, LSN, NAT, or other traffic-processing functionality alone is not sufficient.

·        A single timeout, reset, crash, restart, or failover event is not sufficient.

·        Coverage requires same-asset correlation between suspicious traffic-processing activity and materially independent appliance-health, service-health, HA, resource, connection, availability, or downstream application effects.

·        Current SIP ALG and LSN context may be used for CVE-2026-19489-specific implementation but is not a universal requirement for traffic-processing coverage.

Appliance Instability After Suspicious ADC Activity

This behavior is covered where suspicious control-plane or traffic-processing activity can be correlated to appliance-health events, management-service faults, API handler exceptions, authentication-handler errors, traffic-processing faults, watchdog restarts, service crashes, failover events, abnormal connection states, resource exhaustion, or availability degradation.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage for suspicious control-plane or traffic-processing activity followed by abnormal connection behavior, service unavailability, reset patterns, timeout behavior, rare egress, status anomalies, appliance-facing instability indicators, or downstream availability impact.

·        Splunk, Elastic, QRadar, and SIGMA coverage for suspicious ADC activity followed by appliance instability where network, protocol, management/API, appliance syslog, health events, service-fault events, and asset context are normalized or enriched.

·        SentinelOne supporting coverage where endpoint or appliance-support-host telemetry identifies service restart behavior, diagnostic execution, shell activity, suspicious service-context behavior, or artifact access.

·        AWS, Azure, and GCP provide only downstream contextual coverage when appliance-instability context is forwarded and joined to independently suspicious cloud behavior through reliable cloud mappings.

Coverage Qualification

·        Appliance instability alone is not sufficient.

·        A reboot alone is not sufficient.

·        A failover event alone is not sufficient.

·        A timeout or reset sequence alone is not sufficient.

·        A management-service, protocol-handler, or traffic-processing error alone is not sufficient.

·        Coverage requires preceding suspicious ADC control-plane or traffic-processing activity and same-asset continuity, source, interface, listener, protocol, request-family, service-health, configuration, egress, or downstream impact context.

·        Approved failover testing, health checks, patching, maintenance, vendor support, monitoring, backup, load testing, diagnostic collection, and incident-response activity require local baseline validation.

Rare ADC Egress and Suspicious Destination Activity

This behavior is covered where DNS, proxy, firewall, NDR, destination reputation, destination first-seen, domain age, ASN, geography, destination port, protocol, flow telemetry, and ADC asset mapping can identify unusual outbound communication after suspicious ADC activity.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage for rare ADC-originated destination access, unusual egress ports, suspicious ASN, new or rare domains, abnormal destination geography, proxy anomalies, firewall anomalies, unusual protocols, and ADC-activity-to-egress sequencing.

·        SentinelOne supporting coverage for rare egress from ADC-adjacent hosts after service-context execution, diagnostic activity, backup activity, certificate access, or suspicious artifact access.

·        Splunk, Elastic, QRadar, and SIGMA coverage where DNS, proxy, firewall, endpoint, destination reputation, first-seen status, ASN, geography, destination-port, protocol, ADC asset, and upstream ADC context are normalized or enriched.

·        AWS, Azure, and GCP coverage only where rare egress or other ADC compromise context can be joined to independently suspicious cloud identity, storage, secrets, keys, resource, workload, network, load balancer, WAF, or control-plane activity.

Coverage Qualification

·        Rare egress alone is not sufficient.

·        A suspicious domain alone is not sufficient.

·        Destination reputation alone is not sufficient.

·        Unusual destination port alone is not sufficient.

·        New domain age alone is not sufficient.

·        A single outbound connection alone is not sufficient.

·        Coverage requires preceding suspicious ADC activity or independent appliance, configuration, certificate, administrative, endpoint, downstream application, or cloud-impact context tied to the same asset and time window.

·        Approved vendor support, update retrieval, license validation, telemetry, monitoring, backup, NTP, DNS, syslog, security tooling, vulnerability validation, and incident-response destinations require local allowlisting.

Configuration, Backup, Diagnostic, Certificate, and Credential-Material Access

This behavior is covered where ADC administrative audit logs, configuration-change records, certificate-management records, backup records, diagnostic bundle records, packet capture records, file telemetry, endpoint telemetry, appliance syslog, and SIEM telemetry can identify suspicious access to protected ADC trust-boundary objects after suspicious ADC activity.

Mapped Coverage

·        SentinelOne coverage for sensitive configuration access, certificate or key access, backup access, diagnostic bundle access, packet capture access, shell or script execution, transfer-tool use, archive-tool use, and suspicious ADC-support-host artifact access.

·        Splunk, Elastic, QRadar, and SIGMA coverage where protected configuration objects, certificate objects, private-key material, API tokens, credential-bearing artifacts, backup actions, diagnostic actions, packet capture actions, source context, and ADC asset context are normalized or enriched.

·        NDR / Network Behavioral Analytics supporting coverage where suspicious configuration, backup, diagnostic, or certificate activity is followed by rare egress, unusual destination access, or downstream network behavior.

·        AWS, Azure, and GCP coverage only when protected-object context is forwarded and can be joined to independently suspicious cloud-resource, secret, storage, key, identity, workload, or control-plane activity.

Coverage Qualification

·        Configuration access alone is not sufficient.

·        Certificate access alone is not sufficient.

·        Backup creation alone is not sufficient.

·        Diagnostic bundle creation alone is not sufficient.

·        Packet capture creation alone is not sufficient.

·        Private-key or keystore access alone is not sufficient.

·        Coverage requires suspicious ADC context plus same-asset, same-object, source, interface, rare-egress, downstream application, administrative, or cloud-impact linkage.

·        Approved backup jobs, certificate rotation, key rotation, vendor support, diagnostic collection, packet capture collection, migration, failover testing, troubleshooting, emergency maintenance, and incident-response collection require local baseline validation.

Traffic-Path Manipulation and Administrative-Control Change

This behavior is covered where ADC configuration-change telemetry, administrative audit logs, virtual-service records, backend-pool records, routing-rule records, rewrite-rule records, header-rule records, TLS binding records, persistence-profile records, NAT or ALG records, health-check records, logging-setting records, administrative-user records, API-key records, and downstream application telemetry can be joined to suspicious ADC activity.

Mapped Coverage

·        Splunk, Elastic, QRadar, and SIGMA coverage for virtual-service modification, backend-pool modification, routing-rule modification, rewrite-rule modification, header-rule modification, persistence-profile modification, certificate binding change, TLS offload change, NAT or ALG configuration change, health-check modification, logging-setting modification, administrative-setting modification, API-key creation, administrator creation, or role modification after suspicious ADC activity.

·        NDR / Network Behavioral Analytics supporting coverage where traffic-path changes result in routing deviation, backend selection anomalies, traffic mirroring, header anomalies, TLS behavior changes, unexpected backend access, or downstream traffic shifts.

·        SentinelOne supporting coverage where file, process, command-line, script, diagnostic, service-context, or artifact behavior supports administrative-control change or traffic-path manipulation.

·        Cloud coverage applies only where the ADC traffic-path or administrative-control context is forwarded and can be joined to independently suspicious AWS, Azure, or Google Cloud load-balancer, WAF, DNS, storage, secret, key, logging, compute, identity, or application-delivery activity.

Coverage Qualification

·        A virtual-service change alone is not sufficient.

·        A backend-pool change alone is not sufficient.

·        A routing change alone is not sufficient.

·        A header change alone is not sufficient.

·        A certificate binding change alone is not sufficient.

·        NAT or ALG configuration change alone is not sufficient.

·        An administrator creation event alone is not sufficient.

·        Logging degradation alone is not sufficient.

·        Reliable suspicious ADC context, source continuity, asset continuity, interface continuity, configuration-object lineage, certificate-object lineage, downstream application behavior, network behavior, or cloud-context linkage must exist.

·        Legitimate application deployment, routing changes, certificate rotation, health-check tuning, WAF tuning, NAT or ALG changes, traffic migration, failover testing, change-management activity, vendor support, emergency maintenance, and incident-response workflows require suppression or downgrade when expected context aligns.

Multi-Asset ADC Control-Plane Probing and Campaign-Like Activity

This behavior is covered where related control-plane probing across multiple ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management assets can be correlated through source clustering, forwarded-source clustering, source ASN, user agent, request-family grouping, API-method grouping, parameter-family grouping, timing pattern, exposure class, asset group, and post-access behavior.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage for multi-asset control-plane probing, related suspicious sources, request-family repetition, abnormal timing, exposure-class clustering, rare egress, downstream traffic shifts, and post-access behavior across more than one ADC asset.

·        Splunk, Elastic, QRadar, and SIGMA coverage for related multi-asset control-plane activity where ADC asset ID, asset group, exposure class, criticality, source, forwarded source, user agent, request path, request pattern, status sequence, post-access behavior, and campaign-cluster fields are normalized or enriched.

·        SentinelOne supporting coverage where one or more affected ADC-adjacent hosts show service-context execution, diagnostic activity, artifact access, sensitive file access, or rare egress after clustered control-plane probing.

·        AWS, Azure, and GCP coverage only when multi-asset control-plane probing or resulting post-access behavior can be forwarded into cloud analytics and joined to independently suspicious cloud activity.

Coverage Qualification

·        Multi-asset probing alone is not sufficient.

·        Shared source infrastructure alone is not sufficient.

·        A repeated request path alone is not sufficient.

·        A shared user agent alone is not sufficient.

·        Scanner-like behavior alone is not sufficient.

·        Coverage requires at least one post-access behavior indicator, appliance instability, rare egress, configuration access, certificate access, traffic-path manipulation, administrative-control change, logging degradation, downstream application anomaly, or cloud-impact context.

·        Multi-asset traffic-processing campaign correlation is not claimed as implemented coverage by the current S25 campaign rules. Traffic-processing activity is presently covered through the dedicated per-asset NDR, Splunk, Elastic, QRadar, and SIGMA implementations.

·        Approved enterprise vulnerability scanning, external attack-surface management, vendor advisory validation, patch verification, synthetic monitoring, red-team activity, incident-response sweeps, and exposure reviews require suppression or downgrade when expected context aligns.

Downstream AWS Cloud Activity

This behavior is covered by conditional downstream AWS cloud-impact detection where normalized suspicious ADC context can be joined to independently suspicious AWS activity. Native AWS rules do not independently establish ADC exploitation.

Mapped Coverage

·        AWS coverage for suspicious federated access, IAM Identity Center activity, role assumption, IAM privilege activity, access-key activity, Secrets Manager access, KMS activity, S3 enumeration or access, CloudTrail modification, security-control modification, GuardDuty findings, Security Hub findings, AWS Config activity, Organizations activity, compute changes, network exposure changes, load balancer or WAF modification, Route 53 or DNS modification, snapshot or image export, and administrative events following suspicious ADC context.

·        Splunk, Elastic, and QRadar coverage where AWS logs and ADC context are ingested into the same analytics environment.

·        SIGMA coverage only where target backends can map AWS events into local event-rule templates and perform backend-native correlation.

·        Suspicious ADC traffic-processing activity may serve as upstream AWS correlation context only when it has already been normalized and forwarded from NDR, Splunk, Elastic, QRadar, SIGMA-backed SIEM logic, or another validated analytics source.

Coverage Qualification

·        AWS activity alone is not sufficient.

·        AWS console access alone is not sufficient.

·        IAM activity alone is not sufficient.

·        Role assumption alone is not sufficient.

·        Secrets Manager, KMS, or S3 access alone is not sufficient.

·        Load balancer or WAF modification alone is not sufficient.

·        Reliable AWS account lineage plus workload, identity, source, host, resource, load balancer, WAF, S3, Secrets Manager, KMS, assumed-role, instance, container, ADC asset, virtual-service, backend-pool, or correlation linkage to suspicious ADC context must exist.

·        CloudTrail management events, CloudTrail data events, GuardDuty, Security Hub, AWS Config, AWS Organizations, VPC Flow Logs, Route 53 Resolver logs, WAF logs, ALB/NLB logs, sensitive-resource inventories, access-key novelty tracking, and event ordering determine deployment confidence.

Downstream Azure Control-Plane, Network, and Resource-Access Activity

This behavior is covered by conditional downstream Azure cloud-impact detection where normalized suspicious ADC context can be joined to independently suspicious Azure activity. Native Azure rules do not independently establish ADC exploitation.

Mapped Coverage

·        Azure coverage for Entra ID sign-ins, Entra ID audit events, Azure Activity events, Azure Resource Manager activity, role assignments, service-principal activity, managed-identity activity, Key Vault access, Storage access, logging changes, diagnostic-setting changes, Azure Policy changes, network security changes, Application Gateway changes, Front Door changes, WAF policy changes, App Service changes, VM changes, container workload changes, Defender for Cloud alerts, Sentinel incidents, and sensitive Azure resource access following suspicious ADC context.

·        Splunk, Elastic, and QRadar coverage where Azure logs and ADC context are ingested into the same analytics environment.

·        SIGMA coverage only where target backends can map Azure events into local event-rule templates and perform backend-native correlation.

·        Suspicious ADC traffic-processing activity may serve as upstream Azure correlation context only when it has already been normalized and forwarded from validated network, SIEM, or detection-platform logic.

Coverage Qualification

·        Azure activity alone is not sufficient.

·        Azure portal access alone is not sufficient.

·        Entra ID sign-in activity alone is not sufficient.

·        Role assignment alone is not sufficient.

·        Key Vault access alone is not sufficient.

·        Storage access alone is not sufficient.

·        Application Gateway, Front Door, or WAF modification alone is not sufficient.

·        Reliable tenant and subscription lineage plus workload, identity, source, host, resource, Storage, Key Vault, service-principal, managed-identity, application, Application Gateway, Front Door, WAF policy, ADC asset, virtual-service, backend-pool, or correlation-ID linkage to suspicious ADC context must exist.

·        Azure Activity logs, Entra ID logs, Key Vault logging, Storage logging, Defender for Cloud, Sentinel, Network Security Group flow logs, Azure Firewall logs, Application Gateway logs, Front Door logs, WAF logs, diagnostic visibility, sensitive-resource inventories, managed-identity novelty tracking, and event ordering determine deployment confidence.

Downstream GCP Cloud Activity

This behavior is covered by conditional downstream Google Cloud-impact detection where normalized suspicious ADC context can be joined to independently suspicious Google Cloud activity. Native GCP rules do not independently establish ADC exploitation.

Mapped Coverage

·        GCP coverage for suspicious Google Cloud Admin Activity, Data Access activity, IAM policy changes, role changes, service-account activity, service-account credential activity, service-account impersonation, workload identity federation, workforce identity federation, Cloud Storage access, Secret Manager access, Cloud KMS activity, logging changes, monitoring changes, Security Command Center findings, Security Command Center suppression, network exposure changes, load balancer modification, Cloud Armor modification, DNS modification, compute changes, GKE changes, Cloud Run changes, App Engine changes, project administration, organization administration, and sensitive resource access following suspicious ADC context.

·        Splunk, Elastic, and QRadar coverage where Google Cloud audit logs and ADC context are ingested into the same analytics environment.

·        SIGMA coverage only where target backends can map Google Cloud events into local event-rule templates and perform backend-native correlation.

·        Suspicious ADC traffic-processing activity may serve as upstream Google Cloud correlation context only when it has already been normalized and forwarded from validated network, SIEM, or detection-platform logic.

Coverage Qualification

·        Google Cloud activity alone is not sufficient.

·        Google Cloud console access alone is not sufficient.

·        Service-account activity alone is not sufficient.

·        Cloud Storage, Secret Manager, or Cloud KMS access alone is not sufficient.

·        Load balancer or Cloud Armor modification alone is not sufficient.

·        Reliable organization and project lineage plus workload, identity, source, host, resource, Cloud Storage, Secret Manager, KMS, service-account, workload-identity, load balancer, Cloud Armor, ADC asset, virtual-service, backend-pool, or correlation-ID linkage to suspicious ADC context must exist.

·        Data Access logging, Cloud Storage logging, Secret Manager logging, Cloud KMS visibility, Cloud Identity telemetry, Security Command Center context, Chronicle enrichment, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, audit coverage, service-account baseline quality, sensitive-resource inventories, and event ordering determine deployment confidence.

NDR / Network Behavioral Analytics Coverage Disposition

NDR / Network Behavioral Analytics provides primary network-behavior and sequence coverage for suspicious ADC control-plane access and suspicious per-asset traffic-processing activity, including subsequent appliance instability, rare egress, traffic-path effects, downstream application exposure, and downstream cloud context where correlated.

Coverage may include suspicious management/API access, unusual source infrastructure, abnormal request behavior, protocol anomalies, listener or virtual-service targeting, malformed or oversized traffic, control-plane-to-instability sequencing, traffic-processing-to-instability sequencing, control-plane-to-egress sequencing, rare destination access, new or rare domains, unusual egress ports, suspicious destination reputation, proxy anomalies, firewall anomalies, multi-asset control-plane probing, hosted application traffic shifts, or cloud access paths.

NDR cannot independently prove ADC exploitation, appliance command execution, configuration theft, certificate theft, credential theft, administrative compromise, AWS compromise, Azure compromise, Google Cloud compromise, downstream cloud compromise, downstream application compromise, or data theft without appliance, web, endpoint, configuration, certificate, administrative, cloud, downstream application, or SIEM-forwarded context.

SIGMA Coverage Disposition

SIGMA provides portable event-rule template coverage for suspicious ADC control-plane access, backend-correlated per-asset traffic-processing exploitation, appliance instability, rare ADC egress, configuration access, certificate access, backup export, diagnostic artifact access, traffic-path manipulation, administrative-control change, multi-asset control-plane probing, and downstream application behavior.

SIGMA should not be treated as a complete backend-independent sequence-correlation layer for this report. Local field mapping, enrichment-field creation, backend conversion, exception validation, and SIEM-native correlation are required.

SIGMA event rules support traceability for control-plane-to-instability, control-plane-to-egress, control-plane-to-configuration-access, control-plane-to-certificate-access, control-plane-to-traffic-path-change, per-asset traffic-processing-to-instability, and multi-asset-control-plane-probing-to-post-access behavior. The target backend must implement the required temporal and same-asset correlation.

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report's detection model is behavioral, sequence-based, network- and protocol-aware, control-plane and traffic-processing driven, appliance-context based, SIEM-correlation based, egress-correlation based, configuration-change based, certificate-object based, and downstream-impact based rather than static-file, malware-signature, or artifact-matching based.

YARA may provide limited supporting value only if a confirmed malicious appliance artifact, webshell body, encoded payload, loader, dropper, script artifact, archive artifact, memory artifact, configuration implant, certificate-theft artifact, credential-harvesting artifact, diagnostic-bundle payload, or reusable malware family artifact is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

Coverage Gaps and Non-Coverage Conditions

The S25 rule set does not directly prove ADC exploitation, appliance command execution, memory corruption, configuration theft, certificate theft, credential theft, administrative compromise, traffic-path manipulation, AWS compromise, Azure compromise, Google Cloud compromise, downstream cloud compromise, downstream application compromise, or data theft by itself.

Coverage Weakens Under the Following Conditions

·        ADC management/API, traffic-processing, protocol, WAF, reverse-proxy, CDN, load-balancer, gateway, appliance syslog, administrative audit, configuration-change, certificate-management, or access telemetry is unavailable, delayed, truncated, or not retained.

·        ADC assets are not consistently tagged by asset ID, management interface, traffic-facing interface, listener, virtual service, protocol, processing function, vendor, backend pool, backend host, workload, tenant, account, subscription, project, exposure state, or business criticality.

·        ADC management/API surfaces, control-plane paths, listeners, protocol handlers, virtual services, NAT or ALG functions, Progress Kemp LoadMaster /accessv2 paths where locally relevant, protected configuration objects, certificate objects, backup objects, and diagnostic objects are not maintained.

·        URI paths, query strings, HTTP method, user agent, content type, request size, response size, HTTP status, source IP, forwarded source IP, protocol, listener, message size, connection state, timing fields, appliance-health events, service faults, or traffic-processing fault fields are unavailable or not normalized.

·        Source attribution is unstable or hidden behind VPN, proxy, NAT, CDN, partner, scanner, managed-service, or validation infrastructure.

·        Control-plane-to-instability, traffic-processing-to-instability, control-plane-to-egress, control-plane-to-configuration-access, control-plane-to-certificate-access, control-plane-to-traffic-path-change, multi-asset control-plane, or downstream cloud correlation windows are not tuned.

·        Multi-asset traffic-processing campaign correlation is not presently implemented as a dedicated S25 campaign rule and therefore should not be assumed from the per-asset traffic-processing detections.

·        Endpoint or EDR telemetry from ADC appliances, ADC-adjacent hosts, jump hosts, management hosts, support hosts, or protected backend workloads is unavailable, incomplete, delayed, or not mapped to ADC asset context.

·        File, process, command-line, parent-process, service-context, diagnostic, backup, certificate, key, keystore, API-token, packet-capture, or appliance artifact telemetry is unavailable.

·        Sensitive ADC configuration objects, certificate objects, private-key material, credential-bearing artifacts, backup patterns, diagnostic bundle patterns, packet-capture patterns, suspicious command patterns, shell interpreter lists, scripting interpreter lists, transfer-tool patterns, and archive-tool patterns are missing or stale.

·        DNS, proxy, firewall, NDR, destination reputation, destination first-seen, domain age, ASN, geography, destination port, protocol, or flow telemetry is unavailable or not joined to ADC asset context.

·        Virtual-service changes, backend-pool changes, routing changes, rewrite-rule changes, header-rule changes, persistence-profile changes, NAT or ALG changes, TLS offload changes, certificate binding changes, health-check changes, logging-setting changes, administrator creation, API-key creation, role modification, or downstream application behavior is unavailable or not normalized.

·        Approved administrator sources, protocol sources, scanners, vendor support sources, managed-service sources, monitoring systems, validation sources, backup workflows, certificate-rotation workflows, diagnostic workflows, patch workflows, maintenance windows, load-test windows, failover-test windows, change windows, incident-response windows, approved process baselines, approved file paths, approved command patterns, and approved egress destinations are not tightly scoped.

·        Cloud telemetry or ADC-to-cloud workload, identity, source, host, resource, load balancer, WAF, storage, secret, KMS, service-account, managed-identity, role, account, subscription, project, organization, or correlation mapping is incomplete or unreliable.

·        Traffic-processing exploitation context is not forwarded or normalized into cloud analytics when downstream AWS, Azure, or Google Cloud correlation is required.

·        Adversary activity blends into approved administrative, traffic-processing, diagnostic, backup, certificate-rotation, patch, failover, migration, vendor-support, managed-service, monitoring, scanner, load-testing, security-tooling, incident-response, or emergency-maintenance workflows.

·        Exploitation produces no observable control-plane anomaly, traffic-processing anomaly, appliance instability, rare egress, configuration access, certificate access, backup export, diagnostic export, traffic-path change, administrative-control change, logging degradation, downstream application exposure, or downstream cloud activity.

Traceability Conclusion

The S25 detection set provides broad behavior-led coverage across suspicious ADC control-plane access, suspicious per-asset traffic-processing activity, appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, multi-asset control-plane probing, downstream application exposure, and downstream AWS, Azure, and Google Cloud activity.

Coverage is strongest where management/API behavior or suspicious per-asset traffic-processing activity can be correlated to materially independent appliance, service-health, configuration, certificate, egress, administrative, availability, downstream application, or cloud behavior. Multi-asset traffic-processing campaign coverage is not claimed until the corresponding S25 campaign rules are modernized.

The rule set intentionally avoids treating CVE labels, vendor names, appliance names, exploit names, static payload strings, single request paths, isolated source IPs, malformed traffic, protocol anomalies, isolated crashes, vulnerable configurations, scanner signatures, campaign names, actor branding, or other single-event observations as proof of compromise.

S27 Behavior & Log Artifacts

Purpose

This section identifies the primary behavior and log artifacts that support detection, investigation, triage, and validation for suspicious ADC control-plane access; suspicious traffic-processing activity; appliance instability; rare ADC-originated egress; configuration access; certificate or TLS-object access; backup or diagnostic export; virtual-service modification; backend-pool modification; routing, header, persistence, NAT, ALG, TLS, or logging change; administrative-control change; multi-asset control-plane probing; downstream application exposure; and downstream cloud-impact activity.

The artifacts below are behavior-led. They should not be treated as proof of ADC exploitation, appliance command execution, memory corruption, configuration theft, certificate theft, credential theft, administrative compromise, traffic-path manipulation, downstream application compromise, AWS compromise, Azure compromise, Google Cloud compromise, downstream cloud compromise, or data theft unless they are correlated into a coherent sequence.

Primary Artifact Categories

·        ADC management/API, administrative, diagnostic, authentication, telemetry, configuration, and control-plane request artifacts.

·        ADC listener, virtual-service, protocol-handler, NAT, ALG, protocol, message-size, transaction, connection-state, traffic-processing, and network-flow artifacts.

·        Appliance health, service fault, API handler, authentication handler, protocol-handler, watchdog, restart, reboot, failover, resource exhaustion, and abnormal connection-state artifacts.

·        Configuration object, backup, diagnostic bundle, packet capture, certificate object, TLS object, private-key, keystore, API-token, and credential-bearing artifact-access artifacts.

·        Virtual-service, backend-pool, routing-rule, rewrite-rule, header-rule, persistence-profile, NAT, ALG, TLS offload, certificate-binding, health-check, logging-setting, administrative-setting, API-key, administrator, and role-change artifacts.

·        DNS, proxy, firewall, NDR, rare-destination, destination-reputation, first-seen, domain-age, ASN, geography, protocol, destination-port, and ADC-originated egress artifacts.

·        Multi-asset control-plane probing, source-cluster, request-family, exposure-class, asset-group, campaign-cluster, and post-access behavior artifacts.

·        Downstream AWS, Azure, and Google Cloud activity artifacts following suspicious ADC context, including forwarded traffic-processing context where available and appropriately normalized.

·        ADC asset, management interface, traffic-facing interface, listener, virtual service, protocol, processing function, backend pool, backend host, workload, source, forwarded source, path, object, destination, cloud principal, resource, and event-timestamp correlation artifacts.

ADC Control-Plane Access and Request-Handling Artifacts

Relevant Artifacts

ADC asset ID, ADC asset name, edge asset flag, appliance role, management interface, virtual service, backend pool, backend host, HTTP method, request path, request query, full URL, source IP, forwarded source IP, source ASN, source geography, source network type, user agent, content type, request size, response size, HTTP status, request timing, request burst behavior, management/API surface family, administrative route, diagnostic route, authentication route, telemetry route, configuration route, control-plane route, suspicious payload pattern, command-delimiter pattern, shell-control pattern, malformed JSON pattern, oversized API field, authentication-bypass pattern, API parameter manipulation, Progress Kemp LoadMaster /accessv2 surface where locally visible, and event timestamp.

Useful Log Sources

·        ADC management/API logs.

·        Appliance syslog.

·        Administrative audit logs.

·        WAF logs.

·        Reverse-proxy logs.

·        CDN logs.

·        Load-balancer logs.

·        Gateway logs.

·        Web server logs where ADC-adjacent.

·        Firewall logs.

·        DNS logs.

·        Proxy logs.

·        NDR / Network Behavioral Analytics telemetry.

·        SIEM-normalized ADC telemetry.

·        ADC asset inventory.

·        Management-interface inventory.

·        Virtual-service inventory.

·        Backend-pool inventory.

Detection Use

These artifacts support detection when suspicious ADC control-plane, management/API, administrative, diagnostic, authentication, telemetry, or configuration access is joined with abnormal source context, abnormal request timing, suspicious request patterns, unusual request size, abnormal response size, abnormal status sequence, appliance instability, configuration access, certificate access, rare egress, traffic-path manipulation, administrative-control change, multi-asset control-plane probing, downstream application exposure, or downstream cloud activity.

Investigation Use

Investigators should determine whether management/API access is expected for the ADC asset, administrator, source IP, forwarded source IP, ASN, geography, user agent, route, request method, request timing, maintenance state, vendor-support workflow, managed-service workflow, monitoring workflow, scanner activity, validation workflow, patch workflow, backup workflow, or business process. They should also review whether the activity is followed by appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, downstream application behavior, or downstream cloud activity.

Non-Coverage Conditions

A single management/API request does not prove exploitation. A single /accessv2 request does not prove compromise. A single source IP, forwarded source IP, user-agent value, status code, request path, request size, or vendor-specific route is not sufficient. These artifacts require correlation with same-asset context, same-management-interface context, source context, request-family lineage, appliance-health lineage, configuration-object lineage, certificate-object lineage, egress behavior, administrative-control behavior, downstream application behavior, or downstream cloud activity.

ADC Traffic-Processing and Protocol Artifacts

Relevant Artifacts

ADC asset ID, traffic-facing interface, destination IP, destination port, listener, virtual service, protocol, application protocol, protocol handler, traffic-processing function, NAT function, ALG function, source IP, source port, source ASN, source geography, source network type, request or message size, packet or payload size where available, protocol method, transaction identifier, session identifier, message sequence, transaction sequence, malformed-field indicator, protocol-inconsistency indicator, abnormal transaction indicator, fuzzing-like pattern, repeated-invalid-request pattern, request cadence, retransmission behavior, connection reset, timeout, service-unavailable state, backend mapping, and event timestamp.

Where locally applicable to CVE-2026-19489, relevant enrichment may include SIP signaling metadata, SIP listener or destination mapping, SIP ALG enabled state, LSN configuration, LSN group membership, and mapping between LSN-managed traffic and the affected ADC asset.

Useful Log Sources

·        NDR / Network Behavioral Analytics telemetry.

·        Packet metadata or packet-capture telemetry where permitted.

·        Network flow telemetry.

·        Firewall logs.

·        ADC listener logs.

·        Virtual-service logs.

·        Load-balancer logs.

·        Reverse-proxy logs.

·        WAF logs.

·        Gateway logs.

·        Protocol-specific appliance logs where available.

·        ADC system and traffic-processing logs.

·        NAT or LSN configuration records where applicable.

·        ALG configuration records where applicable.

·        SIEM-normalized network and protocol telemetry.

·        ADC listener, virtual-service, protocol, and traffic-processing inventories.

Detection Use

These artifacts support detection when suspicious, malformed, oversized, abnormal, repeated, or protocol-inconsistent traffic reaches an exposed ADC traffic-processing function and is followed by materially independent appliance instability, service-health degradation, restart, failover, resource exhaustion, abnormal connection behavior, availability degradation, or downstream application impact.

Investigation Use

Investigators should determine whether observed protocol traffic is expected for the listener, virtual service, processing function, source population, client type, transaction pattern, message size, request cadence, maintenance state, load-testing activity, protocol-validation activity, vendor-support workflow, or business application. They should review whether suspicious traffic aligns with process or service faults, watchdog activity, restart or failover behavior, resource pressure, connection disruption, downstream application availability, or other independent evidence.

For CVE-2026-19489-specific review, investigators should determine whether the affected asset had the relevant SIP ALG and LSN configuration and whether suspicious SIP signaling aligns temporally with appliance-health or availability effects.

Non-Coverage Conditions

Malformed traffic alone does not prove exploitation. A SIP message alone does not prove compromise. A protocol anomaly, oversized request, repeated transaction, timeout, reset, enabled SIP ALG, configured LSN group, or vulnerable processing function alone is not sufficient. These artifacts require same-asset, same-listener, same-virtual-service, same-protocol, processing-function, source, health-event, availability, or bounded-time correlation before they become compromise-oriented evidence.

Appliance Instability and Health Artifacts

Relevant Artifacts

Watchdog restart, process crash, service crash, service restart, appliance reboot, management-service fault, API handler exception, authentication-handler error, protocol-handler fault, traffic-processing fault, failover event, HA transition, resource exhaustion, resource pressure, high CPU, memory pressure, abnormal connection state, timeout, reset, closed-after-error event, service-unavailable response, repeated errors, abnormal status or connection sequence, appliance health event, management daemon log, protocol daemon log, system log, process crash log, restart timestamp, failover peer, cluster member, HA role, and event timestamp.

Useful Log Sources

·        Appliance syslog.

·        ADC health logs.

·        Management-service logs.

·        API service logs.

·        Authentication-service logs.

·        Traffic-processing or protocol-service logs.

·        Failover or HA logs.

·        Load-balancer logs.

·        Gateway logs.

·        NDR / Network Behavioral Analytics telemetry.

·        Firewall logs.

·        Proxy logs.

·        SIEM-normalized appliance-health telemetry.

·        Vendor-support or diagnostic records where available.

Detection Use

These artifacts support detection when appliance instability occurs after suspicious ADC control-plane or traffic-processing activity. They are strongest when tied to same-asset continuity, source or interface continuity, request or protocol lineage, abnormal status or connection sequencing, rare egress, configuration access, certificate access, or traffic-path manipulation.

Investigation Use

Investigators should determine whether appliance instability is expected for patching, failover testing, health-check tuning, vendor support, maintenance, monitoring, backup, load testing, diagnostic collection, configuration change, capacity pressure, known device defect, or incident-response activity. They should review whether instability follows suspicious control-plane or traffic-processing activity and whether it is followed by rare egress, protected-object access, administrative-control change, downstream application anomalies, or cloud activity.

Non-Coverage Conditions

Appliance instability alone is not sufficient. A reboot alone is not sufficient. A failover event alone is not sufficient. A service fault alone is not sufficient. A timeout or reset sequence alone is not sufficient. These artifacts require preceding suspicious ADC activity plus same-asset, source, interface, listener, request-family, protocol, traffic-processing, egress, configuration, administrative, or downstream-impact context.

Configuration, Backup, Diagnostic, Certificate, and Credential-Material Artifacts

Relevant Artifacts

Protected configuration object, configuration read, configuration export, configuration download, configuration create, configuration modify, configuration delete, configuration replace, backup creation, backup export, backup download, diagnostic bundle creation, diagnostic export, diagnostic download, packet capture creation, packet capture read, packet capture export, certificate object, TLS object, certificate read, certificate export, certificate download, certificate binding, certificate unbinding, certificate modification, private-key access, keystore access, API-token access, credential-bearing file access, SAML material access, OIDC material access, file path, file name, object name, object ID, administrator identity, source IP, management interface, and event timestamp.

Useful Log Sources

·        ADC management/API logs.

·        Administrative audit logs.

·        Configuration-change records.

·        Certificate-management logs.

·        Backup logs.

·        Diagnostic bundle logs.

·        Packet-capture logs.

·        Appliance syslog.

·        Endpoint or support-host telemetry where available.

·        File-integrity monitoring where applicable.

·        SentinelOne endpoint telemetry where ADC-adjacent.

·        SIEM-normalized configuration and artifact telemetry.

Detection Use

These artifacts support detection when protected ADC configuration, certificate, private-key, backup, diagnostic, packet-capture, API-token, or credential-bearing material is accessed after suspicious ADC activity. They are useful for identifying likely configuration exposure, certificate theft, credential-material access, staging, diagnostic misuse, and post-access appliance impact.

Investigation Use

Investigators should determine whether protected-object access is expected for the ADC asset, administrator, vendor-support workflow, backup workflow, certificate rotation, key rotation, migration, failover testing, troubleshooting, monitoring, patching, emergency maintenance, or incident-response collection. They should review whether access occurred after suspicious ADC activity and whether it was followed by rare egress, traffic-path manipulation, administrative-control change, downstream application exposure, or cloud activity.

Non-Coverage Conditions

Configuration access alone is not sufficient. Backup creation alone is not sufficient. Diagnostic bundle creation alone is not sufficient. Packet-capture creation alone is not sufficient. Certificate access alone is not sufficient. Private-key or keystore access alone is not sufficient. These artifacts require suspicious ADC context plus same-asset, same-source, same-object, interface, rare-egress, downstream application, administrative, or cloud-impact linkage.

Traffic-Path and Administrative-Control Artifacts

Relevant Artifacts

Virtual-service modification, backend-pool modification, backend-host change, routing-rule modification, rewrite-rule modification, header-rule modification, header removal, header addition, header rewrite, forwarded-for anomaly, host-header anomaly, persistence-profile modification, health-check modification, NAT configuration change, ALG configuration change, TLS offload change, certificate-binding change, unexpected plaintext backend flow, logging-setting modification, administrative-setting modification, administrator creation, admin-role modification, API-key creation, API-key modification, API-key deletion, traffic mirroring, unexpected route, unexpected backend selection, authentication-flow change, session-routing change, downstream application behavior, and event timestamp.

Useful Log Sources

·        ADC management/API logs.

·        Administrative audit logs.

·        Configuration-change records.

·        Virtual-service records.

·        Backend-pool records.

·        Routing-rule records.

·        Rewrite-rule records.

·        Header-rule records.

·        NAT and ALG configuration records where applicable.

·        TLS binding records.

·        Certificate-management records.

·        WAF logs.

·        Reverse-proxy logs.

·        CDN logs.

·        Load-balancer logs.

·        Downstream application logs.

·        NDR / Network Behavioral Analytics telemetry.

·        SIEM-normalized ADC and application telemetry.

Detection Use

These artifacts support detection when traffic-path changes, administrative-control changes, or downstream application behavior occur after suspicious ADC activity. They are useful for identifying application-delivery manipulation, traffic redirection, header tampering, TLS-path changes, backend exposure, logging degradation, unauthorized administrative access, or protected application impact.

Investigation Use

Investigators should determine whether traffic-path or administrative activity is expected for the application, ADC asset, virtual service, backend pool, NAT or ALG configuration, certificate rotation, routing change, WAF tuning, TLS migration, deployment workflow, change window, vendor support, managed-service activity, failover testing, troubleshooting, emergency maintenance, or incident-response workflow. They should review whether the activity follows suspicious ADC behavior and whether it causes backend selection anomalies, traffic mirroring, header anomalies, downstream application behavior, rare egress, or cloud activity.

Non-Coverage Conditions

A virtual-service change alone is not sufficient. A backend-pool change alone is not sufficient. A routing change alone is not sufficient. A header change alone is not sufficient. A certificate binding change alone is not sufficient. NAT or ALG configuration change alone is not sufficient. Administrator creation alone is not sufficient. Logging degradation alone is not sufficient. These artifacts require suspicious ADC context plus source, asset, interface, configuration-object, downstream application, network, or cloud-context linkage.

Rare Egress and Suspicious Destination Artifacts

Relevant Artifacts

Destination domain, destination IP, destination port, destination reputation, destination first-seen status, destination domain age, destination ASN, destination geography, network protocol, unusual protocol indicator, proxy action, firewall action, DNS query, NDR flow, ADC source host, ADC source IP, ADC private IP, ADC public IP, appliance asset ID, management interface, traffic-facing interface, workload ID, destination baseline, egress baseline, egress timing, and event timestamp.

Useful Log Sources

·        DNS logs.

·        Proxy logs.

·        Firewall logs.

·        NDR / Network Behavioral Analytics telemetry.

·        ADC network logs.

·        Appliance syslog.

·        EDR network telemetry where ADC-adjacent.

·        SentinelOne telemetry where ADC-adjacent.

·        VPC or cloud flow logs where applicable.

·        SIEM-normalized egress telemetry.

Detection Use

These artifacts support detection when rare or suspicious outbound communication occurs after suspicious ADC control-plane activity, suspicious traffic-processing activity, appliance instability, configuration access, certificate access, backup export, diagnostic export, or traffic-path manipulation. They are useful for identifying callback behavior, staging activity, command-and-control-like behavior, exfiltration paths, vendor-support impersonation, and downstream cloud access paths.

Investigation Use

Investigators should determine whether the destination is expected for vendor support, update retrieval, license validation, telemetry, monitoring, backup, DNS, NTP, syslog, managed-service operations, security tooling, vulnerability validation, incident-response activity, or approved business processes. They should review destination age, reputation, ASN, geography, port, protocol, proxy action, firewall action, timing, and ADC asset lineage.

Non-Coverage Conditions

Rare egress alone is not sufficient. A suspicious destination alone is not sufficient. Destination reputation alone is not sufficient. New domain age alone is not sufficient. Unusual destination port alone is not sufficient. These artifacts require suspicious ADC or materially independent appliance, configuration, certificate, endpoint, downstream application, or cloud-impact context.

Multi-Asset ADC Control-Plane Probing and Campaign-Cluster Artifacts

Relevant Artifacts

Related asset count, related asset-group count, related exposure-class count, high or critical asset in cluster, source cluster, forwarded-source cluster, source ASN, source network type, source geography, user agent, request-path family, API-method family, parameter family, timing pattern, failed-then-success sequence, abnormal status sequence, control-plane surface, management/API surface, post-access behavior indicator, appliance-health event, rare egress, configuration access, certificate access, traffic-path change, downstream application behavior, and event timestamp.

Useful Log Sources

·        ADC management/API logs.

·        WAF logs.

·        Reverse-proxy logs.

·        CDN logs.

·        Load-balancer logs.

·        Gateway logs.

·        Appliance syslog.

·        NDR / Network Behavioral Analytics telemetry.

·        DNS logs.

·        Proxy logs.

·        Firewall logs.

·        SIEM-normalized ADC telemetry.

·        Asset inventory.

·        External attack-surface management telemetry where available.

Detection Use

These artifacts support detection when related control-plane probing appears across multiple ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management assets and at least one affected asset shows post-access behavior. They are useful for identifying coordinated targeting, exposure review, opportunistic exploitation attempts, and campaign-like activity across application-delivery infrastructure.

Per-asset traffic-processing artifacts remain separately useful for identifying protocol-processing exploitation, but the current S25 campaign-rule implementation should not be represented as providing multi-asset traffic-processing campaign correlation.

Investigation Use

Investigators should determine whether the activity is explained by approved enterprise vulnerability scanning, vendor advisory validation, patch verification, synthetic monitoring, health checks, red-team activity, managed-service review, incident-response sweeps, or exposure management. They should review whether clustered control-plane activity produces appliance instability, rare egress, configuration access, certificate access, traffic-path manipulation, administrative-control change, downstream application exposure, or cloud activity.

Non-Coverage Conditions

Multi-asset probing alone is not sufficient. Shared source infrastructure alone is not sufficient. Repeated request paths alone are not sufficient. A shared user agent alone is not sufficient. Scanner-like behavior alone is not sufficient. These artifacts require post-access behavior, appliance instability, rare egress, configuration access, certificate access, traffic-path manipulation, administrative-control change, downstream application anomaly, or cloud-impact context.

Downstream AWS Cloud Artifacts

Relevant Artifacts

CloudTrail management event, CloudTrail data event, IAM Identity Center activity, role assumption, IAM policy change, access-key creation, access-key use, Secrets Manager access, KMS activity, S3 access, S3 enumeration, CloudTrail modification, CloudWatch logging change, GuardDuty finding, Security Hub finding, AWS Config change, Organizations activity, compute change, network exposure change, load balancer modification, WAF modification, Route 53 modification, snapshot export, image export, principal ARN, role ARN, account ID, region, resource ID, resource ARN, load balancer ARN, WAF web ACL ID, S3 bucket, secret ID, KMS key ID, source IP, user agent, event name, and event timestamp.

Useful Log Sources

·        AWS CloudTrail management events.

·        AWS CloudTrail data events.

·        IAM Identity Center logs.

·        GuardDuty.

·        Security Hub.

·        AWS Config.

·        AWS Organizations logs.

·        VPC Flow Logs.

·        Route 53 Resolver logs.

·        WAF logs.

·        ALB access logs.

·        NLB flow logs.

·        S3 access logs where applicable.

·        Secrets Manager logs.

·        KMS logs.

·        SIEM-normalized AWS telemetry.

·        SIEM-forwarded ADC cloud context.

Detection Use

These artifacts support downstream AWS cloud-impact detection only when normalized suspicious ADC context is present and AWS activity is independently suspicious. Traffic-processing exploitation can contribute upstream context only when that context has already been correlated, normalized, and forwarded into the cloud or SIEM analytics layer.

Investigation Use

Investigators should determine whether AWS activity aligns to the same AWS account, workload, host, source IP, assumed role, instance, container, load balancer, WAF resource, S3 bucket, secret, KMS key, resource, ADC asset, virtual service, backend pool, or equivalent normalized cloud lineage tied to the ADC context. They should also review whether activity involves high-risk events, access-key novelty, sensitive resources, secrets access, KMS activity, S3 activity, logging changes, security-control modification, load balancer or WAF modification, DNS changes, or administrative changes.

Non-Coverage Conditions

AWS activity alone is not sufficient. AWS console access alone is not sufficient. IAM activity alone is not sufficient. Role assumption alone is not sufficient. Secrets Manager, KMS, or S3 access alone is not sufficient. Load balancer or WAF modification alone is not sufficient. Cloud-only anomalies must not be attributed to ADC exploitation, appliance compromise, traffic-path manipulation, or downstream compromise unless reliable upstream ADC context and workload, source, identity, or resource-lineage correlation exist.

Downstream Azure Cloud Artifacts

Relevant Artifacts

Azure Activity event, Entra ID sign-in activity, Entra ID audit activity, Azure Resource Manager activity, role assignment, service-principal activity, managed-identity activity, Key Vault access, Storage access, Defender for Cloud alert, Sentinel incident, Azure Policy change, diagnostic-setting change, logging change, network security change, Application Gateway activity, Front Door activity, WAF policy activity, Azure Firewall activity, Network Security Group flow activity, App Service activity, VM activity, container workload activity, tenant ID, subscription ID, resource group, resource ID, application ID, service principal ID, managed identity ID, Application Gateway ID, Front Door profile ID, WAF policy ID, source IP, user agent, correlation ID, and event timestamp.

Useful Log Sources

·        Azure Activity logs.

·        Entra ID sign-in logs.

·        Entra ID audit logs.

·        Azure Resource Manager activity.

·        Azure Key Vault logs.

·        Azure Storage logs.

·        Defender for Cloud.

·        Microsoft Sentinel.

·        Azure Policy logs.

·        Azure diagnostic-setting logs.

·        Azure Firewall logs.

·        Network Security Group flow logs.

·        Application Gateway logs.

·        Front Door logs.

·        WAF logs.

·        SIEM-normalized Azure telemetry.

·        SIEM-forwarded ADC Azure context.

Detection Use

These artifacts support downstream Azure cloud-impact detection only when normalized suspicious ADC context is present and Azure activity is independently suspicious. Traffic-processing exploitation can contribute upstream context only when it has already been correlated, normalized, and forwarded into the cloud or SIEM analytics layer.

Investigation Use

Investigators should determine whether Azure activity aligns to the same tenant, subscription, resource group, resource, VM, App Service, container workload, application, service principal, managed identity, source IP, Storage account, Key Vault, Application Gateway, Front Door profile, WAF policy, correlation ID, ADC asset, virtual service, backend pool, or equivalent normalized cloud lineage tied to the ADC context. They should also review whether activity involves role changes, Key Vault access, Storage access, diagnostic logging changes, security-control changes, policy changes, service-principal changes, managed-identity activity, Application Gateway changes, Front Door changes, WAF changes, Defender alerts, or Sentinel incidents.

Non-Coverage Conditions

Azure activity alone is not sufficient. Azure portal access alone is not sufficient. Entra ID sign-in activity alone is not sufficient. Role assignment alone is not sufficient. Key Vault access alone is not sufficient. Storage access alone is not sufficient. Application Gateway, Front Door, or WAF modification alone is not sufficient. Cloud-only anomalies must not be attributed to ADC exploitation, appliance compromise, traffic-path manipulation, or downstream compromise unless reliable upstream ADC context and workload, source, identity, or resource-lineage correlation exist.

Downstream GCP Cloud Artifacts

Relevant Artifacts

Google Cloud Admin Activity, Data Access activity, IAM policy change, role binding, service-account key creation, service-account impersonation, service-account use, workload identity federation activity, workforce identity federation activity, Cloud Storage access, Secret Manager access, Cloud KMS activity, logging sink modification, monitoring change, audit logging modification, Security Command Center finding, Security Command Center suppression, firewall rule change, public exposure change, load balancer modification, Cloud Armor modification, DNS change, project administration, organization administration, principal email, Google account ID, service account ID, workload identity subject, organization ID, folder ID, project ID, resource name, method name, load balancer name, Cloud Armor policy name, storage bucket name, secret name, KMS key name, source IP, user agent, and event timestamp.

Useful Log Sources

·        Google Cloud Admin Activity audit logs.

·        Google Cloud Data Access audit logs.

·        Google Cloud IAM logs.

·        Google Cloud service-account logs.

·        Cloud Storage logs.

·        Secret Manager logs.

·        Cloud KMS logs.

·        Cloud Identity logs.

·        Security Command Center.

·        Cloud Logging.

·        VPC Flow Logs.

·        Cloud DNS logs.

·        Cloud Armor logs.

·        External Application Load Balancer logs.

·        Chronicle or SIEM-normalized Google Cloud telemetry.

·        SIEM-forwarded ADC GCP context.

Detection Use

These artifacts support downstream Google Cloud-impact detection only when normalized suspicious ADC context is present and Google Cloud activity is independently suspicious. Traffic-processing exploitation can contribute upstream context only when it has already been correlated, normalized, and forwarded into the cloud or SIEM analytics layer.

Investigation Use

Investigators should determine whether Google Cloud activity aligns to the same organization, folder, project, resource, Compute instance, GKE cluster, Cloud Run service, App Engine service, service account, workload identity, source IP, load balancer, Cloud Armor policy, Cloud Storage bucket, Secret Manager secret, KMS key, correlation ID, ADC asset, virtual service, backend pool, or equivalent normalized cloud lineage tied to the ADC context. They should also review whether activity involves IAM changes, service-account credential novelty, Cloud Storage access, Secret Manager access, Cloud KMS activity, logging changes, Cloud Armor changes, load-balancer changes, Security Command Center findings, project administration, or organization administration.

Non-Coverage Conditions

Google Cloud activity alone is not sufficient. Google Cloud console access alone is not sufficient. Service-account activity alone is not sufficient. Cloud Storage, Secret Manager, or Cloud KMS access alone is not sufficient. Load balancer or Cloud Armor modification alone is not sufficient. Cloud-only anomalies must not be attributed to ADC exploitation, appliance compromise, traffic-path manipulation, or downstream compromise unless reliable upstream ADC context and workload, source, identity, or resource-lineage correlation exist.

YARA Artifact Disposition

YARA has no deployable primary-rule artifact set for this EXP report.

YARA is not viable as a primary artifact model because the report's detection surface is behavioral, sequence-based, control-plane and traffic-processing driven, network- and protocol-aware, SIEM-correlation based, appliance-context based, egress-correlation based, configuration-change based, certificate-object based, and downstream-impact based rather than static-file, malware-signature, or artifact-matching based.

YARA may become useful only if a confirmed malicious appliance artifact, webshell body, encoded payload, loader, dropper, script artifact, archive artifact, memory artifact, configuration implant, certificate-theft artifact, credential-harvesting artifact, diagnostic-bundle payload, or reusable malware family artifact is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

S28 Detection Strategy and SOC Implementation Guidance

Figure 5

Purpose

This section provides implementation guidance for operationalizing the S25 rule set and S26 traceability model across ADC management/API telemetry, traffic-processing and protocol telemetry, appliance syslog, NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, GCP, WAF, reverse-proxy, CDN, load-balancer, gateway, endpoint, EDR, DNS, proxy, firewall, SIEM, SOAR, and incident-response environments.

The detection strategy is sequence-based. It prioritizes correlated behavior over single-event alerting and avoids treating a single CVE label, vendor name, appliance name, exploit name, request path, protocol anomaly, source IP, user agent, payload string, command string, scanner hit, vulnerable-version observation, configuration event, certificate event, rare destination, cloud event, crash, failover event, or static indicator as proof of compromise.

Implementation Strategy

Deploy the detection model in layered stages:

·        ADC asset ID, edge asset status, management interface, traffic-facing interface, listener, virtual service, backend pool, backend host, workload, vendor, exposure context, and business criticality first.

·        ADC management/API surface, administrative route, diagnostic route, authentication route, telemetry route, configuration route, request, source, forwarded source, timing, method, status, request-size, and response-size context second.

·        ADC traffic-processing context, including listener, virtual service, protocol, protocol handler, NAT function, ALG function, message or request size, transaction behavior, connection state, protocol anomaly, and source context third.

·        Appliance health, process or service fault, management/API handler fault, authentication-handler error, protocol-handler fault, watchdog, restart, reboot, failover, HA transition, resource exhaustion, abnormal connection-state, and availability context fourth.

·        Configuration object, backup, diagnostic bundle, packet capture, certificate object, TLS object, private-key, keystore, API-token, credential-bearing artifact, and protected-object context fifth.

·        Virtual-service, backend-pool, routing, rewrite, header, persistence, NAT, ALG, TLS offload, certificate binding, health-check, logging-setting, administrator, API-key, role, and downstream application context sixth.

·        DNS, proxy, firewall, NDR, destination reputation, first-seen, domain-age, ASN, geography, destination-port, protocol, and ADC-originated egress correlation seventh.

·        Multi-asset control-plane probing, source clustering, request-family grouping, exposure-class clustering, asset-group clustering, and post-access behavior context eighth.

·        Downstream AWS, Azure, and Google Cloud impact correlation ninth, using normalized upstream ADC context. Traffic-processing context may contribute only when it has already been correlated and forwarded from the relevant network or SIEM detection layer.

·        Alert promotion only after local telemetry validation, false-positive baselining, suppression governance, and triage playbook alignment.

Telemetry Normalization Requirements

Implementation requires normalized entity and time correlation across ADC management/API, traffic-processing, protocol, appliance syslog, administrative audit, configuration-change, certificate-management, backup, diagnostic, packet-capture, WAF, reverse-proxy, CDN, load-balancer, gateway, endpoint, EDR, DNS, proxy, firewall, NDR, downstream application, AWS, Azure, Google Cloud, SOAR, incident-response, and SIEM telemetry.

Minimum Normalization Requirements

·        ADC asset ID.

·        ADC asset name.

·        Edge asset indicator.

·        Management interface.

·        Traffic-facing interface.

·        Vendor and platform family.

·        Virtual service.

·        Listener.

·        Backend pool.

·        Backend host.

·        Workload ID.

·        Business criticality.

·        Exposure state.

·        Administrative route.

·        Management/API surface.

·        Diagnostic route.

·        Authentication route.

·        Telemetry route.

·        Configuration route.

·        Request path.

·        Request query.

·        Full URL.

·        HTTP method.

·        Source IP.

·        Forwarded source IP.

·        ASN.

·        Geography.

·        Source network type.

·        User agent.

·        Content type.

·        Request size.

·        Response size.

·        HTTP status code.

·        Request timing.

·        Status sequence.

·        Protocol.

·        Application protocol.

·        Protocol handler.

·        Traffic-processing function.

·        NAT function.

·        ALG function.

·        Message or request size.

·        Protocol behavior.

·        Transaction or session identifier where available.

·        Connection state.

·        Appliance health event.

·        Process or service crash.

·        Management-service fault.

·        API handler exception.

·        Authentication-handler error.

·        Protocol-handler or traffic-processing fault.

·        Restart or reboot event.

·        Failover or HA event.

·        Resource-exhaustion or resource-pressure event.

·        Configuration object.

·        Certificate object.

·        TLS object.

·        Private-key or keystore indicator.

·        API-token indicator.

·        Backup action.

·        Diagnostic action.

·        Packet-capture action.

·        Virtual-service change.

·        Backend-pool change.

·        Routing-rule change.

·        Rewrite-rule change.

·        Header-rule change.

·        Persistence-profile change.

·        NAT or ALG configuration change.

·        TLS offload change.

·        Certificate-binding change.

·        Health-check change.

·        Logging-setting change.

·        Administrative-setting change.

·        Administrator or role change.

·        API-key event.

·        DNS query.

·        Destination domain.

·        Destination IP.

·        Destination port.

·        Destination protocol.

·        Destination reputation.

·        Destination first-seen status.

·        Destination domain age.

·        Destination ASN.

·        Destination geography.

·        Proxy action.

·        Firewall action.

·        Downstream application behavior.

·        AWS account, role, principal, region, load balancer, WAF, storage, secret, KMS, and resource.

·        Azure tenant, subscription, application, service principal, managed identity, Application Gateway, Front Door, WAF, Key Vault, Storage, and resource.

·        GCP organization, folder, project, principal, service account, workload identity, load balancer, Cloud Armor, Cloud Storage, Secret Manager, KMS, and resource.

·        SOAR case ID.

·        Incident-response case ID.

·        Event timestamp.

·        Event source.

·        Approved workflow context.

Correlation Requirements

Rules should use bounded correlation windows that reflect the relationship between suspicious ADC activity and follow-on appliance instability, egress behavior, protected-object access, traffic-path manipulation, administrative-control change, downstream application behavior, multi-asset control-plane probing, or cloud behavior.

Recommended Starting Windows

·        Suspicious ADC control-plane access to appliance instability within 30 minutes.

·        Suspicious ADC traffic-processing activity to appliance instability or availability impact within 30 minutes.

·        Suspicious ADC control-plane access to rare ADC-originated egress within 4 hours.

·        Suspicious ADC control-plane access to configuration, backup, diagnostic, packet-capture, certificate, private-key, keystore, API-token, or credential-bearing artifact access within 4 hours.

·        Suspicious ADC control-plane access to virtual-service, backend-pool, routing, rewrite, header, persistence, NAT, ALG, TLS, certificate-binding, health-check, logging, administrative, API-key, or role change within 8 hours.

·        Suspicious ADC control-plane or validated traffic-processing context to downstream application behavior within 8 hours where reliable ADC-to-application linkage exists.

·        Related multi-asset ADC control-plane probing to post-access behavior within 8 hours.

·        Suspicious ADC context to AWS, Azure, or Google Cloud activity within 24 hours where ADC context has been normalized and joined to independently suspicious cloud activity.

·        Continued rare egress, configuration access, certificate access, administrative-control change, traffic-path behavior, downstream application behavior, or cloud activity after incident-response containment or administrative remediation within 24 hours.

These windows should be tightened in high-volume environments and extended only when source continuity, management-interface lineage, traffic-facing-interface lineage, listener or virtual-service lineage, request-family lineage, protocol lineage, asset lineage, appliance evidence, configuration-object evidence, certificate-object evidence, egress evidence, downstream application evidence, SOAR evidence, or incident-response evidence supports continuity.

Alert Promotion Guidance

Do not promote a hunt or correlation search into alert mode until the following conditions are met:

·        Required telemetry is present and normalized.

·        Required field mappings are validated.

·        ADC asset and management-interface tagging are reliable.

·        Traffic-facing-interface, listener, protocol, and traffic-processing-function mapping are reliable.

·        Virtual-service and backend-pool mapping is reliable.

·        ADC management/API route mapping is reliable.

·        Appliance-health and syslog mapping is reliable.

·        Traffic-processing and protocol telemetry mapping is reliable.

·        Configuration object, certificate object, backup, diagnostic, and packet-capture mapping is reliable.

·        Traffic-path change and administrative-control mapping is reliable.

·        Entity resolution is reliable.

·        Event timing and ordering are reliable.

·        ADC, WAF, reverse-proxy, CDN, load-balancer, gateway, appliance syslog, configuration, certificate, endpoint, DNS, proxy, firewall, NDR, downstream application, and cloud context are mapped.

·        Approved workflow baselines are defined.

·        False-positive sources are reviewed.

·        High-volume expected workflows are suppressed or downgraded.

·        Query performance is tested.

·        Triage guidance is documented.

·        Analyst review criteria are established.

·        Local severity logic is calibrated.

·        Alert-routing ownership is assigned.

False-Positive Control

False-positive control should use allowlists, reference sets, approved workflow baselines, known source IP ranges, approved ADC administrators, approved forwarded administrator sources, approved scanner sources, approved protocol sources, approved health-check sources, approved vendor support sources, approved managed-service sources, approved validation sources, approved load-testing sources, approved protocol-testing sources, approved patch workflows, approved backup workflows, approved certificate-rotation workflows, approved diagnostic workflows, approved failover workflows, approved maintenance windows, approved change windows, approved incident-response windows, approved file paths, approved process baselines, approved command patterns, approved egress destinations, expected virtual-service changes, expected backend-pool changes, expected routing changes, expected NAT or ALG changes, expected TLS changes, expected health-check changes, approved service accounts, approved cloud automation identities, and known incident-response workflows.

Common False-Positive Sources

·        Approved ADC administration.

·        Approved management/API access.

·        Approved health checks.

·        Approved protocol testing.

·        Approved load testing.

·        Approved diagnostic collection.

·        Approved backup jobs.

·        Approved configuration export.

·        Approved certificate rotation.

·        Approved key rotation.

·        Approved virtual-service changes.

·        Approved backend-pool changes.

·        Approved routing changes.

·        Approved NAT or ALG changes.

·        Approved header or rewrite changes.

·        Approved WAF tuning.

·        Approved TLS migration.

·        Approved health-check tuning.

·        Approved failover testing.

·        Approved patch validation.

·        Approved scanner activity.

·        Approved vulnerability validation.

·        Approved penetration testing.

·        Approved vendor support activity.

·        Approved managed-service activity.

·        Approved monitoring activity.

·        Approved emergency maintenance.

·        Approved incident-response collection.

·        Approved security tooling.

·        Approved update retrieval.

·        Approved license validation.

·        Approved telemetry destinations.

·        Approved backup destinations.

·        Approved DNS, NTP, syslog, monitoring, vendor, or business destinations.

·        Approved cloud automation.

·        Infrastructure-as-code workflows.

·        CI/CD workflows.

·        Break-glass activity.

·        Platform-support activity.

·        Managed-service access.

·        Security-tooling access.

·        Incident-response activity.

Triage Guidance

Initial triage should determine whether suspicious activity forms a coherent sequence rather than a single-event anomaly.

Triage Questions

·        Was suspicious ADC control-plane, management/API, administrative, diagnostic, authentication, telemetry, or configuration access observed?

·        Was suspicious traffic-processing activity observed against an exposed listener, virtual service, protocol handler, NAT function, ALG, or other ADC processing surface?

·        Was the affected asset internet-facing, partner-reachable, management-exposed, production, authentication-fronting, TLS-terminating, or high criticality?

·        Was the source IP, forwarded source IP, ASN, geography, user agent, source network type, HTTP method, request volume, request timing, request size, response size, status sequence, protocol, message size, transaction behavior, or connection pattern unusual?

·        Was control-plane activity tied to a management/API surface, diagnostic surface, administrative surface, authentication surface, configuration surface, telemetry surface, or Progress Kemp LoadMaster /accessv2 path where locally relevant?

·        Was traffic-processing activity tied to an exposed listener, virtual service, protocol handler, NAT function, ALG, or comparable processing function?

·        Did appliance instability, management-service fault, API handler exception, authentication-handler error, protocol-handler fault, traffic-processing fault, watchdog restart, service restart, reboot, failover, resource exhaustion, or abnormal connection behavior follow?

·        Did rare ADC-originated egress, suspicious destination access, new-domain access, unusual egress port, suspicious ASN, abnormal destination geography, or unusual protocol behavior occur?

·        Did protected configuration access, certificate access, private-key access, keystore access, API-token access, backup export, diagnostic export, or packet-capture activity occur?

·        Did virtual-service modification, backend-pool modification, routing-rule modification, rewrite-rule modification, header-rule modification, NAT or ALG change, TLS offload change, certificate-binding change, logging-setting change, administrator creation, API-key creation, or role modification occur?

·        Did downstream application behavior suggest unexpected backend access, authentication-flow change, session-routing change, header manipulation, traffic mirroring, data-exposure-like response, connection disruption, or availability degradation?

·        Did related multi-asset ADC control-plane probing appear across asset groups, exposure classes, or critical application-delivery paths?

·        Did downstream AWS, Azure, or Google Cloud administrative, network, identity, storage, secret, key, WAF, load-balancer, or sensitive-resource activity follow validated upstream ADC context?

·        Can the activity be linked by ADC asset, management interface, traffic-facing interface, listener, protocol, source IP, forwarded source IP, request family, virtual service, backend pool, configuration object, certificate object, endpoint ID, destination, cloud principal, SOAR case, incident-response case, or equivalent normalized lineage?

·        Is the activity explained by approved administration, monitoring, backup, certificate rotation, patching, scanning, protocol testing, load testing, vendor support, managed-service operation, failover testing, troubleshooting, security tooling, automation, incident-response activity, emergency maintenance, or known business workflow?

Escalation Guidance

Escalate when multiple behavior classes align in sequence, especially when suspicious ADC control-plane activity or suspicious per-asset traffic-processing activity is followed by independent appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, logging degradation, downstream application behavior, or validated downstream cloud behavior.

Higher-Priority Escalation Conditions

·        The affected ADC asset is internet-facing.

·        The affected ADC asset is partner-reachable.

·        The affected ADC asset fronts authentication, customer, payment, account, regulated, legal, executive, operational, or production applications.

·        The affected ADC asset terminates TLS for sensitive applications.

·        The affected ADC asset has administrative access to traffic routing, backend pools, certificates, WAF policies, cloud resources, or customer data.

·        Suspicious control-plane access and appliance instability align.

·        Suspicious traffic-processing activity and appliance instability or availability impact align.

·        Suspicious control-plane access and rare ADC-originated egress align.

·        Suspicious control-plane access and protected configuration access align.

·        Suspicious control-plane access and certificate, private-key, keystore, API-token, or credential-bearing artifact access align.

·        Suspicious control-plane access and backup, diagnostic bundle, or packet-capture export align.

·        Suspicious control-plane access and virtual-service or backend-pool modification align.

·        Suspicious control-plane access and routing, rewrite, header, NAT, ALG, TLS, certificate-binding, persistence, or health-check change align.

·        Suspicious control-plane access and logging degradation align.

·        Suspicious control-plane access and administrator, role, or API-key change align.

·        Suspicious ADC activity and downstream application anomaly align.

·        Multi-asset ADC control-plane probing produces post-access behavior on one or more assets.

·        AWS, Azure, or Google Cloud activity involves privileged roles, service accounts, managed identities, secrets, keys, storage, logging changes, security-control suppression, WAF or load-balancer changes, or administrative configuration and can be tied to validated upstream ADC context.

·        Multiple systems independently show aligned behavior.

Deployment Guardrails

Do not deploy these detections as fully automated blocking or containment logic without local validation.

Do not treat a single CVE label, vendor name, appliance name, exploit name, request path, /accessv2 hit, protocol anomaly, SIP message, enabled SIP ALG, configured LSN group, POST request, source IP, user agent, content type, payload string, command string, HTTP status code, vulnerable-version observation, scanner hit, file hash, destination, configuration event, certificate event, crash, restart, failover event, cloud event, or static indicator as proof of compromise.

Do not attribute cloud-only, endpoint-only, egress-only, web-only, network-only, appliance-only, configuration-only, certificate-only, traffic-path-only, administrative-only, protocol-only, or content-only anomalies to ADC exploitation, appliance command execution, configuration theft, certificate theft, traffic-path manipulation, downstream application compromise, or downstream cloud compromise without suspicious ADC context and reliable workload, source, host, asset, identity, object, resource, interface, listener, protocol, or time-window correlation.

Do not enable high-confidence alerting until platform-specific schemas, index names, sourcetypes, DSM fields, custom properties, ECS mappings, ADC fields, traffic-processing fields, protocol fields, WAF fields, CloudTrail fields, Azure fields, Google Cloud audit fields, endpoint mappings, configuration mappings, certificate mappings, network mappings, source mappings, asset mappings, workload mappings, cloud identity mappings, enrichment sources, exception lists, false-positive baselines, query performance, triage readiness, and escalation criteria have been validated.

S29 Detection Coverage Summary

Coverage Summary

The S25 detection set provides broad behavior-led coverage for suspicious ADC control-plane access, suspicious per-asset traffic-processing activity, appliance instability, rare ADC-originated egress, configuration access, certificate or TLS-object access, backup or diagnostic export, virtual-service modification, backend-pool modification, routing, header, persistence, NAT, ALG, TLS, or logging change, administrative-control change, multi-asset control-plane probing, downstream application exposure, and downstream cloud-impact activity.

Coverage is strongest when ADC management/API, traffic-processing, protocol, appliance syslog, administrative audit, configuration-change, certificate-management, WAF, reverse-proxy, CDN, load-balancer, gateway, endpoint, EDR, DNS, proxy, firewall, NDR, downstream application, AWS, Azure, Google Cloud, and SIEM telemetry are normalized and correlated into bounded sequences.

The report's detection model intentionally avoids CVE-label-only matching, vendor-name-only matching, appliance-name-only matching, exploit-name-only matching, static payload strings, single request paths, isolated source IPs, user-agent values, malformed protocol events, command strings, file hashes, scanner signatures, vulnerable-version observations, campaign names, actor branding, tool names, cloud events alone, crashes alone, failovers alone, and other single-event conclusions. It focuses on durable activity patterns that remain useful across ADC, load balancer, reverse proxy, WAF-adjacent, and traffic-management control-plane and traffic-processing exploitation scenarios.

Strong Coverage Areas

·        Suspicious ADC management/API, administrative, diagnostic, authentication, telemetry, configuration, and control-plane access behavior.

·        Progress Kemp LoadMaster /accessv2 access where locally visible and correlated with broader ADC control-plane context and follow-on behavior.

·        Suspicious per-asset traffic-processing activity against exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or related processing functions when followed by independent appliance instability or availability impact.

·        Appliance instability after suspicious ADC activity, including watchdog restart, service or process crash, service restart, management-service fault, API handler exception, authentication-handler error, protocol-handler or traffic-processing fault, failover event, resource exhaustion, abnormal connection state, or availability degradation.

·        Rare ADC-originated egress, suspicious destination access, new or rare domain access, unusual egress port, suspicious ASN, suspicious destination geography, unusual protocol behavior, or suspicious destination reputation after suspicious ADC activity.

·        Protected configuration access, configuration export, backup export, diagnostic bundle export, packet-capture activity, certificate access, TLS-object access, private-key access, keystore access, API-token access, and credential-bearing artifact access after suspicious ADC context.

·        Virtual-service modification, backend-pool modification, routing-rule modification, rewrite-rule modification, header-rule modification, NAT or ALG change, TLS offload change, certificate-binding change, persistence-profile modification, health-check modification, logging-setting modification, administrative-setting modification, administrator creation, API-key creation, or role modification after suspicious ADC context.

·        Multi-asset ADC control-plane probing with related source, request-family, exposure-class, asset-group, timing, status-sequence, and post-access behavior.

·        Downstream AWS, Azure, and Google Cloud activity when independently suspicious and correlated with validated upstream ADC context. Traffic-processing activity can contribute upstream context only after it has been normalized and forwarded from the relevant detection layer.

Moderate Coverage Areas

·        Suspicious ADC control-plane activity where web, WAF, ADC, CDN, reverse-proxy, load-balancer, or gateway logs are partial or field mappings vary.

·        Traffic-processing activity where protocol, listener, message-size, traffic-facing-interface, virtual-service, or appliance-health telemetry is partial.

·        Management/API route detection where query strings, URI paths, request-body fields, or content-type fields are incomplete.

·        Appliance-instability coverage where health logs, syslog, service-fault telemetry, protocol-handler telemetry, or failover telemetry is partial.

·        Configuration, certificate, backup, diagnostic, packet-capture, private-key, keystore, or API-token coverage where object-level audit logging is incomplete.

·        SentinelOne and endpoint coverage where ADC-adjacent hosts, jump hosts, support hosts, or management hosts have partial process, command-line, file, or network telemetry.

·        NDR visibility into control-plane access, traffic-processing anomalies, status or connection sequencing, rare egress, and multi-asset control-plane probing without appliance, configuration, certificate, or administrative enrichment.

·        Traffic-path manipulation coverage where virtual-service, backend-pool, routing, header, NAT, ALG, TLS, logging, or administrative-change telemetry is inconsistent.

·        SIGMA portability across SIEM backends.

·        Cloud detection where ADC-to-cloud workload, identity, host, source, load balancer, WAF, storage, secret, KMS, service-account, managed-identity, role, resource, account, subscription, project, organization, or upstream ADC-context lineage is partial.

·        Downstream application exposure detection where application logs, backend mapping, WAF telemetry, CDN telemetry, listener mapping, or availability telemetry is incomplete.

Limited Coverage Areas

·        Exploitation that produces no observable control-plane anomaly, traffic-processing anomaly, appliance instability, rare egress, configuration access, certificate access, backup export, diagnostic export, traffic-path change, administrative-control change, downstream application exposure, or cloud activity.

·        Traffic-processing exploitation where the initiating connection or protocol event cannot be linked to the affected ADC asset or resulting appliance-health event.

·        Appliance command execution that does not produce process telemetry, shell activity, diagnostic activity, service-context behavior, rare egress, configuration access, or artifact access.

·        Configuration theft that occurs through expected backup, migration, vendor support, or administrative workflows without anomalous timing or context.

·        Certificate or private-key theft that does not produce object-level access, export telemetry, egress, downstream application change, or cloud activity.

·        Traffic-path manipulation that blends into approved deployment, routing, WAF tuning, NAT or ALG change, TLS migration, failover, or change-management workflows.

·        Administrative compromise that uses approved administrator accounts, expected source IPs, expected devices, expected user agents, and normal change windows.

·        Rare egress that uses approved vendor, update, license-validation, telemetry, monitoring, DNS, NTP, syslog, backup, hosting-provider, managed-service, or business destinations.

·        Downstream application exposure that mirrors approved release, routing, backend, cache, CDN, or application-maintenance workflows.

·        Cloud activity without reliable ADC-to-AWS, ADC-to-Azure, or ADC-to-Google Cloud workload, identity, source, host, resource, load balancer, WAF, storage, secret, KMS, service-account, managed-identity, role, or correlation linkage.

·        Multi-asset traffic-processing campaign activity because the current S25 campaign rules remain control-plane-oriented. Per-asset traffic-processing detection is implemented, but multi-asset traffic-processing campaign correlation is not currently claimed.

·        Environments without CloudTrail data events, Azure Key Vault logs, Azure Storage logs, Google Cloud Data Access logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, or equivalent sensitive-service visibility.

Non-Covered Areas

The S25 rule set does not directly prove:

·        ADC exploitation.

·        Appliance command execution.

·        Memory corruption.

·        Configuration theft.

·        Certificate theft.

·        Credential theft.

·        Administrative compromise.

·        Traffic-path manipulation.

·        Downstream application compromise.

·        Data theft.

·        AWS compromise.

·        Azure compromise.

·        Google Cloud compromise.

·        Downstream cloud compromise.

·        Adversary attribution.

·        Campaign attribution.

These outcomes require investigation, corroborating telemetry, and incident-specific validation.

System Coverage Summary

NDR / Network Behavioral Analytics

NDR provides primary network-behavior and sequence coverage for suspicious ADC control-plane access, suspicious per-asset traffic-processing activity, unusual source infrastructure, abnormal request behavior, protocol anomalies, listener or virtual-service targeting, control-plane-to-instability behavior, traffic-processing-to-instability behavior, control-plane-to-egress behavior, rare destination access, suspicious destination reputation, new or rare domains, unusual egress ports, unusual protocols, proxy anomalies, firewall anomalies, multi-asset control-plane probing, downstream traffic shifts, and cloud access paths.

NDR does not independently prove ADC exploitation, appliance command execution, memory corruption, configuration theft, certificate theft, administrative compromise, cloud compromise, downstream application compromise, or data theft without ADC appliance, configuration, certificate, administrative, endpoint, downstream application, cloud, or SIEM-forwarded context.

SentinelOne

SentinelOne provides strong supporting endpoint coverage where ADC-adjacent host, appliance-support host, jump host, management host, service-context, process, command-line, file, sensitive-artifact, backup, diagnostic, packet-capture, certificate, key, transfer-tool, archive-tool, network, and rare-egress context can be joined to suspicious ADC activity, appliance instability, configuration access, certificate access, or traffic-path manipulation.

SentinelOne is strongest as host-side or support-host behavior context rather than as the primary source of ADC traffic-processing or control-plane exploitation proof.

Splunk

Splunk provides strong correlation coverage when ADC management/API, traffic-processing, protocol, appliance syslog, administrative audit, configuration-change, certificate-management, WAF, reverse-proxy, CDN, load-balancer, gateway, endpoint, file, process, DNS, proxy, firewall, NDR, downstream application, AWS, Azure, and Google Cloud telemetry are normalized into searchable indexes with reliable field mappings, sourcetypes, lookups, summary datasets, and sequence logic.

Elastic

Elastic provides strong SIEM sequence and correlation coverage when ADC management/API, traffic-processing, protocol, appliance syslog, administrative audit, configuration-change, certificate-management, WAF, reverse-proxy, CDN, load-balancer, gateway, endpoint, file, process, DNS, proxy, firewall, NDR, downstream application, AWS, Azure, and Google Cloud data are normalized into ECS-compatible or locally enriched fields with reliable EQL sequencing, transforms, enrichments, value lists, and exception handling.

QRadar

QRadar provides strong correlation coverage when DSM parsing, custom properties, reference sets, reference maps, building blocks, event ordering, and offense grouping are validated across ADC management/API, traffic-processing, protocol, appliance syslog, administrative audit, configuration-change, certificate-management, WAF, reverse-proxy, CDN, load-balancer, gateway, endpoint, file, process, DNS, proxy, firewall, NDR, downstream application, AWS, Azure, and Google Cloud telemetry.

SIGMA

SIGMA provides portable event-rule template logic for suspicious ADC control-plane access, backend-correlated per-asset traffic-processing exploitation, appliance instability, rare ADC egress, configuration access, certificate access, backup export, diagnostic artifact access, traffic-path manipulation, administrative-control change, multi-asset control-plane probing, and downstream application behavior.

SIGMA production value depends on SIEM translation quality, field mappings, enrichment-field creation, sequence support, wildcard behavior, case handling, backend-native correlation, and local event-source coverage.

YARA

YARA has zero deployable rules for this EXP report because no stable malicious appliance artifact, webshell body, payload family, dropper, loader, script artifact, archive artifact, memory artifact, configuration implant, certificate-theft artifact, credential-harvesting artifact, diagnostic-bundle payload, or reusable malware family is available.

AWS

AWS provides conditional downstream cloud-impact coverage when suspicious AWS activity is correlated with validated upstream ADC context through reliable AWS account lineage plus workload, identity, source, host, resource, load balancer, WAF, S3, Secrets Manager, KMS, assumed-role, instance, container, ADC asset, virtual-service, backend-pool, or correlation linkage.

Suspicious traffic-processing activity can serve as upstream context only after it has been correlated, normalized, and forwarded into the AWS or SIEM analytics environment.

Azure

Azure provides conditional downstream cloud-impact coverage when suspicious Azure control-plane, identity, resource, Key Vault, Storage, service-principal, managed-identity, diagnostic, logging, security, network, Application Gateway, Front Door, WAF, or administrative activity is correlated with validated upstream ADC context through reliable tenant and subscription lineage plus workload, identity, source, host, resource, Storage, Key Vault, service-principal, managed-identity, application, Application Gateway, Front Door, WAF policy, ADC asset, virtual-service, backend-pool, or correlation-ID linkage.

Suspicious traffic-processing activity can serve as upstream context only after it has been correlated, normalized, and forwarded into the Azure or SIEM analytics environment.

GCP

GCP provides conditional downstream Google Cloud coverage when Google Cloud audit logs, Data Access logs, IAM logs, service-account logs, Cloud Storage logs, Secret Manager logs, KMS logs, Security Command Center context, Chronicle context, Cloud Armor logs, load-balancer logs, and validated ADC context are normalized and correlated through organization and project lineage plus workload, identity, source, host, resource, Cloud Storage, Secret Manager, KMS, service-account, workload-identity, load balancer, Cloud Armor, ADC asset, virtual-service, backend-pool, or correlation-ID linkage.

Suspicious traffic-processing activity can serve as upstream context only after it has been correlated, normalized, and forwarded into the GCP or SIEM analytics environment.

Coverage Conclusion

The detection set provides strong practical coverage for observable enterprise behavior associated with suspicious ADC control-plane access, suspicious per-asset traffic-processing activity, appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, multi-asset control-plane probing, downstream application exposure, and downstream cloud activity.

It is strongest when multiple telemetry classes align in sequence and weakest where exploitation produces no observable control-plane anomaly, traffic-processing anomaly, appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path change, administrative-control change, downstream application behavior, or downstream cloud behavior. Multi-asset traffic-processing campaign coverage is not claimed under the current S25 campaign rules.

S30 Intelligence Maturity Assessment

Maturity Assessment Summary

The intelligence maturity level for this report is high for behavior-led detection strategy and moderate for direct compromise confirmation.

The detection model is mature because it focuses on durable behavioral relationships: suspicious ADC control-plane access, suspicious per-asset traffic-processing activity, appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, multi-asset control-plane probing, downstream application exposure, and downstream cloud activity.

Direct compromise confirmation remains limited because enterprise telemetry generally does not expose attacker intent, exploit success, memory corruption, appliance command execution, configuration theft, certificate theft, credential theft, administrative compromise, traffic-path manipulation, downstream application compromise, or downstream cloud compromise directly. Most environments infer misuse through correlated control-plane or traffic-processing behavior, appliance instability, configuration and certificate access, rare egress, traffic-path changes, administrative-control changes, downstream application behavior, and downstream cloud activity.

Behavioral Intelligence Maturity

Behavioral maturity is high.

The report identifies repeatable behavior that can be detected across ADC management/API, traffic-processing, protocol, appliance syslog, administrative audit, configuration-change, certificate-management, backup, diagnostic, WAF, reverse-proxy, CDN, load-balancer, gateway, endpoint, EDR, DNS, proxy, firewall, NDR, downstream application, SIEM, AWS, Azure, and Google Cloud platforms.

The behaviors are durable across CVE labels, vendor names, appliance names, exploit names, request-path variation, protocol variation, source infrastructure, user-agent values, payload strings, command strings, scanner signatures, actor branding, campaign names, tool names, and cloud-provider variation.

Strong Behavioral Anchors

·        Suspicious ADC management/API, administrative, diagnostic, authentication, telemetry, configuration, and control-plane access behavior.

·        Progress Kemp LoadMaster /accessv2 access where locally visible and correlated with source, asset, management-interface, and follow-on behavior.

·        Suspicious per-asset traffic-processing activity directed at exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or related processing functions and correlated with independent appliance or availability effects.

·        Appliance instability after suspicious ADC activity, including watchdog restart, process or service crash, service restart, management-service fault, API handler exception, authentication-handler error, protocol-handler or traffic-processing fault, failover event, resource exhaustion, abnormal connection state, and availability degradation.

·        Rare outbound communication, suspicious destination access, new or rare domain access, unusual egress port, suspicious ASN, abnormal destination geography, unusual protocol behavior, and suspicious destination reputation.

·        Protected configuration access, backup export, diagnostic export, packet-capture activity, certificate access, TLS-object access, private-key access, keystore access, API-token access, and credential-bearing artifact access.

·        Virtual-service modification, backend-pool modification, routing-rule modification, rewrite-rule modification, header-rule modification, persistence-profile modification, NAT or ALG change, TLS offload change, certificate-binding change, health-check modification, logging-setting modification, administrative-setting modification, administrator creation, API-key creation, and role modification.

·        Multi-asset ADC control-plane probing with source clustering, request-family clustering, asset-group clustering, exposure-class clustering, and post-access behavior.

·        Downstream AWS, Azure, or Google Cloud activity following validated upstream ADC context and independently suspicious cloud behavior.

Telemetry Maturity

Telemetry maturity is moderate to high.

ADC management/API, traffic-processing, protocol, appliance syslog, administrative audit, configuration-change, certificate-management, backup, diagnostic, WAF, reverse-proxy, CDN, load-balancer, gateway, endpoint, EDR, DNS, proxy, firewall, NDR, downstream application, SIEM, AWS, Azure, and Google Cloud telemetry provide strong coverage where ADC asset, management interface, traffic-facing interface, listener, virtual service, protocol, processing function, backend pool, backend host, workload, source, forwarded source, path, object, process, destination, cloud principal, resource, and timestamp fields are available and normalized.

Telemetry maturity decreases when ADC management/API logs are incomplete, protocol telemetry is unavailable, listener or traffic-processing mapping is weak, query strings are unavailable, management-surface mapping is weak, appliance-health telemetry is unavailable, configuration and certificate audit records are incomplete, backup or diagnostic events are not logged, source attribution is noisy, downstream application telemetry is inconsistent, cloud logs are not correlated, or approved workflow baselines are weak.

Cloud and Application-Delivery Maturity

Cloud and application-delivery maturity is moderate to strong.

AWS, Azure, and Google Cloud provide useful downstream cloud-impact visibility when cloud telemetry can be joined to validated upstream ADC context through workload, identity, source, host, load balancer, WAF, storage, secret, KMS, service account, managed identity, role, resource, account, tenant, subscription, organization, project, or correlation lineage.

Cloud platforms do not independently prove ADC exploitation, traffic-processing exploitation, appliance command execution, configuration theft, certificate theft, administrative compromise, traffic-path manipulation, downstream application compromise, or data theft. Their strongest value comes from correlation with prior normalized ADC context, which may include control-plane access, validated traffic-processing activity, appliance instability, configuration or certificate access, rare egress, traffic-path manipulation, administrative-control change, downstream application exposure, SOAR, incident-response, or SIEM-forwarded context.

Maturity increases when CloudTrail, Azure Activity, Entra ID, Key Vault, Storage, Google Cloud Audit Logs, Data Access logs, Cloud Storage logs, Secret Manager logs, KMS logs, Security Command Center, GuardDuty, Security Hub, Defender for Cloud, Sentinel, Chronicle, sensitive-resource inventories, cloud identity mappings, and upstream ADC-context mappings are normalized and validated.

Adversary-Resilience Maturity

Adversary-resilience maturity is high for behavior-led detection and moderate for high-confidence exploitation attribution.

The detection model is resilient because it avoids brittle indicators and focuses on behavior an adversary may produce when converting ADC control-plane or traffic-processing access into appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, downstream application exposure, or downstream cloud activity.

The model is less resilient when adversaries use expected administrator sources, expected protocol patterns, approved vendor support paths, approved managed-service sources, approved deployment workflows, normal certificate-rotation paths, expected backup or diagnostic processes, approved cloud automation, known business destinations, or other established operational workflows. It is also less resilient when adversaries avoid command execution, avoid appliance instability, avoid rare egress, avoid configuration access, avoid certificate access, avoid traffic-path changes, avoid administrative-control changes, avoid downstream application behavior, avoid cloud activity, and stop activity before downstream impact.

Multi-asset traffic-processing campaign resilience remains lower because current S25 campaign rules are still control-plane-oriented even though per-asset traffic-processing coverage is implemented.

Operationalization Maturity

Operationalization maturity is moderate.

The S25 rules are implementation-ready detection patterns, but production deployment requires local validation of schemas, index names, sourcetypes, DSM fields, custom properties, ECS mappings, ADC fields, protocol fields, traffic-processing fields, WAF fields, endpoint fields, file fields, process fields, DNS fields, proxy fields, firewall fields, appliance syslog fields, configuration fields, certificate fields, CloudTrail fields, Azure fields, Google Cloud audit fields, identity mappings, source mappings, asset mappings, listener mappings, workload mappings, cloud identity mappings, enrichment, exception lists, false-positive baselines, query performance, triage logic, and alert-routing decisions.

Operational maturity increases when detection owners validate each platform's field mappings, confirm telemetry quality, baseline approved ADC administration, monitoring, scanning, protocol testing, load testing, patch validation, vendor support, managed-service activity, backup workflows, certificate rotation, diagnostic collection, failover testing, deployment workflows, routing changes, NAT or ALG changes, WAF tuning, TLS changes, cloud administration, service accounts, automation, CI/CD, infrastructure-as-code, break-glass, and incident-response workflows, and test sequence logic using realistic benign and suspicious event data.

Attribution Maturity

Attribution maturity is low to moderate.

The rule set supports detection of behavior consistent with suspicious ADC control-plane compromise, traffic-processing exploitation, appliance instability, configuration access, certificate access, rare egress, traffic-path manipulation, administrative-control change, downstream application exposure, and downstream cloud activity. It should not be used by itself to attribute activity to a specific adversary, campaign, exploit developer, infrastructure provider, malware family, or named threat group without external evidence and incident-specific validation.

Attribution requires corroborating evidence such as exploitation timeline, ADC logs, request or protocol traces, appliance artifacts, source infrastructure, endpoint evidence, command history, configuration changes, certificate access, administrative changes, traffic-path changes, destination infrastructure, cloud activity, victimology, actor tradecraft, and threat-intelligence reporting.

Maturity Limitations

Primary Maturity Limitations

·        Limited direct visibility into exploitation success.

·        Limited direct visibility into memory corruption.

·        Limited direct visibility into appliance command execution.

·        Limited direct visibility into configuration theft.

·        Limited direct visibility into certificate theft.

·        Limited direct visibility into credential theft.

·        Limited direct visibility into administrative compromise.

·        Limited direct visibility into traffic-path manipulation.

·        Limited direct visibility into downstream application compromise.

·        Variable ADC management/API logging.

·        Variable traffic-processing and protocol telemetry.

·        Variable listener, virtual-service, NAT, ALG, and processing-function mapping.

·        Variable query-string and request-body visibility.

·        Variable management-surface mapping.

·        Variable appliance-health telemetry.

·        Variable configuration-change telemetry.

·        Variable certificate-management telemetry.

·        Variable backup and diagnostic telemetry.

·        Variable endpoint and EDR visibility around ADC-adjacent hosts.

·        Variable source-IP stability.

·        Variable destination reputation and first-seen coverage.

·        Variable ADC-to-AWS, ADC-to-Azure, and ADC-to-Google Cloud workload and identity correlation.

·        Variable cloud data-event logging.

·        Variable approved workflow baselines.

·        No dedicated multi-asset traffic-processing campaign rule in the current S25 implementation.

·        High false-positive potential when detections are deployed without local tuning.

Maturity Improvement Priorities

Priority Improvements

·        Improve ADC management/API, traffic-processing, protocol, WAF, reverse-proxy, CDN, load-balancer, gateway, and appliance syslog retention.

·        Improve ADC asset ID, management interface, traffic-facing interface, listener, virtual service, protocol, processing function, backend pool, backend host, workload, exposure, and business-criticality tagging.

·        Improve ADC management/API surface, administrative route, diagnostic route, authentication route, telemetry route, configuration route, listener, protocol handler, NAT function, ALG function, and protected-object mapping.

·        Improve Progress Kemp LoadMaster /accessv2 mapping where locally relevant without making detection dependent on that path.

·        Improve URI path, query string, HTTP method, content type, request size, response size, status sequence, source IP, forwarded source IP, user agent, timing, protocol, message size, connection state, and transaction normalization.

·        Improve appliance-health, management-service fault, API handler, authentication-handler, protocol-handler, traffic-processing fault, failover, watchdog, restart, reboot, and resource-exhaustion telemetry.

·        Improve configuration object, certificate object, backup, diagnostic, packet capture, private-key, keystore, API-token, and credential-bearing artifact logging.

·        Improve virtual-service, backend-pool, routing-rule, rewrite-rule, header-rule, persistence-profile, NAT, ALG, TLS offload, certificate-binding, health-check, logging-setting, administrator, role, and API-key change telemetry.

·        Improve endpoint, EDR, process, command-line, parent-process, process-user, file-action, diagnostic, backup, certificate, and transfer-tool telemetry for ADC-adjacent hosts.

·        Improve DNS, proxy, firewall, NDR, destination reputation, destination first-seen, domain age, ASN, geography, protocol, listener, and egress-port normalization.

·        Improve downstream application logging, backend mapping, authentication-flow monitoring, session-routing monitoring, header behavior, availability monitoring, and content-impact monitoring.

·        Improve SOAR and incident-response integration for containment and post-remediation context.

·        Improve sensitive-resource inventories and application-delivery baselines.

·        Improve ADC-to-AWS, ADC-to-Azure, and ADC-to-Google Cloud workload, identity, source, host, load balancer, WAF, storage, secret, KMS, service-account, managed-identity, role, and resource lineage.

·        Enable relevant cloud data-event logging for sensitive AWS, Azure, and Google Cloud services.

·        Build approved workflow baselines for ADC administrators, monitoring, scanning, protocol testing, load testing, patch validation, vendor support, managed-service access, backup, certificate rotation, diagnostic collection, packet-capture collection, failover testing, emergency maintenance, cloud administration, service accounts, automation, CI/CD, infrastructure-as-code, break-glass use, security tooling, and incident-response activity.

·        Modernize the existing multi-asset campaign rules if future coverage is intended to include coordinated traffic-processing exploit activity across multiple ADC assets.

·        Test detection logic against realistic benign and suspicious sequences before alert promotion.

Final Intelligence Maturity Assessment

The report's intelligence maturity is strong for behavior-led detection engineering, strong for executive risk framing, moderate to strong for telemetry-driven operational detection, moderate to strong for ADC management/API, per-asset traffic-processing, appliance, SIEM, egress, configuration, certificate, traffic-path, administrative-control, downstream application, and cloud correlation, moderate for AWS, Azure, and Google Cloud downstream cloud correlation, and low to moderate for direct exploitation or attribution confirmation.

The S25 through S30 detection model is best used as an implementation-ready threat-to-detection framework that identifies suspicious ADC control-plane access, suspicious per-asset traffic-processing activity, appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, multi-asset control-plane probing, downstream application exposure, and downstream cloud-impact patterns. It should not be used as a standalone proof model for ADC exploitation, memory corruption, appliance command execution, configuration theft, certificate theft, credential theft, administrative compromise, traffic-path manipulation, downstream application compromise, data theft, or cloud compromise without corroborating telemetry and incident-specific validation.

S31 — Telemetry Dependencies

Edge ADC exploitation requires telemetry capable of determining whether suspicious control-plane or traffic-processing activity remained routine application-delivery behavior, reflected a failed exploit attempt, produced appliance instability, or progressed into material trust-boundary impact. The central dependency is the ability to correlate ADC asset inventory, management/API exposure, exposed listeners and processing functions, access restrictions, management logs, protocol and traffic-processing telemetry, WAF records, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, service-health telemetry, administrative audit logs, configuration-change records, certificate-management records, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, downstream application logs, backup comparison data, change-management records, business-owner context, and remediation evidence into one ADC-facing-activity-to-impact investigation model.

ADC Asset, Exposure, and Control-Plane Telemetry

·        ADC asset telemetry must identify ADCs, load balancers, reverse proxies, WAF-adjacent appliances, virtual appliances, cloud-hosted ADC workloads, managed ADC services, high-availability pairs, disaster-recovery appliances, staging appliances, production appliances, internet-facing management paths, partner-reachable management paths, internal-only management surfaces, externally reachable listeners, and traffic-processing functions.

·        Exposure telemetry must identify management/API endpoints, administrative interfaces, diagnostic functions, authentication paths, telemetry paths, configuration paths, support paths, listener exposure, virtual-service exposure, protocol-handler exposure, NAT or ALG functionality, management-interface exposure state, access restrictions, approved source networks, partner access paths, and affected platform state.

·        Required fields include appliance name, appliance role, vendor or platform family, version, patch state, management interface, API endpoint, public exposure state, partner exposure state, traffic-facing interface, virtual service, backend pool, listener, protocol, processing function, NAT or ALG context where applicable, environment, region, business owner, application owner, certificate owner, administrator owner, and remediation status where available.

·        This telemetry is required to determine whether suspicious activity affected the correct exposure class: an exposed or insufficiently isolated ADC control plane, traffic-processing surface, or both.

·        Asset and exposure telemetry must be interpreted conservatively because unrelated firewall management interfaces, VPN appliances, CMS platforms, hosting-control panels, identity portals, cloud control planes, internal-only ADC deployments, or unrelated protocol services may not share the same behavior model.

Management/API, WAF, Reverse-Proxy, CDN, and Load-Balancer Telemetry

·        Management and gateway telemetry must capture ADC request activity involving management/API, administrative, diagnostic, authentication, telemetry, configuration, and control-plane behavior.

·        Required fields include timestamp, appliance name, destination host, destination IP, management interface, virtual service, backend host, source IP, forwarded source IP where available, URI path, URI query, HTTP method, status code, response size, request size, user agent, content type, API method, action, WAF disposition, and endpoint family where available.

·        This telemetry is required to determine whether suspicious external or partner-originated activity involved malformed, unusual, repeated, automation-like, command-shaped, encoded, oversized, failed-to-success, or API-parameter manipulation behavior against exposed ADC control-plane paths.

·        Management/API telemetry must be interpreted against approved ADC administration, vendor support, patch validation, firmware updates, health-check tuning, certificate rotation, backup activity, failover testing, monitoring, vulnerability validation, maintenance windows, and documented incident-response activity.

·        Request-path telemetry should not be used as a standalone compromise signal because exposed ADCs and load balancers are routinely scanned, and management/API access may occur during approved administration or validation.

Traffic-Processing, Protocol, Listener, NAT, and ALG Telemetry

·        Traffic-processing telemetry must capture externally supplied activity reaching ADC listeners, virtual services, protocol handlers, NAT functions, ALGs, or comparable packet and application-processing components.

·        Required fields should include appliance name, traffic-facing interface, destination IP, destination port, listener, virtual service, protocol, application protocol where available, protocol handler, processing function, NAT context, ALG context, source IP, forwarded source where available, message or request size, transaction or session identifier where available, connection state, retransmission behavior, reset state, timeout state, protocol-validation outcome, processing disposition, and timestamp.

·        Detection-relevant processing behavior includes malformed, oversized, repeated, protocol-inconsistent, abnormal, fuzzing-like, or otherwise exploit-shaped traffic.

·        Traffic-processing telemetry should be correlated with independent appliance-health or availability effects, including process or service faults, watchdog behavior, restart, reboot, HA transition, failover, resource pressure, connection disruption, service-unavailable conditions, and downstream availability degradation.

·        Protocol-specific or feature-specific fields may be used where locally relevant, but the telemetry model must not depend on one protocol, ALG, NAT implementation, listener type, or processing function.

·        Malformed traffic, an enabled processing feature, an exposed listener, or an isolated protocol anomaly is exposure or investigative context, not proof of successful exploitation.

Appliance System, Process, Service-Health, and Runtime Execution Telemetry

·        Appliance system telemetry must capture service faults, protocol-handler faults, API-handler errors, authentication-handler errors, management-service faults, watchdog events, restarts, reboots, HA transitions, failover events, resource pressure, diagnostic activity, shell activity, script activity, command execution, package activity, transfer-tool activity, and service-context behavior where available.

·        Required fields include appliance name, process name where available, parent process where available, process user where available, command line where available, executable path where available, diagnostic action, service name, fault type, crash indicator, restart event, reboot event, HA or failover state, resource state, timestamp, management interface, traffic-facing interface, virtual-service context, listener context, protocol context, and administrator context where available.

·        This telemetry is required to distinguish suspicious control-plane activity that progressed into execution from traffic-processing exploitation that produced process, service, connection, or availability impact without command execution.

·        Runtime execution telemetry may be unavailable in sealed, hardware-only, vendor-managed, managed-service, or appliance-restricted deployments and should be treated as high-value evidence when present, not as a guaranteed telemetry source.

·        Appliance system and runtime telemetry must be interpreted against approved vendor support, firmware updates, diagnostics, backups, monitoring, patch validation, health checks, load testing, failover testing, emergency maintenance, and incident-response collection.

Configuration, Virtual-Service, and Traffic-Path Telemetry

·        Configuration telemetry must capture reads, writes, exports, downloads, creation, modification, deletion, replacement, rollback, backup creation, diagnostic-bundle creation, packet-capture creation, and object-level changes across ADC configuration state.

·        Required coverage includes virtual services, listener ports, backend pools, real-server pools, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, health checks, NAT or ALG configuration, WAF-adjacent policies, proxy policies, SSL/TLS offload settings, logging settings, authentication templates, administrative settings, and management-access restrictions.

·        Required fields include appliance name, configuration object, object family, action, old value where available, new value where available, administrative identity where available, source IP where available, timestamp, virtual service, backend pool, route, listener, processing function where applicable, change source, and approved change record where available.

·        This telemetry is required to determine whether suspicious ADC control-plane or independently validated appliance-compromise activity resulted in traffic-path manipulation, downstream routing change, logging degradation, weakened security policy, unauthorized virtual-service change, backend-pool modification, or application-delivery trust impact.

·        Traffic-processing exploitation should not be assumed to cause configuration or routing changes unless independent configuration or administrative evidence establishes those effects.

·        Configuration telemetry must be interpreted against approved maintenance, emergency routing changes, certificate rotation, health-check tuning, failover testing, backup jobs, vendor support, monitoring, patch validation, and incident-response activity.

Certificate, TLS, Credential, and Sensitive Object Telemetry

·        Certificate and sensitive-object telemetry must capture access to TLS certificates, private keys, key stores, certificate bindings, SSL/TLS offload settings, SAML material, OIDC material, API tokens, administrative credentials, backend credentials, diagnostic bundles, packet captures, backup archives, configuration exports, and credential-bearing appliance files.

·        Required fields include appliance name, certificate object, key object, credential object, file path where available, action, timestamp, administrative identity where available, process context where available, source IP where available, certificate owner, virtual service, backend pool, and approved certificate-management context where available.

·        This telemetry is required to determine whether suspicious control-plane or independently confirmed appliance-compromise activity created certificate exposure, private-key exposure, API-token exposure, credential exposure, TLS-trust impact, authentication-flow risk, or downstream application trust uncertainty.

·        Certificate or credential access should not be inferred from traffic-processing anomalies or appliance instability alone.

·        Certificate and credential telemetry must be interpreted against approved certificate rotation, certificate renewal, key replacement, backup activity, vendor support, diagnostic collection, migration, failover testing, emergency maintenance, and documented incident-response collection.

·        Where native object-level certificate telemetry is absent, configuration-export comparison, backup comparison, certificate-inventory review, administrative audit records, and incident-response artifact collection may be required.

Network, DNS, Proxy, Firewall, NDR, and Egress Telemetry

·        Network telemetry must capture inbound and outbound communication involving ADC appliances, virtual appliances, ADC-supporting hosts, management hosts, exposed listeners, traffic-processing surfaces, and downstream application paths.

·        Source-enrichment telemetry should identify rare inbound sources, suspicious ASNs, cloud-hosted infrastructure, residential proxy infrastructure, VPN-provider infrastructure, scanner infrastructure, compromised-host indicators, newly observed sources, and geographies inconsistent with approved ADC administration, partner access, or expected application traffic.

·        Outbound telemetry should identify rare destinations, newly observed domains, raw-IP communication, DNS anomalies, HTTP or HTTPS callbacks, SSH, SMTP, file-transfer behavior, tunneling, command-and-control-like communication, tool retrieval, repeated callbacks, or traffic inconsistent with approved vendor support, updates, license validation, telemetry, monitoring, DNS, NTP, syslog, backups, health checks, integrations, or downstream application paths.

·        Required fields include source appliance, source IP, source interface, destination domain, destination IP, destination port, protocol, timestamp, action, destination reputation, ASN, geography, first-seen status, domain age, proxy action, firewall action, and NDR behavior where available.

·        Network telemetry is required to connect suspicious control-plane or traffic-processing activity with appliance-health effects, command execution, configuration access, certificate access, administrative activity, egress, and downstream application anomalies.

·        Network telemetry must not be used as standalone exploit confirmation because it may lack request-body detail, protocol-processing context, process attribution, configuration state, certificate state, administrative identity, or downstream application context.

Downstream Application, Backend, and Trust-Path Telemetry

·        Downstream telemetry must capture application behavior behind affected ADCs, including backend access, authentication-flow behavior, session routing, header behavior, TLS termination behavior, service-account use, internal API access, database access, storage access, backup access, application-administration activity, response behavior, connection behavior, and availability impact.

·        Required fields include downstream application, backend host, backend IP, virtual service, backend pool, listener, protocol, request path where applicable, source path, header state, session identifier where available, authentication-flow state, service account, response size, response code, connection state, timestamp, route family, and application owner where available.

·        This telemetry is required to determine whether suspicious ADC activity affected downstream applications, backend services, customer-facing availability, partner workflows, authentication flows, regulated application paths, or application-delivery integrity.

·        Traffic-processing exploitation may produce downstream availability, connection-handling, or traffic-delivery effects without providing administrative access or downstream compromise.

·        Downstream telemetry must be interpreted against approved application releases, infrastructure changes, load-balancer changes, certificate rotations, protocol testing, load testing, emergency maintenance, failover testing, incident-response cleanup, and expected application behavior.

·        Downstream application anomalies should not be attributed to ADC exploitation unless aligned by appliance, virtual service, listener, backend pool, route, protocol, source path, administrative action where applicable, destination, or bounded time window.

Change-Control, Remediation, Incident Response, and Business-Workflow Context

·        Change-control telemetry must capture approved ADC administration, patching, firmware updates, vendor support, certificate rotation, virtual-service changes, backend-pool changes, routing changes, listener changes, protocol-processing changes, NAT or ALG changes, health-check tuning, backup activity, failover testing, monitoring changes, vulnerability validation, red-team activity, emergency maintenance, load testing, protocol testing, and incident-response cleanup.

·        Incident-response records must capture affected appliance, affected version, affected control-plane or traffic-processing surface, affected management or API path where applicable, affected listener or protocol where applicable, affected configuration object, affected certificate object, affected virtual service, affected backend pool, affected administrator account, affected credential material, affected downstream application, containment action, action owner, timestamp, validation status, evidence source, decision owner, and closure rationale.

·        Business-workflow context must capture approved ADC administrators, approved vendor-support sources, approved partner administrators, approved vulnerability scanners, approved patch-validation sources, approved automation accounts, approved monitoring systems, approved maintenance windows, approved certificate workflows, approved backup jobs, approved failover windows, approved protocol or load-testing activity, and approved business-required egress.

·        This telemetry is required to determine whether containment was complete, whether suspicious activity continued after remediation, whether certificate or credential exposure was scoped, whether appliance instability reflected malicious or operational causes, and whether observed behavior aligned with approved application-delivery operations.

·        Remediation should not be assumed complete unless patch or mitigation state, management/API isolation, exposed processing-function state, appliance health, configuration integrity, virtual services, listeners, backend pools, certificate exposure, credential exposure, administrative state, outbound activity, downstream application behavior, availability, and post-remediation monitoring are explicitly validated.

S32 — Detection Limitations

Detection of edge ADC exploitation is limited by whether the organization can reconstruct the relationship between exposed ADC assets, management/API reachability, traffic-processing exposure, suspicious control-plane requests, suspicious protocol or listener activity, appliance instability, command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, outbound communication, administrative-control activity, availability effects, downstream application behavior, remediation evidence, and approved application-delivery operations. Environments that rely only on vulnerable-version status, scanner findings, public exploit references, single request strings, isolated source IPs, unusual user agents, generic command-injection patterns, malformed protocol traffic, API errors, exposed features, service faults, or appliance banners will not have enough evidence for high-confidence compromise or impact determination.

Primary Limitations

·        Missing ADC asset inventory may prevent identification of ADCs, load balancers, reverse proxies, WAF-adjacent appliances, virtual appliances, cloud-hosted ADC workloads, managed ADC services, high-availability pairs, disaster-recovery appliances, staging appliances, production appliances, business owners, application owners, and public exposure state.

·        Missing management/API exposure inventory may prevent review of administrative interfaces, API endpoints, diagnostic functions, authentication handlers, telemetry endpoints, configuration paths, support paths, partner-reachable paths, and control-plane reachability.

·        Missing listener, virtual-service, protocol-handler, NAT, ALG, traffic-facing-interface, or processing-function inventories may prevent identification of exposed traffic-processing attack surfaces.

·        Missing WAF, reverse-proxy, CDN, load-balancer, gateway, management/API, protocol, flow, NDR, or appliance logs may prevent reliable assessment of suspicious request or traffic-processing activity, source context, destination listener, protocol context, request or message size, transaction behavior, processing outcome, connection state, response behavior, and appliance-health effects.

·        Missing request-body, query-string, protocol-message, or packet metadata preservation may prevent detection of command-delimiter patterns, shell-control content, quote manipulation, encoded command content, malformed JSON, oversized API fields, malformed protocol structures, unusual message sizes, repeated invalid transactions, or exploit-shaped processing behavior.

·        Missing appliance system, shell, diagnostic, process, service-health, runtime, or endpoint telemetry may prevent review of command execution, diagnostic abuse, child-process activity, service-context execution, transfer-tool use, archive activity, package activity, process faults, service crashes, watchdog events, restart or reboot behavior, HA transitions, failover, resource exhaustion, or rare egress by process.

·        Missing configuration-change telemetry may prevent identification of virtual-service changes, backend-pool changes, listener changes, routing changes, rewrite changes, header changes, persistence-profile changes, NAT or ALG changes, health-check changes, WAF-adjacent policy changes, logging changes, administrative-setting changes, or management-exposure changes.

·        Missing certificate-management telemetry may prevent review of certificate access, private-key access, key-store access, TLS-offload changes, certificate-binding changes, SAML material access, OIDC material access, API-token access, or credential-bearing object exposure.

·        Missing DNS, proxy, firewall, NDR, EDR-network, flow, or hosting-provider egress telemetry may prevent assessment of rare outbound communication, suspicious destinations, raw-IP communication, file-transfer behavior, tunneling, repeated callbacks, tool retrieval, or command-and-control-like activity.

·        Missing downstream application logs may prevent review of unexpected backend access, authentication-flow disruption, session-routing changes, header manipulation, traffic-delivery disruption, TLS termination changes, service-account use, internal API access, database access, storage access, backup access, application-administration activity, connection disruption, or availability degradation.

·        Missing change-control, maintenance, vendor-support, patch-validation, monitoring, backup, certificate-rotation, failover, protocol-testing, load-testing, red-team, emergency-maintenance, and incident-response records may prevent reliable false-positive control.

·        Short log retention may prevent reconstruction of the period between suspicious control-plane or traffic-processing activity, appliance instability, command execution, configuration access, certificate access, outbound communication, downstream application anomalies, patching, cleanup, and post-remediation validation.

·        Poor timestamp normalization can break sequence logic between management/API telemetry, protocol telemetry, appliance logs, service-health events, configuration changes, certificate records, network events, downstream application telemetry, change-management records, and remediation evidence.

·        Incomplete appliance, management-interface, traffic-facing-interface, source, forwarded-source, API-path, listener, protocol, virtual-service, backend-pool, certificate-object, configuration-object, administrator, destination, application, and business-owner normalization can prevent reliable correlation across ADC, network, application, and incident-response telemetry.

Detection Boundary

·        A vulnerable ADC version, public exploit reference, KEV status, scanner hit, rare source IP, unusual user agent, suspicious API path, exposed listener, enabled processing feature, appliance banner, command-injection string, malformed protocol event, API error, crash, restart, failover, or resource-exhaustion event is not proof of compromise by itself.

·        Suspicious ADC management/API activity should not be treated as successful exploitation without independent appliance execution, configuration access, certificate access, administrative-control activity, outbound communication, traffic-path manipulation, downstream application impact, or other validated exploitation evidence.

·        Suspicious traffic-processing activity should not be treated as successful exploitation without independent process or service faults, watchdog behavior, restart or reboot, HA transition, failover, resource exhaustion, connection disruption, service unavailability, or downstream application availability impact.

·        Traffic-processing exploitation must not be interpreted as command execution, certificate exposure, credential access, configuration theft, routing manipulation, administrative compromise, rare egress, or downstream system compromise unless independent evidence establishes those outcomes.

·        Appliance command execution should not be attributed to ADC exploitation unless tied to ADC asset, source, management path, API method, request sequence, process context, administrative context, or bounded time-window evidence.

·        Configuration changes, virtual-service changes, backend-pool changes, certificate activity, administrative changes, outbound communication, or downstream application anomalies should not be attributed to ADC compromise without appliance, source, path, configuration object, certificate object, identity, destination, or time-window linkage.

·        Cloud-only anomalies, identity-only anomalies, database-only anomalies, certificate-only anomalies, downstream-application-only anomalies, or network-only anomalies should not be treated as ADC exploitation without validated upstream appliance, control-plane, processing, configuration, availability, or traffic-path context.

·        Legitimate ADC administration, firmware updates, vendor support, protocol testing, load testing, health-check tuning, backup activity, certificate rotation, failover testing, configuration migration, vulnerability validation, monitoring, red-team activity, emergency remediation, and incident-response cleanup can create overlapping signals.

·        Detection logic must not rely on prior alert state, another rule's output, analyst judgment after alert generation, DRI, or TCR as an input.

·        High-confidence control-plane alerting should require validated multi-signal correlation between suspicious management/API behavior and independent execution, configuration, certificate, administrative, egress, traffic-path, or downstream evidence.

·        High-confidence traffic-processing alerting should require suspicious ADC-facing processing activity followed by independent appliance-health, connection, availability, or downstream application-delivery effects.

Operational Impact of Limitations

Detection coverage should be reduced, scoped down, converted to hunt-only logic, or withheld when required telemetry is unavailable, incomplete, delayed, sampled, inconsistently normalized, or unable to support bounded sequence correlation. Suspicious ADC control-plane activity may be analytically important but unsuitable for high-confidence alerting if the organization cannot validate exposure, request sequence, execution, configuration access, certificate exposure, administrative behavior, egress, traffic-path manipulation, or downstream effects. Suspicious traffic-processing activity may likewise be unsuitable for high-confidence alerting if the organization cannot correlate the initiating traffic with the affected appliance, listener, virtual service, protocol or processing function and an independent process, service-health, connection, availability, or downstream application effect.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making ADC asset exposure, control-plane isolation, traffic-processing exposure, appliance execution and resilience, configuration state, certificate handling, virtual-service routing, backend-pool mapping, administrative control, outbound communication, availability, downstream application behavior, and post-remediation activity measurable, governed, and resilient under active edge exploitation pressure. The objective is to prove that suspicious ADC-facing activity can be scoped, correlated, contained, and separated from legitimate application-delivery operations while reducing both management-plane and traffic-processing attack surface.

ADC Asset, Exposure, and Management-Plane Governance

·        Maintain a complete inventory of ADCs, load balancers, reverse proxies, WAF-adjacent appliances, hardware appliances, virtual appliances, cloud-hosted ADC workloads, managed ADC services, high-availability pairs, disaster-recovery appliances, staging appliances, production appliances, management interfaces, API endpoints, traffic-facing interfaces, virtual services, listeners, backend pools, protocol handlers, NAT or ALG functions, business owners, application owners, certificate owners, and administrator owners.

·        Maintain a complete inventory of exposed management/API, administrative, diagnostic, authentication, telemetry, configuration, support, control-plane, listener, virtual-service, protocol-processing, NAT, and ALG surfaces, including internet-facing paths, partner-reachable paths, VPN-restricted paths, privileged-access paths, vendor-support paths, and internal-only paths.

·        Prioritize remediation for ADCs and load balancers supporting customer portals, authentication-fronting services, TLS termination, regulated applications, partner workflows, payment-adjacent processes, public web applications, support services, file-transfer paths, specialized protocols, high-availability applications, and multiple downstream services.

·        Require auditable change control for ADC patching, firmware updates, management/API isolation, traffic-processing configuration, access-control changes, virtual-service changes, listener changes, backend-pool changes, routing changes, NAT or ALG changes, health-check changes, certificate rotation, backup activity, failover testing, vendor support, emergency maintenance, and incident-response cleanup.

·        Treat unknown ADC ownership, unknown API exposure, unknown management-interface reachability, unknown exposed listener or processing-function state, unknown patch or mitigation state, unknown certificate ownership, or unknown downstream application mapping as enterprise application-delivery trust risk until resolved.

Management/API Isolation and Access Hardening

·        Restrict ADC management/API access to approved administrative networks, VPN paths, privileged-access workflows, documented partner-reachable paths, and monitored vendor-support paths where operationally feasible.

·        Disable, isolate, or restrict unnecessary ADC APIs, diagnostic functions, support functions, administrative interfaces, telemetry endpoints, configuration endpoints, and management paths where operationally feasible.

·        Require strong administrative authentication, role-based administration, MFA where supported, privileged-access controls, session monitoring, source restrictions, and auditable approval for high-risk ADC administrative activity.

·        Baseline approved ADC administrators, API clients, automation accounts, monitoring systems, vendor-support sources, vulnerability scanners, patch-validation tools, backup jobs, certificate-management workflows, failover workflows, and maintenance windows.

·        Treat unauthenticated, external, unusual, partner-originated, or non-administrative access to ADC control-plane paths as high-priority investigation context when followed by appliance execution, configuration access, certificate access, administrative activity, rare egress, traffic-path changes, or downstream anomalies.

Traffic-Processing Surface and Protocol Hardening

·        Maintain an approved inventory of internet-facing and partner-reachable listeners, virtual services, protocols, protocol handlers, NAT functions, ALGs, and other traffic-processing features.

·        Disable or restrict unnecessary listeners, protocols, ALGs, NAT processing features, protocol helpers, legacy processing functions, and unused application-delivery services where operationally feasible.

·        Limit externally reachable processing functions to business-required interfaces, destinations, ports, protocols, and virtual services.

·        Apply vendor-supported patches, mitigations, feature restrictions, or configuration changes to vulnerable traffic-processing components according to business-criticality and exposure.

·        Monitor malformed, oversized, abnormal, repeated, protocol-inconsistent, fuzzing-like, or exploit-shaped traffic targeting exposed processing surfaces.

·        Correlate suspicious traffic-processing behavior with appliance process or service faults, watchdog events, restart or reboot behavior, HA transitions, failover, resource exhaustion, connection disruption, service unavailability, and downstream application availability.

·        Treat protocol anomalies, exposed listeners, enabled ALGs, NAT configuration, individual crashes, restarts, or failovers as investigative context rather than proof of exploitation.

·        Baseline legitimate protocol testing, load testing, application-health checks, partner traffic, failover exercises, and other high-volume or abnormal-but-approved traffic patterns.

Configuration, Virtual-Service, and Traffic-Path Hardening

·        Maintain known-good configuration baselines for ADC appliances, virtual services, backend pools, listener ports, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, NAT or ALG settings, health checks, WAF-adjacent policies, proxy policies, logging settings, administrative settings, and management-access restrictions.

·        Monitor new, modified, deleted, exported, downloaded, or replaced configuration objects, virtual services, backend pools, listeners, routing rules, rewrite rules, header rules, persistence profiles, NAT or ALG settings, health checks, certificate bindings, logging settings, and security-control policies.

·        Require approval and documentation for virtual-service changes, backend-pool changes, listener changes, route changes, header changes, rewrite changes, NAT or ALG changes, certificate-binding changes, TLS-offload changes, health-check changes, failover actions, and emergency routing updates.

·        Compare current appliance configuration against known-good backups and approved change records after suspicious control-plane activity or independently confirmed appliance compromise.

·        Treat unexplained configuration drift, virtual-service changes, backend-pool changes, traffic-routing changes, logging degradation, or weakened management restrictions after suspicious ADC activity as high-priority investigation context.

·        Do not infer configuration or routing manipulation solely from traffic-processing exploitation or appliance instability without supporting configuration or administrative evidence.

Certificate, Credential, and Sensitive Object Hardening

·        Protect and monitor TLS certificates, private keys, key stores, certificate bindings, SSL/TLS offload settings, SAML material, OIDC material, API tokens, administrative credentials, backend credentials, configuration exports, backup archives, diagnostic bundles, packet captures, and credential-bearing appliance files.

·        Restrict certificate export, private-key access, API-token access, diagnostic-bundle creation, packet-capture creation, configuration export, and backup-archive access to approved users, workflows, systems, and maintenance windows.

·        Require certificate and credential review or rotation when suspicious control-plane or independently confirmed appliance-compromise activity aligns with command execution, configuration access, certificate access, backup export, diagnostic-bundle creation, packet-capture activity, rare egress, administrative-control changes, or incomplete containment.

·        Monitor certificate-binding changes, TLS-offload changes, private-key access, key-store access, SAML or OIDC material access, API-token access, backup-archive access, and diagnostic-bundle access after suspicious control-plane activity.

·        Treat certificate exposure, private-key exposure, API-token exposure, or administrative-credential exposure as scope-expansion conditions affecting downstream applications and trust paths.

·        Do not infer certificate or credential exposure from traffic-processing anomalies, crashes, failover, or service instability alone.

Network, Source, Egress, and Downstream Application Hardening

·        Enrich WAF, firewall, proxy, DNS, NDR, reverse-proxy, CDN, load-balancer, appliance, endpoint-adjacent, protocol, flow, and downstream application telemetry with ADC asset identity, management interface, traffic-facing interface, listener, protocol, processing function, virtual service, backend pool, source reputation, ASN, geography, network type, request or transaction context, response metadata, destination context, certificate context, application owner, business owner, and approved-source status.

·        Monitor rare inbound sources, suspicious ASNs, cloud-hosted infrastructure, residential proxy infrastructure, VPN-provider infrastructure, scanner infrastructure, geographically inconsistent access paths, abnormal request timing, repeated API attempts, malformed protocol activity, unusual transaction patterns, and low-and-slow probing against ADC control-plane and traffic-processing surfaces.

·        Monitor outbound traffic from ADC appliances for rare destinations, raw-IP communication, file-transfer behavior, SSH, SMTP, newly observed domains, low-reputation infrastructure, unusual ports, unexpected protocols, repeated callbacks, and traffic inconsistent with approved vendor support, updates, license validation, telemetry, monitoring, DNS, NTP, syslog, backup, health-check, integration, or downstream application behavior.

·        Review downstream applications for unexpected backend access, authentication-flow disruption, session-routing changes, header manipulation, traffic-delivery disruption, TLS termination changes, unusual service-account use, internal API access, database access, storage access, backup access, application-administration activity, connection disruption, and availability degradation after suspicious ADC behavior.

·        Treat network and downstream telemetry as supporting context rather than standalone proof of ADC exploitation, command execution, certificate exposure, routing manipulation, data theft, or downstream compromise.

Incident Response and Containment Hardening

·        Create response procedures for suspicious ADC management/API activity, suspicious traffic-processing activity, exploit-attempt behavior, appliance instability, service or process faults, command execution, configuration access, certificate access, virtual-service manipulation, backend-pool changes, outbound communication, administrative-control changes, availability degradation, downstream application anomalies, and post-remediation activity.

·        Require responders to validate affected appliance, version and mitigation state, management/API exposure, affected control-plane path where applicable, affected listener or processing function where applicable, suspicious source, request or protocol behavior, appliance instability, command execution where present, configuration state, virtual-service state, backend-pool mapping, certificate exposure, credential exposure, administrative state, outbound communication, downstream application impact, business owner, data sensitivity, availability state, and remediation status.

·        Prepare decision paths for emergency patching, management-plane isolation, API restriction, exposed-listener restriction, protocol or processing-feature mitigation, configuration restoration, virtual-service review, backend-pool validation, certificate review, credential rotation, administrative-account review, egress blocking, downstream application review, vendor escalation, legal and compliance escalation, cyber-insurance coordination, communications planning, executive reporting, and customer or partner trust management.

·        Treat suspected ADC command execution or certificate exposure as an application-delivery trust, traffic-path integrity, certificate-exposure, administrative-control, downstream-application, and containment-validation incident.

·        Treat suspicious traffic-processing activity followed by independent appliance instability, service failure, connection disruption, failover, resource exhaustion, or availability degradation as an application-delivery resilience and availability incident requiring validation of affected traffic paths and dependent applications.

·        Require post-event validation to distinguish approved ADC administration, firmware updates, certificate rotation, health-check changes, protocol testing, load testing, failover testing, backup activity, vendor support, vulnerability validation, red-team activity, emergency maintenance, and incident-response cleanup from attacker-driven behavior.

S34 — Defensive Control & Hardening Architecture

Figure 6

Edge ADC exploitation and application-delivery trust compromise defensive architecture showing ADC asset governance, control-plane isolation, traffic-processing exposure governance, appliance execution and resilience monitoring, configuration and virtual-service integrity, certificate and credential protection, outbound and downstream application monitoring, SOC correlation, incident-response containment, and executive application-delivery trust restoration.

The defensive architecture should treat ADCs, load balancers, reverse proxies, WAF-adjacent appliances, and traffic-management systems as governed application-delivery trust infrastructure rather than isolated network appliances or routine patch-management assets. The architecture must connect ADC asset inventory, management/API exposure mapping, traffic-processing exposure mapping, access governance, appliance and service-health telemetry, configuration integrity, virtual-service governance, certificate protection, outbound monitoring, downstream application review, incident-response containment, and executive trust decisioning into one ADC-facing-activity-to-impact assurance model.

Architecture Layer One — ADC Asset and Exposure Governance

ADC asset and exposure governance establishes which ADC, load-balancer, reverse-proxy, WAF-adjacent, and traffic-management appliances exist; which are internet-facing or partner-reachable; which management/API surfaces, listeners, virtual services, protocol handlers, NAT functions, ALGs, and other processing functions are exposed; which virtual services and backend pools depend on each appliance; which certificates and credentials are present; and which business workflows require protection. This layer captures appliance identity, platform family, version, patch or mitigation state, exposure state, management interface, traffic-facing interface, API endpoint, listener, protocol, processing function, virtual service, backend pool, environment, region, business owner, application owner, certificate owner, administrator owner, and remediation status.

Architecture Layer Two — Management/API Access Visibility

Management/API access visibility determines whether suspicious external activity remained routine scanning or became exploit-relevant control-plane behavior. This layer captures WAF events, management/API logs, reverse-proxy records, CDN records, load-balancer records, HTTP method, URI path, query string, source IP, forwarded source IP, user agent, request size, response size, content type, status code, API method, endpoint family, failed-to-success sequences, API-handler errors, response instability, and maintenance-window context.

Architecture Layer Three — Traffic-Processing and Protocol Visibility

Traffic-processing and protocol visibility determines whether suspicious activity targeted exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or other packet and application-processing components. This layer captures traffic-facing interface, destination IP and port, listener, virtual service, protocol, application protocol, processing function, NAT or ALG context, source identity, request or message size, transaction or session context, protocol-validation outcome, abnormal or repeated requests, retransmissions, resets, timeouts, connection state, processing disposition, and approved protocol or load-testing context.

Architecture Layer Four — Appliance Execution, Stability, and Availability Monitoring

Appliance execution, stability, and availability monitoring determines whether suspicious ADC-facing activity resulted in command execution, diagnostic abuse, process or service failure, watchdog behavior, restart or reboot, HA transition, failover, resource exhaustion, connection disruption, or application-delivery unavailability. This layer captures appliance syslog, management-service faults, API-handler errors, protocol-handler faults, diagnostic utility execution, shell activity, script execution, transfer-tool activity, archive activity, package behavior, process faults, watchdog events, service restarts, reboots, HA events, failover events, resource-pressure conditions, and endpoint telemetry where available.

Traffic-processing activity should not be interpreted as command execution unless execution telemetry independently establishes that outcome.

Architecture Layer Five — Configuration and Traffic-Path Integrity

Configuration and traffic-path integrity determines whether validated appliance compromise altered application delivery. This layer captures virtual services, listener configuration, real-server pools, backend pools, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, NAT or ALG configuration, health checks, WAF-adjacent policies, proxy policies, logging settings, administrative settings, access-control settings, configuration exports, backup comparison, known-good configuration baselines, and approved change records.

Configuration or routing manipulation must not be inferred solely from traffic-processing anomalies, process faults, crashes, restarts, or failover.

Architecture Layer Six — Certificate, TLS, and Credential Protection

Certificate, TLS, and credential protection determines whether control-plane exploitation or independently confirmed appliance compromise affected trust material or privileged appliance objects. This layer captures TLS certificates, private keys, key stores, certificate bindings, SSL/TLS offload settings, SAML material, OIDC material, API tokens, administrative credentials, backend credentials, backup archives, diagnostic bundles, packet captures, configuration exports, key-rotation workflows, certificate-renewal workflows, and approved certificate-management context.

Architecture Layer Seven — Network Egress and Internal Service Monitoring

Network egress and internal-service monitoring determines whether an appliance with validated post-exploitation control became a callback source, staging point, exfiltration path, or bridge into internal services. This layer captures DNS queries, proxy events, firewall events, NDR metadata, outbound HTTP or HTTPS, raw-IP communication, SSH, SMTP, file-transfer behavior, tunneling, repeated callbacks, tool retrieval, internal management-service access, destination reputation, first-seen destination context, and approved ADC egress baselines.

Rare egress should not be attributed to traffic-processing exploitation unless independent evidence establishes appliance execution or another post-exploitation path.

Architecture Layer Eight — Downstream Application and Backend Trust Review

Downstream application and backend trust review determines whether suspicious ADC activity affected applications behind the application-delivery layer. This layer captures backend access, authentication-flow behavior, session routing, header behavior, TLS termination behavior, service-account use, internal API access, database access, storage access, backup access, application-administration activity, application response behavior, connection disruption, availability impact, virtual-service mapping, backend-pool mapping, listener or protocol context, and application-owner validation.

Traffic-processing exploitation may create downstream availability, connection-handling, or traffic-delivery impact without establishing downstream compromise or administrative access.

Architecture Layer Nine — SOC Correlation and False-Positive Control

SOC correlation joins ADC asset context, control-plane exposure, traffic-processing exposure, management/API telemetry, protocol telemetry, appliance-health data, configuration state, certificate access, administrative context, outbound communication, downstream application behavior, change-control records, vendor-support records, patch-validation activity, protocol testing, load testing, monitoring activity, red-team activity, maintenance windows, and business-workflow baselines. This layer determines whether activity is attacker-driven, scanner-driven, administrator-driven, vendor-support-driven, application-driven, monitoring-related, maintenance-related, validation-related, red-team-related, emergency-change-related, or incident-response-related.

Architecture Layer Ten — Incident Response and Executive Trust Workflow

Incident-response and executive-trust workflow connects technical validation to business decisions. This layer captures incident severity, affected appliances, affected versions or mitigation states, affected management/API paths, affected listeners or processing functions, affected configuration objects, affected certificates, affected credentials, affected virtual services, affected backend pools, affected downstream applications, appliance-health impact, containment actions, patch validation, management-plane isolation, processing-function restriction, configuration restoration, certificate rotation, credential rotation, downstream application review, legal review, compliance review, cyber-insurance coordination, communications planning, executive reporting, board-level assurance, and validation that application-delivery services can safely remain online.

Architecture Outcome

The architecture should enable the organization to answer seven questions during an ADC exploitation and application-delivery trust incident:

·        Which ADC appliance, management interface, API path, traffic-facing interface, listener, protocol, processing function, configuration object, certificate object, virtual service, backend pool, downstream application, administrative account, credential source, outbound destination, business owner, or remediation action was affected?

·        Did the activity align with approved ADC administrators, vendor support, vulnerability scanners, patch-validation sources, protocol testing, load testing, monitoring systems, certificate-management workflows, backup jobs, failover testing, maintenance windows, emergency changes, red-team activity, or incident-response activity?

·        Did suspicious control-plane activity transition into command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, backend-pool changes, outbound communication, administrative-control compromise, or downstream application exposure?

·        Did suspicious traffic-processing activity transition into process or service faults, watchdog behavior, restart or reboot, HA transition, failover, resource exhaustion, connection disruption, service unavailability, or downstream availability impact?

·        Did the activity affect customer portals, authentication-fronting services, TLS termination, regulated applications, partner workflows, payment-adjacent processes, public web applications, support services, file-transfer paths, specialized protocols, high-availability services, or multiple downstream applications?

·        Can the organization patch, mitigate, or isolate affected appliances, restrict management/API access or vulnerable processing functions, validate configuration integrity, review virtual services and listeners, validate backend pools, inspect certificate exposure, rotate credentials where warranted, preserve evidence, and restore application-delivery availability without over-attributing unrelated operational activity to exploitation?

·        Can leadership make defensible decisions about appliance availability, certificate exposure, credential exposure, routing integrity, downstream application trust, customer or partner impact, regulatory review, cyber-insurance coordination, notification analysis, and application-delivery trust restoration?

S35 — Defensive Control Mapping Matrix

Preventive Controls

·        Maintain complete inventory of ADCs, load balancers, reverse proxies, WAF-adjacent appliances, virtual appliances, cloud-hosted ADC workloads, managed ADC services, high-availability pairs, management interfaces, API endpoints, traffic-facing interfaces, listeners, protocol handlers, NAT or ALG functions, virtual services, backend pools, certificates, administrator owners, application owners, business owners, patch or mitigation state, exposure state, and downstream application dependencies.

·        Enforce timely ADC patching and vendor mitigation, management/API isolation, unnecessary API disablement, unnecessary listener or processing-function restriction, administrative source restrictions, privileged-access workflows, role-based administration, MFA where supported, vendor-support restrictions, and change-control validation.

·        Restrict ADC management/API, diagnostic, configuration, certificate-management, backup, support, telemetry, and administrative functions to approved users, approved sources, approved workflows, and monitored maintenance windows.

·        Disable or restrict unnecessary exposed listeners, protocols, protocol helpers, ALGs, NAT functions, legacy processing components, and unused application-delivery services where operationally feasible.

·        Harden virtual-service changes, listener changes, backend-pool changes, routing rules, rewrite rules, header rules, persistence profiles, NAT or ALG configuration, health checks, WAF-adjacent policies, proxy policies, TLS-offload settings, certificate bindings, logging settings, and management-access restrictions.

·        Maintain allowlists for approved ADC administrators, vendor-support sources, partner administrators, vulnerability scanners, patch-validation sources, automation accounts, monitoring systems, backup destinations, update destinations, license-validation destinations, telemetry destinations, DNS, NTP, syslog, health-check destinations, integration destinations, and business-required egress.

·        Prioritize preventive controls for ADCs supporting customer portals, authentication-fronting services, TLS termination, regulated applications, partner workflows, payment-adjacent processes, public web applications, support services, file-transfer paths, specialized protocol processing, high-availability services, and multiple downstream applications.

Detective Controls

·        Monitor unauthenticated, external, partner-originated, unusual, or non-administrative requests to ADC management, API, administrative, authentication, diagnostic, telemetry, configuration, or control-plane endpoints.

·        Monitor malformed, oversized, abnormal, repeated, protocol-inconsistent, fuzzing-like, or exploit-shaped traffic targeting exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or other traffic-processing components.

·        Monitor command-delimiter patterns, shell-control content, quote manipulation, encoded command content, malformed management requests, oversized API fields, unusual API parameters, abnormal methods, failed-to-success sequences, abnormal status-code patterns, response-size deviations, API-handler errors, authentication-handler errors, and management-service faults.

·        Monitor process or service faults, protocol-handler faults, watchdog events, service restarts, reboots, HA transitions, failover, resource exhaustion, connection disruption, service-unavailable conditions, and downstream availability changes after suspicious traffic-processing activity.

·        Monitor appliance-level command execution, shell activity, script execution, diagnostic-utility abuse, transfer-tool activity, archive-tool activity, package activity, command-output files, service-context execution, and short-lived process behavior after suspicious control-plane activity.

·        Monitor configuration exports, backup files, diagnostic bundles, packet captures, virtual-service objects, listener configuration, backend pools, routing rules, rewrite rules, header rules, persistence profiles, NAT or ALG configuration, health checks, WAF-adjacent policies, proxy policies, authentication templates, logging settings, and administrative settings.

·        Monitor TLS certificate access, private-key access, key-store access, certificate-binding changes, SSL/TLS offload changes, SAML or OIDC material access, API-token access, administrative-credential access, and credential-bearing appliance-file access.

·        Monitor DNS, proxy, firewall, EDR-network, NDR, and flow telemetry for rare destinations, raw-IP communication, file-transfer behavior, SSH, SMTP, newly observed domains, low-reputation infrastructure, repeated callbacks, internal management-service access, and traffic inconsistent with approved ADC behavior.

·        Monitor downstream application logs for unexpected backend access, authentication-flow disruption, session-routing changes, header manipulation, traffic-delivery disruption, TLS changes, service-account use, internal API access, database access, storage access, backup access, application-administration activity, connection disruption, and availability degradation.

·        Require multi-signal control-plane-to-impact or traffic-processing-to-independent-health/availability correlation before high-confidence exploitation determination.

Responsive Controls

·        Patch or mitigate affected ADCs, isolate management/API surfaces where necessary, disable unnecessary APIs, restrict vulnerable listeners or processing functions, restrict partner-reachable exposure, and validate affected appliance state.

·        Preserve ADC management/API logs, protocol telemetry, WAF records, reverse-proxy logs, CDN logs, load-balancer records, appliance syslog, service-health events, administrative audit logs, configuration-change records, certificate-management records, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, downstream application logs, change-management records, backup comparison data, and remediation evidence before log rotation or cleanup.

·        Inspect appliance configuration, virtual services, listeners, backend pools, routing rules, rewrite rules, header rules, persistence profiles, NAT or ALG settings, health checks, WAF-adjacent policies, proxy policies, logging settings, administrative settings, and management-access restrictions.

·        Review certificates, private keys, key stores, certificate bindings, SSL/TLS offload settings, SAML material, OIDC material, API tokens, administrative credentials, backend credentials, backup archives, diagnostic bundles, packet captures, and configuration exports when control-plane compromise or other independent evidence warrants trust-material review.

·        Rotate administrative credentials, API keys, certificate material, private keys, backend credentials, service credentials, monitoring credentials, vendor-support credentials, deployment secrets, and reused credentials when exposure cannot be ruled out through evidence.

·        Review outbound communication, rare destinations, callbacks, tool retrieval, internal management-service access, firewall actions, proxy actions, DNS queries, NDR behaviors, and egress that deviates from approved ADC behavior when post-exploitation control is suspected.

·        Review downstream applications for backend access, authentication-flow disruption, session-routing changes, header manipulation, traffic-delivery disruption, TLS termination changes, service-account use, internal API access, database access, storage access, backup access, application-administration activity, connection disruption, and availability impact.

·        Perform legal and compliance review, cyber-insurance coordination, communications planning, customer or partner notification analysis, executive reporting, and board-level application-delivery trust assurance where certificate exposure, credential access, regulated application impact, downstream exposure, customer-facing disruption, or incomplete containment is suspected.

·        Confirm that initiating ADC-facing activity, appliance state, service health, configuration integrity, certificate exposure where relevant, credential exposure where relevant, outbound communication where relevant, downstream application behavior, availability, and post-remediation monitoring support closure before the incident is considered contained.

Governance Controls

·        Maintain approved inventories for ADC appliances, management interfaces, API endpoints, traffic-facing interfaces, listeners, protocols, processing functions, virtual services, backend pools, certificates, private keys, administrators, API clients, automation accounts, vendor-support sources, partner administrators, monitoring systems, patch-validation systems, business owners, application owners, certificate owners, and downstream application dependencies.

·        Maintain approved workflows for ADC administration, firmware updates, patching, mitigation, vendor support, protocol testing, load testing, certificate rotation, listener or processing-function changes, virtual-service changes, backend-pool changes, routing changes, health-check tuning, failover testing, backups, monitoring, vulnerability validation, red-team activity, emergency maintenance, incident-response cleanup, configuration restoration, credential rotation, and downstream application validation.

·        Require change-control records for ADC patching, management/API isolation, API enablement or disablement, exposed-listener changes, protocol-processing changes, NAT or ALG changes, virtual-service changes, backend-pool changes, routing changes, rewrite changes, header changes, health-check changes, TLS-offload changes, certificate-binding changes, logging changes, administrative changes, vendor-support activity, and emergency remediation.

·        Maintain separate escalation criteria for suspicious control-plane access and suspicious traffic-processing activity.

·        Escalate control-plane activity when it aligns with command execution, configuration access, certificate exposure, private-key exposure, virtual-service manipulation, backend-pool changes, outbound communication, administrative-control changes, or downstream application anomalies.

·        Escalate traffic-processing activity when it aligns with independent process or service faults, watchdog events, restart or reboot, HA transition, failover, resource exhaustion, connection disruption, service unavailability, or downstream application availability degradation.

·        Track ADC exploitation and application-delivery trust risk in the risk register when telemetry, patching or mitigation, control-plane isolation, processing-surface governance, certificate protection, configuration visibility, appliance-health visibility, outbound monitoring, downstream application mapping, or response gaps create unresolved enterprise risk.

Control Mapping Summary

The strongest control posture combines prevention of unnecessary control-plane and traffic-processing exposure, detection of suspicious ADC-facing activity followed by independent appliance or trust-boundary effects, and response workflows that restore application-delivery trust, appliance availability, certificate confidence where affected, routing integrity where affected, administrative control where affected, downstream application assurance, and business continuity. Controls should be prioritized for ADC environments supporting customer portals, authentication-fronting services, TLS termination, partner workflows, regulated applications, payment-adjacent processes, public web applications, support services, file-transfer paths, specialized protocols, high-availability services, and multiple downstream applications.

S36 — CyberDax Intelligence Maturity Assessment

Current Intelligence Maturity

Moderate

Maturity Rationale

Edge ADC exploitation is a well-defined behavior class, but organization-specific maturity depends on whether suspicious control-plane and traffic-processing activity can be correlated with independent appliance, service-health, configuration, certificate, administrative, network, availability, and downstream application evidence. Many environments can identify exposed ADCs, vulnerable versions, internet scanning, suspicious management/API requests, malformed protocol traffic, or appliance faults, but fewer can prove whether suspicious ADC activity resulted in command execution, service instability, configuration manipulation, certificate exposure, routing impact, availability degradation, downstream application exposure, or containment failure.

Strengths

·        The behavior pattern is durable because it focuses on externally reachable ADC functionality and observable impact rather than one scanner fingerprint, actor name, source IP, request path, user agent, protocol, endpoint label, payload, response code, vulnerable-version finding, proof-of-concept reference, KEV status, or static IOC.

·        The control-plane sequence is analytically clear: edge ADC discovery, management/API exploitation, appliance-level command execution where achieved, configuration or certificate access where present, traffic-path manipulation, outbound communication, downstream application exposure, and post-remediation trust validation.

·        The traffic-processing sequence is analytically distinct: exposed listener or processing-function discovery, suspicious or exploit-shaped traffic, independent process or service faults, restart or failover, resource exhaustion, connection disruption, availability degradation, and downstream application-delivery impact.

·        Detection opportunities are strong where ADC asset inventory, management/API exposure mapping, listener and processing-function mapping, management telemetry, protocol telemetry, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, service-health telemetry, configuration-change records, certificate-management records, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, downstream application logs, change-control records, and business context can be correlated.

·        Defensive controls can be mapped directly to exposure governance, management/API isolation, traffic-processing surface reduction, patch and mitigation validation, appliance execution visibility, appliance-health monitoring, configuration integrity, certificate protection, outbound monitoring, downstream application review, SOC triage, and incident-response containment.

Maturity Gaps

·        ADC asset inventory may not reliably identify ADCs, load balancers, reverse proxies, WAF-adjacent appliances, virtual appliances, cloud-hosted ADC workloads, managed ADC services, high-availability pairs, business owners, application owners, certificate owners, or public exposure state.

·        Management/API exposure mapping may not reliably identify administrative interfaces, API endpoints, diagnostic functions, authentication handlers, telemetry endpoints, configuration paths, support paths, partner-reachable paths, and control-plane reachability.

·        Traffic-processing exposure mapping may not reliably identify traffic-facing interfaces, listeners, virtual services, protocols, protocol handlers, NAT functions, ALGs, exposed processing functions, or their downstream application dependencies.

·        WAF, reverse-proxy, CDN, load-balancer, gateway, management/API, protocol, flow, and appliance telemetry may not preserve enough source, destination, URI, listener, protocol, request or message size, transaction, connection-state, processing-outcome, response, or timestamp detail for complete reconstruction.

·        Appliance system, process, diagnostic, shell, runtime, and service-health telemetry may not preserve sufficient command-execution, process-lineage, command-line, service-context, diagnostic activity, process-fault, watchdog, restart, reboot, HA, failover, resource-pressure, or connection-disruption evidence.

·        Configuration-change telemetry may not preserve sufficient virtual-service, backend-pool, listener, route, rewrite, header, persistence-profile, NAT or ALG, health-check, certificate-binding, logging-setting, administrative-setting, or management-access detail.

·        Certificate-management telemetry may not preserve sufficient certificate-object, private-key, key-store, TLS-offload, certificate-binding, SAML, OIDC, API-token, backup, diagnostic-bundle, packet-capture, or credential-bearing-object detail.

·        DNS, proxy, firewall, NDR, EDR-network, and flow telemetry may not reliably connect outbound behavior to the affected ADC appliance, virtual-appliance host, management host, workload identity, source interface, or process context.

·        Downstream application telemetry may be limited, inconsistently retained, or disconnected from ADC asset, virtual-service, listener, protocol, backend-pool, route, header, session, authentication-flow, availability, and business-owner context.

·        Incident-response, SOAR, vulnerability-management, vendor-support, change-control, and remediation records may not consistently document patch or mitigation validation, management/API isolation, processing-function restriction, certificate review, credential rotation, configuration restoration, service-health validation, downstream application review, or post-remediation monitoring.

·        Business-workflow baselines for ADC administrators, vendor support, partner access, automation, monitoring, protocol testing, load testing, certificate rotation, backup activity, health-check tuning, failover testing, patch validation, red-team activity, emergency maintenance, and incident-response cleanup may be insufficient for false-positive control.

·        Organizations may over-rely on patch status, scanner alerts, vulnerable-version names, public exploit reporting, single source IPs, suspicious API paths, malformed protocol events, isolated appliance faults, or KEV status rather than validating the full ADC-facing-activity-to-impact sequence.

·        Multi-asset campaign detection maturity is stronger for control-plane probing than for traffic-processing activity where no dedicated cross-appliance processing-campaign correlation has been implemented.

Maturity Improvement Priorities

·        Normalize ADC asset inventory, public exposure mapping, management/API exposure mapping, traffic-facing-interface mapping, listener and protocol mapping, processing-function mapping, patch or mitigation state, virtual-service mapping, backend-pool mapping, certificate inventory, administrator ownership, business ownership, application ownership, and downstream application sensitivity.

·        Improve management/API logging, WAF logging, reverse-proxy logging, CDN logging, load-balancer logging, URI preservation, query-string retention, request-body metadata where available, source-IP preservation, forwarded-source preservation, response metadata, API-method capture, endpoint-family mapping, and timestamp normalization.

·        Improve protocol and traffic-processing telemetry, including listener identity, protocol context, message or request size, processing result, transaction or session lineage, connection state, retransmission, reset, timeout, and processing-function mapping.

·        Improve appliance system telemetry, diagnostic telemetry, shell telemetry, runtime telemetry where available, command-execution visibility, service-context mapping, process- and service-fault capture, watchdog events, restart and reboot events, HA transitions, failover events, resource-pressure events, connection disruption, and virtual-appliance endpoint tagging.

·        Improve configuration telemetry, known-good baseline management, backup comparison, virtual-service integrity monitoring, backend-pool integrity monitoring, listener monitoring, routing-rule monitoring, rewrite-rule monitoring, header-rule monitoring, NAT or ALG monitoring, persistence-profile monitoring, health-check monitoring, logging-setting monitoring, and management-access restriction monitoring.

·        Improve certificate-management visibility, private-key access monitoring, key-store access monitoring, certificate-binding monitoring, TLS-offload monitoring, SAML or OIDC material monitoring, API-token monitoring, credential-bearing-object monitoring, and certificate-owner mapping.

·        Improve DNS, proxy, firewall, NDR, EDR-network, flow, downstream application, backend service, identity service, database service, storage service, backup service, application-administration, connection-health, and availability correlation.

·        Improve remediation evidence capture for ADC patch or mitigation validation, management/API isolation, processing-function restriction, configuration review, virtual-service and listener review, backend-pool validation, certificate review, credential rotation, administrative-account review, appliance-health validation, outbound review, downstream application review, vendor escalation, and post-remediation monitoring.

·        Improve baselines for ADC administration, firmware updates, vendor support, partner administration, monitoring, backups, certificate rotation, protocol testing, load testing, health-check tuning, failover testing, configuration migration, vulnerability validation, red-team activity, emergency remediation, incident-response cleanup, and approved outbound destinations.

·        Add ADC exploitation validation steps to SOC, network engineering, application owner, infrastructure, vulnerability management, incident response, legal, compliance, privacy, cyber-insurance, communications, business-continuity, customer-impact, partner-impact, and executive reporting workflows.

Maturity Outlook

Maturity can improve materially when the organization prioritizes ADC asset inventory completeness, management/API and traffic-processing exposure mapping, access restriction, protocol and request telemetry retention, appliance-health visibility, configuration baselines, certificate inventory, certificate-access visibility, virtual-service and listener mapping, backend-pool mapping, outbound monitoring, downstream application correlation, vendor-support baselining, change-control completeness, and SOC workflows that connect suspicious ADC-facing activity to independent appliance, configuration, certificate, administrative, network, availability, and downstream application evidence.

S37 — Strategic Defensive Improvements

Strategic improvement should reduce the likelihood that attackers can abuse exposed ADC control-plane or traffic-processing functionality to create command execution, appliance instability, configuration exposure, certificate risk, routing impact, availability degradation, downstream application impact, containment uncertainty, or business-continuity loss without detection. The objective is measurable ADC-facing-activity-to-impact resilience and application-delivery trust governance, not patch response alone.

Priority One — Establish Edge Application-Delivery Trust as a Security Metric

·        Define measurable assurance metrics for ADC asset inventory completeness, management/API exposure mapping, traffic-processing exposure mapping, patch or mitigation state, public and partner reachability, management-plane isolation, listener and protocol inventory, appliance-health telemetry coverage, configuration baseline coverage, virtual-service mapping, backend-pool mapping, certificate inventory, certificate-access visibility, outbound monitoring, downstream application mapping, availability monitoring, and post-remediation monitoring.

·        Track resilience completeness for ADC environments supporting customer portals, authentication-fronting services, TLS termination, regulated applications, partner workflows, payment-adjacent processes, public web applications, support services, file-transfer paths, specialized protocol processing, high-availability services, and multiple downstream applications.

·        Report unresolved ADC exposure, unknown API reachability, unknown listener or processing-function exposure, weak management-plane isolation, incomplete request or protocol logging, weak appliance-health telemetry, weak configuration baselines, incomplete certificate visibility, unclear virtual-service ownership, weak outbound monitoring, incomplete downstream application mapping, and post-remediation uncertainty as enterprise risk.

·        Treat unexplained ADC control-plane activity, suspicious traffic-processing activity, appliance instability, command execution, configuration access, certificate exposure, virtual-service manipulation, backend-pool changes, outbound communication, availability degradation, downstream anomalies, or post-remediation activity affecting high-value application-delivery infrastructure as executive-relevant trust issues.

Priority Two — Harden ADC Exposure, Management/API Access, and Traffic-Processing Governance

·        Maintain live inventory of ADCs, load balancers, reverse proxies, WAF-adjacent appliances, virtual appliances, cloud-hosted ADC workloads, managed ADC services, high-availability pairs, public and partner exposure state, management interfaces, API endpoints, traffic-facing interfaces, listeners, protocols, processing functions, virtual services, backend pools, certificate inventory, administrator owners, business owners, application owners, and downstream application sensitivity.

·        Enforce vendor remediation, ADC patch or mitigation validation, management/API isolation, unnecessary API disablement, unnecessary listener or processing-function restriction, administrative source restrictions, privileged-access workflows, role-based administration, MFA where supported, vendor-support restrictions, partner-access restrictions, monitoring validation, and change-control validation by business criticality and application-delivery sensitivity.

·        Harden administrative interfaces, API endpoints, diagnostic functions, authentication handlers, telemetry endpoints, configuration paths, support functions, certificate-management functions, backup functions, listener configuration, protocol handlers, NAT or ALG functions, and management-access restrictions.

·        Validate that ADC operations can distinguish approved firmware updates, patch validation, vendor support, health-check tuning, protocol testing, load testing, certificate rotation, backup activity, failover testing, monitoring activity, red-team activity, emergency maintenance, and incident response from attacker-relevant access or traffic.

·        Reduce broad or informal exceptions that allow high-value ADCs or sensitive application-delivery infrastructure to remain exposed to unnecessary public management access, unnecessary processing functions, weak API controls, incomplete logging, unclear certificate ownership, or unresolved application-delivery risk.

Priority Three — Improve ADC Request, Protocol, Appliance, Configuration, and Certificate Visibility

·        Centralize ADC management/API logs, protocol and traffic-processing telemetry, WAF logs, reverse-proxy logs, CDN logs, load-balancer records, appliance syslog, service-health telemetry, administrative audit logs, diagnostic logs, command-execution logs where available, configuration-change records, certificate-management records, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, downstream application logs, vulnerability-management data, change-control records, vendor-support records, and remediation evidence.

·        Improve telemetry that links suspicious control-plane activity to appliance execution, configuration access, certificate access, virtual-service change, backend-pool change, administrative-control change, rare egress, and downstream application impact.

·        Improve telemetry that links suspicious traffic-processing activity to process or service faults, watchdog behavior, restart or reboot, HA transition, failover, resource exhaustion, connection disruption, service unavailability, and downstream application availability.

·        Validate timestamp normalization, field mapping, schema mapping, lookup accuracy, enrichment quality, exception logic, asset tagging, management-interface mapping, traffic-facing-interface mapping, listener and protocol mapping, virtual-service mapping, backend-pool mapping, certificate-object mapping, source-IP preservation, forwarded-source preservation, and SIEM correlation before promoting hunt logic into high-severity alerting.

·        Require staged containment review for ADCs with unresolved command execution evidence, configuration drift, certificate exposure, administrative changes, rare egress, appliance instability, sustained availability impact, downstream application anomalies, or post-remediation activity.

Priority Four — Strengthen Certificate, Credential, Routing, Availability, and Downstream Trust Controls

·        Improve visibility into TLS certificates, private keys, key stores, certificate bindings, SSL/TLS offload settings, SAML material, OIDC material, API tokens, administrative credentials, backend credentials, backup archives, diagnostic bundles, packet captures, configuration exports, and credential-bearing appliance files.

·        Improve configuration and routing protection for virtual services, backend pools, listener ports, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, NAT or ALG configuration, health checks, WAF-adjacent policies, proxy policies, logging settings, administrative settings, management-interface restrictions, and access-control lists.

·        Improve appliance-resilience monitoring for process faults, service faults, watchdog behavior, restart and reboot events, HA transitions, failover, resource pressure, connection disruption, service-unavailable conditions, and application-delivery availability.

·        Improve downstream application visibility into backend access, authentication-flow behavior, session routing, header behavior, TLS termination behavior, service-account use, internal API access, database access, storage access, backup access, application-administration activity, connection disruption, availability degradation, and application-owner validation.

·        Define rapid response paths for certificate review, private-key rotation, credential rotation, configuration restoration, virtual-service review, listener or processing-function restriction, backend-pool validation, routing rollback, administrative-account review, API-key review, service-health validation, downstream application review, legal review, compliance review, cyber-insurance engagement, communications planning, and executive reporting.

·        Prioritize assets and workflows involving customer portals, authentication-fronting services, TLS termination, partner access, regulated applications, payment-adjacent processes, support workflows, file-transfer paths, specialized protocols, high-availability services, multiple downstream services, and shared certificate or administrative workflows.

Priority Five — Improve Source-Enrichment, Egress, Campaign, and Post-Remediation Correlation

·        Enrich WAF, firewall, proxy, DNS, NDR, reverse-proxy, CDN, load-balancer, appliance, protocol, endpoint-adjacent, downstream application, and change-management telemetry with ADC asset identity, management interface, traffic-facing interface, listener, protocol, processing function, virtual service, backend pool, source reputation, ASN, geography, network type, request or transaction context, response metadata, destination context, certificate context, application owner, business owner, and approved-workflow status.

·        Monitor suspicious source activity and egress after abnormal ADC control-plane activity when post-exploitation execution or appliance access is suspected.

·        Monitor suspicious traffic-processing activity across affected appliances, but do not represent cross-appliance traffic-processing campaign correlation as implemented unless dedicated correlation logic exists.

·        Restrict outbound access from ADC appliances to approved update destinations, vendor-support destinations, license-validation destinations, monitoring destinations, telemetry destinations, DNS, NTP, syslog, backup destinations, health-check destinations, integration destinations, and documented business paths where feasible.

·        Prevent network-only detections from asserting ADC exploitation, command execution, certificate exposure, credential access, command-and-control, data theft, traffic-path manipulation, downstream compromise, or containment failure without validated ADC, appliance, configuration, certificate, administrative, availability, downstream, remediation, or workflow correlation.

·        Treat continued suspicious control-plane activity, unexplained processing anomalies with independent appliance effects, rare egress where post-exploitation control is established, configuration drift, certificate access, administrative changes, downstream anomalies, or suspicious appliance behavior after remediation as containment-validation concerns requiring investigation.

Priority Six — Strengthen SOC, Network, Application, Legal, and Executive Response

·        Create or update playbooks for suspicious ADC management/API activity, suspicious traffic-processing activity, exploit-attempt behavior, appliance instability, process or service faults, command execution, configuration access, certificate exposure, private-key access, virtual-service manipulation, backend-pool changes, routing changes, outbound communication, administrative-control compromise, availability degradation, downstream application anomalies, and post-remediation activity.

·        Require responders to validate affected appliance, version or mitigation state, management interface, API endpoint where applicable, traffic-facing interface, listener or processing function where applicable, source IP, ASN, geography, request or protocol behavior, appliance state, service-health evidence, command-execution evidence where present, configuration state, certificate exposure where relevant, credential exposure where relevant, virtual-service state, backend-pool mapping, outbound communication where relevant, downstream application behavior, business owner, data sensitivity, availability state, and remediation status.

·        Require rapid decision paths for emergency patching or mitigation, management-plane isolation, API restriction, listener or processing-function restriction, configuration restoration, routing rollback, certificate rotation, credential rotation, administrative review, appliance-health validation, downstream application review, vendor escalation, legal and compliance escalation, cyber-insurance coordination, communications planning, customer or partner notification analysis, and executive reporting.

·        Require ADC trust validation before affected application-delivery paths resume unrestricted public web, customer portal, partner workflow, regulated application, payment-adjacent, support, file-transfer, authentication-fronting, TLS-terminating, protocol-processing, or high-availability functions.

·        Require post-event review to determine whether the organization can demonstrate that observed ADC activity was approved operational activity or properly contained attacker-driven behavior.

Strategic Outcome

The organization should be able to determine whether suspicious ADC activity affected appliance execution, appliance stability, certificate exposure, credential access, configuration integrity, virtual-service routing, backend-pool state, administrative control, outbound communication, connection handling, downstream application behavior, customer-facing availability, partner workflows, regulated applications, or post-remediation access. It should also be able to scope exposure across ADC appliance, management interface, traffic-facing interface, API route, listener, protocol, processing function, configuration object, certificate object, virtual service, backend pool, downstream application, administrator, credential source, outbound destination, business owner, remediation action, change-control record, and business-workflow context, then restore application-delivery trust, appliance availability, certificate confidence where affected, routing integrity where affected, administrative control where affected, downstream application assurance, and business continuity.

S38 — Attack Economics & Organizational Impact Model

Figure 7

Edge ADC exploitation and application-delivery trust compromise attack-economics model showing how exposed control-plane and traffic-processing functions can create command-execution uncertainty, appliance-instability and availability risk, certificate and credential exposure risk, traffic-path trust loss, downstream application impact, containment burden, and executive application-delivery trust restoration.

Edge ADC exploitation changes intrusion economics by allowing adversaries to pressure infrastructure that may support customer-facing availability, TLS termination, authentication-fronting services, partner workflows, regulated applications, payment-adjacent processes, public web applications, support services, file-transfer paths, specialized protocol processing, backend routing, WAF-adjacent enforcement, and business-critical application delivery. When suspicious ADC-facing activity aligns with independent appliance execution, service-health effects, configuration access, certificate or private-key exposure, virtual-service manipulation, outbound communication, administrative-control changes, connection disruption, availability degradation, downstream application anomalies, or post-remediation activity, an adversary can create disproportionate business uncertainty without compromising every endpoint, user account, application, or internal system individually.

The organization’s cost expands when responders must determine whether suspicious management/API or traffic-processing activity remained routine operation, whether control-plane exploitation enabled appliance-level command execution, whether traffic-processing activity produced service or process failure, whether configuration objects were accessed or changed, whether TLS certificates or private keys were exposed, whether virtual services or backend pools were manipulated, whether outbound communication reflected callback or staging behavior, whether administrative control changed, whether application delivery or availability was affected, and whether dependent services can safely remain online after remediation.

Adversary Economic Advantage

·        Edge ADC exploitation can reduce attacker friction because ADCs, load balancers, reverse proxies, and WAF-adjacent appliances often expose management, API, listener, virtual-service, protocol-processing, NAT, ALG, diagnostic, authentication, telemetry, or configuration functionality near public or partner-reachable application paths.

·        Unauthenticated or weakly authenticated control-plane behavior can create a path from external or partner-originated requests into appliance-level command execution without requiring employee endpoint compromise, phishing success, VPN access, or a prior internal foothold.

·        Exposed traffic-processing functionality can create a separate low-friction path for adversaries to reach vulnerable listeners, protocol handlers, NAT functions, ALGs, or comparable processing components directly through attacker-controlled network traffic.

·        Appliance command execution can provide a low-cost path to configuration access, certificate exposure, credential access, virtual-service manipulation, outbound communication, persistence-like appliance changes, or downstream application exposure.

·        Traffic-processing exploitation can create economically significant disruption through process or service faults, watchdog activity, restart or reboot, HA transition, failover, resource exhaustion, connection disruption, service unavailability, or downstream application availability impact without providing command execution.

·        ADCs give adversaries scalable access to high-value application-delivery trust surfaces that may be reachable from cloud-hosted infrastructure, VPN providers, residential proxies, scanner infrastructure, compromised hosts, or automated exploit tooling.

·        Normal ADC administration, application traffic, firmware updates, vendor support, protocol testing, load testing, health-check tuning, certificate rotation, backup activity, failover testing, monitoring, vulnerability validation, red-team activity, emergency maintenance, and incident-response cleanup can make attacker-driven behavior harder to classify quickly.

·        A single affected ADC supporting customer portals, authentication-fronting services, TLS termination, regulated applications, partner workflows, payment-adjacent processes, public web applications, support services, file-transfer paths, specialized protocols, or high-availability services can create disproportionate business impact when execution, appliance stability, certificate exposure, routing integrity, or downstream application impact cannot be resolved quickly.

·        The attacker benefits when defenders cannot quickly determine whether ADC request or protocol activity, appliance behavior, service-health changes, configuration changes, certificate access, outbound communication, administrative activity, downstream anomalies, or post-remediation behavior were legitimate operations or adversary-driven exploitation.

·        Downstream organizational impact can extend into emergency patching or mitigation, management-plane isolation, listener or processing-function restriction, configuration restoration, virtual-service review, backend-pool validation, certificate rotation, credential rotation, service-health validation, downstream application review, vendor escalation, legal assessment, compliance review, cyber-insurance coordination, communications planning, executive reporting, and application-delivery trust restoration.

Defender Cost Expansion

·        The organization must investigate both suspicious ADC activity and the reliability of the asset, exposure, management/API, protocol, WAF, reverse-proxy, CDN, load-balancer, appliance-health, configuration, certificate, DNS, proxy, firewall, NDR, endpoint, downstream application, change-control, remediation, and business-workflow evidence needed to confirm or disprove impact.

·        Response teams may need to reconstruct ADC asset exposure, version and mitigation state, suspicious management/API request sequences, suspicious protocol or listener activity, appliance instability, command-execution evidence, process or service faults, configuration access, certificate access, virtual-service changes, backend-pool changes, outbound communication, administrative-control activity, connection disruption, availability impact, downstream application behavior, and post-remediation activity.

·        Mitigation may require emergency vendor remediation, ADC patching, management/API isolation, API disablement, listener or processing-function restriction, configuration restoration, virtual-service review, backend-pool validation, routing rollback, certificate review, certificate rotation, credential rotation, administrative-account review, appliance-health validation, outbound investigation, downstream application review, legal and compliance review, cyber-insurance support, communications planning, and executive assurance.

·        Internal exposure scoping may be required across affected ADC appliances, high-availability pairs, disaster-recovery appliances, staging appliances, production appliances, traffic-facing interfaces, listeners, protocol handlers, NAT or ALG functions, virtual services, backend pools, certificates, private keys, API tokens, administrative accounts, partner paths, downstream applications, authentication flows, regulated workflows, and business owners.

·        Response cost increases when ADC asset inventory, management/API exposure mapping, traffic-processing exposure mapping, request or protocol logging, appliance-health telemetry, configuration-change records, certificate-management records, virtual-service or listener mapping, backend-pool mapping, outbound telemetry, downstream application logs, change-control records, or credential-rotation evidence are incomplete.

·        Business impact increases when defenders must determine whether command execution occurred, whether appliance instability was malicious, whether certificates or private keys were exposed, whether configuration changed, whether traffic routing was manipulated, whether administrative control changed, whether downstream applications were affected, whether customer-facing availability degraded, and whether application-delivery services can safely continue.

Organizational Impact Model

Application-Delivery Trust Impact

The organization must determine whether ADCs, load balancers, reverse proxies, WAF-adjacent appliances, virtual appliances, cloud-hosted ADC workloads, managed ADC services, high-availability pairs, or disaster-recovery appliances were exposed, affected, vulnerable, misconfigured, reachable from the internet or partners, tied to high-value application workflows, or positioned in customer-facing, partner-facing, authentication-fronting, regulated, payment-adjacent, support, file-transfer, specialized protocol, or business-critical application-delivery roles during the event window.

Management/API and Control-Plane Impact

The organization must determine whether ADC management/API, administrative, diagnostic, authentication, telemetry, configuration, or other control-plane behavior reflected normal administration, patch validation, vendor support, monitoring, vulnerability validation, or exploit-relevant access to command execution, configuration objects, certificate material, administrative controls, or traffic-management functions.

Traffic-Processing and Protocol Impact

The organization must determine whether exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, or comparable traffic-processing components received suspicious, malformed, oversized, repeated, protocol-inconsistent, or exploit-shaped traffic and whether that activity aligned with process or service faults, watchdog behavior, restart or reboot, HA transition, failover, resource exhaustion, connection disruption, service unavailability, or downstream application availability impact.

Traffic-processing activity should not be interpreted as command execution, certificate exposure, credential theft, configuration manipulation, or administrative compromise unless independent evidence establishes those outcomes.

Command Execution and Appliance Runtime Impact

The organization must determine whether suspicious control-plane activity remained exploit-attempt behavior, whether command execution occurred, whether shell or script activity appeared, whether diagnostic utilities were abused, whether transfer tools or package activity appeared, whether service-context execution occurred, and whether observed runtime activity represented actual appliance compromise rather than failed probing, approved administration, or maintenance.

Appliance Stability and Availability Impact

The organization must determine whether process faults, service crashes, watchdog events, restart or reboot activity, HA transitions, failover, resource pressure, connection resets, timeouts, service-unavailable conditions, or downstream application degradation occurred after suspicious ADC-facing activity and whether those effects can be distinguished from hardware failure, maintenance, load testing, failover testing, capacity pressure, or other operational causes.

Configuration and Traffic-Path Impact

The organization must determine whether virtual services, listener configuration, backend pools, real-server pools, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, NAT or ALG settings, health checks, WAF-adjacent policies, proxy policies, logging settings, administrative settings, or management-access restrictions were accessed, exported, changed, rolled back, weakened, or restored after validated compromise activity.

Configuration or routing manipulation should not be inferred from traffic-processing anomalies or appliance instability alone.

Certificate, Credential, and Trust Material Impact

The organization must determine whether TLS certificates, private keys, key stores, certificate bindings, SSL/TLS offload settings, SAML material, OIDC material, API tokens, administrative credentials, backend credentials, backup archives, diagnostic bundles, packet captures, configuration exports, or credential-bearing appliance files were accessed, copied, exposed, rotated, or reused after suspicious control-plane or independently confirmed appliance-compromise activity.

Certificate or credential exposure should not be inferred from traffic-processing activity or availability effects alone.

Outbound Communication and Internal Service Impact

The organization must determine whether an ADC appliance, virtual-appliance host, management host, or supporting workload with validated post-exploitation control initiated rare outbound communication, DNS anomalies, HTTP or HTTPS callbacks, SSH, SMTP, file-transfer behavior, raw-IP communication, tunneling, tool retrieval, repeated callbacks, or internal management-service access inconsistent with approved vendor support, updates, license validation, monitoring, telemetry, DNS, NTP, syslog, backups, health checks, integrations, or downstream application behavior.

Downstream Application and Availability Impact

The organization must determine whether downstream applications, authentication flows, partner workflows, backend services, customer-facing availability, regulated applications, payment-adjacent processes, support services, file-transfer paths, session routing, header behavior, TLS termination, service-account use, internal API access, database access, storage access, backup access, application-administration activity, connection handling, or service availability were affected after suspicious ADC activity.

Traffic-processing exploitation may affect downstream application availability or traffic delivery without establishing downstream administrative compromise.

Containment and Application-Delivery Trust Restoration Impact

The organization must restore application-delivery trust, appliance availability, certificate confidence where affected, routing integrity where affected, administrative control where affected, downstream application assurance, and business continuity through ADC patch or mitigation validation, management/API isolation, vulnerable processing-function restriction, configuration review, virtual-service and listener review, backend-pool validation, service-health validation, certificate review, certificate rotation where warranted, credential rotation where warranted, administrative-account review, outbound review where relevant, downstream application validation, vendor escalation, legal review, compliance assessment, cyber-insurance coordination, executive reporting, and post-remediation monitoring.

Governance Impact

Leadership may need to treat confirmed or strongly suspected ADC exploitation as an executive-level application-delivery trust incident because affected appliances can support customer portals, authentication-fronting services, TLS termination, partner workflows, regulated applications, payment-adjacent processes, public web applications, support services, file-transfer paths, specialized protocol processing, high-availability services, multiple downstream applications, shared certificate workflows, and business-critical service continuity.

Economic Impact Summary

Edge ADC exploitation is economically powerful for adversaries because it can convert exposed application-delivery trust into command execution, appliance instability, configuration exposure, certificate risk, traffic-path disruption, availability degradation, downstream application impact, and containment uncertainty. The organization’s financial exposure grows when it cannot quickly determine whether suspicious ADC activity remained contained, whether commands executed, whether appliance instability was malicious, whether certificates or credentials were exposed, whether configuration or routing changed, whether administrative control was weakened, whether post-exploitation outbound communication occurred, whether downstream applications or customer-facing availability were affected, and whether application-delivery services can safely continue.

S39 — Economic Impact & Organizational Exposure

Edge ADC exploitation expands the organizational exposure model by increasing uncertainty around whether externally reachable application-delivery infrastructure was abused through control-plane or traffic-processing functionality. The core business risk is not limited to one vendor, appliance version, management path, protocol, vulnerable feature, proof-of-concept, scanner pattern, or vulnerability identifier. The governing question is whether trusted application-delivery infrastructure was converted into an appliance-execution point, configuration or certificate exposure point, traffic-path control layer, availability-disruption point, outbound communication source, or downstream application trust risk.

Economic exposure rises when suspicious ADC activity involves internet-facing or partner-reachable management/API surfaces, exposed listeners, virtual services, protocol handlers, NAT functions, ALGs, command-shaped requests, malformed or exploit-shaped traffic, appliance instability, configuration objects, backup archives, diagnostic bundles, packet captures, backend pools, routing rules, rewrite rules, header rules, persistence profiles, health checks, TLS certificates, private keys, API tokens, administrative credentials, service faults, watchdog events, HA transitions, failover, resource pressure, outbound communication, internal-service access, downstream applications, authentication-fronting services, customer portals, partner workflows, regulated applications, public web applications, file-transfer paths, specialized protocol processing, or high-availability application delivery.

Exposure is highest when suspicious control-plane activity cannot be separated from command execution, configuration access, certificate exposure, traffic-path manipulation, rare egress, administrative-control changes, or downstream application anomalies, or when suspicious traffic-processing activity cannot be separated from process or service faults, restart, reboot, failover, resource exhaustion, connection disruption, service unavailability, or downstream availability impact.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate is tied to whether activity remains limited to scanning, probing, denied requests, vulnerable-version findings, exposed-feature findings, isolated suspicious management/API requests, malformed traffic, protocol anomalies, WAF-adjacent bypass behavior, reverse-proxy configuration probes, or patch validation; becomes suspected or confirmed ADC control-plane or traffic-processing exploitation; or expands into command execution, appliance instability, configuration access, certificate or private-key exposure, routing manipulation, administrative-control compromise, sustained availability impact, outbound communication, downstream application exposure, multi-appliance impact, or loss of confidence in application-delivery trust.

Economic exposure increases when the organization cannot quickly determine whether management/API behavior remained attempted exploitation, whether suspicious traffic-processing activity caused appliance or service impact, whether command-shaped behavior reached appliance execution, whether configuration objects were accessed or changed, whether certificates or private keys were exposed, whether virtual services or backend pools were manipulated, whether outbound communication occurred, whether administrative control changed, whether customer-facing availability degraded, whether downstream applications were affected, and whether available telemetry can be joined into a reliable exploit-to-impact sequence.

Low Impact Scenario

Estimated $450K - $3.5M

This scenario applies when suspicious ADC management/API probing, traffic-processing anomalies, exposed-version findings, scanner activity, malformed requests, public proof-of-concept-like activity, denied API attempts, abnormal protocol behavior, WAF-adjacent bypass testing, reverse-proxy configuration probes, isolated process faults, or appliance errors are detected quickly, but available telemetry confirms no command execution, no configuration access, no certificate or private-key access, no API-token or credential exposure, no unauthorized virtual-service or backend-pool change, no routing or header manipulation, no administrative-control change, no rare egress, no sustained service instability, no customer-facing availability degradation, no downstream application anomaly, and no post-remediation activity.

Response remains limited to targeted patch or mitigation validation, management-plane isolation where appropriate, exposed-listener or processing-function review, evidence preservation, focused configuration review, appliance-health validation, certificate precaution, administrator review, egress review, downstream application spot-checking, short-term monitoring, and executive tracking.

Moderate Impact Scenario

Estimated $4.5M - $24M

This scenario applies when confirmed or strongly suspected ADC, load-balancer, reverse-proxy, WAF-adjacent, ingress-controller, gateway, or traffic-management exploitation affects one or more exposed, partner-reachable, production, high-availability, authentication-fronting, or business-critical systems, but available evidence does not confirm broad downstream compromise, large-scale data theft, widespread multi-appliance compromise, or prolonged customer-facing disruption.

The organization cannot immediately determine whether suspicious control-plane activity led to command execution, configuration export, certificate or private-key access, API-token exposure, administrative-control change, virtual-service manipulation, backend-pool modification, routing changes, outbound communication, or downstream application access, or whether suspicious traffic-processing activity produced malicious appliance instability, process or service failure, failover, resource exhaustion, connection disruption, or availability degradation.

Response may require management/API, protocol, WAF, reverse-proxy, CDN, load-balancer, appliance-health, and configuration reconstruction; appliance-state inspection; configuration comparison; certificate and credential review where warranted; administrator and API-key validation; traffic-processing and service-health review; outbound traffic analysis; downstream application review; change-management reconciliation; vendor escalation; legal and compliance review; cyber-insurance coordination; executive reporting; and strengthened post-remediation monitoring.

High Impact Scenario

Estimated $30M - $140M+

This scenario applies when edge ADC exploitation becomes an enterprise-impact event involving confirmed or strongly suspected command execution, certificate or private-key exposure, credential access, configuration export, virtual-service manipulation, backend-routing abuse, authentication-flow disruption, traffic-path manipulation, administrative-control compromise, persistence-like appliance change, sustained appliance or service instability, repeated failover, customer-facing availability degradation, downstream application exposure, or multi-appliance impact.

The upper end of this range applies when the organization must assume that customer-facing services, partner workflows, TLS-protected traffic, regulated applications, backend service paths, administrative credentials, API keys, configuration backups, diagnostic artifacts, application-delivery availability, and downstream application trust were affected until evidence proves otherwise.

Response may require extended appliance forensics, emergency management-plane isolation, traffic-processing-function restriction, broad credential or certificate rotation where warranted, configuration restoration, application-delivery redesign, HA or failover validation, backend application review, customer or partner notification analysis, legal and privacy escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal validation that affected ADCs and dependent applications can safely remain online.

Annualized Risk Exposure

Estimated $4.5M - $30M+ for materially exposed enterprise environments with internet-facing or partner-reachable ADCs, vulnerable or weakly isolated management/API surfaces, exposed traffic-processing functionality, TLS termination, authentication-fronting services, customer-facing or partner-facing workflows, regulated downstream applications, incomplete request or protocol logging, weak configuration baselines, limited appliance-health telemetry, incomplete certificate-access logging, unclear virtual-service or listener ownership, weak outbound monitoring, incomplete administrative baselines, or poor downstream application mapping.

Exposure may exceed $30M - $140M+ where ADC exploitation results in confirmed or suspected command execution, certificate or private-key exposure, credential access, configuration manipulation, virtual-service manipulation, traffic-path abuse, authentication-flow disruption, sustained appliance instability, customer-facing outage, downstream application exposure, multi-appliance impact, incomplete containment, legal escalation, cyber-insurance review, communications response, or board-level reporting.

Management-Platform Dependency

Management-platform dependency is high where ADC administration, management/API access, diagnostic functions, configuration export, virtual-service management, backend-pool management, certificate management, API automation, backup workflows, health-check tuning, failover testing, vendor support, monitoring integrations, WAF policy management, ingress-controller administration, gateway configuration, or privileged-access workflows are used to manage application-delivery infrastructure.

Dependency also increases where exposed listeners, protocol handlers, NAT functions, ALGs, or other processing functions are critical to customer portals, authentication-fronting services, partner workflows, TLS termination, regulated applications, payment-adjacent processes, public web applications, specialized protocols, support services, file-transfer paths, high-availability services, shared backend pools, or multiple downstream applications that cannot be isolated without business disruption.

Control-Plane Trust

Control-plane trust is reduced when the organization cannot prove that ADC management/API access, administrative state, virtual-service configuration, backend-pool configuration, routing rules, rewrite rules, header rules, persistence profiles, health checks, WAF-adjacent policies, proxy policies, logging settings, certificate bindings, TLS-offload settings, API keys, administrative accounts, management-interface restrictions, and configuration baselines remained reliable during the activity window.

Control-plane trust is further reduced when suspicious management/API requests, command execution, configuration access, certificate access, virtual-service changes, backend-pool changes, outbound communication, administrative changes, logging degradation, or downstream anomalies cannot be tied to approved administration, vendor support, patch validation, monitoring, health-check tuning, certificate rotation, backup activity, failover testing, red-team activity, emergency change, or validated incident-response activity.

Traffic-processing instability alone should not be interpreted as loss of control-plane integrity unless separate configuration, administrative, execution, or trust-object evidence supports that conclusion.

Visibility Confidence

Visibility confidence is highest when ADC management/API logs, WAF records, reverse-proxy records, CDN records, load-balancer records, protocol and listener telemetry, appliance syslog, process and service-health telemetry, administrative audit logs, configuration-change records, certificate-management records, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, downstream application logs, asset inventory, management-interface inventory, traffic-facing-interface inventory, listener and protocol inventory, virtual-service inventory, backend-pool inventory, certificate inventory, approved-source records, change-control records, and remediation evidence can be joined reliably.

Visibility confidence is reduced when management logs do not preserve request paths, query strings, request bodies or metadata, API parameters, source context, forwarded source IPs, response sizes, API methods, or management-interface mapping; when protocol telemetry cannot identify the affected listener or processing function; when appliance operating-system or service-health telemetry is unavailable; when configuration changes require manual comparison; when certificate or private-key access lacks object-level detail; when outbound telemetry cannot distinguish approved ADC behavior from suspicious communication; when downstream application logs cannot map activity to virtual services, listeners, or backend pools; or when timestamps and change records are insufficient to reconstruct the exploit-to-impact sequence.

Privileged Object Confidence

Privileged-object confidence is high when administrative accounts, support accounts, API keys, privileged automation, TLS certificates, private keys, key stores, certificate bindings, SAML material, OIDC material, backend credentials, configuration exports, backup archives, diagnostic bundles, packet captures, virtual services, backend pools, routing rules, rewrite rules, header rules, persistence profiles, health checks, logging settings, WAF policies, ingress or gateway configuration objects, and management-access restrictions can be validated against approved baselines.

Confidence is reduced when suspicious control-plane or independently validated appliance-compromise activity occurs outside approved windows, lacks an owning ticket, creates or modifies administrative accounts, changes API keys, accesses certificate material, exports configuration, creates diagnostic bundles, accesses packet captures, changes virtual services or backend pools, modifies routing behavior, weakens logging, initiates unusual outbound communication, or creates uncertainty around whether the action was performed by an expected administrator, vendor-support workflow, automation account, monitoring process, emergency change, or incident-response workflow.

Traffic-processing anomalies or appliance instability alone should not be interpreted as privileged-object access.

Connector and Credential Dependency

Connector and credential dependency is high when ADC appliances, load balancers, reverse proxies, WAF-adjacent appliances, ingress controllers, or gateway components rely on API keys, administrative credentials, backend credentials, service credentials, monitoring credentials, vendor-support credentials, certificate material, private keys, SAML material, OIDC material, backup access, deployment secrets, health-check credentials, automation accounts, or integrations with downstream applications, identity services, storage systems, monitoring systems, backup systems, DNS services, CDN services, or management platforms.

These dependencies increase the impact of validated control-plane compromise because responders may need to prove that configuration files, credential material, certificate stores, API tokens, backend connections, administrative workflows, and downstream integrations remained intact.

Credential dependency becomes materially higher when certificates, private keys, API tokens, administrative credentials, backend credentials, backup archives, diagnostic bundles, packet captures, configuration exports, or credential-bearing appliance files may have been accessed after suspicious control-plane activity, command execution, configuration access, outbound communication, or administrative-control changes.

Traffic-processing exploitation should not by itself trigger a conclusion that credential or certificate material was exposed.

Downstream Device Dependency

Downstream dependency is high when ADC appliances, load balancers, reverse proxies, WAF-adjacent appliances, backend web servers, ingress controllers, identity providers, databases, storage services, backup systems, mail systems, file-transfer services, monitoring systems, deployment systems, and application-administration services depend on the affected application-delivery layer.

Control-plane compromise can increase downstream scope when attackers gain configuration access, certificate material, credentials, routing control, header manipulation, backend visibility, administrative privileges, or other trust relationships.

Traffic-processing exploitation can increase downstream scope through connection disruption, failed traffic delivery, service instability, failover, degraded availability, or customer-facing outage without providing downstream administrative access.

Downstream dependency should be interpreted conservatively because ADC exploitation does not automatically prove lateral movement, cloud compromise, identity compromise, database compromise, or data theft.

Customer, Workforce, and Regulatory Exposure

Customer, workforce, and regulatory exposure increases when suspicious ADC activity affects customer-facing services, partner-facing workflows, public portals, support portals, authentication-fronting services, TLS-terminating services, regulated applications, payment-adjacent processes, workforce-facing applications, specialized application-delivery functions, or externally trusted service paths.

Exposure is highest where control-plane compromise creates uncertainty around command execution, configuration access, certificate exposure, private-key exposure, credential access, traffic-path manipulation, authentication-flow disruption, administrative-control changes, or downstream application access.

Exposure also increases where traffic-processing exploitation produces sustained appliance instability, service interruption, connection disruption, failover, or customer-facing availability impact.

Telemetry gaps can materially increase legal, regulatory, contractual, insurance, and customer-trust exposure when they prevent timely confirmation of whether customer traffic, partner access, regulated workflows, authentication flows, TLS termination, certificate material, backend routing, administrative actions, appliance availability, or downstream applications were affected.

Residual Economic Risk

Residual economic risk remains after vendor remediation, ADC patching, management/API isolation, exposed-processing-function restriction, configuration restoration, certificate review, credential rotation, administrative review, egress blocking, downstream application validation, vendor escalation, WAF tuning, or incident-response cleanup when the pre-remediation activity window cannot be reconstructed.

Updating or mitigating affected appliances reduces future exposure, but it does not prove that pre-remediation command execution, configuration access, certificate exposure, private-key access, traffic-path manipulation, outbound communication, administrative-control compromise, appliance instability, availability degradation, downstream application exposure, or persistence-like appliance changes did not occur.

Residual risk should remain elevated until historical management/API records, traffic-processing telemetry, WAF records, reverse-proxy records, CDN records, load-balancer records, appliance syslog, service-health events, administrative audit logs, configuration-change records, certificate-management records, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, downstream application logs, backup-comparison data, change-control records, incident-response notes, remediation records, and business-owner evidence have been reviewed.

Proof-of-Concept / KEV Behavioral Coverage Assessment

The report's behavioral detection model directly covers control-plane exploitation where observable activity matches the existing management/API-to-execution, privileged-operation, configuration, certificate, administrative, network, or downstream correlation model.

The expanded S25 traffic-processing detections also provide coverage for vulnerabilities where attacker-controlled traffic reaches an exposed ADC processing surface and is followed by independent process or service faults, watchdog activity, restart or reboot, HA transition, failover, resource exhaustion, connection disruption, service unavailability, or downstream availability impact.

CISA KEV status, public proof-of-concept availability, scanner coverage, affected-version state, and public exploitation reporting should be treated as prioritization, remediation, and historical-review inputs rather than local compromise evidence.

The current validated KEV count for this coverage register is one: CVE-2026-8037. CISA's KEV catalog remains the authoritative catalog source, while NVD provides the vulnerability record supporting the CVE's command-injection remote-code-execution behavior.

Detection Engineering Coverage Interpretation

The S25 detection content provides Direct Coverage when suspicious ADC control-plane behavior falls inside the report's established management/API, command-execution, privileged-operation, configuration, certificate, administrative, network, downstream application, or containment-validation model without requiring a new detection branch.

Coverage With Adaptation applies when the governing behavior is represented by S25 but reliable implementation requires product-, listener-, protocol-, profile-, configuration-, object-, or telemetry-specific mapping.

The new per-asset traffic-processing rules materially expand this report's behavioral coverage. They support detection of suspicious traffic-processing activity followed by independent appliance-health or availability effects, but they do not establish command execution, certificate exposure, credential theft, configuration manipulation, administrative compromise, or rare egress without additional evidence.

Detection coverage remains behavior-led rather than CVE-string-led. CVE identifiers, vendor names, endpoint names, protocol names, source IPs, user agents, scanner labels, proof-of-concept names, payload strings, appliance banners, malware names, actor names, campaign labels, and exploit labels should remain enrichment unless they directly support locally validated triage.

The report does not detect named malware or named APT groups directly. It detects behavior that exploitation tooling, operators, affiliates, and campaigns may produce when interacting with covered ADC control-plane or traffic-processing functionality.

Direct Coverage

Direct Coverage applies where observable activity aligns with the existing S25 control-plane exploitation model without requiring additional product-specific detection logic.

·        CVE-2026-59690

·        CVE-2026-59688

·        CVE-2026-59687

·        CVE-2026-59686

·        CVE-2026-8037

·        CVE-2026-42406

·        CVE-2026-41957

·        CVE-2026-41225

·        CVE-2026-34176

·        CVE-2026-4048

·        CVE-2026-3519

·        CVE-2026-3518

·        CVE-2026-3517

The Progress vulnerabilities represented by CVE-2026-59686, CVE-2026-59687, CVE-2026-59688, and CVE-2026-59690 map to existing management/API, command-execution, privileged-operation, and administrative-control logic.

CVE-2026-8037 maps directly to the management/API-to-execution model because it represents unauthenticated OS command-injection remote code execution through Progress ADC API functionality.

CVE-2026-42406, CVE-2026-41957, CVE-2026-41225, and CVE-2026-34176 map to the existing management-plane, Configuration utility, iControl REST, privileged configuration-object, or command-execution model.

CVE-2026-4048, CVE-2026-3519, CVE-2026-3518, and CVE-2026-3517 map to existing Progress ADC management/API and appliance-execution detections.

Coverage With Adaptation

Coverage With Adaptation applies where S25 represents the governing behavior but reliable implementation requires additional local mapping.

·        CVE-2026-19489

·        CVE-2026-59689

·        CVE-2026-59762

·        CVE-2026-13474

·        CVE-2026-10816

·        CVE-2026-8655

·        CVE-2026-8452

·        CVE-2026-50107

·        CVE-2026-42945

·        CVE-2026-42409

·        CVE-2026-41227

·        CVE-2026-41218

·        CVE-2026-40618

·        CVE-2026-40423

·        CVE-2026-40067

·        CVE-2026-39458

·        CVE-2026-33691

·        CVE-2026-4342

·        CVE-2026-3288

·        CVE-2026-2507

·        CVE-2026-21876

CVE-2026-19489 is Coverage With Adaptation because its NetScaler traffic-processing path can produce appliance instability or denial-of-service effects represented by the new S25 traffic-processing detections. Reliable implementation requires NetScaler asset identification, listener and protocol mapping, SIP ALG and LSN configuration context, traffic-processing telemetry, and appliance-health correlation. Vulnerable version, SIP ALG state, or LSN configuration alone must not be counted as compromise.

CVE-2026-59689 requires authenticated identity, privilege-state, administrative-action, and appliance-state correlation because its privilege-transition behavior is not a direct external command-injection path.

CVE-2026-59762 maps to the traffic-processing branch because attacker-controlled HTTP/2 activity can create memory-pressure, TMM restart, or availability effects, but reliable implementation requires virtual-server, profile, protocol, TMM, memory-pressure, restart, and service-health mapping.

CVE-2026-13474, CVE-2026-10816, CVE-2026-8655, and CVE-2026-8452 require NetScaler-specific feature, management, listener, virtual-service, protocol, object, or appliance-health correlation. File-read behavior should not be converted into command-execution coverage, and processing faults should not be converted into administrative compromise.

CVE-2026-50107, CVE-2026-4342, and CVE-2026-3288 require ingress or gateway controller, configuration, annotation, secret-access, execution, and downstream mapping.

CVE-2026-42945 maps to request-to-worker-instability behavior. Command execution must not be inferred from traffic-processing effects without independent runtime evidence.

CVE-2026-42409, CVE-2026-41227, CVE-2026-41218, CVE-2026-40618, CVE-2026-40423, CVE-2026-40067, CVE-2026-39458, and CVE-2026-2507 require BIG-IP asset, virtual-server, profile, protocol, TMM or related-process, restart, HA, failover, and service-health correlation.

CVE-2026-33691 requires WAF request-normalization, upload, and downstream-impact telemetry rather than ADC command-execution logic.

CVE-2026-21876 requires WAF-processing and application-delivery trust context and should not be interpreted as direct appliance command execution.

Non-Coverage Conditions

·        Vulnerable-version state, public exploit availability, KEV status, internet exposure, exposed management interfaces, exposed listeners, enabled protocol handlers, ALGs, NAT functions, HTTP profiles, WAF profiles, DNS processing, or other affected-feature state without exploit-relevant behavior.

·        Malformed, oversized, abnormal, repeated, fuzzing-like, or protocol-inconsistent traffic without an independent appliance, service-health, connection, availability, or downstream application-delivery effect.

·        Isolated crash, restart, reboot, watchdog, HA transition, failover, connection reset, timeout, resource-pressure, or service-unavailable activity without preceding suspicious ADC-facing traffic.

·        Memory disclosure or memory overread without an S25-observable sensitive-object, processing, appliance-health, configuration, or downstream effect.

·        Authentication or session bypass alone where subsequent behavior is not represented by the report's control-plane, administrative, configuration, traffic-processing, or downstream detections.

·        Command execution, certificate exposure, credential theft, configuration manipulation, routing manipulation, administrative compromise, rare egress, or downstream compromise inferred solely from traffic-processing exploitation.

·        Cloud-only, identity-only, database-only, certificate-only, downstream-application-only, or network-only anomalies without validated ADC or appliance context.

·        Approved administration, firmware updates, vendor support, protocol testing, load testing, failover testing, certificate rotation, backup activity, vulnerability validation, red-team activity, emergency maintenance, or incident-response behavior that adequately explains the observed activity.

Current Coverage Count

Directly Covered CVEs

13

CVEs Covered With Adaptation

21

Total CVEs Represented

34

Current KEV Count

1

·        CVE-2026-8037

CISA KEV status increases remediation and historical-compromise-review priority but does not establish local compromise.

Known Exploited / Exploitation-Represented CVEs

1 confirmed

·        CVE-2026-8037

No additional CVE in the validated register should currently be described as confirmed actively exploited based solely on the evidence used for this coverage assessment.

Public Exploit / Proof-of-Concept Coverage

Public proof-of-concept or exploit availability should be treated as prioritization and enrichment rather than local compromise evidence. Detection coverage remains based on locally observable behavior represented by S25.

Named Malware Coverage

No named malware family should be claimed as directly covered.

The S25 rules detect exploitation behavior and observable post-exploitation effects rather than malware-family identity.

Named Actor / APT Coverage

No named actor or APT group should currently be claimed as directly covered.

Named-actor coverage should be added only where reliable reporting establishes a sufficiently specific relationship between a named actor and behavior materially represented by S25.

Coverage Qualification

Coverage is strongest where suspicious control-plane behavior can be joined with independent execution, configuration, certificate, administrative, network, traffic-path, downstream application, or containment evidence, or where suspicious traffic-processing activity can be joined with independent process, service-health, watchdog, restart, reboot, HA, failover, resource, connection, availability, or downstream application-delivery effects.

The expanded S25 traffic-processing rules materially broaden coverage beyond management/API command execution, but the report remains behavior-driven rather than a generic denial-of-service report.

Multi-asset traffic-processing campaign correlation is not implemented by the current S25 campaign rules. Existing multi-asset campaign detection remains control-plane-oriented and must not be represented as cross-appliance traffic-processing campaign coverage.

Coverage is weaker where evidence remains limited to exposed versions, scanner findings, public exploit references, suspicious paths, malformed traffic, isolated appliance faults, WAF bypass without downstream evidence, ingress or gateway findings without local configuration or secret-access telemetry, ordinary administration, approved vendor support, approved patch validation, approved failover testing, approved security testing, or environments where required telemetry cannot be joined reliably.

The report does not claim universal ADC, LoadMaster, BIG-IP, NetScaler, NGINX, ingress-controller, WAF, command-injection, RCE, memory-corruption, denial-of-service, KEV, malware, actor, or APT coverage.

Executive Exposure Statement

The organization's economic exposure is highest when edge ADC exploitation creates uncertainty around whether application-delivery infrastructure remained trustworthy, resilient, and safe to operate.

The strategic risk is not merely that a vulnerable appliance exists, that a scanner touched a management endpoint, that malformed traffic reached a listener, that public proof-of-concept code exists, or that a vulnerability appears in KEV. The material business risk is that attackers may have used exposed control-plane functionality to execute commands, access configuration, expose certificates or credentials, manipulate routing, alter backend service paths, initiate outbound communication, weaken administrative controls, or affect downstream applications, or used exposed traffic-processing functionality to produce process or service failure, appliance instability, failover, connection disruption, customer-facing outage, or loss of confidence in application-delivery availability.

Leadership should treat unresolved execution, configuration, certificate, routing, administrative, service-health, availability, downstream application, and containment uncertainty as an application-delivery trust and business-continuity risk until sufficient evidence demonstrates that affected services can safely remain online.

S40 — References

CVE Data

·        CVE-2026-19489 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-19489

·        CVE-2026-59690 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-59690

·        CVE-2026-59689 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-59689

·        CVE-2026-59688 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-59688

·        CVE-2026-59687 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-59687

·        CVE-2026-59686 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-59686

·        CVE-2026-59762 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-59762

·        CVE-2026-8037 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-8037

·        CVE-2026-13474 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-13474

·        CVE-2026-10816 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-10816

·        CVE-2026-8655 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-8655

·        CVE-2026-8452 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-8452

·        CVE-2026-50107 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-50107

·        CVE-2026-42945 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-42945

·        CVE-2026-42409 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-42409

·        CVE-2026-42406 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-42406

·        CVE-2026-41957 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-41957

·        CVE-2026-41227 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-41227

·        CVE-2026-41225 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-41225

·        CVE-2026-41218 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-41218

·        CVE-2026-40618 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-40618

·        CVE-2026-40423 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-40423

·        CVE-2026-40067 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-40067

·        CVE-2026-39458 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-39458

·        CVE-2026-34176 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-34176

·        CVE-2026-4048 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-4048

·        CVE-2026-3519 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-3519

·        CVE-2026-3518 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-3518

·        CVE-2026-3517 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-3517

·        CVE-2026-33691 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-33691

·        CVE-2026-4342 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-4342

·        CVE-2026-3288 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-3288

·        CVE-2026-2507 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-2507

·        CVE-2026-21876 — hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-21876

Known Exploited Vulnerabilities

·        CISA Known Exploited Vulnerabilities Catalog — hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Threat Technique Framework

MITRE ATT&CK — hxxps://attack[.]mitre[.]org/