[EXP] Progress Kemp LoadMaster Pre-Auth RCE and Edge ADC Compromise Risk

Report Type: EXP
Threat Category: Edge ADC Control-Plane Exploitation and Application-Delivery Trust-Boundary Compromise
Assessment Date: July 08, 2026
Primary Impact Domain: Application Delivery and Edge Control-Plane Trust
Secondary Impact Domains: Certificate and TLS Trust; Configuration Integrity; Credential Exposure; Downstream Application Availability; Partner and Customer-Facing Service Continuity; Incident Response and Executive Assurance
Affected Asset Class: ADCs, Load Balancers, Reverse Proxies, WAF-Adjacent Appliances, Ingress Controllers, Gateway Fabric Components, Traffic-Management Control Planes, Virtual Services, Backend Pools, TLS/Certificate Stores, and Downstream Application Paths
Threat Objective Classification: Control-Plane Exploitation, Appliance-Level Command Execution, Configuration and Certificate Exposure, Traffic-Path Manipulation, Outbound Communication, Downstream Application Exposure, and Post-Remediation Trust Degradation

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

BLUF

‍  Progress Kemp LoadMaster CVE-2026-8037 and comparable edge application delivery controller compromise behavior create material business risk because internet-exposed, partner-reachable, or insufficiently isolated ADC, load balancer, reverse proxy, WAF-adjacent, and traffic-management appliances may sit directly between external users and critical downstream applications. The core risk is whether unauthenticated or weakly authenticated control-plane exploit behavior allowed adversaries to execute appliance-level commands, access configuration objects, expose TLS or certificate material, manipulate virtual services or traffic routing, weaken administrative controls, initiate outbound communication, create persistence-like appliance changes, or affect downstream application trust before the organization can validate appliance state, routing integrity, credential exposure, certificate exposure, and application-delivery continuity. Immediate executive action is required to confirm exposed ADC and load-balancer assets, management/API isolation, affected version status, public exploit exposure, patch state, configuration integrity, certificate and private-key handling, administrative account state, outbound communication, downstream application impact, and the organization’s ability to distinguish routine traffic-management administration from control-plane compromise behavior.

Executive Risk Translation

Edge ADC compromise shifts the business risk from a single appliance vulnerability to uncertainty over whether the organization can still trust the application-delivery layer that routes, terminates, inspects, authenticates, balances, and protects access to downstream services. If the organization cannot reliably connect suspicious management/API access to appliance command execution, configuration access, certificate exposure, routing changes, administrative activity, outbound communication, and downstream application behavior, leadership may need to assume that the traffic-management trust boundary, TLS termination layer, virtual-service configuration, backend routing, administrative credentials, or customer-facing application path was exposed until proven otherwise. That response can expand into emergency patch validation, management-plane isolation, appliance forensic review, configuration comparison, certificate and credential rotation, backend application review, WAF and proxy policy validation, traffic-path restoration, legal and compliance assessment, cyber-insurance coordination, executive reporting, and customer or partner trust management.

S3 — Why This Matters Now

·        Progress Kemp LoadMaster CVE-2026-8037 provides a current public anchor for pre-authentication command-injection risk against an ADC control plane, but the durable enterprise concern is broader edge traffic-management compromise behavior.

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

·        Public PoC availability and reported exploitation attempts increase urgency, but compromise confidence must come from correlated appliance, management/API, configuration, certificate, outbound, administrative, routing, or downstream-application evidence.

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

·        The highest-risk condition occurs when exposed ADC control-plane access is followed by appliance-level 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.

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

·        Missing request bodies, rotated management logs, incomplete API records, weak appliance telemetry, absent configuration baselines, limited certificate-access logging, incomplete egress attribution, or poor 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 directly cover ADC and load-balancer traffic-path compromise as a reusable behavior family.

S4 — Key Judgments

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

·        The primary enterprise risk is reduced ability to determine whether exposed or weakly isolated management/API access led to command execution, configuration exposure, virtual-service manipulation, certificate or TLS-offload exposure, administrative-control compromise, outbound communication, persistence-like appliance changes, or downstream application access.

·        Suspicious ADC management/API activity followed by appliance instability, command execution, configuration access, certificate access, routing changes, rare egress, administrative changes, logging degradation, or downstream application anomalies is the strongest executive risk signal.

·        A single scanner hit, vulnerable-version finding, public PoC reference, unusual user agent, management endpoint request, or appliance error should not be treated as confirmed compromise without supporting appliance, configuration, certificate, outbound, administrative, routing, or downstream-application evidence.

·        Business exposure increases sharply when affected ADCs terminate TLS, front authentication workflows, route customer traffic, support partner access, protect regulated applications, 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, appliance state, configuration changes, certificate handling, virtual-service routing, backend-pool exposure, outbound communication, administrative activity, and downstream application behavior across separate systems.

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

S5 — Executive Risk Summary

Business Risk

Edge ADC control-plane compromise can weaken the organization’s ability to trust the infrastructure that delivers, routes, terminates, balances, 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, 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. The business impact is not limited to the vulnerable appliance; it can expand into uncertainty about whether adversaries executed commands, accessed configuration backups, exposed certificates or private keys, modified routing, altered headers, changed persistence settings, weakened logging, created administrative access, initiated outbound communication, or affected downstream applications after apparent remediation.

Technical Cause

The risk is driven by unauthenticated or weakly authenticated ADC management/API exposure, command-injection behavior, unsafe input handling, insufficient control-plane isolation, incomplete management-source restrictions, and inadequate segmentation between the traffic-management plane and downstream application trust paths. Technical exposure becomes material when suspicious management/API requests align with appliance command execution, API handler instability, configuration object reads or writes, virtual-service changes, backend-pool changes, routing or rewrite manipulation, TLS-offload or certificate binding changes, backup export, diagnostic bundle creation, private-key access, API token access, rare egress, administrative changes, or downstream traffic-path anomalies. Exposure increases when ADC inventory, management-interface mapping, API exposure records, virtual-service mapping, backend-pool inventory, certificate inventory, configuration baselines, appliance logging, outbound monitoring, change-management context, and downstream application telemetry are incomplete or poorly coordinated.

Threat Posture

The threat posture is elevated because edge ADC compromise can turn a traffic-management appliance into an attacker-controlled execution point, credential source, certificate exposure point, routing-control layer, downstream application access path, persistence location, or staging point for additional activity. Exploitation may not begin with endpoint malware or user credential theft because the initial path can be direct unauthenticated or weakly authenticated interaction with an exposed appliance control plane. 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 are patched or isolated, management/API surfaces are restricted, partner-reachable paths are documented, 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, outbound appliance communication is examined, logs and diagnostic artifacts are preserved, downstream applications are reviewed for traffic-path 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, downstream access, customer-facing disruption, or application-delivery trust loss is suspected.

S6 — Executive Cost Summary

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

Cost increases materially when ADC logs rotate quickly, request bodies are unavailable, API parameters are redacted, appliance shell or process telemetry is inaccessible, certificate access is poorly logged, configuration exports are not baselined, virtual-service ownership is unclear, backend-pool mappings are outdated, approved administrative sources are not documented, partner access is poorly inventoried, 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, or appliance clusters supporting critical business operations.

Low Impact Scenario

Rapid investigation confirms suspicious ADC management/API probing 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, downstream application anomalies, or post-remediation activity. Activity may involve internet scanning, public PoC-like requests, failed API access, malformed command-injection attempts, abnormal status codes, or limited appliance instability, but management/API logs, WAF records, appliance logs, 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 isolation, evidence preservation, focused configuration review, administrator review, certificate precaution, egress review, 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 control-plane exploitation affects one or more exposed or partner-reachable appliances where suspicious management/API behavior aligns with appliance instability, command execution evidence, configuration access, virtual-service changes, certificate-object access, backup or diagnostic artifact access, rare outbound communication, administrative changes, logging 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, or downstream applications were reached. Response requires enterprise-focused ADC asset review, management/API and WAF record reconstruction, appliance-state inspection, configuration comparison, certificate and credential review, administrator and API-key validation, outbound traffic analysis, downstream application review, 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 compromise becomes an enterprise-impact event when suspected or confirmed command execution results in certificate or private-key exposure, credential access, configuration export, virtual-service manipulation, backend routing abuse, authentication-flow disruption, traffic mirroring, 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 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, and critical application-delivery assets.

·        Scope of exposed management/API surfaces, including administrative interfaces, API endpoints, diagnostic functions, authentication handlers, telemetry endpoints, configuration paths, support functions, and partner-reachable control-plane routes.

·        Availability and retention of ADC management logs, WAF records, reverse-proxy records, CDN records, load-balancer records, appliance syslog, 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, appliance instability, command execution, configuration reads, configuration writes, virtual-service changes, backend-pool changes, certificate access, private-key exposure, outbound communication, administrative changes, logging degradation, and downstream application behavior across separate telemetry sources.

·        Whether ADC management/API access can be restricted to approved administrative networks, VPN paths, privileged access workflows, vendor support sources, and documented partner paths 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, 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, 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, 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

Progress Kemp LoadMaster and edge ADC compromise executive risk model showing how exposed traffic-management control-plane access can escalate from exploit-attempt behavior into command execution, configuration exposure, certificate risk, routing manipulation, downstream application exposure, customer-facing service disruption, and enterprise-level business exposure.

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

Progress Kemp LoadMaster Pre-Auth RCE and Edge ADC Compromise Risk

Risk Description

Adversaries may exploit unauthenticated or weakly authenticated ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management control-plane behavior to move from suspicious management/API access into 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. This may increase business interruption, customer-facing availability degradation, credential and certificate exposure, regulated application concern, partner workflow exposure, legal and compliance review, cyber-insurance scrutiny, customer or partner notification analysis, and board-level concern around edge application-delivery resilience. Compliance exposure should be driven by local evidence of command execution, certificate exposure, credential access, routing manipulation, downstream application impact, administrative compromise, regulated data access, traffic-path tampering, customer-facing disruption, or post-remediation activity, not by vulnerable-version status, scanner traffic, public exploit availability, KEV status, or isolated management/API request activity 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, TLS termination, authentication-fronting services, customer-facing or partner-facing workflows, regulated downstream applications, incomplete request logging, weak configuration baselines, limited appliance telemetry, incomplete certificate-access logging, unclear virtual-service ownership, weak outbound monitoring, incomplete administrative activity baselines, or poor downstream application mapping. Exposure may exceed $30M - $140M+ where ADC compromise results in confirmed or suspected command execution, certificate or private-key exposure, credential access, configuration export, virtual-service manipulation, authentication-flow disruption, traffic mirroring, 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, 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.

·        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.

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

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

·        ADC administration, firmware updates, vendor support, health-check changes, 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, or multiple downstream services.

·        Missing or inconsistent management logs, request bodies, API parameters, appliance syslog, 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, restrict control-plane access, compare configuration, review virtual services, 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, 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

Progress Kemp LoadMaster CVE-2026-8037 and comparable edge ADC compromise behavior should be treated as a high-priority application-delivery trust, control-plane resilience, certificate protection, credential exposure, and downstream application risk because a vulnerable or weakly isolated traffic-management appliance can become a path for attacker-controlled command execution and visible business impact. The executive question is not only whether the appliance was patched, whether a scanner touched the management interface, whether public PoC code exists, or whether traffic is still flowing; it is whether the organization can prove that suspicious ADC activity did not lead to command execution, configuration access, private-key exposure, certificate misuse, virtual-service manipulation, backend routing abuse, administrative compromise, rare outbound communication, downstream application access, or continued access after remediation. Response must focus on validating exposed assets, management/API isolation, appliance state, configuration integrity, virtual services, backend pools, TLS and certificate handling, administrative accounts, API keys, 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 compromise 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, or internet scanning occurred; it is the possibility that adversaries used exposed or weakly isolated control-plane behavior to execute commands, access configuration, expose certificates or private keys, manipulate traffic routing, alter backend service paths, weaken administrative controls, 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, patch validation, WAF and management records, 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

Progress Kemp LoadMaster pre-authentication RCE and edge ADC compromise describes adversary behavior in which exposed or insufficiently isolated ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management control planes may be abused through unauthenticated or weakly authenticated management/API access, command-injection behavior, diagnostic-function abuse, configuration access, certificate exposure, virtual-service manipulation, routing control, administrative-control compromise, outbound communication, persistence-like appliance changes, or downstream application exposure. Progress Kemp LoadMaster CVE-2026-8037 is the current anchor example for this behavior family, but the durable enterprise risk is broader than a single vendor, endpoint path, scanner wave, public proof-of-concept, or CVE identifier.

·        This is not only a scanner, vulnerable-version, KEV, proof-of-concept, single-request, single-source-IP, user-agent, API-path, exploit-string, or IOC-only model.

·        The core threat behavior is movement from exposed edge traffic-management control-plane access into appliance-level command execution, configuration exposure, TLS or certificate exposure, routing manipulation, administrative-control compromise, outbound communication, downstream application access, or persistence-like appliance modification.

·        Internet-facing, partner-reachable, cloud-hosted, managed, virtual, high-availability, authentication-fronting, TLS-terminating, and production ADC deployments are the relevant exposure class when management/API access is reachable from untrusted or insufficiently restricted paths.

·        The primary risk is reduced ability to determine whether ADC activity remained routine administration, patch validation, vendor support, health-check tuning, certificate rotation, backup activity, failover testing, or emergency maintenance, or crossed into unauthorized command execution, configuration access, certificate exposure, traffic-path manipulation, or downstream application impact.

·        ADC management logs, API records, WAF records, reverse-proxy records, CDN records, load-balancer records, appliance syslog, 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 comparison data, and change-management records may be incomplete or difficult to reconcile during active investigation.

·        The behavior can create uncertainty around application-delivery trust, TLS termination integrity, customer-facing availability, backend routing, partner access, administrative control, credential protection, certificate handling, downstream application exposure, legal exposure, cyber-insurance posture, and business continuity.

·        Public reporting on Progress Kemp LoadMaster CVE-2026-8037, public PoC availability, and observed exploitation attempts should support the relevance and urgency of the behavior class but should not narrow the report into an actor-only, IOC-only, scanner-only, payload-only, exploit-string-only, or single-CVE-only report.

S11 — Threat Classification and Type

Threat Type

Edge application delivery controller control-plane exploitation and traffic-management trust-boundary compromise risk.

Threat Sub-Type

Pre-authentication command injection, ADC management/API abuse, appliance-level command execution, 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, downstream application exposure, and multi-appliance traffic-management compromise risk.

Operational Classification

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

Primary Function

Abuse exposed or insufficiently isolated ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management control-plane access to move from unauthenticated or weakly authenticated management/API interaction 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, creating uncertainty around application-delivery trust, TLS handling, backend routing integrity, containment completeness, and customer-facing service assurance.

S12 — Campaign or Activity Overview

Figure 2

Progress Kemp LoadMaster and edge ADC compromise activity model showing exposed management/API access, pre-authentication exploit behavior, appliance command execution, configuration or certificate exposure, virtual-service or routing manipulation, administrative-control compromise, outbound communication, downstream application exposure, and post-remediation trust validation.

This report assesses Progress Kemp LoadMaster CVE-2026-8037 and comparable edge ADC control-plane compromise as a durable behavior class rather than a single product advisory, scanner wave, exploit string, public proof-of-concept, actor cluster, or appliance patch event. The activity pattern involves adversaries or automated infrastructure interacting with exposed or weakly isolated ADC management/API surfaces in ways that may produce command execution, appliance instability, configuration access, certificate exposure, traffic-path manipulation, outbound communication, administrative changes, downstream application anomalies, or post-remediation uncertainty.

·        The activity is best understood as an application-delivery trust, control-plane resilience, certificate protection, routing integrity, and downstream application exposure threat rather than a routine internet scan, generic appliance error, isolated API request, 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, or business-critical application delivery.

·        The behavior may involve rare source infrastructure, cloud-hosted infrastructure, residential proxies, VPN providers, scanner 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 API-handler errors.

·        The activity may remain limited to reconnaissance, malformed requests, failed exploit attempts, vulnerable endpoint probing, abnormal response behavior, or management/API instability, or it may progress into appliance-level command execution, configuration export, certificate access, virtual-service changes, backend-pool manipulation, routing changes, administrative changes, rare egress, logging 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, connect to internal services, or serve multiple downstream applications through shared traffic-management configuration.

·        Actor names, infrastructure references, exploit-attempt reporting, scanner fingerprints, CVE references, KEV status, or public PoC references may increase urgency, but they should enrich the report rather than replace local behavior-led evidence of suspicious management/API activity, appliance execution, configuration access, certificate exposure, traffic-path manipulation, outbound communication, administrative change, 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, and production ADC, load balancer, reverse proxy, WAF-adjacent, and traffic-management appliances. It also includes ADC control planes, management/API endpoints, diagnostic functions, authentication handlers, administrative accounts, API keys, virtual services, backend pools, listener ports, routing rules, rewrite rules, header rules, persistence profiles, health checks, WAF or proxy-adjacent controls, SSL/TLS offload settings, certificate bindings, private keys, configuration exports, backup archives, diagnostic bundles, packet captures, outbound network paths, and downstream applications that depend on the traffic-management layer.

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

·        Progress Kemp LoadMaster deployments affected by CVE-2026-8037 where versions, patch state, API exposure, management-interface exposure, and access restrictions require local validation.

·        ADC API paths and management functions that can expose 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, 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 behavior, paste-site access, tunneling, command-and-control-like communication, vendor-support paths, update paths, telemetry paths, monitoring paths, syslog paths, backup paths, and internal management-service access.

·        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 API exposure, weak management-plane isolation, undocumented partner access, incomplete request logging, limited appliance 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, 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, 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, or partner-facing 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, 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, 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, certificate handling, or application-layer resilience.

Countries Affected

·        Global.

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

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

·        Country-specific impact should be assessed by ADC management/API exposure, affected version presence, internet or partner reachability, TLS termination role, downstream application sensitivity, certificate exposure risk, credential reuse, routing complexity, telemetry availability, regulatory obligations, and incident-response maturity 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, recognize reachable management/API surfaces, interact with administrative or diagnostic endpoints, and determine whether unauthenticated or weakly authenticated behavior can produce command execution, appliance instability, configuration access, certificate exposure, or traffic-path manipulation. Lower-complexity activity may involve broad scanning, exploit replay, commodity proof-of-concept use, public endpoint probing, automated API requests, source rotation, malformed command-injection attempts, or opportunistic probing of known appliance paths. Higher-capability activity may involve selective targeting of high-value ADCs, custom request shaping, API parameter manipulation, encoded command content, multi-stage access attempts, configuration export review, certificate or private-key access, virtual-service manipulation, stealthy routing changes, outbound communication, log suppression, cleanup, and downstream application exploration.

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, infrastructure designed to blend with vendor support or monitoring activity, and access patterns that resemble routine ADC administration, patch validation, health-check tuning, 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 LoadMaster or comparable ADC appliance to broader enterprise exposure when multiple ADCs, virtual services, 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 vulnerable management/API path to command execution, configuration exposure, certificate access, routing manipulation, administrative-control compromise, rare egress, downstream application exposure, and post-remediation trust validation.

Escalation Likelihood

Moderate to High

Escalation likelihood is moderate to high when suspicious ADC management/API access is followed by command execution, appliance instability, 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 increases when affected appliances support customer portals, authentication-fronting services, regulated applications, partner access, payment-adjacent workflows, TLS termination, high-availability services, shared backend pools, multi-region application delivery, reused credentials, weak management-plane 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.

·        Public exploit knowledge, repeatable API paths, commodity scanning, and automated exploitation can lower the barrier for opportunistic adversaries once a pre-authentication RCE pattern becomes public.

·        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.

·        Attackers benefit from environments where ADC asset inventory, management-interface mapping, API exposure records, virtual-service ownership, backend-pool mapping, certificate inventory, configuration baselines, appliance 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, 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, 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, affected version presence, access restrictions, TLS termination role, downstream application sensitivity, certificate exposure risk, credential reuse, telemetry maturity, and local evidence of control-plane-to-impact behavior rather than actor names or scanner labels alone.

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 paths.

·        Progress Kemp LoadMaster deployments affected by CVE-2026-8037 where management/API access, affected version status, and patch state require validation.

·        ADC deployments used for TLS termination, authentication-fronting services, customer portals, partner workflows, regulated applications, public web applications, support services, file-transfer paths, 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.

·        Virtual services, backend pools, listener ports, 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 surfaces, incomplete appliance inventory, delayed patching, weak management-plane isolation, undocumented partner access, weak API restrictions, 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, telemetry, configuration, or control-plane surfaces.

·        T1595 — Active Scanning.

Stage 2 — ADC Management/API Exploitation

The adversary sends unauthenticated, weakly authenticated, malformed, repeated, automation-like, or exploit-shaped requests against exposed ADC management/API behavior to reach command endpoints, diagnostic functions, API handlers, authentication components, or control-plane paths.

·        T1190 — Exploit Public-Facing Application.

Stage 3 — Appliance-Level Command Execution

The adversary uses successful control-plane exploitation to execute commands, invoke shell or script behavior, abuse diagnostic functionality, or execute appliance-context activity outside approved administration.

·        T1059 — Command and Scripting Interpreter.

Stage 4 — Configuration, Certificate, and Credential Access

The adversary accesses ADC 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, 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

The adversary causes the ADC appliance or ADC-supporting workload to initiate unusual DNS, HTTP, HTTPS, callback-like, file-transfer, tunneling, or command-and-control-like communication after suspicious control-plane access or command execution.

·        T1071 — Application Layer Protocol.

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

Progress Kemp LoadMaster pre-authentication RCE and edge ADC compromise begins when adversaries identify exposed or insufficiently isolated ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management appliances with reachable management/API, administrative, diagnostic, authentication, telemetry, configuration, or control-plane surfaces. The attacker’s objective is to move from suspicious edge control-plane access into appliance-level command execution, configuration exposure, certificate or private-key access, traffic-path manipulation, administrative-control compromise, outbound communication, downstream application exposure, or persistence-like appliance changes. The attack path is defined by edge ADC discovery, exposed management/API exploitation, appliance-level command execution, configuration and certificate access, traffic-path manipulation, outbound communication, downstream application exposure, and post-remediation trust validation. 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 that expose management/API, administrative, diagnostic, authentication, telemetry, configuration, or control-plane surfaces. This may involve internet scanning, repeated appliance-path access, API endpoint probing, version or banner discovery, source-infrastructure rotation, cloud-hosted infrastructure, VPN providers, residential proxies, scanner infrastructure, unusual geographies, suspicious ASNs, or probing of known vendor and appliance-management routes. This stage is not sufficient by itself to establish compromise because edge appliances are routinely scanned. It becomes material when discovery activity aligns with exposed management paths, affected versions, weak access restrictions, abnormal request timing, repeated API access, unusual response patterns, or later evidence of command execution, configuration access, certificate access, rare egress, or traffic-path change.

Stage 2: ADC Management/API 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 control-plane behavior. Observable evidence may include requests to Progress Kemp LoadMaster API behavior, including /accessv2 where locally visible, 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 the event from routine exposure into possible exploitation when suspicious request behavior aligns with appliance instability, command execution evidence, configuration access, certificate access, administrative activity, rare egress, or downstream application anomalies.

Stage 3: Appliance-Level Command Execution

The adversary uses successful control-plane exploitation to execute commands, invoke shell or script behavior, abuse diagnostic functionality, run transfer tools, interact with appliance utilities, access package or firmware-related functions, or execute 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, service-context execution, crash or fault behavior, watchdog or restart events, or endpoint telemetry from virtual appliances, cloud-hosted appliances, ADC-supporting hosts, or management hosts where available. This stage is the key execution point because the event moves from suspicious control-plane access into possible attacker-controlled activity on or adjacent to the application-delivery appliance.

Stage 4: Configuration, Certificate, and Credential Access

The adversary uses appliance-level access, API behavior, diagnostic functions, administrative context, or compromised appliance state to access 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. Observable evidence may include configuration export activity, backup creation or download, diagnostic bundle access, packet capture creation, certificate store access, private-key access, API token reads, administrative credential exposure, unusual file reads, object-level configuration access, certificate binding review, or activity that aligns with sensitive-object access after suspicious management/API behavior. This stage increases business risk because certificate, credential, and configuration exposure can extend the incident beyond the appliance and into TLS trust, backend routing, administrative workflows, partner access, and downstream applications.

Stage 5: Traffic-Path and Trust-Boundary Manipulation

The adversary modifies or abuses 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, WAF-adjacent policies, proxy policies, logging settings, or security-control policies. Observable evidence may include new or modified virtual services, backend-pool changes, unexpected listener changes, altered routing, header manipulation, rewrite-rule changes, certificate binding changes, TLS termination changes, modified persistence behavior, changed health checks, logging degradation, weakened access controls, or downstream traffic behavior that does not match approved change records. This stage becomes materially significant when traffic-path changes occur after suspicious control-plane activity and cannot be tied to approved maintenance, emergency change, vendor support, certificate rotation, failover testing, backup activity, vulnerability validation, or incident-response activity.

Stage 6: Outbound Communication

The adversary causes the ADC appliance, virtual appliance host, management host, or ADC-supporting workload to initiate unusual outbound communication after suspicious control-plane access or command execution. Observable evidence may include rare DNS lookups, outbound HTTP or HTTPS connections, raw-IP communication, SSH, SMTP, file-transfer behavior, paste-site access, tunneling, callback-like behavior, command-and-control-like communication, tool retrieval, repeated callbacks, internal management-service access, or destinations inconsistent with approved vendor support, updates, license validation, telemetry, monitoring, NTP, DNS, syslog, backup, health-check, or integration behavior. This stage increases exposure because the appliance may become a staging point, callback source, exfiltration path, or bridge into internal application, management, identity, storage, backup, or deployment services.

Stage 7: Downstream Application Exposure and Administrative-Control Risk

The adversary uses 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 termination 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, support-account activity, management-interface exposure changes, or access-control changes. This stage becomes high priority when downstream behavior aligns with suspicious ADC activity by virtual service, backend pool, route, header pattern, source path, administrative identity, destination, or bounded time window.

Stage 8: Post-Remediation Trust Validation and Containment Risk

The adversary may retain access or leave uncertainty through modified configuration, altered virtual services, exposed certificates, changed backend pools, administrative-control changes, API key changes, logging degradation, diagnostic artifact deletion, unauthorized management exposure, outbound communication, or downstream application impact after patching or apparent remediation. Observable evidence may include post-patch access to management/API paths, continued rare egress, unexplained configuration drift, certificate or key access, recurring appliance instability, repeated callbacks, suspicious administrative activity, changed logging settings, unexpected downstream anomalies, or traffic-path behavior that does not match known-good configuration. This stage becomes high priority when activity continues after patching, management-plane isolation, configuration restoration, credential rotation, certificate review, administrative account review, egress blocking, or downstream application validation.

S19 — Attack Chain Risk Amplification Summary

Progress Kemp LoadMaster pre-authentication RCE and edge ADC compromise 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, certificate handling, administrative control, and downstream application trust. The chain becomes materially more dangerous when suspicious ADC management/API activity is followed by appliance-level command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, backend-pool changes, routing or header control, administrative changes, rare outbound communication, downstream application anomalies, or activity that continues after remediation.

·        Internet-facing or partner-reachable ADC exposure increases risk because the control plane may be reachable from adversary-controlled infrastructure, scanner infrastructure, cloud-hosted sources, VPN providers, residential proxies, compromised hosts, or insufficiently restricted partner paths.

·        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.

·        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.

·        Configuration access amplifies business impact when exposed material includes virtual services, backend pools, routing rules, rewrite rules, header rules, persistence profiles, 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, 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, paste-site access, SMTP behavior, 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 exposed 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 management/API access, rare egress, configuration drift, certificate access, administrative changes, appliance instability, logging degradation, or downstream anomalies continue after patching, isolation, credential rotation, or configuration restoration.

·        Business exposure increases when affected ADCs support customer-facing services, partner access, regulated information, authentication flows, TLS termination, regional applications, critical internal applications, executive communications, or high-availability web properties.

·        Incomplete management logs, API records, WAF records, reverse-proxy records, CDN records, load-balancer records, appliance syslog, configuration-change records, certificate-management records, DNS records, proxy records, firewall records, NDR telemetry, endpoint telemetry, downstream application logs, backup comparison data, or change-management records can force broader investigation because the organization cannot quickly prove whether command execution, certificate exposure, routing manipulation, or downstream impact occurred.

·        Response burden increases because teams must validate ADC asset exposure, affected version status, management/API isolation, suspicious request activity, appliance command execution, 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

Progress Kemp LoadMaster and edge ADC compromise attack-chain model showing edge ADC discovery, exposed management/API exploitation, appliance-level command execution, 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, version or banner discovery, source-infrastructure rotation, cloud-hosted infrastructure, VPN providers, residential proxies, suspicious ASNs, unusual geographies, scanner infrastructure, or probing of known management routes. This behavior becomes risk-relevant when exposed appliances have reachable management/API, administrative, diagnostic, authentication, telemetry, configuration, or control-plane surfaces and the activity aligns with later abnormal request behavior, appliance instability, command execution, configuration access, certificate access, rare egress, or traffic-path change.

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 behavior. This behavior becomes high priority when it aligns with command-delimiter patterns, shell-control content, quote manipulation, encoded command content, malformed JSON, oversized fields, unusual API parameters, abnormal methods, repeated failed-to-success sequences, abnormal status codes, response-size deviations, API-handler errors, authentication-handler errors, management-service faults, connection resets, or locally visible Progress Kemp LoadMaster API behavior such as /accessv2.

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 management/API access 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 control-plane activity and cannot be tied to approved backup jobs, certificate rotation, vendor support, configuration migration, failover testing, monitoring, vulnerability validation, emergency maintenance, or incident-response collection.

Traffic-Path and Trust-Boundary Manipulation

Adversaries may modify or abuse 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, WAF-adjacent policies, proxy policies, logging settings, or security-control policies. This behavior becomes high risk when traffic-path 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

Adversaries may use the ADC appliance, virtual appliance host, management host, or ADC-supporting workload for outbound DNS, HTTP, HTTPS, SSH, SMTP, raw-IP communication, file transfer, paste-site access, 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 management/API access or command execution, reaches rare destinations, uses unfamiliar infrastructure, deviates from approved vendor-support or update behavior, triggers DNS, proxy, firewall, NDR, or EDR alerts, or cannot be tied to approved 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, or backend visibility 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 follow suspicious ADC control-plane behavior and involve unexpected backend access, authentication-flow disruption, session-routing changes, header manipulation, traffic mirroring, TLS termination changes, service-account use, internal API access, database access, storage access, backup access, application-administration activity, or unauthorized administrative-control changes.

Operational Blending With ADC Administration and Support Workflows

Adversaries may blend malicious activity into normal ADC administration, firmware updates, vendor support, health-check tuning, backup jobs, certificate rotation, failover testing, configuration migrations, vulnerability validation, monitoring activity, red-team activity, emergency remediation, or incident-response cleanup. This blending is effective because ADC environments often generate legitimate management/API requests, configuration changes, certificate actions, routing updates, backend-pool changes, diagnostic bundles, appliance reboots, failover events, health-check changes, and vendor support activity. Detection and response require correlating request behavior, appliance execution, configuration state, certificate access, administrative context, outbound communication, and downstream application impact rather than relying on one artifact in isolation.

Post-Remediation Access and Trust Validation Failure

Adversaries may continue accessing management/API paths, altered configuration, exposed certificates, administrative accounts, API keys, outbound infrastructure, modified virtual services, changed backend pools, weakened logging, or downstream application paths after patching, isolation, credential rotation, certificate review, configuration restoration, or application validation. This behavior becomes high priority when access continues after remediation, originates from suspicious infrastructure, touches sensitive configuration or certificate material, triggers rare outbound communication, modifies traffic paths, causes downstream anomalies, or cannot be tied to approved business, vendor-support, or incident-response activity.

S20A — Adversary Tradecraft Summary

Progress Kemp LoadMaster pre-authentication RCE and edge ADC compromise targets the trust relationship between exposed traffic-management control planes, appliance command execution, configuration state, certificate handling, virtual services, backend routing, administrative control, outbound communication, and downstream application delivery. The adversary objective is to convert exposed or insufficiently isolated management/API access into command execution, configuration exposure, TLS or certificate risk, traffic-path manipulation, administrative-control compromise, outbound communication, downstream application exposure, or containment uncertainty while blending into normal ADC administration, vendor support, and application-delivery operations.

·        The core tradecraft pattern is suspicious ADC management/API activity followed by appliance instability, command 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 behavior is not dependent on a single exploit string, actor name, scanner fingerprint, request path, source IP, user agent, vendor label, API endpoint, 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, command-delimiter patterns, encoded command content, API parameter manipulation, diagnostic-function abuse, appliance-context command execution, configuration export, certificate access, virtual-service manipulation, backend-pool changes, rare egress, 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, file-transfer paths, high-availability applications, or multiple downstream services tied to common traffic-management infrastructure.

·        Detection requires visibility into the ADC request behavior that begins the chain and the appliance, configuration, certificate, administrative, outbound, network, and downstream application evidence that confirms or disproves impact.

·        Response requires treating suspected ADC control-plane exploitation as an application-delivery trust, certificate exposure, configuration integrity, traffic-path control, administrative-control, downstream application, and containment-validation incident, not a routine scanner alert, isolated appliance error, single vulnerable-version finding, or patch-management task.

·        The behavior remains durable because the adversary objective is to convert exposed edge control-plane trust into command execution, configuration exposure, certificate risk, traffic-path manipulation, downstream application exposure, or containment uncertainty regardless of the specific source infrastructure, API route, vendor appliance, scanner label, exploit variant, or campaign branding used.

S21 — Detection Strategy Overview

Detection Philosophy

Detect edge ADC, load balancer, reverse proxy, WAF-adjacent appliance, and traffic-management control-plane compromise through correlated behavior across management/API, appliance, configuration, network, certificate, routing, authentication, and downstream-application telemetry, not through CVE names, KEV status, vendor name, vulnerable-version status, proof-of-concept names, scanner hits, or isolated request strings alone. The durable detection model is unauthenticated or weakly authenticated access to an exposed ADC control plane followed by command execution, appliance instability, management/API abuse, configuration access, virtual-service or traffic-routing manipulation, TLS or certificate exposure, credential access, outbound communication, persistence-like appliance changes, administrative-control compromise, or downstream application exposure.

Primary Detection Anchors

·        Suspicious unauthenticated, external, partner-originated, or unusual requests to ADC management, API, administrative, configuration, authentication, diagnostic, telemetry, or control-plane endpoints.

·        Requests targeting Progress Kemp LoadMaster API behavior, including /accessv2 where API exposure is locally observable.

·        Requests containing command-delimiter, shell-control, quote-manipulation, encoded, malformed JSON, oversized, heap-shaping, authentication-bypass, or API-parameter manipulation patterns against ADC management surfaces.

·        ADC appliance process, service, diagnostic, shell, script, command, or utility execution that is not associated with approved administrative activity, vendor support, upgrade, backup, monitoring, or health-check behavior.

·        Management/API requests followed by appliance faults, crashes, abnormal status-code patterns, authentication anomalies, configuration reads, configuration writes, or administrative session behavior.

·        New, modified, exported, downloaded, or accessed ADC configuration objects, virtual services, real-server pools, content-switching rules, routing policies, persistence profiles, 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 credential-bearing appliance files.

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

·        Appliance-originated outbound DNS, HTTP, HTTPS, SSH, SMTP, raw-IP, file-transfer, paste-site, tunneling, or command-and-control-like communication after suspicious management/API access or command-execution behavior.

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

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

·        Multiple ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management appliances showing similar management/API probing, exploit-attempt, configuration, outbound, or traffic-path anomalies within a bounded time window.

Detection Prioritization Model

Prioritize activity where exposed ADC management/API access is followed within a bounded time window by appliance command execution, abnormal process behavior, configuration access, virtual-service manipulation, certificate or key access, credential exposure, outbound communication, administrative-control changes, logging degradation, appliance instability, or downstream application impact. Treat request telemetry alone as exposure or exploit-attempt evidence unless it is joined to appliance, process, configuration, authentication, certificate, routing, outbound, administrative, or downstream-application evidence.

Correlation Strategy (Strict Enforcement)

Do not promote a single ADC management request, a vulnerable-version finding, API exposure, KEV presence, public exploit availability, scanner traffic, generic command-injection string, isolated authentication failure, appliance error, or standalone network event to high-confidence compromise without correlation by appliance, management interface, API endpoint, source IP, forwarded source IP, partner network, virtual service, listener, backend pool, administrative account, session, request path, API command, configuration object, certificate object, process lineage, destination, maintenance window, or bounded time window. High-confidence detection requires a sequence that connects exposed ADC control-plane access to command execution, configuration exposure, traffic-path manipulation, credential or certificate access, outbound communication, persistence-like appliance change, administrative-control compromise, or downstream application exposure.

Telemetry Prioritization

Prioritize ADC management/API logs, administrative audit logs, appliance system logs, appliance shell or diagnostic execution logs, configuration-change logs, virtual-service and real-server change records, authentication logs, API access logs, WAF logs, reverse-proxy logs, load-balancer logs, CDN logs, TLS/certificate management logs, backup and export logs, firmware and package-change logs, DNS logs, proxy logs, firewall logs, EDR or NDR telemetry where available, SIEM asset inventory, vulnerability exposure data, partner access records, network flow logs, downstream web and application logs, and incident-response appliance review artifacts. Request-path, query-string, request-body metadata, API method, source identity, management-interface mapping, and appliance-to-application mapping are mandatory for strong request-side and traffic-path correlation.

Detection Design Constraints

Avoid detection designs based only on CVE identifiers, KEV status, vendor names, appliance banners, vulnerable-version status, proof-of-concept repository names, public user agents, IP addresses, file hashes, single endpoint names, one exploit string, or isolated scanner behavior. Detection must remain useful across ADC, load balancer, reverse proxy, WAF-adjacent, and traffic-management compromise variants that differ in vendor, endpoint path, authentication model, API method, command-injection primitive, exploit payload, appliance process model, configuration object, traffic-routing function, TLS-offload behavior, logging depth, and post-exploitation sequence.

Baseline and Deployment Requirements

Baseline approved ADC administrators, management source networks, partner-reachable access paths, vendor support sources, vulnerability scanners, patch-validation tools, maintenance windows, automation accounts, API clients, backup jobs, firmware update workflows, configuration export workflows, virtual-service changes, backend pool changes, certificate-management workflows, health-check changes, routing changes, persistence-profile changes, WAF/proxy-adjacent policy changes, approved outbound destinations, approved appliance reboots, and normal ADC configuration activity. Validate appliance-to-virtual-service, appliance-to-backend, management-interface-to-control-plane, and ADC-to-downstream-application mapping before promoting correlation logic to alert mode.

Variant Resilience Requirements

Rules should remain effective for future ADC, load balancer, reverse proxy, WAF-adjacent appliance, traffic-management, and edge control-plane abuse paths that produce the same operational behavior: exposed management/API access, unauthenticated or weakly authenticated exploit behavior, appliance command execution, configuration access, virtual-service manipulation, routing or header control, TLS/certificate exposure, credential access, rare egress, administrative-control changes, persistence-like appliance modification, or downstream application exposure.

Operational Detection Model

Run detections in hunt mode first, validate management/API log parsing, confirm request-path and request-body preservation where available, tune approved administrative and partner sources, validate joins between ADC logs and network telemetry, baseline normal appliance administration, verify configuration-object normalization, confirm virtual-service and backend-host mapping, test command-injection and encoded-input matching, validate certificate and key-management visibility, and then promote to alert mode. Use escalating confidence: suspicious management/API request, suspicious request plus appliance instability, suspicious request plus command-execution evidence, suspicious request plus configuration access, suspicious request plus certificate or credential access, suspicious request plus outbound communication, and suspicious request plus administrative, routing, TLS, logging, or downstream-application impact.

Explicit Non-Deployment Guardrails

Do not deploy weak WAF-only request rules as compromise detection. Do not claim appliance compromise from vulnerable-version status alone. Do not claim confirmed compromise from scanner traffic, public PoC availability, KEV status, generic ADC probing, common management paths, isolated API errors, unrelated authentication failures, cloud-only anomalies, identity-only anomalies, or network-only anomalies. Do not attribute downstream application behavior, certificate access, credential use, routing changes, backend access, or outbound traffic to ADC compromise without appliance, source, path, API, configuration, process, identity, destination, or time-window linkage.

S22 — Primary Detection Signals

Figure 4

Primary Detection Signals

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

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

·        API requests containing command-delimiter, shell-control, quote-manipulation, encoded, malformed JSON, oversized, heap-shaping, authentication-bypass, or parameter-manipulation patterns.

·        Management/API access followed by appliance command execution, shell invocation, diagnostic utility execution, script execution, package activity, transfer-tool execution, or unusual service-context behavior.

·        Management/API access followed by appliance faults, crashes, restart behavior, HTTP 400, 401, 403, 404, 500, timeout, abnormal response-size, or failed-to-success status-code sequences.

·        Access to ADC configuration exports, backup files, diagnostic bundles, packet captures, virtual-service objects, real-server pools, routing rules, WAF/proxy-adjacent policy objects, authentication templates, logging settings, or administrative settings.

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

·        New, modified, deleted, exported, or replaced virtual services, listener ports, backend pools, content-switching rules, rewrite rules, header rules, persistence profiles, health checks, authentication profiles, routing settings, or security-control policies.

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

·        New administrative accounts, administrative role changes, API key changes, support-account activity, backup schedule changes, firmware changes, package changes, cron-like activity, script changes, log clearing, diagnostic artifact deletion, or appliance reboot behavior near suspicious access.

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

Supporting Detection Signals

·        Unusual user agents, request sizes, JSON bodies, content types, API methods, request cadence, response sizes, source geographies, source ASNs, partner network paths, or repeated attempts around ADC management/API endpoints.

·        Scanner-like activity followed by management/API access, command-execution evidence, appliance instability, configuration access, outbound communication, or traffic-path changes.

·        HTTP 200, 202, 204, 206, 302, 400, 401, 403, 404, 500, timeout, or connection-reset patterns around API access, authentication attempts, command execution, configuration access, or appliance instability.

·        Administrative login from unfamiliar source IPs, devices, geographies, ASNs, partner paths, access methods, or time windows near suspicious management/API activity.

·        Configuration object changes inconsistent with approved ADC deployment behavior, maintenance windows, automation workflows, emergency changes, or vendor support activity.

·        Certificate or TLS object access inconsistent with approved certificate rotation, renewal, backup, deployment, or troubleshooting activity.

·        DNS, proxy, firewall, NDR, or EDR network activity from ADC appliances inconsistent with approved update, telemetry, monitoring, vendor-support, backup, or integration behavior.

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

·        SIEM, ITSM, change-management, backup, vulnerability-management, and asset-inventory records that confirm no approved maintenance, patch validation, vendor support, or configuration activity occurred during the suspicious window.

Exploit Attempt and Instability Signals

·        Repeated requests to ADC management, API, authentication, diagnostic, configuration, telemetry, or control-plane endpoints from external, unfamiliar, or partner-reachable sources.

·        Requests containing shell metacharacters, quote manipulation, encoded command content, JSON anomalies, oversized fields, unusual API keys, malformed authentication fields, or parameter structures inconsistent with normal ADC API clients.

·        Failed-to-success status-code transitions around the same ADC endpoint, source, management interface, API method, or appliance within a bounded time window.

·        Appliance errors, service faults, management-interface instability, API handler exceptions, authentication-handler failures, process crashes, watchdog events, unexplained restarts, or diagnostic errors near suspicious request activity.

·        Short-lived command, diagnostic, script, transfer, package, or shell artifacts that appear, execute, fail, restart, or disappear within a narrow window.

·        Unexpected management/API access immediately preceding firmware, configuration, virtual-service, certificate, routing, logging, or administrative changes.

·        Public PoC-like access patterns treated as exploit-attempt evidence only when locally observable through endpoint, request, body, sequence, or appliance-response behavior.

Outbound Communication Signals

·        DNS, proxy, firewall, NDR, EDR, or appliance network activity from ADC appliances to rare, newly seen, newly registered, suspicious, unknown, unapproved, or geographically unusual destinations after suspicious management/API access.

·        Appliance processes, diagnostic functions, shell activity, or service contexts initiating outbound HTTP, HTTPS, DNS, SSH, SMTP, raw-IP, paste-site, file-sharing, tunneling, or command-and-control-like communication.

·        Outbound connections temporally aligned with command execution, configuration access, certificate access, backup export, diagnostic bundle creation, appliance instability, or administrative-control changes.

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

·        Network activity from ADC appliances inconsistent with approved health checks, backend monitoring, license validation, vendor support, update retrieval, telemetry, DNS resolution, NTP, syslog, or monitoring behavior.

·        Unexpected outbound communication from an ADC appliance 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, local scripts, cron-like entries, diagnostic settings, logging settings, or appliance configuration objects.

·        Modified virtual services, backend pools, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, WAF/proxy-adjacent controls, health checks, or SSL/TLS offload settings outside approved maintenance.

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

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

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

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

Lateral Movement and Expansion Signals (Conditional)

·        Use of ADC-stored, appliance-accessible, or traffic-path-exposed credentials against downstream applications, backend servers, identity providers, management systems, databases, storage, backup platforms, or deployment systems.

·        Appliance-originated connections to backend management interfaces, internal APIs, identity services, database services, file-sharing services, mail systems, storage systems, backup repositories, or deployment pipelines.

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

·        Multiple virtual services, backend pools, partner-exposed applications, or edge appliances showing similar exploit-attempt, configuration-access, outbound, certificate-access, or traffic-path manipulation patterns.

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

·        Expansion from a traffic-management appliance into internal application, identity, certificate, cloud, monitoring, backup, or deployment infrastructure using trust relationships exposed through the appliance.

Signal Usage Constraints

Do not treat any single signal as compromise confirmation. Promote confidence only when signals align by ADC appliance, management interface, API endpoint, source IP, forwarded source IP, partner path, administrative account, virtual service, backend pool, configuration object, certificate object, process lineage, destination, maintenance window, or bounded time window. Treat KEV status, public PoC availability, vulnerable-version status, and exploitation-attempt reporting as urgency inputs, not detection proof.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

·        EDR, NDR, appliance shell logging, Linux audit, syslog, vendor diagnostic logs, command-execution logs, or equivalent process and service-context telemetry from ADC appliances where available.

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

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

·        Detection of 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, and managed ADC deployments.

·        Approved deployment-user, approved API client, approved command, approved diagnostic, approved backup, approved upgrade, approved monitoring, approved vulnerability-validation, and approved vendor-support exceptions.

Memory and Execution Telemetry

·        Appliance service-context execution evidence where available.

·        API handler, management service, authentication component, diagnostic service, shell, script, package, or appliance daemon execution context where available.

·        Runtime command execution, interpreter invocation, encoded command execution, child-process spawning, abnormal argument handling, or unusual API-driven execution behavior.

·        Process lineage linking management/API access, authentication handling, command construction, shell invocation, configuration access, file access, certificate access, transfer-tool use, or outbound connection behavior.

·        Memory telemetry is optional and should be treated as conditional enrichment, not a minimum requirement.

·        Runtime execution telemetry is strongly recommended but may be unavailable on sealed, vendor-managed, virtual, or appliance-restricted ADC deployments.

Crash and Fault Telemetry

·        ADC appliance system logs.

·        Management/API error logs.

·        Authentication-handler logs.

·        API gateway logs.

·        WAF block, allow, anomaly, and violation logs.

·        Reverse-proxy, CDN, and load-balancer status-code logs.

·        Appliance service crash, watchdog, restart, health, failover, high-availability, diagnostic, and resource-exhaustion events.

·        HTTP 400, 401, 403, 404, 500, abnormal response-size, timeout, connection-reset, repeated retry, failed-to-success, and API instability patterns around suspicious ADC management routes.

·        Vendor support, monitoring, resource-abuse, configuration-integrity, failover, health-check, or incident-response events where available.

File and Persistence Telemetry

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

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

·        Detection of unexpected shell scripts, command output files, diagnostic artifacts, encoded files, compressed archives, credential-bearing exports, certificate material, private-key access, configuration backups, and suspicious temporary files.

·        Known-good appliance configuration baseline.

·        Approved virtual-service inventory.

·        Approved real-server pool inventory.

·        Approved certificate and TLS binding inventory.

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

·        Configuration-change records for administrative users, API keys, virtual services, backend pools, routing rules, content-switching rules, SSL/TLS settings, certificate bindings, WAF/proxy-adjacent policies, logging, backups, and management access.

·        Backup comparison data, appliance configuration exports, SIEM change records, ITSM change 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.

·        Destination domain, destination IP, destination port, protocol, process context where available, source appliance, source interface, source account where available, timestamp, action, and reputation enrichment.

·        Recently seen domain enrichment.

·        Newly registered domain enrichment.

·        Destination country and ASN enrichment where available.

·        Approved egress-destination lookup.

·        Approved vendor-support destination lookup.

·        Approved update, telemetry, monitoring, license-validation, health-check, DNS, NTP, syslog, backup, and integration destination lookups.

·        Backend application, identity, database, storage, mail, monitoring, backup, and management-service destination mapping.

Web and Application Telemetry (Conditional Availability)

·        ADC management/API logs with request path, method, query-string, and request-body metadata preservation 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, user agent, source IP, forwarded source IP, management interface, 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 exposure inventory.

·        ADC API exposure inventory.

·        Virtual-service and backend-pool inventory.

·        Certificate and TLS-offload inventory.

·        Administrative audit logs where available.

·        Configuration database records, configuration export records, and change-management records where native audit logs are absent.

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

Telemetry Availability Requirements

·        Minimum viable coverage requires ADC management/API, WAF, reverse-proxy, CDN, load-balancer, or server-side access logs plus ADC appliance, version, management-exposure, API-exposure, virtual-service, and backend-pool inventory.

·        Strong coverage requires management/API telemetry joined to appliance system logs, configuration-change logs, network telemetry, authentication logs, certificate-management records, outbound DNS/proxy/firewall logs, approved-source lookups, and downstream-application context.

·        Highest confidence requires correlation across suspicious ADC management/API request activity, appliance instability, command-execution evidence, configuration access or change, certificate or credential access, virtual-service or routing manipulation, rare egress, administrative-control change, logging degradation, and downstream-application review.

·        Managed, virtual, cloud-hosted, or sealed appliance environments require compensating evidence from WAF logs, reverse-proxy logs, CDN logs, vendor appliance logs, configuration exports, backup comparison, SIEM records, network telemetry, change-management records, and downstream application logs.

·        Cloud-hosted ADC environments require appliance-layer, application-layer, and network-layer telemetry; cloud control-plane logs alone are not sufficient.

Telemetry Limitations and Gaps

·        ADC management logs may rotate quickly.

·        Request bodies may not be logged.

·        Query strings may not be logged.

·        API parameters may be redacted.

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

·        Sealed or managed ADC deployments may not expose process, memory, file, package, or shell telemetry.

·        WAF, CDN, reverse-proxy, and load-balancer logs may hide backend host identity without mapping.

·        Virtual-service and backend-pool changes may require configuration export comparison rather than native audit logs.

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

·        File timestamps may be unreliable after backup restore, appliance failover, firmware update, configuration import, vendor support activity, or attacker cleanup.

·        Endpoint telemetry may be unavailable on appliance operating systems.

·        Network telemetry may not attribute outbound connections to a specific appliance process.

·        Cloud logs alone cannot prove ADC management/API exploitation, appliance command execution, configuration manipulation, certificate exposure, or downstream application impact.

·        Vulnerable-version status cannot prove compromise or non-compromise.

S24 — Detection Opportunities and Gaps

Detection Opportunities

·        Suspicious ADC management/API 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.

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

·        ADC API request review may identify command-delimiter, quoting, encoded, malformed JSON, oversized, heap-shaping, or authentication-bypass patterns tied to exploit attempts.

·        Appliance system logs can reveal management-service faults, process crashes, watchdog events, API handler errors, service restarts, failover behavior, and diagnostic instability after suspicious access.

·        Configuration-change telemetry can reveal unexpected virtual-service, backend-pool, routing, rewrite, header, persistence, health-check, WAF/proxy-adjacent, 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, or internal service access from ADC appliances after suspicious management/API behavior.

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

·        WAF, CDN, reverse-proxy, and load-balancer logs may preserve request-path, source, forwarded-source, virtual-service, and backend context when appliance logs are incomplete or rotated.

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

·        Change-management, SIEM, ITSM, vulnerability-management, and vendor-support records can separate approved ADC maintenance from suspicious activity.

·        Multi-appliance correlation can identify campaigns targeting exposed ADC control planes 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.

·        ADC appliances may not expose process, memory, shell, file, or package telemetry to defenders.

·        Request-path and query-string visibility may be incomplete when traffic passes through CDN, WAF, reverse-proxy, NAT, or centralized logging layers.

·        API exposure may be limited to partner networks or internal paths that are poorly inventoried.

·        Attackers may exploit one management path and perform configuration, certificate, outbound, or downstream activity through another path.

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

·        Configuration export timestamps may reflect backup, migration, failover, 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, and incident-response cleanup may resemble suspicious behavior.

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

·        Cloud control-plane, identity, DNS, or flow telemetry cannot prove ADC management/API exploitation without appliance-layer, configuration-layer, traffic-path, or downstream-application correlation.

·        Vulnerability scanner findings cannot determine whether appliance configuration, credentials, certificates, virtual services, or downstream applications were affected before patching.

Compensating Controls

·        Use ADC management/API logs, WAF logs, CDN logs, reverse-proxy logs, load-balancer logs, and downstream web logs together to recover URI, method, source, forwarded-source, virtual-service, and backend-host context.

·        Preserve appliance, WAF, CDN, reverse-proxy, load-balancer, firewall, DNS, proxy, and downstream application logs before rotation during exposure review.

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

·        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 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 APIs and management interfaces where operationally feasible.

·        Review appliance-originated outbound traffic for rare destinations, newly seen 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, availability impact, and unauthorized backend access.

·        Use vulnerability scanning, public PoC awareness, and KEV status as prioritization inputs, not standalone proof of compromise.

·        Maintain ADC appliance, version, management exposure, API exposure, virtual-service, backend-pool, certificate, route, policy, administrator, approved-source, approved-maintenance, approved-egress, and downstream-application inventories.

Non-Coverage Conditions

·        Activity limited to vulnerable-version status without suspicious management/API, appliance, configuration, certificate, outbound, administrative, traffic-path, or downstream-application evidence.

·        Scanner traffic that does not align with command execution, appliance instability, configuration access, certificate access, outbound communication, administrative change, or downstream impact.

·        Generic command-injection activity with no ADC appliance, management interface, API endpoint, source, configuration object, process, destination, or time-window linkage.

·        Unrelated ADC, load balancer, reverse proxy, WAF, firewall, VPN, or management-plane vulnerabilities that do not involve exposed traffic-management control-plane abuse, appliance command execution, configuration manipulation, certificate exposure, routing control, or downstream application exposure.

·        Citrix identity/session disclosure, Cisco firewall-management-plane compromise, cPanel hosting-control-plane compromise, or CMS exploitation unless the observable behavior is being used only as external comparison and not claimed as direct ADC/load-balancer coverage.

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

·        Benign administrative maintenance, approved patching, approved certificate renewal, approved API automation, approved virtual-service changes, approved backup activity, approved failover testing, approved vendor support, approved vulnerability validation, 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

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

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")
)

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

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

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, 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 the observable enterprise sequence associated with suspicious ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management control-plane access; 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, TLS, or logging change; administrative-control change; multi-asset probing; and downstream cloud or protected-application activity.

Coverage is strongest where ADC management/API logs, appliance syslog, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, gateway logs, administrative audit logs, configuration-change records, certificate-management records, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, endpoint telemetry, downstream application logs, SIEM correlation, and cloud telemetry can be joined into bounded behavioral sequences.

Primary Coverage Areas

·        Suspicious ADC management/API 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 access behavior tied to ADC, load balancer, reverse proxy, WAF-adjacent, or traffic-management appliances

·        Appliance instability after suspicious control-plane access, including watchdog restart, management-service fault, API handler exception, authentication-handler error, failover event, service restart, abnormal connection state, resource exhaustion, or control-plane instability sequence

·        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 control-plane access

·        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 control-plane 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, logging-setting modification, administrative-setting modification, API-key creation, administrator creation, or role modification after suspicious control-plane access

·        Multi-asset ADC control-plane probing involving related source infrastructure, request-family behavior, control-plane 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 following suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, downstream application exposure, or multi-asset ADC probing

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 when 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

Appliance Instability After Control-Plane Access

This behavior is covered where suspicious ADC control-plane access can be correlated to appliance health events, management-service faults, API handler exceptions, authentication-handler errors, watchdog restarts, failover events, abnormal connection states, resource exhaustion, or control-plane instability sequences.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage for control-plane access followed by abnormal connection behavior, service unavailability, reset patterns, timeout behavior, rare egress, status-sequence anomalies, and appliance-facing instability indicators

·        Splunk, Elastic, QRadar, and SIGMA coverage for suspicious control-plane access followed by appliance instability where management/API telemetry, appliance syslog, health events, status sequences, 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 after control-plane activity

·        AWS, Azure, and GCP coverage only when ADC instability can be joined to later cloud identity, resource, network, logging, security-control, or application-delivery activity through reliable cloud-context mapping

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 error alone is not sufficient

·        Coverage requires prior suspicious control-plane access, same-asset continuity, source continuity, request-family continuity, management-interface lineage, appliance-health lineage, egress behavior, configuration activity, or downstream impact context

·        Approved failover testing, health checks, patching, maintenance, vendor support, monitoring, backup, 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 control-plane 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 control-plane-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, management-interface, and control-plane context are normalized or enriched

·        AWS, Azure, and GCP coverage only where rare egress or ADC compromise context can be joined to 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 prior suspicious ADC control-plane access, same-asset lineage, management-interface lineage, source continuity, appliance instability, configuration or certificate access, administrative-control change, endpoint context, downstream application behavior, or cloud-impact context

·        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 control-plane 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, management/API activity, 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 configuration, credential, certificate, or secret-access context leads to cloud-resource, secret, storage, key, identity, workload, or control-plane activity tied back to ADC context

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 prior suspicious ADC control-plane access, same-asset lineage, same-object lineage, same-source lineage, management-interface continuity, rare egress, downstream application behavior, or cloud-impact context

·        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, health-check records, logging-setting records, administrative-user records, API-key records, and downstream application telemetry can be joined to suspicious control-plane access.

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, health-check modification, logging-setting modification, administrative-setting modification, API-key creation, administrator creation, or role modification after suspicious control-plane access

·        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 only where ADC traffic-path or administrative-control impact touches AWS, Azure, or Google Cloud load balancer, WAF, DNS, storage, secrets, keys, logging, compute, identity, or application-delivery workflows

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

·        An administrator creation event alone is not sufficient

·        Logging degradation alone is not sufficient

·        Reliable prior suspicious control-plane access, source continuity, asset continuity, management-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, 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 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 probing

·        AWS, Azure, and GCP coverage only when multi-asset probing or post-access behavior can be joined to cloud identity, resource, network, load balancer, WAF, storage, secret, key, workload, account, subscription, project, or organization 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

·        A scanner-like pattern 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

·        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 suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, backup or diagnostic export, virtual-service or backend-pool change, routing or header manipulation, TLS or certificate binding change, administrative-control change, logging degradation, downstream application exposure, or multi-asset ADC probing can be joined to AWS activity.

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

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 stronger workload, identity, source, host, resource, load balancer, WAF, S3, Secrets Manager, KMS, assumed-role, instance, container, workload, 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 suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, backup or diagnostic export, virtual-service or backend-pool change, routing or header manipulation, TLS or certificate binding change, administrative-control change, logging degradation, downstream application exposure, or multi-asset ADC probing can be joined to Azure activity.

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

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 stronger 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 suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, backup or diagnostic export, virtual-service or backend-pool change, routing or header manipulation, TLS or certificate binding change, administrative-control change, logging degradation, downstream application exposure, or multi-asset ADC probing can be joined to Google Cloud activity.

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

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 stronger 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 supporting sequence coverage where suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, multi-asset probing, downstream application exposure, or downstream cloud activity can be paired with network behavior.

Coverage may include suspicious management/API access, unusual source infrastructure, rare ASN, rare geography, abnormal request timing, abnormal request size, abnormal response size, suspicious payload patterns, abnormal status sequence, control-plane-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 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, traffic-path manipulation, AWS compromise, Azure compromise, Google Cloud compromise, downstream cloud compromise, downstream application compromise, or data theft without ADC 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, appliance instability, rare ADC egress, configuration access, certificate access, backup export, diagnostic artifact access, traffic-path manipulation, administrative-control change, multi-asset probing, and downstream application behavior.

SIGMA is useful as event-level detection logic but 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, and multi-asset-probing-to-post-access behavior, but the target backend must implement temporal correlation between ADC management/API telemetry, appliance syslog, configuration-change records, certificate records, endpoint telemetry, DNS, proxy, firewall, NDR, downstream application logs, and downstream cloud telemetry.

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.

Coverage Gaps and Non-Coverage Conditions

The S25 rule set does not directly prove ADC exploitation, appliance command execution, 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, 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, vendor, virtual service, backend pool, backend host, workload, tenant, account, subscription, project, exposure state, or business criticality

·        ADC management/API surfaces, diagnostic routes, administrative routes, configuration surfaces, authentication surfaces, telemetry surfaces, Progress Kemp LoadMaster /accessv2 paths where locally relevant, generic control-plane paths, virtual-service objects, backend-pool objects, certificate objects, backup objects, diagnostic objects, and protected configuration 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, timing fields, appliance health events, or management-service fault fields are unavailable or not normalized

·        Source IP attribution is unstable or hidden behind shared VPN, proxy, NAT, CDN, partner, scanner, managed-service, or validation infrastructure

·        Control-plane-to-instability, control-plane-to-egress, control-plane-to-configuration-access, control-plane-to-certificate-access, control-plane-to-traffic-path-change, multi-asset-probing, or downstream cloud correlation windows are not tuned

·        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, 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, forwarded administrator sources, scanner sources, vendor support sources, managed-service sources, monitoring systems, validation sources, backup workflows, certificate-rotation workflows, diagnostic workflows, patch workflows, maintenance windows, change windows, incident-response windows, approved process baselines, approved file paths, approved command patterns, and approved egress destinations are not tightly scoped

·        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, or AWS sensitive-resource inventories are disabled or incomplete

·        Azure Activity, Entra ID, Key Vault diagnostics, Storage logging, Defender for Cloud, Sentinel, resource diagnostics, Network Security Group flow logs, Azure Firewall logs, Application Gateway logs, Front Door logs, WAF logs, managed-identity telemetry, or Azure sensitive-resource inventories are disabled or incomplete

·        Google Cloud Admin Activity logs, Data Access logs, Cloud Identity logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Security Command Center context, Chronicle enrichment, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, load-balancer logs, service-account inventory, or sensitive-resource inventories are disabled or incomplete

·        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, account, subscription, project, organization, or correlation mapping is unreliable

·        Adversary activity blends into approved administrative, diagnostic, backup, certificate-rotation, patch, failover, migration, vendor-support, managed-service, monitoring, scanner, security-tooling, incident-response, or emergency maintenance workflows

·        Downstream cloud activity does not occur after suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, downstream application exposure, or multi-asset ADC probing

·        Exploitation produces no observable control-plane 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 the key observable stages of suspicious ADC control-plane access, appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, multi-asset probing, downstream application exposure, and downstream AWS, Azure, and Google Cloud activity.

Coverage is strongest for suspicious ADC management/API behavior, control-plane-to-instability sequencing, control-plane-to-egress sequencing, protected configuration access, certificate or private-key access, backup or diagnostic export, virtual-service or backend-pool modification, routing or header manipulation, TLS or certificate binding change, administrative-control change, logging degradation, multi-asset control-plane probing, and downstream cloud activity when telemetry is normalized and sequence correlation is available.

The rule set 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, command strings, file hashes, scanner signatures, campaign names, actor branding, tool names, and other single-event conclusions as the basis for detection. Detection confidence depends on correlating suspicious ADC control-plane activity, appliance context, egress behavior, configuration and certificate activity, administrative changes, traffic-path behavior, downstream application impact, and downstream cloud behavior rather than treating any single event category 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, load balancer, reverse proxy, WAF-adjacent, or traffic-management control-plane access; 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, TLS, or logging change; administrative-control change; multi-asset 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, 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

·        Appliance health, service fault, API handler, authentication handler, watchdog, 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, 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 control-plane access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, downstream application exposure, or multi-asset probing

·        ADC asset, management interface, virtual service, 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 probing, downstream application exposure, or downstream cloud activity.

Investigation Use

Investigators should determine whether the 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 AWS, Azure, or Google 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 before they become actionable as compromise-oriented detection evidence.

Appliance Instability and Health Artifacts

Relevant Artifacts

Watchdog restart, service restart, management-service fault, API handler exception, authentication-handler error, failover event, resource exhaustion, high CPU, memory pressure, abnormal connection state, timeout, reset, closed-after-error event, service unavailable response, abnormal redirect sequence, repeated errors, errors-then-success sequence, control-plane instability sequence, appliance health event, management 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

·        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, service fault, API fault, failover behavior, restart behavior, or abnormal connection behavior occurs after suspicious ADC control-plane access. They are strongest when tied to same-asset continuity, same-source continuity, management-interface lineage, request-family continuity, abnormal status 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, diagnostic collection, configuration change, resource pressure, known device defect, or incident-response activity. They should review whether the instability follows suspicious management/API access 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 prior suspicious control-plane activity, same-asset context, source continuity, request-family continuity, management-interface lineage, egress behavior, configuration or certificate access, administrative-control change, 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 control-plane 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 configuration, backup, diagnostic, packet capture, certificate, key, keystore, API-token, or credential-bearing artifact 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 control-plane behavior and whether activity 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 prior suspicious control-plane access, same-asset lineage, same-source lineage, same-object lineage, management-interface continuity, rare egress, downstream application behavior, or cloud-impact context.

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, 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

·        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 control-plane access. 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-control activity is expected for the application, ADC asset, virtual service, backend pool, 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 management/API access 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. Administrator creation alone is not sufficient. Logging degradation alone is not sufficient. These artifacts require prior suspicious control-plane access, source continuity, asset continuity, management-interface continuity, configuration-object lineage, downstream application behavior, network behavior, 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, 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 access, 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 prior suspicious ADC control-plane behavior, appliance instability, configuration access, certificate access, same-asset lineage, endpoint or appliance context, downstream application behavior, or cloud-impact context.

Multi-Asset ADC 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.

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 the clustered 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 prior suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, downstream application exposure, or multi-asset probing context is present and AWS activity is objectively suspicious.

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 prior suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, downstream application exposure, or multi-asset probing context is present and Azure activity is objectively suspicious.

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 prior suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, downstream application exposure, or multi-asset probing context is present and Google Cloud activity is objectively suspicious.

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 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 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, 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, source IP, user agent, payload string, command string, scanner hit, vulnerable-version observation, configuration event, certificate event, rare destination, cloud 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, 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

·        Appliance health, service fault, API handler, authentication handler, watchdog, failover, abnormal connection-state, and instability context third

·        Configuration object, backup, diagnostic bundle, packet capture, certificate object, TLS object, private-key, keystore, API-token, credential-bearing artifact, and protected-object context fourth

·        Virtual-service, backend-pool, routing, rewrite, header, persistence, TLS offload, certificate binding, health-check, logging-setting, administrator, API-key, role, and downstream application context fifth

·        DNS, proxy, firewall, NDR, destination reputation, first-seen, domain-age, ASN, geography, destination-port, protocol, and ADC-originated egress correlation sixth

·        Multi-asset probing, source clustering, request-family grouping, exposure-class clustering, asset-group clustering, and post-access behavior context seventh

·        Downstream AWS, Azure, and Google Cloud cloud-impact correlation eighth

·        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, 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

·        Vendor and platform family

·        Virtual service

·        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

·        Appliance health event

·        Management-service fault

·        API handler exception

·        Authentication-handler error

·        Failover event

·        Abnormal connection state

·        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

·        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 control-plane activity and follow-on appliance instability, egress behavior, protected object access, traffic-path manipulation, administrative-control change, downstream application behavior, multi-asset probing, or cloud behavior.

Recommended Starting Windows

·        Suspicious ADC control-plane access to appliance instability 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, TLS, certificate-binding, health-check, logging, administrative, API-key, or role change within 8 hours

·        Suspicious ADC control-plane access to downstream application behavior within 8 hours

·        Related multi-asset ADC control-plane probing to post-access behavior within 8 hours

·        Suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, downstream application exposure, or multi-asset probing context to AWS, Azure, or Google Cloud activity within 24 hours

·        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, request-family 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

·        Virtual-service and backend-pool mapping is reliable

·        ADC management/API route mapping is reliable

·        Appliance health and syslog 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 vendor support sources, approved managed-service sources, approved validation 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 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 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 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 the affected asset an internet-facing, partner-reachable, management-exposed, production, authentication-fronting, TLS-terminating, or high-criticality ADC asset

·        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, or request pattern unusual

·        Was the activity tied to a management/API surface, diagnostic surface, administrative surface, authentication surface, configuration surface, telemetry surface, control-plane surface, or Progress Kemp LoadMaster /accessv2 path where locally relevant

·        Did appliance instability, management-service fault, API handler exception, authentication-handler error, watchdog restart, failover event, 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, 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, or availability degradation

·        Did related multi-asset ADC 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

·        Can the activity be linked by ADC asset, management interface, 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, 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 access is followed by appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, logging degradation, downstream application behavior, multi-asset post-access behavior, or downstream cloud administrative 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 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, 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 control-plane access 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

·        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, 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, cloud event, or static indicator as proof of compromise.

Do not attribute cloud-only, endpoint-only, egress-only, web-only, appliance-only, configuration-only, certificate-only, traffic-path-only, administrative-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 prior suspicious ADC context and reliable workload, source, host, asset, identity, object, or resource-lineage correlation.

Do not enable high-confidence alerting until platform-specific schemas, index names, sourcetypes, DSM fields, custom properties, ECS mappings, ADC 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, 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, TLS, or logging change, administrative-control change, multi-asset probing, downstream application exposure, and downstream cloud-impact activity.

Coverage is strongest when ADC management/API, 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, command strings, file hashes, scanner signatures, vulnerable-version observations, campaign names, actor branding, tool names, cloud events alone, and 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 compromise, appliance instability, configuration and certificate access, traffic-path manipulation, rare egress, downstream application exposure, and downstream cloud activity.

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

·        Appliance instability after suspicious control-plane access, including watchdog restart, service restart, management-service fault, API handler exception, authentication-handler error, failover event, resource exhaustion, abnormal connection state, or abnormal status sequencing

·        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 control-plane behavior

·        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 control-plane activity

·        Virtual-service modification, backend-pool modification, routing-rule modification, rewrite-rule modification, header-rule modification, 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 control-plane behavior

·        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 correlated with suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, downstream application exposure, or multi-asset probing context

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

·        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, 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, status sequencing, rare egress, and multi-asset probing without appliance, configuration, certificate, or administrative enrichment

·        Traffic-path manipulation coverage where virtual-service, backend-pool, routing, header, 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, or organization lineage is partial

·        Downstream application exposure detection where application logs, backend mapping, WAF telemetry, CDN telemetry, or content-monitoring telemetry is incomplete

Limited Coverage Areas

·        Exploitation that produces no observable control-plane 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

·        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, 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

·        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

·        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 supporting sequence coverage for suspicious ADC control-plane access, unusual source infrastructure, rare source ASN, abnormal request timing, abnormal request size, abnormal response size, unusual status sequences, control-plane-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 probing, downstream traffic shifts, and cloud access paths.

NDR does not independently prove ADC exploitation, appliance command execution, 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 control-plane access, 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 exploitation proof.

Splunk

Splunk provides strong correlation coverage when ADC management/API, 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, 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, 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, appliance instability, rare ADC egress, configuration access, certificate access, backup export, diagnostic artifact access, traffic-path manipulation, administrative-control change, multi-asset 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 prior ADC control-plane access, appliance instability, rare egress, configuration or certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, logging degradation, downstream application exposure, or multi-asset probing context through reliable AWS account lineage plus stronger workload, identity, source, host, resource, load balancer, WAF, S3, Secrets Manager, KMS, assumed-role, instance, container, workload, ADC asset, virtual-service, backend-pool, or correlation linkage.

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 prior ADC context through reliable tenant and subscription lineage plus stronger 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.

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 ADC context are normalized and correlated through organization and project lineage plus stronger 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.

Coverage Conclusion

The detection set provides strong practical coverage for observable enterprise behavior associated with suspicious ADC control-plane access, appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, multi-asset 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, appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path change, administrative-control change, downstream application behavior, multi-asset post-access behavior, or downstream cloud behavior.

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, appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, multi-asset probing, downstream application exposure, and downstream cloud activity.

Direct compromise confirmation remains limited because enterprise telemetry generally does not expose attacker intent, exploit success, 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 suspicious control-plane 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 post-exposure behavior that can be detected across ADC management/API, 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, 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

·        Appliance instability after suspicious control-plane access, including watchdog restart, service restart, management-service fault, API handler exception, authentication-handler error, failover event, resource exhaustion, abnormal connection state, and abnormal status sequencing

·        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, 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 suspicious ADC control-plane access, appliance instability, rare egress, configuration or certificate access, traffic-path manipulation, administrative-control change, logging degradation, downstream application exposure, or multi-asset probing context

Telemetry Maturity

Telemetry maturity is moderate to high.

ADC management/API, 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, virtual service, 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, 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 IP 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 suspicious 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, 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 ADC control-plane access, 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, and cloud identity 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 access into appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, downstream application exposure, multi-asset post-access behavior, or downstream cloud activity.

The model is less resilient when adversaries use expected administrator sources, expected user agents, approved vendor support paths, approved managed-service sources, approved deployment workflows, normal certificate rotation paths, expected backup or diagnostic processes, approved cloud automation, or known business destinations. 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.

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, 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, 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, patch validation, vendor support, managed-service activity, backup workflows, certificate rotation, diagnostic collection, failover testing, deployment workflows, routing 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, 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 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 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 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

·        High false-positive potential when detections are deployed without local tuning

Maturity Improvement Priorities

Priority Improvements

·        Improve ADC management/API, WAF, reverse-proxy, CDN, load-balancer, gateway, and appliance syslog retention

·        Improve ADC asset ID, management interface, virtual service, 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, 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, and timing normalization

·        Improve appliance health, management-service fault, API handler, authentication-handler, failover, watchdog, 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, 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, and egress-port normalization

·        Improve downstream application logging, backend mapping, authentication-flow monitoring, session-routing monitoring, header behavior, 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, 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

·        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, 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, appliance instability, rare egress, configuration access, certificate access, backup or diagnostic export, traffic-path manipulation, administrative-control change, multi-asset probing, downstream application exposure, and downstream cloud-impact patterns. It should not be used as a standalone proof model for ADC exploitation, 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

Progress Kemp LoadMaster pre-authentication RCE and edge ADC compromise requires telemetry that can prove whether suspicious ADC management/API access, command-injection behavior, appliance instability, command execution, configuration exposure, certificate or private-key access, virtual-service manipulation, routing changes, administrative-control activity, outbound communication, downstream application exposure, or post-remediation activity stayed within normal traffic-management administration or created material application-delivery trust risk. The central dependency is the ability to correlate ADC asset inventory, management/API exposure, affected version state, access restrictions, management logs, WAF records, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, 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 control-plane-to-impact investigation model.

ADC Asset, Exposure, and Control-Plane Telemetry

·        ADC asset telemetry must identify Progress Kemp LoadMaster appliances, comparable 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, and internal-only management surfaces.

·        Exposure telemetry must identify management/API endpoints, administrative interfaces, diagnostic functions, authentication paths, telemetry paths, configuration paths, support paths, API exposure state, management-interface exposure state, access restrictions, approved source networks, partner access paths, and affected version 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, virtual service, backend pool, listener, environment, region, business owner, application owner, certificate owner, administrator owner, and remediation status where available.

·        This telemetry is required to determine whether suspicious management/API activity affected the correct exposure class: exposed or insufficiently isolated ADC control planes that can influence application-delivery trust.

·        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, and internal-only ADC deployments 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 API-path access may occur during approved administration or validation.

Appliance System, Process, and Runtime Execution Telemetry

·        Appliance system telemetry must capture service faults, API handler errors, authentication-handler errors, management-service faults, watchdog events, restarts, failover events, 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, restart event, timestamp, management interface, virtual-service context, and administrator context where available.

·        This telemetry is required to determine whether suspicious ADC management/API activity remained exploit-attempt behavior or progressed into appliance-level command execution, diagnostic abuse, abnormal process behavior, or runtime activity.

·        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 process and runtime telemetry must be interpreted against approved vendor support, firmware updates, diagnostics, backups, monitoring, patch validation, health checks, 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, 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, change source, and approved change record where available.

·        This telemetry is required to determine whether suspicious ADC control-plane 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.

·        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 ADC activity created certificate exposure, private-key exposure, API-token exposure, credential exposure, TLS trust impact, authentication-flow risk, or downstream application trust uncertainty.

·        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, 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 or partner access.

·        Outbound telemetry should identify rare destinations, newly observed domains, raw-IP communication, DNS anomalies, HTTP or HTTPS callbacks, SSH, SMTP, file-transfer behavior, paste-site access, 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 access, appliance command execution, configuration access, certificate access, administrative activity, and downstream application anomalies into one investigation timeline.

·        Network telemetry must not be used as standalone exploit confirmation because it may lack request body detail, API 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, and availability impact.

·        Required fields include downstream application, backend host, backend IP, virtual service, backend pool, request path, source path, header state, session identifier where available, authentication-flow state, service account, response size, response code, 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.

·        Downstream telemetry must be interpreted against approved application releases, infrastructure changes, load-balancer changes, certificate rotations, emergency maintenance, failover testing, incident-response cleanup, and expected application behavior.

·        Downstream application anomalies should not be attributed to ADC compromise unless aligned by appliance, virtual service, backend pool, route, header pattern, source path, administrative action, 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, health-check tuning, backup activity, failover testing, monitoring changes, vulnerability validation, red-team activity, emergency maintenance, and incident-response cleanup.

·        Incident-response records must capture affected appliance, affected version, affected management path, affected API path, 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, and approved business-required egress.

·        This telemetry is required to determine whether containment was complete, whether suspicious access continued after remediation, whether certificate or credential exposure was scoped, and whether observed behavior aligned with approved traffic-management operations.

·        Remediation should not be assumed complete unless patch state, management/API isolation, appliance state, configuration integrity, virtual services, backend pools, certificate exposure, credential exposure, administrative state, outbound activity, downstream application behavior, and post-remediation monitoring are explicitly validated.

S32 — Detection Limitations

Detection of Progress Kemp LoadMaster pre-authentication RCE and edge ADC compromise is limited by whether the organization can reconstruct the relationship between exposed ADC assets, management/API reachability, affected version status, suspicious control-plane request activity, command-injection behavior, appliance instability, appliance-level command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, outbound communication, administrative-control activity, downstream application behavior, remediation evidence, and approved traffic-management 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, API errors, 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 Progress Kemp LoadMaster appliances, comparable 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 WAF, reverse-proxy, CDN, load-balancer, gateway, management/API, or appliance logs may prevent reliable assessment of suspicious request activity, source context, forwarded source, URI path, query string, request method, status code, response size, request size, content type, API method, failed-to-success behavior, and response instability.

·        Missing request-body or query-string preservation may prevent detection of command-delimiter patterns, shell-control content, quote manipulation, encoded command content, malformed JSON, oversized API fields, heap-shaping patterns, authentication-bypass behavior, or API-parameter manipulation.

·        Missing appliance system, shell, diagnostic, process, 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, crash behavior, watchdog events, 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, 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, paste-site access, 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 mirroring, TLS termination changes, service-account use, internal API access, database access, storage access, backup access, or application-administration activity.

·        Missing change-control, maintenance, vendor-support, patch-validation, monitoring, backup, certificate-rotation, failover, 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 management/API access, 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, WAF records, appliance logs, configuration changes, certificate records, network events, downstream application telemetry, change-management records, and remediation evidence.

·        Incomplete appliance, management-interface, source, forwarded-source, API path, 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, appliance banner, command-injection string, API error, or appliance instability event is not proof of compromise by itself.

·        Suspicious ADC management/API activity should not be treated as successful exploitation without appliance instability, command execution evidence, configuration access, certificate access, administrative-control activity, outbound communication, traffic-path manipulation, downstream application impact, or active exploitation intelligence.

·        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, API, 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 control-plane compromise without appliance-layer, configuration-layer, traffic-path, or downstream-application correlation.

·        Legitimate ADC administration, firmware updates, vendor support, 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 alerting should require validated multi-signal correlation across ADC request behavior, appliance instability, command execution, configuration access, certificate access, administrative activity, outbound communication, traffic-path behavior, downstream application review, remediation evidence, and approved workflow context where applicable.

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 asset exposure, management/API reachability, request sequence, appliance instability, command execution, configuration access, certificate exposure, administrative-control behavior, outbound communication, traffic-path manipulation, downstream application impact, remediation status, and approved traffic-management workflow evidence within locally validated correlation windows.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making ADC asset exposure, management/API isolation, command-execution risk, configuration state, certificate handling, virtual-service routing, backend-pool mapping, administrative control, outbound communication, downstream application behavior, and post-remediation activity measurable, governed, and resilient under active edge control-plane exploitation pressure. The objective is not only to patch one LoadMaster version, block one scanner, or suppress one API path, but to prove that ADC activity can be scoped, correlated, contained, and separated from legitimate traffic-management operations when application-delivery trust exposure is suspected.

ADC Asset, Exposure, and Management-Plane Governance

·        Maintain a complete inventory of Progress Kemp LoadMaster appliances, comparable 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, virtual services, backend pools, business owners, application owners, certificate owners, and administrator owners.

·        Maintain a complete inventory of exposed management/API, administrative, diagnostic, authentication, telemetry, configuration, support, and control-plane 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, high-availability applications, and multiple downstream services.

·        Require auditable change-control for ADC patching, firmware updates, management/API isolation, access-control changes, virtual-service changes, backend-pool changes, routing 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 affected version state, unknown certificate ownership, or unknown downstream application mapping as enterprise application-delivery trust risk until exposure is 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 instability, command execution, configuration access, certificate access, administrative activity, rare egress, or downstream anomalies.

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, 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, routing rules, rewrite rules, header rules, persistence profiles, health checks, certificate bindings, logging settings, and security-control policies.

·        Require approval and documentation for virtual-service changes, backend-pool changes, route changes, header changes, rewrite 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 management/API activity.

·        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.

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, approved workflows, approved systems, and approved maintenance windows.

·        Require certificate and credential review or rotation when suspicious ADC 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 behavior.

·        Treat certificate exposure, private-key exposure, API token exposure, or administrative credential exposure as scope-expansion conditions affecting downstream applications and trust paths.

Network, Source, Egress, and Downstream Application Hardening

·        Enrich WAF, firewall, proxy, DNS, NDR, reverse-proxy, CDN, load-balancer, appliance, endpoint-adjacent, and downstream application telemetry with ADC asset identity, management interface, virtual service, backend pool, source reputation, ASN, geography, network type, request path, 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, and low-and-slow probing against ADC management/API surfaces.

·        Monitor outbound traffic from ADC appliances for rare destinations, raw-IP communication, paste-site access, 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 mirroring, TLS termination changes, unusual service-account use, internal API access, database access, storage access, backup access, application-administration activity, 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, exploit-attempt behavior, appliance instability, command execution, configuration access, certificate access, virtual-service manipulation, backend-pool changes, outbound communication, administrative-control changes, downstream application anomalies, and post-remediation activity.

·        Require responders to validate affected appliance, affected version, management/API exposure, affected API path, suspicious source, request behavior, appliance instability, command execution, configuration state, virtual-service state, backend-pool mapping, certificate exposure, credential exposure, administrative state, outbound communication, downstream application impact, business owner, data sensitivity, and remediation status.

·        Prepare decision paths for emergency patching, management-plane isolation, API restriction, 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, not a routine scanner alert, isolated API error, single vulnerable-version finding, or patch-management task.

·        Require post-event validation to distinguish approved ADC administration, firmware updates, certificate rotation, health-check changes, 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

Progress Kemp LoadMaster and edge ADC compromise defensive architecture showing ADC asset governance, management/API isolation, appliance execution visibility, configuration and virtual-service integrity, certificate and credential protection, outbound and downstream application monitoring, SOC triage, and executive application-delivery trust restoration.

The defensive architecture should treat edge ADCs, load balancers, reverse proxies, and WAF-adjacent appliances 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, access governance, appliance telemetry, configuration integrity, virtual-service governance, certificate protection, outbound monitoring, downstream application review, incident-response containment, and executive trust decisioning into one ADC control-plane-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 appliances are internet-facing or partner-reachable, which management/API surfaces are reachable, 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 state, exposure state, management interface, API endpoint, 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 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 — Appliance Execution and Stability Monitoring

Appliance execution and stability monitoring determines whether suspicious control-plane access resulted in command execution, diagnostic-function abuse, service instability, or runtime activity. This layer captures appliance syslog, management-service faults, API handler errors, authentication-handler failures, diagnostic utility execution, shell activity, script execution, transfer-tool activity, archive activity, package behavior, watchdog events, service restarts, failover events, resource-exhaustion events, and endpoint telemetry where available.

Architecture Layer Four — Configuration and Traffic-Path Integrity

Configuration and traffic-path integrity determines whether suspicious activity altered application delivery. This layer captures virtual services, listener ports, real-server pools, backend pools, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, 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.

Architecture Layer Five — Certificate, TLS, and Credential Protection

Certificate, TLS, and credential protection determines whether exploitation 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 Six — Network Egress and Internal Service Monitoring

Network egress and internal service monitoring determines whether the ADC appliance 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, paste-site access, tunneling, repeated callbacks, tool retrieval, internal management-service access, destination reputation, first-seen destination context, and approved ADC egress baselines.

Architecture Layer Seven — Downstream Application and Backend Trust Review

Downstream application and backend trust review determines whether ADC compromise affected applications behind the traffic-management 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, availability impact, virtual-service mapping, backend-pool mapping, and application-owner validation.

Architecture Layer Eight — SOC Correlation and False-Positive Control

SOC correlation joins ADC asset context, management/API exposure, request telemetry, appliance telemetry, configuration state, certificate access, administrative context, outbound communication, downstream application behavior, change-control records, vendor-support records, patch-validation activity, monitoring activity, red-team activity, maintenance windows, and business workflow baselines. This layer validates whether activity is attacker-driven, scanner-driven, administrator-driven, vendor-support-driven, monitoring-related, maintenance-related, validation-related, red-team-related, emergency-change-related, or incident-response-related.

Architecture Layer Nine — 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, affected management/API paths, affected configuration objects, affected certificates, affected credentials, affected virtual services, affected backend pools, affected downstream applications, containment actions, patch validation, management-plane isolation, 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 control-plane exploitation and edge application-delivery trust incident:

·        Which ADC appliance, management interface, API path, 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, monitoring systems, certificate-management workflows, backup jobs, failover testing, maintenance windows, emergency changes, red-team activity, or incident-response activity?

·        Did suspicious ADC management/API activity transition into appliance instability, command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, backend-pool changes, outbound communication, administrative-control compromise, downstream application exposure, or post-remediation activity?

·        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, high-availability services, or multiple downstream applications?

·        Can the organization patch or isolate affected appliances, restrict management/API access, validate configuration integrity, review virtual services, validate backend pools, inspect certificate exposure, rotate credentials, preserve evidence, and restore application-delivery availability without over-attributing unrelated ADC administration or vendor support activity to exploitation?

·        Can the organization prove that ADC request activity, appliance behavior, configuration changes, certificate activity, outbound communication, administrative actions, and downstream application behavior were approved operational activity rather than suspicious follow-on behavior?

·        Can leadership make defensible decisions about 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 Progress Kemp LoadMaster appliances, comparable ADCs, load balancers, reverse proxies, WAF-adjacent appliances, virtual appliances, cloud-hosted ADC workloads, managed ADC services, high-availability pairs, management interfaces, API endpoints, virtual services, backend pools, certificates, administrator owners, application owners, business owners, patch state, exposure state, and downstream application dependencies.

·        Enforce timely ADC patching, emergency vendor remediation, management/API isolation, unnecessary API disablement, source restrictions for administration, 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.

·        Harden virtual-service changes, backend-pool changes, routing rules, rewrite rules, header rules, persistence profiles, 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, 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, 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 Progress Kemp LoadMaster API behavior, including /accessv2 where API exposure is locally observable.

·        Monitor command-delimiter patterns, shell-control content, quote manipulation, encoded command content, malformed JSON, oversized API fields, heap-shaping patterns, authentication-bypass patterns, unusual API parameters, abnormal methods, failed-to-success sequences, abnormal status-code patterns, response-size deviations, API-handler errors, authentication-handler errors, management-service faults, connection resets, watchdog events, and service restarts.

·        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 management/API access.

·        Monitor configuration exports, backup files, diagnostic bundles, packet captures, virtual-service objects, backend pools, routing rules, rewrite rules, header rules, persistence profiles, 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 new, modified, deleted, exported, or replaced virtual services, listener ports, backend pools, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, health checks, certificate bindings, logging settings, management restrictions, and security-control policies.

·        Monitor DNS, proxy, firewall, EDR network, NDR, and flow telemetry for rare destinations, raw-IP communication, file-transfer behavior, paste-site access, tunneling, 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 mirroring, TLS termination changes, service-account use, internal API access, database access, storage access, backup access, application-administration activity, and availability degradation.

·        Require multi-signal ADC request-to-appliance, request-to-configuration, request-to-certificate, request-to-egress, or request-to-downstream correlation before high-confidence alerting or compromise determination.

Responsive Controls

·        Patch affected ADC versions, apply vendor remediation, isolate management/API surfaces, disable unnecessary APIs, restrict partner-reachable control-plane paths, and validate affected appliance state.

·        Preserve ADC management/API logs, WAF records, reverse-proxy logs, CDN logs, load-balancer records, appliance syslog, 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, backend pools, listener ports, routing rules, rewrite rules, header rules, persistence profiles, 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.

·        Rotate administrative credentials, API keys, certificate material, private keys, backend credentials, service credentials, monitoring credentials, vendor support credentials, deployment secrets, and reused credentials when compromise cannot be ruled out.

·        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.

·        Review downstream applications for backend access, authentication-flow disruption, session-routing changes, header manipulation, traffic mirroring, TLS termination changes, service-account use, internal API access, database access, storage access, backup access, application-administration activity, 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 ADC request activity, appliance state, configuration integrity, certificate exposure, credential exposure, outbound communication, downstream application behavior, and post-remediation monitoring support closure before the incident is considered contained.

Governance Controls

·        Maintain approved inventories for ADC appliances, management interfaces, API endpoints, 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, vendor support, certificate rotation, 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, 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 escalation criteria for suspicious management/API access, appliance instability, command execution, configuration access, certificate access, private-key exposure, virtual-service manipulation, backend-pool changes, outbound communication, administrative-control changes, downstream application anomalies, post-remediation activity, and unresolved exposure.

·        Track ADC control-plane exploitation and application-delivery trust risk in the risk register when telemetry, patching, management/API isolation, certificate protection, configuration visibility, outbound monitoring, downstream application mapping, or response gaps create unresolved enterprise risk.

Control Mapping Summary

The strongest control posture combines prevention of unnecessary ADC management exposure, detection of suspicious control-plane request-to-appliance or request-to-impact behavior, and response workflows that restore application-delivery trust, certificate confidence, routing integrity, administrative control, 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, high-availability services, and multiple downstream applications.

S36 — CyberDax Intelligence Maturity Assessment

Current Intelligence Maturity

Moderate

Maturity Rationale

Progress Kemp LoadMaster pre-authentication RCE and edge ADC compromise is a well-defined behavior class, but organization-specific maturity depends on whether suspicious management/API activity, command-injection behavior, appliance instability, command execution, configuration access, certificate exposure, virtual-service manipulation, outbound communication, administrative-control activity, downstream application behavior, post-remediation activity, and approved ADC administration or vendor-support workflows can be correlated. Many environments can identify exposed ADCs, vulnerable versions, internet scanning, or suspicious API requests, but fewer can prove whether suspicious ADC activity resulted in command execution, certificate exposure, configuration manipulation, routing impact, downstream application exposure, or containment failure.

Strengths

·        The behavior pattern is durable because it focuses on ADC control-plane-to-impact tradecraft rather than one scanner fingerprint, actor name, source IP, request path, user agent, endpoint label, payload, response code, vulnerable-version finding, proof-of-concept reference, KEV status, or static IOC.

·        The core sequence is analytically clear: edge ADC discovery, management/API exploitation, appliance-level command execution, configuration and certificate access, traffic-path manipulation, outbound communication, downstream application exposure, and post-remediation trust validation.

·        Detection opportunities are strong where ADC asset inventory, management/API exposure mapping, URI-preserving management telemetry, WAF logs, reverse-proxy logs, CDN logs, load-balancer logs, appliance syslog, 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, patch validation, appliance execution visibility, configuration integrity, certificate protection, outbound monitoring, downstream application review, SOC triage, and incident-response containment.

·        Blocks 2, 3, 4, and 5 remain aligned while preserving a behavior-led model and avoiding actor-only, scanner-only, IOC-only, payload-only, exploit-string-only, product-only, or single-CVE-only overreach.

Maturity Gaps

·        ADC asset inventory may not reliably identify Progress Kemp LoadMaster appliances, comparable 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.

·        WAF, reverse-proxy, CDN, load-balancer, gateway, management/API, and appliance telemetry may not preserve enough URI path, query string, method, status, response size, request size, source IP, forwarded source IP, user agent, content type, API method, endpoint family, response instability, or timestamp detail for complete reconstruction.

·        Appliance system, process, diagnostic, shell, runtime, and endpoint telemetry may not preserve sufficient command execution, process lineage, command line, service context, diagnostic activity, transfer-tool use, archive activity, package activity, or rare egress behavior.

·        Configuration-change telemetry may not preserve sufficient virtual-service, backend-pool, route, rewrite, header, persistence-profile, 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, backend-pool, route, header, session, authentication-flow, and business-owner context.

·        Help desk, incident-response, SOAR, vulnerability-management, vendor-support, change-control, and remediation records may not consistently document patch validation, management/API isolation, certificate review, credential rotation, configuration restoration, downstream application review, or post-remediation validation.

·        Business workflow baselines for ADC administrators, vendor support, partner access, automation, monitoring, 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, appliance errors, or KEV status rather than validating the full ADC request-to-impact sequence.

Maturity Improvement Priorities

·        Normalize ADC asset inventory, public exposure mapping, management/API exposure mapping, affected version state, virtual-service mapping, backend-pool mapping, certificate inventory, management-interface mapping, 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 capture where available, source-IP preservation, forwarded-source preservation, response metadata, API method capture, endpoint-family mapping, and timestamp normalization.

·        Improve appliance system telemetry, diagnostic telemetry, shell telemetry, runtime telemetry where available, command-execution visibility, service-context mapping, appliance health event capture, watchdog event capture, restart event capture, failover event capture, and virtual appliance endpoint tagging.

·        Improve configuration telemetry, known-good baseline management, backup comparison, virtual-service integrity monitoring, backend-pool integrity monitoring, routing-rule monitoring, rewrite-rule monitoring, header-rule 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, and application-administration correlation.

·        Improve remediation evidence capture for ADC patch validation, management/API isolation, configuration review, virtual-service review, backend-pool validation, certificate review, credential rotation, administrative account review, 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, health-check tuning, failover testing, configuration migration, vulnerability validation, red-team activity, emergency remediation, incident-response cleanup, and approved outbound destinations.

·        Add ADC control-plane 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 quickly if the organization prioritizes ADC asset inventory completeness, management/API exposure mapping, access restriction, URI and query-string retention, appliance telemetry coverage, configuration baselines, certificate inventory, certificate-access visibility, virtual-service mapping, backend-pool mapping, outbound monitoring, downstream application correlation, vendor-support baselining, change-control completeness, and SOC workflows that connect ADC request behavior to appliance, configuration, certificate, administrative, outbound, and downstream application evidence. The highest-value improvements are ADC ownership, management-plane isolation, configuration integrity, certificate protection, virtual-service governance, backend-pool mapping, administrator-state validation, credential rotation readiness, downstream application visibility, and post-remediation containment correlation.

S37 — Strategic Defensive Improvements

Strategic improvement should reduce the likelihood that attackers can use exposed ADC management/API functionality, weak control-plane isolation, command execution, configuration access, certificate exposure, routing control, administrative access, outbound communication, or downstream trust relationships to create certificate, credential, traffic-path, application-delivery, containment, or business-continuity uncertainty without detection. The objective is measurable ADC control-plane-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, affected version state, public and partner reachability, management-plane isolation, URI and query-string retention, appliance telemetry coverage, configuration baseline coverage, virtual-service mapping, backend-pool mapping, certificate inventory, certificate-access visibility, outbound monitoring, downstream application mapping, 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, high-availability services, and multiple downstream applications.

·        Report unresolved ADC exposure, unknown API reachability, weak management-plane isolation, incomplete request logging, weak appliance 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 management/API activity, appliance instability, command execution, configuration access, certificate exposure, virtual-service manipulation, backend-pool changes, outbound communication, 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 Control-Plane Governance

·        Maintain live inventory of Progress Kemp LoadMaster appliances, comparable ADCs, load balancers, reverse proxies, WAF-adjacent appliances, virtual appliances, cloud-hosted ADC workloads, managed ADC services, high-availability pairs, public exposure state, partner exposure state, management interfaces, API endpoints, virtual services, backend pools, certificate inventory, administrator owners, business owners, application owners, and downstream application sensitivity.

·        Enforce emergency vendor remediation, ADC patch validation, management/API isolation, unnecessary API disablement, source restrictions for administration, 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, and management-access restrictions.

·        Validate that ADC administration can distinguish approved firmware updates, patch validation, vendor support, health-check tuning, certificate rotation, backup activity, failover testing, monitoring activity, red-team activity, emergency maintenance, and incident response from attacker-relevant access.

·        Reduce broad or informal exceptions that allow high-value ADCs or sensitive application-delivery infrastructure to remain exposed to unnecessary public access, weak API controls, incomplete logging, unclear certificate ownership, or unresolved management-plane risk.

Priority Three — Improve ADC Request, Appliance, Configuration, and Certificate Visibility

·        Centralize ADC management/API logs, WAF logs, reverse-proxy logs, CDN logs, load-balancer records, appliance syslog, 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 ADC management/API activity to appliance instability, command execution, diagnostic abuse, configuration access, virtual-service change, backend-pool change, certificate access, private-key exposure, outbound communication, administrative-control change, downstream application impact, and post-remediation access.

·        Prioritize detection for suspicious ADC management/API activity followed by appliance instability, command execution, configuration access, certificate or private-key access, virtual-service manipulation, backend-pool modification, routing changes, administrative changes, rare egress, downstream application anomalies, or continued access after remediation.

·        Validate timestamp normalization, field mapping, schema mapping, lookup accuracy, enrichment quality, exception logic, asset tagging, management-interface 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, downstream application anomalies, or post-remediation activity.

Priority Four — Strengthen Certificate, Credential, Routing, 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, health checks, WAF-adjacent policies, proxy policies, logging settings, administrative settings, management-interface restrictions, and access-control lists.

·        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, availability degradation, and application-owner validation.

·        Define rapid response paths for certificate review, private-key rotation, credential rotation, configuration restoration, virtual-service review, backend-pool validation, routing rollback, administrative account review, API key review, 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, 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, endpoint-adjacent, downstream application, and change-management telemetry with ADC asset identity, management interface, virtual service, backend pool, source reputation, ASN, geography, network type, request path, response metadata, destination context, certificate context, application owner, business owner, and approved workflow status.

·        Monitor suspicious source activity and egress after abnormal ADC management/API requests, appliance instability, command execution, configuration access, certificate access, virtual-service changes, administrative-control activity, downstream anomalies, or post-remediation activity.

·        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 ADC request, appliance, configuration, certificate, administrative, downstream, remediation, or workflow correlation.

·        Treat continued management/API access, rare egress, configuration drift, certificate access, administrative changes, outbound communication, downstream anomalies, or suspicious appliance behavior after remediation as containment-validation failure until proven otherwise.

Priority Six — Strengthen SOC, Network, Application, Legal, and Executive Response

·        Create or update playbooks for suspicious ADC management/API activity, exploit-attempt behavior, appliance instability, command execution, configuration access, certificate exposure, private-key access, virtual-service manipulation, backend-pool changes, routing changes, outbound communication, administrative-control compromise, downstream application anomalies, and post-remediation activity.

·        Require responders to validate affected appliance, affected version, management interface, API endpoint, source IP, ASN, geography, request path, query string, response behavior, appliance state, command execution evidence, configuration state, certificate exposure, credential exposure, virtual-service state, backend-pool mapping, outbound communication, downstream application behavior, business owner, data sensitivity, and remediation status.

·        Require rapid decision paths for emergency patching, management-plane isolation, API restriction, configuration restoration, routing rollback, certificate rotation, credential rotation, administrative review, 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, or high-availability functions.

·        Require post-event review to determine whether the organization can prove that ADC activity was approved operational activity rather than suspicious follow-on behavior.

Strategic Outcome

The organization should be able to prove whether suspicious ADC activity affected command execution, certificate exposure, credential access, configuration integrity, virtual-service routing, backend-pool state, administrative control, outbound communication, 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, API route, 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, certificate confidence, routing integrity, administrative control, downstream application assurance, and business continuity before edge ADC compromise becomes broad operational disruption.

S38 — Attack Economics & Organizational Impact Model

Figure 7

Progress Kemp LoadMaster and edge ADC compromise attack economics model showing how exposed application-delivery control planes can create command-execution uncertainty, certificate and credential exposure risk, traffic-path trust loss, downstream application impact, containment burden, and executive application-delivery trust restoration.

Progress Kemp LoadMaster pre-authentication RCE and edge ADC compromise 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, backend routing, WAF-adjacent enforcement, and business-critical application delivery. When suspicious ADC management/API access, exploit-attempt behavior, appliance instability, command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, outbound communication, administrative-control changes, downstream application anomalies, or post-remediation activity aligns inside one investigation window, the attacker can create disproportionate business uncertainty without compromising every endpoint, user account, application, or internal system individually.

The organization’s cost expands when responders must prove whether ADC management/API activity remained routine administration, whether exploit behavior allowed appliance-level command execution, 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 downstream applications were affected, and whether application-delivery services can safely remain online after remediation.

Adversary Economic Advantage

·        Edge ADC control-plane exploitation can reduce attacker friction because ADCs, load balancers, reverse proxies, and WAF-adjacent appliances often expose management, API, diagnostic, authentication, telemetry, or configuration surfaces 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 prior internal foothold.

·        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.

·        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, firmware updates, vendor support, 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, or high-availability services can create disproportionate business impact if command execution, certificate exposure, routing manipulation, or downstream application impact cannot be ruled out.

·        The attacker benefits when defenders cannot quickly determine whether ADC request activity, appliance behavior, configuration changes, certificate access, outbound communication, administrative activity, downstream anomalies, or post-remediation access were legitimate operational activity or adversary-driven exploitation.

·        Downstream impact can extend into emergency patching, management-plane isolation, configuration restoration, virtual-service review, backend-pool validation, certificate rotation, credential rotation, 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, WAF, reverse-proxy, CDN, load-balancer, appliance, 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, affected version state, suspicious request sequences, command-injection behavior, appliance instability, command execution evidence, configuration access, certificate access, virtual-service changes, backend-pool changes, outbound communication, administrative-control activity, downstream application behavior, and post-remediation activity.

·        Mitigation may require emergency vendor remediation, ADC patching, management/API isolation, API disablement, configuration restoration, virtual-service review, backend-pool validation, routing rollback, certificate review, certificate rotation, credential rotation, administrative account review, 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, 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, request logging, appliance telemetry, configuration-change records, certificate-management records, virtual-service mapping, backend-pool mapping, outbound telemetry, downstream application logs, change-control records, or credential rotation evidence are incomplete.

·        Business impact increases when defenders must prove whether command execution occurred, whether certificates or private keys were exposed, whether configuration changed, whether traffic routing was manipulated, whether administrative control changed, whether downstream applications were affected, 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, 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 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.

Command Execution and Appliance Runtime Impact

The organization must determine whether suspicious control-plane activity remained exploit-attempt behavior, whether appliance instability occurred, whether command execution happened, whether shell or script activity occurred, whether diagnostic utilities were abused, whether transfer tools or package activity appeared, whether service-context execution occurred, and whether the activity represented actual appliance compromise rather than failed probing or benign maintenance.

Configuration and Traffic-Path Impact

The organization must determine whether virtual services, listener ports, backend pools, real-server pools, routing rules, content-switching rules, rewrite rules, header rules, persistence profiles, 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 suspicious ADC activity.

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 ADC activity.

Outbound Communication and Internal Service Impact

The organization must determine whether the ADC appliance, virtual appliance host, management host, or ADC-supporting workload initiated rare outbound communication, DNS anomalies, HTTP or HTTPS callbacks, SSH, SMTP, file-transfer behavior, raw-IP communication, paste-site access, 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, traffic mirroring, service-account use, internal API access, database access, storage access, backup access, or application-administration activity were affected after suspicious ADC control-plane behavior.

Containment and Application-Delivery Trust Restoration Impact

The organization must restore application-delivery trust, certificate confidence, routing integrity, administrative control, downstream application assurance, and business continuity through ADC patch validation, management/API isolation, API restriction, configuration review, virtual-service review, backend-pool validation, certificate review, certificate rotation, credential rotation, administrative account review, outbound review, 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 control-plane 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, high-availability services, multiple downstream applications, shared certificate workflows, and business-critical service continuity.

Economic Impact Summary

Progress Kemp LoadMaster pre-authentication RCE and edge ADC compromise is economically powerful for adversaries because it can convert exposed control-plane trust into command execution, configuration exposure, certificate risk, traffic-path manipulation, downstream application exposure, and containment uncertainty. The organization’s financial exposure grows when it cannot quickly prove whether ADC activity remained contained, whether commands executed, whether certificates or credentials were exposed, whether configuration or routing changed, whether administrative control was weakened, whether outbound communication occurred, whether downstream applications were affected, and whether application-delivery services can safely continue.

S39 Economic Impact & Organizational Exposure

Progress Kemp LoadMaster pre-authentication RCE and edge ADC compromise expands the organizational exposure model by increasing uncertainty around whether exposed application-delivery control planes were used for unauthenticated or weakly authenticated management/API exploitation, command-injection behavior, appliance-level command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, backend-pool modification, routing or header-control changes, administrative-control compromise, outbound communication, downstream application exposure, persistence-like appliance changes, or post-remediation access. The exposure aligns with the report’s established behavior model because the core business risk is not limited to one Progress advisory, one appliance version, one API path, one proof-of-concept, or one scanner pattern; it is whether trusted edge application-delivery infrastructure can be converted into a command-execution point, certificate exposure point, routing-control layer, 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 control-plane endpoints, command-shaped requests, appliance instability, configuration objects, backup archives, diagnostic bundles, packet captures, virtual services, backend pools, listener ports, routing rules, rewrite rules, header rules, persistence profiles, health checks, TLS certificates, private keys, key stores, API tokens, administrative credentials, support accounts, logging settings, outbound communication, internal service access, downstream applications, authentication-fronting services, customer portals, partner workflows, regulated applications, public web applications, file-transfer paths, support services, or high-availability application delivery. Exposure is highest when suspicious request activity cannot be separated from appliance command execution, configuration access, certificate exposure, traffic-path manipulation, rare egress, administrative-control changes, downstream application anomalies, or activity that continues after remediation.

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, exposed-version findings, isolated suspicious management/API requests, WAF-adjacent bypass behavior, reverse-proxy configuration probes, ingress-controller configuration injection, or patch validation; becomes suspected or confirmed ADC control-plane exploitation; or expands into appliance-level command execution, configuration access, certificate or private-key exposure, routing manipulation, administrative-control compromise, outbound communication, downstream application exposure, multi-appliance impact, or loss of confidence in application-delivery trust.

Economic exposure increases when the organization cannot quickly prove whether ADC management/API activity remained limited to attempted exploitation, whether command-injection 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 downstream applications were affected, and whether management/API logs, WAF records, reverse-proxy records, CDN records, load-balancer records, appliance syslog, 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 remediation evidence can be joined into a reliable sequence.

Low Impact Scenario

Estimated $450K - $3.5M

This scenario applies when suspicious ADC management/API probing, exposed-version findings, scanner activity, malformed requests, public PoC-like requests, denied API attempts, abnormal status-code behavior, WAF-adjacent bypass testing, reverse-proxy configuration probes, or isolated appliance errors are detected quickly, but available telemetry confirms no appliance-level command execution, no configuration access, no certificate or private-key access, no API token or credential exposure, no virtual-service manipulation, no backend-pool changes, no routing or header manipulation, no administrative-control changes, no rare egress, no logging degradation, no downstream application anomalies, and no post-remediation activity. Response remains limited to targeted patch validation, management-plane isolation, evidence preservation, focused configuration review, 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, or traffic-management control-plane exploitation affects one or more exposed, partner-reachable, production, high-availability, or authentication-fronting systems, but available evidence does not confirm broad downstream application compromise, large-scale data theft, multi-appliance compromise, or customer-facing service disruption. The organization cannot immediately determine whether suspicious requests led to command execution, configuration export, certificate or private-key access, API-token exposure, administrative-control change, virtual-service manipulation, backend-pool modification, reverse-proxy or ingress configuration injection, outbound communication, downstream application access, or persistence-like appliance changes. Response may require management/API and WAF record reconstruction, appliance-state inspection, configuration comparison, certificate and credential review, administrator and API-key validation, outbound traffic analysis, downstream application review, change-management reconciliation, vendor escalation, legal and compliance review, cyber-insurance coordination, executive reporting, and strengthened monitoring for post-remediation activity.

High Impact Scenario

Estimated $30M - $140M+

This scenario applies when edge ADC compromise 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 mirroring, downstream application exposure, customer-facing availability impact, administrative-control compromise, persistence-like appliance changes, reverse-proxy or ingress-controller compromise, or multi-appliance compromise. 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, cloud or Kubernetes secrets, and downstream application trust were affected until audit evidence proves otherwise. Response may require extended appliance forensics, emergency management-plane isolation, broad credential and certificate rotation, configuration restoration, application-delivery redesign, 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, TLS termination, authentication-fronting services, customer-facing or partner-facing workflows, regulated downstream applications, incomplete request logging, weak configuration baselines, limited appliance telemetry, incomplete certificate-access logging, unclear virtual-service ownership, weak outbound monitoring, incomplete administrative activity baselines, WAF-adjacent bypass exposure, reverse-proxy or ingress-controller configuration risk, or poor downstream application mapping.

Exposure may exceed $30M - $140M+ where ADC compromise results in confirmed or suspected command execution, certificate or private-key exposure, credential access, configuration export, virtual-service manipulation, authentication-flow disruption, traffic mirroring, downstream application exposure, cloud or Kubernetes secret exposure, customer-facing outage, multi-appliance compromise, incomplete containment, cyber-insurance review, legal escalation, communications response, or board-level reporting.

Management-Platform Dependency

Management-platform dependency is high where ADC administration, management/API access, diagnostic functions, configuration exports, virtual-service management, backend-pool management, certificate management, API automation, backup workflows, health-check tuning, failover testing, vendor support, monitoring integrations, ingress-controller administration, gateway-fabric configuration, WAF policy management, and privileged access workflows are used to manage application-delivery infrastructure. Dependency increases when affected appliances support customer portals, authentication-fronting services, partner workflows, TLS termination, regulated applications, payment-adjacent processes, public web applications, support services, file-transfer paths, high-availability services, shared certificates, shared backend pools, cloud ingress paths, or multiple downstream applications that cannot be easily 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, ingress annotations, gateway-fabric configuration, 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, appliance instability, command execution, configuration access, certificate access, virtual-service changes, backend-pool changes, reverse-proxy configuration injection, ingress-controller configuration injection, outbound communication, administrative changes, logging degradation, downstream anomalies, or telemetry gaps cannot be tied to approved maintenance, approved ADC administration, approved vendor support, approved patch validation, approved monitoring, approved health-check tuning, approved certificate rotation, approved backup activity, approved failover testing, approved red-team activity, or validated incident-response activity.

Visibility Confidence

Visibility confidence is highest when ADC management/API logs, WAF records, reverse-proxy records, CDN records, load-balancer records, appliance syslog, administrative audit logs, configuration-change records, certificate-management records, ingress-controller records, gateway-fabric configuration records, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, downstream application logs, asset 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, API parameters, source context, forwarded source IPs, response sizes, API methods, or management-interface mapping; when appliance operating-system telemetry is unavailable; when configuration changes require manual export comparison; when certificate and private-key access lacks object-level detail; when reverse-proxy or ingress-controller configuration changes are not centrally audited; when outbound telemetry cannot distinguish approved ADC behavior from suspicious communication; when downstream application logs cannot map activity to virtual services or backend pools; or when timestamps and change records are insufficient to reconstruct the control-plane-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-controller configuration objects, gateway-fabric configuration objects, and management-access restrictions can be validated against approved baselines.

Confidence is reduced when suspicious 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, changes backend pools, modifies routing behavior, modifies ingress or gateway configuration, weakens logging, initiates outbound communication, touches downstream applications, 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.

Connector and Credential Dependency

Connector and credential dependency is high when ADC appliances, load balancers, reverse proxies, WAF-adjacent appliances, ingress controllers, or gateway-fabric 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, Kubernetes secrets, 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 even limited ADC compromise because responders may need to prove that configuration files, credential material, certificate stores, API tokens, backend connections, administrative workflows, cloud secrets, 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, Kubernetes secrets, or credential-bearing appliance files may have been accessed after suspicious management/API behavior, command execution, configuration access, outbound communication, or administrative-control changes.

Downstream Device Dependency

Downstream device 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 traffic-management layer. These dependencies increase scope because attackers may use exposed configuration, certificate material, credentials, routing control, header manipulation, backend visibility, ingress-controller privileges, or trust relationships to affect adjacent services or downstream applications.

Downstream dependency should be interpreted conservatively because ADC control-plane exploitation does not automatically prove lateral movement, cloud compromise, identity compromise, database compromise, or data theft. It becomes materially relevant when telemetry shows credential access, certificate exposure, backend access, internal service access, downstream authentication anomalies, service-account use, traffic-path manipulation, outbound communication, Kubernetes secret access, or suspicious use of credentials connected to the affected appliance or traffic-management component.

Customer, Workforce, and Regulatory Exposure

Customer, workforce, and regulatory exposure increases when suspicious ADC control-plane activity, command execution, configuration access, certificate exposure, private-key exposure, credential access, traffic-path manipulation, authentication-flow disruption, outbound communication, downstream application anomalies, customer-facing availability impact, partner workflow exposure, regulated application concern, cloud secret exposure, or incomplete containment 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, or externally trusted application-delivery paths.

Exposure also increases when telemetry gaps prevent timely confirmation of whether customer traffic, partner access, regulated data, authentication flows, TLS termination, certificate material, backend routing, API keys, administrative actions, ingress configuration, cloud secrets, outbound communication, downstream applications, customer reports, partner reports, or post-remediation activity were impacted.

Residual Economic Risk

Residual economic risk remains after vendor remediation, ADC patching, management/API isolation, configuration restoration, certificate review, credential rotation, administrative review, egress blocking, downstream application validation, ingress-controller remediation, gateway-fabric remediation, vendor escalation, WAF tuning, or incident-response cleanup when the pre-remediation activity window cannot be reconstructed. Updating affected appliances or components 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, cloud secret exposure, downstream application exposure, or persistence-like appliance changes did not occur.

Residual risk should remain elevated until historical management/API logs, WAF records, reverse-proxy records, CDN records, load-balancer records, appliance syslog, administrative audit logs, configuration-change records, certificate-management records, ingress-controller records, gateway-fabric 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

This report’s behavioral detection model directly covers Progress Kemp LoadMaster CVE-2026-8037 where observable activity aligns with the primary edge ADC compromise chain: suspicious management/API access, command-injection behavior, appliance instability, appliance-level command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, backend-pool modification, outbound communication, administrative-control compromise, downstream application exposure, and containment validation.

The model directly covers Progress ADC and LoadMaster command-injection behavior represented by CVE-2026-33691, CVE-2026-3517, CVE-2026-3518, CVE-2026-3519, and CVE-2026-4048 because each maps to appliance command execution through management/API, UI, command endpoint, or WAF-adjacent control-plane behavior. Authentication and role requirements vary by CVE, but the observable defense model remains the same: suspicious control-plane access followed by command execution, sensitive object access, configuration change, rare egress, or downstream impact.

The model directly covers F5 BIG-IP and BIG-IQ control-plane command-execution behavior represented by CVE-2026-34176, CVE-2026-41225, and CVE-2026-42406 where observable activity involves authenticated iControl REST access, privileged configuration-object creation or modification, certificate-management role abuse, appliance-mode boundary crossing, arbitrary command execution, configuration-object abuse, or management-plane command execution. These are not Progress-specific, but they fall inside the report’s reusable ADC control-plane and configuration-object-to-command-execution model.

The model provides coverage with adaptation for ingress-nginx and NGINX Gateway Fabric configuration-injection behavior represented by CVE-2026-3288, CVE-2026-4342, and CVE-2026-50107. These issues are not traditional ADC appliance RCE events, but they map to the report’s reverse-proxy, gateway, traffic-management, configuration-injection, secret-exposure, downstream routing, and application-delivery trust model when local telemetry can join ingress or gateway configuration changes to execution, secret exposure, downstream traffic behavior, or containment impact.

The model provides coverage with adaptation for CVE-2026-21876 because WAF-adjacent multipart parsing and rule-bypass behavior can affect the application-delivery trust boundary and may support exploit attempt classification, WAF-control validation, and request-normalization review. This item should not be counted as direct command-execution coverage unless local telemetry shows follow-on command execution, configuration access, certificate exposure, routing manipulation, or downstream application impact.

The model provides coverage with adaptation for CVE-2026-10816 because NetScaler ADC/Gateway arbitrary file read through management-access exposure maps to the report’s management-plane exposure and sensitive object access model. This should not be counted as direct command-execution coverage unless local telemetry shows command execution, configuration manipulation, certificate exposure, routing manipulation, outbound communication, or downstream application impact.

Known exploitation reporting, public proof-of-concept availability, vendor patch availability, scanner coverage, NVD metadata, and KEV-style urgency should be treated as prioritization inputs, not compromise proof. Local compromise assessment must still be based on observable management/API request activity, appliance behavior, command execution evidence, configuration access, certificate access, outbound communication, administrative changes, downstream application behavior, and incident-response findings.

Detection Engineering Coverage Interpretation

The S25 detection content provides direct behavioral coverage when suspicious ADC management/API, control-plane, command-execution, configuration, certificate, virtual-service, backend-pool, routing, outbound, administrative, downstream application, or post-remediation activity falls inside the report’s edge ADC compromise model. Direct coverage applies because this report explicitly includes Progress Kemp LoadMaster CVE-2026-8037-like behavior, broader Progress ADC command-injection behavior, exposed ADC management/API access, /accessv2-style LoadMaster API behavior where locally visible, command-delimiter and shell-control request patterns, appliance instability, command execution, configuration access, certificate and private-key exposure, virtual-service manipulation, backend-pool changes, rare egress, multi-appliance probing, downstream application anomalies, and containment validation.

Detection coverage should be interpreted as behavior-led coverage, not CVE-string coverage. CVE identifiers, vendor names, endpoint names, route names, request fragments, source IPs, user agents, scanner labels, proof-of-concept names, payload strings, appliance banners, malware names, actor names, campaign labels, or exploit labels should not be used as primary detection inputs unless they are locally approved enrichment supporting triage. Detection confidence remains based on observable request behavior, appliance behavior, configuration behavior, certificate behavior, outbound communication, administrative context, downstream application context, and change-control context.

Exploit scripts, proof-of-concept tooling, scanner logic, API paths, source infrastructure, payload strings, user agents, endpoint labels, and public exploit writeups should be interpreted as behavior-led enrichment only. The report does not detect a named malware family directly. It detects the behavior that exploitation tooling, scanners, and ADC control-plane abuse may produce when they interact with exposed management/API functionality, trigger appliance instability, execute commands, access configuration material, touch certificate or credential objects, communicate externally, manipulate traffic paths, or affect downstream applications.

Actor, campaign, cybercrime, ransomware, initial-access, espionage, broker, or appliance-abuse coverage should be treated as enrichment and context only. The report does not detect actor names directly. It detects the behavior those actors, operators, affiliates, or toolchains may produce when abusing exposed ADC control planes, API paths, command endpoints, configuration functions, certificate stores, virtual-service routing, outbound communication, administrative controls, and downstream application trust.

Active exploitation attempts, public reporting, proof-of-concept availability, vendor priority, scanner coverage, and KEV status should be treated as urgency and remediation-prioritization signals, not as detection coverage by themselves. Local compromise assessment must still be based on observable request activity, appliance behavior, command execution evidence, configuration state, certificate access, outbound communication, administrative activity, downstream application behavior, and incident-response findings.

Direct Coverage

Direct coverage applies where observable activity aligns with the report’s ADC compromise chain: suspicious management/API access, command-injection behavior, appliance instability, command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, backend-pool changes, routing or header manipulation, outbound communication, administrative-control changes, downstream application exposure, or containment failure.

·        CVE-2026-8037

·        CVE-2026-33691

·        CVE-2026-3517

·        CVE-2026-3518

·        CVE-2026-3519

·        CVE-2026-4048

·        CVE-2026-34176

·        CVE-2026-41225

·        CVE-2026-42406

The CVEs listed above should be counted as direct coverage because they fall inside the report’s explicit ADC management/API command-injection, appliance-level command execution, configuration-object abuse, certificate-object abuse, WAF-adjacent command execution, outbound communication, traffic-path manipulation, and downstream application trust model. The S21 through S25 detection strategy is designed to catch these behaviors through correlated request, appliance, configuration, certificate, network, administrative, downstream application, and remediation evidence rather than through CVE strings alone.

Coverage With Adaptation

Coverage with adaptation applies to related ADC, load balancer, reverse proxy, WAF-adjacent, ingress-controller, gateway-fabric, management/API, diagnostic, configuration, certificate, administrative, virtual-service, routing, backend-pool, outbound, secret-exposure, or downstream application issues that are not direct ADC appliance command-injection matches but still produce behavior that can be mapped to the report’s detection model.

·        CVE-2026-3288

·        CVE-2026-4342

·        CVE-2026-50107

·        CVE-2026-21876

·        CVE-2026-10816

Coverage with adaptation requires local route mapping, management/API exposure mapping, affected version validation, control-plane path mapping, ingress or gateway configuration mapping, virtual-service mapping, backend-pool mapping, certificate-object mapping, approved administrator baselines, vendor-support baselines, query-string retention, request metadata preservation, configuration-change telemetry, and telemetry joins. These items should not be counted as direct command-execution coverage unless local telemetry shows suspicious control-plane access, command execution, configuration exposure, certificate exposure, routing manipulation, outbound communication, downstream application impact, secret exposure, or containment failure.

Weak / Optional Instability-Adjacent Coverage

Weak or optional instability-adjacent coverage applies only where ADC appliance instability, memory overflow, error behavior, restart behavior, availability degradation, or abnormal response sequencing is the dominant observable behavior and where the event does not otherwise produce command execution, configuration access, certificate exposure, credential access, routing manipulation, outbound communication, or downstream trust impact.

·        CVE-2026-8655

This item should not be counted in the main direct or adaptation register unless the final report intentionally includes an instability-adjacent coverage line. The current report is not a denial-of-service report, but S25 does include appliance instability and abnormal response sequencing as supporting evidence when tied to broader control-plane compromise behavior.

Non-Coverage Conditions

Non-coverage applies where related activity does not produce observable ADC management/API exploitation, command-injection behavior, appliance instability tied to exploit activity, appliance-level command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, backend-pool modification, routing or header manipulation, outbound communication, administrative-control changes, downstream application exposure, persistence-like appliance changes, or post-remediation activity.

Non-coverage applies when activity remains limited to vulnerable-version exposure, internet exposure, patch-state findings, scanner output, denied requests, isolated API errors, isolated appliance banners, generic command-injection strings with no ADC linkage, unrelated firewall or VPN management-plane activity, identity/session disclosure, downstream application-only anomalies, certificate-only anomalies, or maintenance activity without supporting suspicious source context or downstream behavior.

Non-coverage also applies when required management/API logs, WAF records, reverse-proxy records, CDN records, load-balancer records, appliance syslog, 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 evidence, or SIEM telemetry are unavailable or cannot be joined reliably enough to support a coverage determination.

Activity should not be counted when it is better explained by approved ADC administration, firmware updates, vendor support, patch validation, certificate rotation, virtual-service changes, backend-pool changes, routing changes, health-check tuning, backup activity, failover testing, monitoring, vulnerability validation, red-team activity, emergency remediation, security testing, vulnerability management, or incident response.

Current Coverage Count

Directly covered CVEs: 9

·        CVE-2026-8037

·        CVE-2026-33691

·        CVE-2026-3517

·        CVE-2026-3518

·        CVE-2026-3519

·        CVE-2026-4048

·        CVE-2026-34176

·        CVE-2026-41225

·        CVE-2026-42406

CVEs covered with adaptation: 5

·        CVE-2026-3288

·        CVE-2026-4342

·        CVE-2026-50107

·        CVE-2026-21876

·        CVE-2026-10816

Weak / optional instability-adjacent CVEs: 1

·        CVE-2026-8655

Known exploited / exploitation-attempt-represented vulnerabilities in this S39 review: at least 1

·        CVE-2026-8037

Public exploit / proof-of-concept items requiring final publication QA: at least 1

·        CVE-2026-8037

Named malware / tooling / exploit-framework coverage: behavior-led public exploit-tooling and ADC control-plane abuse coverage, not a named malware-family count.

Named actor / campaign coverage: no confirmed named actor or APT attribution should be claimed.

Total CVEs directly covered by this report’s behavioral detection model: 9

Total CVEs covered with adaptation by this report’s behavioral detection model: 5

Total CVEs represented in the corrected S39 coverage register: 14

Total CVEs represented if weak instability-adjacent coverage is included: 15

Coverage Qualification

Coverage is strong for behaviorally visible ADC control-plane exploitation where suspicious management/API request activity can be joined with appliance instability, command execution, configuration access, certificate or private-key exposure, virtual-service manipulation, backend-pool changes, outbound communication, administrative-control changes, downstream application anomalies, ingress or gateway configuration manipulation, or post-remediation activity.

Coverage is weaker for exposure-only vulnerable version state, isolated denied requests, isolated suspicious paths, isolated appliance errors, WAF bypass without impact evidence, reverse-proxy configuration anomalies without execution or secret exposure, ingress-controller findings without local configuration or secret-access telemetry, public PoC references without local telemetry, ordinary ADC administrator activity, approved vendor support, approved patch validation, approved certificate rotation, approved virtual-service changes, approved failover testing, approved security testing, or environments where request, appliance, configuration, certificate, outbound, administrative, downstream application, and change-management telemetry cannot be joined.

The report should not claim universal ADC detection, universal LoadMaster detection, universal BIG-IP detection, universal NGINX detection, universal Kubernetes ingress detection, universal WAF detection, universal command-injection detection, universal RCE detection, universal data-exfiltration detection, universal KEV coverage, universal APT coverage, or standalone actor attribution. Detection confidence depends on telemetry completeness, field mapping, local baselines, ADC asset inventory, management/API exposure inventory, request logging, query-string retention, appliance telemetry, configuration telemetry, certificate telemetry, outbound telemetry, downstream application visibility, change-control evidence, false-positive testing, query performance testing, and SOC triage readiness.

Executive Exposure Statement

The organization’s economic exposure is highest when ADC control-plane exploitation creates uncertainty around whether application-delivery infrastructure remained trustworthy. The strategic risk is not only that a vulnerable appliance exists, that a scanner touched a management endpoint, that public PoC code exists, or that exploitation attempts were reported; it is the possibility that attackers used exposed ADC, load balancer, reverse proxy, WAF-adjacent, ingress, or gateway control-plane behavior to execute commands, access configuration, expose certificates or credentials, manipulate routing, alter backend service paths, initiate outbound communication, weaken administrative controls, affect downstream applications, expose secrets, or undermine confidence in customer-facing and partner-facing services.

S40 — References

Vendor / Platform Documentation

·        Progress Community - LoadMaster Critical Security Bulletin - June 2026 - CVE-2026-8037, CVE-2026-33691 - hxxps://community[.]progress[.]com/s/article/LoadMaster-Critical-Security-Bulletin-June-2026-CVE-2026-8037-CVE-2026-33691

·        Progress Community - LoadMaster Security Vulnerabilities - CVE-2026-3517, CVE-2026-3518, CVE-2026-3519, CVE-2026-4048, CVE-2026-21876 - hxxps://community[.]progress[.]com/s/article/LoadMaster-Security-Vulnerabilites-CVE-2026-3517-CVE-2026-3518-CVE-2026-3519-CVE-2026-4048-CVE-2026-21876

·        F5 Security Advisory - Appliance mode iControl REST vulnerability CVE-2026-34176 - hxxps://my[.]f5[.]com/manage/s/article/K000160857

·        F5 Security Advisory - iControl REST vulnerability CVE-2026-41225 - hxxps://my[.]f5[.]com/manage/s/article/K000160916

·        F5 Security Advisory - BIG-IP and BIG-IQ privilege escalation vulnerability CVE-2026-42406 - hxxps://my[.]f5[.]com/manage/s/article/K000160971

·        F5 Security Advisory - NGINX Gateway Fabric vulnerability CVE-2026-50107 - hxxps://my[.]f5[.]com/manage/s/article/K000161785

Threat Technique Framework

·        MITRE ATT&CK - hxxps://attack[.]mitre[.]org/

·        CISA Known Exploited Vulnerabilities Catalog - hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Security Vendor Analysis

·        NVD - CVE-2026-8037 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-8037

·        NVD - CVE-2026-33691 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-33691

·        NVD - CVE-2026-3517 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-3517

·        NVD - CVE-2026-3518 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-3518

·        NVD - CVE-2026-3519 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-3519

·        NVD - CVE-2026-4048 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-4048

·        NVD - CVE-2026-34176 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-34176

·        NVD - CVE-2026-41225 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-41225

·        NVD - CVE-2026-42406 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-42406

·        NVD - CVE-2026-3288 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-3288

·        NVD - CVE-2026-4342 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-4342

·        NVD - CVE-2026-50107 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-50107

·        NVD - CVE-2026-21876 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-21876

·        NVD - CVE-2026-10816 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-10816

·        NVD - CVE-2026-8655 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-8655

Threat Tradecraft and Intrusion Patterns

·        watchTowr Labs - Enterprise Tech In, Shell Out: Progress Kemp LoadMaster Uninitialized Heap to Pre-Auth RCE CVE-2026-8037 - hxxps://labs[.]watchtowr[.]com/enterprise-tech-in-shell-out-progress-kemp-loadmaster-uninitialized-heap-to-pre-auth-rce-cve-2026-8037/

·        eSentire - Progress Kemp LoadMaster Vulnerability Targeted CVE-2026-8037 - hxxps://www[.]esentire[.]com/security-advisories/progress-kemp-loadmaster-vulnerability-targeted-cve-2026-8037

·        H-ISAC / AHA - Observed Exploitation Attempts Targeting Critical Progress Kemp LoadMaster Vulnerability CVE-2026-8037 - hxxps://www[.]aha[.]org/h-isac-white-reports/2026-07-01-h-isac-tlp-white-threat-bulletin-observed-exploitation-attempts-targeting-critical-progress

·        Zero Day Initiative - ZDI Advisory for Progress Kemp LoadMaster CVE-2026-8037 - hxxps://www[.]zerodayinitiative[.]com/advisories/ZDI-26-342/

·        Kubernetes Ingress-NGINX Advisory - CVE-2026-3288 - hxxps://github[.]com/kubernetes/ingress-nginx/security/advisories/GHSA-89qw-3p6m-v88g

·        Kubernetes Ingress-NGINX Advisory - CVE-2026-4342 - hxxps://github[.]com/kubernetes/ingress-nginx/security/advisories/GHSA-v6h2-p8h4-qcjw