Report Type: EXP
Threat Category: Network Infrastructure Exploitation / SD-WAN Control-Plane Authentication Bypass
Assessment Date: May 14, 2026
Primary Impact Domain: Network Control-Plane Integrity
Secondary Impact Domains: Administrative Control; SD-WAN Fabric Trust; Routing and Traffic Steering; Branch and Site Connectivity; Cloud-Hosted Network Exposure; Internal Network Segmentation; Business Continuity
Affected Asset Class: Cisco Catalyst SD-WAN Controller, Manager, Validator, edge-device, NETCONF-exposed SD-WAN infrastructure, and cloud-hosted SD-WAN supporting assets
Threat Objective Classification: Rogue Peering, Unauthorized Administrative Access, SD-WAN Control-Plane Trust Abuse, Configuration Manipulation, and Post-Access Fabric Impact

BLUF

‍ Cisco Catalyst SD-WAN Controller Authentication Bypass creates material enterprise risk by weakening confidence in SD-WAN control-plane trust, administrative access, routing behavior, policy enforcement, and branch-to-enterprise connectivity. The risk is driven by unauthorized peering, suspicious administrative authentication, NETCONF management activity, configuration manipulation, and potential SD-WAN fabric impact that may resemble legitimate provider administration, controller migration, emergency maintenance, disaster recovery, automation, or edge-device onboarding. Executive action is required to confirm controller exposure, approved peer inventory, administrative-source governance, NETCONF restrictions, configuration-audit visibility, change-management linkage, and readiness to investigate or reverse unauthorized SD-WAN fabric changes before routing, segmentation, branch connectivity, or data-center access risk expands.

Executive Risk Translation

Cisco Catalyst SD-WAN Controller Authentication Bypass shifts business risk from a narrow network-device vulnerability to an enterprise connectivity, segmentation, and administrative-control assurance issue. The primary concern is not only whether a vulnerable controller exists, but whether SD-WAN trust relationships, peer identity, administrative access, NETCONF workflows, configuration changes, and routing or policy updates can be trusted during suspicious activity. If exploitation or attempted exploitation occurred, response may expand into SD-WAN topology validation, controller and manager log review, administrative-access investigation, NETCONF source review, configuration-drift assessment, route and tunnel validation, branch and data-center connectivity assurance, service-provider coordination, privileged-access review, and executive reporting, creating financial, operational, resilience, compliance, security-governance, and business-continuity exposure beyond the affected SD-WAN controller.

S3 — Why This Matters Now

· Cisco SD-WAN Controllers and Managers sit in a high-trust position because they influence branch connectivity, routing, policy enforcement, device registration, control-plane relationships, and administrative workflows.

· Unauthorized SD-WAN control-plane trust activity can create business impact without resembling conventional malware execution or endpoint compromise.

· Rogue peering or unexpected peer-state changes may allow attacker-controlled infrastructure to appear operationally legitimate if topology baselines are weak.

· Successful administrative authentication or NETCONF access following suspicious control-plane activity creates a higher-risk path from network exposure to privileged SD-WAN management.

· Configuration changes affecting routes, tunnels, policies, certificates, device registration, peer state, or fabric trust can alter business connectivity and security boundaries.

· Service-provider access, managed-service workflows, emergency administration, disaster recovery, controller migration, automation, and edge onboarding can resemble suspicious activity without strong change context.

· Encrypted control-plane traffic and limited packet visibility make behavior-led correlation more important than payload inspection, scanner output, advisory references, or static exploit indicators.

· Organizations without centralized SD-WAN logs, topology inventory, approved peer lists, administrative-source baselines, NETCONF visibility, and configuration audit records face elevated risk of delayed detection and incomplete scoping.

S4 — Key Judgments

· Cisco Catalyst SD-WAN Controller Authentication Bypass creates a high-priority network-control-plane risk when unauthorized peering, administrative access, NETCONF activity, or configuration manipulation is possible.

· The primary business risk is loss of confidence that SD-WAN control-plane trust, administrative control, routing behavior, policy enforcement, and fabric relationships remain authorized and intact.

· The strongest enterprise risk signal is suspicious SD-WAN peering or peer-state activity followed by successful administrative authentication, NETCONF access, configuration change, or fabric-impact behavior.

· Control-plane traffic alone should not be treated as confirmed compromise, but it requires urgent review when the source, peer identity, timing, ASN, geography, access path, controller relationship, or topology context deviates from baseline.

· NETCONF access from unfamiliar or unauthorized sources is a high-value escalation signal when it follows suspicious peering, control-plane instability, administrative authentication, or peer identity mismatch.

· SD-WAN configuration changes are high-risk when they affect routes, tunnels, policies, certificates, device registration, peer state, controller relationships, or fabric trust without matching change authorization.

· Network-only visibility is insufficient because the highest-confidence evidence depends on correlation across controller logs, manager logs, authentication records, NETCONF records, configuration audits, topology inventory, and change-management data.

· Executive risk reduction depends on SD-WAN topology assurance, approved-peer validation, administrative-source governance, configuration-audit readiness, NETCONF control, change-management linkage, and response playbooks for suspected fabric manipulation.

S5 — Executive Risk Summary

Business Risk

Cisco Catalyst SD-WAN Controller Authentication Bypass can create material business risk by weakening confidence in the integrity of SD-WAN control-plane trust, administrative access, routing behavior, policy enforcement, and branch-to-enterprise connectivity. Risk increases when affected SD-WAN infrastructure supports critical branch operations, sensitive internal segmentation, data-center access, cloud connectivity, regulated business units, third-party administration, managed-service operations, or environments where routing and policy manipulation could expose sensitive systems.

Technical Cause

The risk is driven by unauthorized abuse of the SD-WAN control-plane authentication pathway, which may allow attacker activity to appear as trusted peering, administrative access, NETCONF management, or authorized infrastructure behavior. Suspicious activity may include rogue peer registration, unexpected peer identity fields, administrative authentication from unfamiliar sources, NETCONF access from unauthorized networks, configuration changes, route or tunnel manipulation, certificate or fabric-trust changes, device-registration changes, peer-state changes, and persistent access from unfamiliar infrastructure.

Threat Posture

The threat posture is elevated because SD-WAN control-plane compromise can blend into legitimate infrastructure behavior after trust is established. The risk is amplified when approved peer inventories are incomplete, administrative-source baselines are weak, NETCONF access is broadly permitted, configuration audit visibility is limited, change records lack object-level detail, or provider-managed workflows obscure source and actor context. Successful abuse may create routing disruption, segmentation erosion, unauthorized access paths, branch connectivity impact, cloud or data-center exposure, and executive-level operational uncertainty without a clear malware-based signal.

Executive Decision Requirement

Executives must require validation of Cisco SD-WAN Controller and Manager exposure, approved topology and peer inventory, administrative-source governance, NETCONF access controls, configuration-audit retention, change-management linkage, service-provider access boundaries, and SOC readiness for SD-WAN control-plane investigation. Response leadership should also confirm that suspicious peering, administrative authentication, NETCONF access, and configuration changes are reviewed historically rather than closed solely because the activity resembles normal SD-WAN operations.

S6 — Executive Cost Summary

Cisco Catalyst SD-WAN Controller Authentication Bypass creates financial exposure based on the number and criticality of affected SD-WAN controllers, managers, edge devices, branch sites, data-center links, cloud connections, administrative accounts, NETCONF-enabled systems, configuration changes, route and tunnel dependencies, managed-service paths, telemetry completeness, and the degree to which unauthorized control-plane activity may have altered SD-WAN fabric behavior.

Low Impact Scenario

Rapid assessment confirms that vulnerable or exposed Cisco SD-WAN infrastructure is limited, approved peer inventory is accurate, administrative sources are well governed, NETCONF access is restricted, no suspicious rogue peering is identified, no unauthorized administrative authentication is confirmed, no SD-WAN configuration drift is present, and change-management records align with observed controller and manager activity. Response remains limited to exposure validation, controller and manager log review, approved-peer verification, NETCONF source review, detection tuning, and executive tracking; estimated impact $200K to $1M.

Moderate Impact Scenario

One or more Cisco SD-WAN Controllers or Managers show suspicious control-plane access, unknown peer identity fields, peer-state anomalies, administrative authentication from unfamiliar sources, NETCONF access from unauthorized networks, incomplete change linkage, or limited configuration drift without confirmed broad routing manipulation, segmentation failure, data-center exposure, major branch outage, or sustained attacker control. Response requires SD-WAN topology validation, controller and manager log analysis, administrative-account review, NETCONF session investigation, configuration-drift assessment, route and tunnel review, service-provider coordination, change-record reconciliation, targeted containment, detection tuning, and executive incident coordination; estimated impact $1.2M to $8M.

High Impact Scenario

Confirmed or strongly suspected unauthorized SD-WAN control-plane trust activity results in rogue peering, privileged administrative access, NETCONF management activity, route or tunnel manipulation, policy modification, certificate or fabric-trust changes, device-registration abuse, persistent unfamiliar access, segmentation impact, branch disruption, or new connectivity into sensitive internal environments. Response may require emergency SD-WAN control-plane containment, controller and manager remediation, route and policy rollback, branch connectivity validation, segmentation review, privileged credential rotation, service-provider escalation, business-continuity coordination, forensic reconstruction, customer or business-unit assurance, legal review, regulatory assessment where applicable, cyber insurance coordination, and board-level incident governance; estimated impact $8M to $40M or higher.

S6A — Key Cost Drivers

· Number and criticality of affected Cisco SD-WAN Controllers, Managers, Validators, edge devices, branch sites, data-center connections, cloud connections, and managed-service paths.

· Whether suspicious activity involved rogue peering, unauthorized peer-state changes, unfamiliar System IPs, site IDs, domain IDs, peer types, public IPs, device identities, or controller relationships.

· Whether successful administrative authentication occurred from unfamiliar, external, unauthorized, cloud-hosted, VPN-associated, service-provider, or unmanaged source infrastructure.

· Whether NETCONF access occurred from unfamiliar or unauthorized sources, especially after suspicious peering, control-plane instability, or administrative authentication.

· Whether SD-WAN configuration changes affected routes, tunnels, policies, certificates, templates, device registration, peer state, controller relationships, or fabric trust.

· Whether unauthorized SD-WAN fabric changes created new access paths into sensitive internal segments, identity systems, management systems, backup systems, data-center environments, cloud networks, or regulated business environments.

· Completeness of Cisco SD-WAN Controller logs, Manager logs, authentication records, NETCONF records, configuration audit logs, network-flow telemetry, firewall logs, topology inventory, and change-management records.

· Ability to distinguish legitimate controller migration, edge onboarding, disaster recovery, emergency access, automation, service-provider work, and managed-service administration from suspicious control-plane behavior.

· Scope of required route validation, tunnel validation, policy review, certificate review, peer inventory reconciliation, configuration rollback, branch connectivity testing, and segmentation assurance.

· Need for administrative-account review, privileged credential rotation, service-provider escalation, third-party assurance, legal review, regulatory assessment, cyber insurance coordination, business-unit communication, or board reporting.

Most Likely Scenario Justification

Moderate scenario is most likely when suspicious SD-WAN control-plane or administrative activity requires historical review, topology validation, NETCONF investigation, and configuration-drift assessment, but available evidence does not confirm broad fabric manipulation, sustained attacker control, regulated-data exposure, major branch outage, or enterprise-wide routing impact. The estimate moves toward the lower end when telemetry confirms narrow exposure, approved operational context, no unauthorized peer activity, no NETCONF misuse, no configuration drift, and no post-access traffic-flow change. The estimate moves toward the upper end when affected infrastructure supports critical branches, data-center access, cloud connectivity, regulated environments, service-provider administration, sensitive segmentation, incomplete logging, weak peer inventory, or configuration changes that cannot be confidently tied to approved activity.

S6B — Compliance and Risk Context

Compliance Exposure Indicator

Moderate to High depending on whether suspicious SD-WAN control-plane activity, unauthorized administrative access, NETCONF misuse, configuration manipulation, route or policy changes, segmentation impact, telemetry gaps, or incomplete forensic scoping affected regulated environments, customer-facing services, sensitive internal systems, contractual service obligations, third-party access paths, or evidence required for incident investigation.

Risk Register Entry

Risk Title

Cisco Catalyst SD-WAN Control-Plane Trust and Administrative-Control Exposure

Risk Description

Adversaries may abuse Cisco Catalyst SD-WAN Controller authentication weaknesses to establish unauthorized control-plane trust, create rogue peer relationships, gain administrative access, use NETCONF management paths, alter SD-WAN configuration, manipulate routes or policies, affect fabric trust, or create new access paths into sensitive enterprise environments. This can create operational, financial, compliance, resilience, third-party governance, and executive oversight exposure.

Likelihood

Medium to High.

Impact

Severe.

Risk Rating

Critical.

Annualized Risk Exposure

Estimated $2M to $18M or higher based on SD-WAN footprint, internet exposure, controller criticality, branch dependency, data-center and cloud connectivity, sensitive-segment reliance, approved-peer inventory quality, NETCONF access control, administrative-source governance, configuration-audit readiness, service-provider dependency, telemetry completeness, containment complexity, route and policy rollback burden, operational downtime, and legal or regulatory obligations.

S7 — Risk Drivers

· SD-WAN Controllers and Managers are high-trust infrastructure components that can influence routing, policy, branch connectivity, device registration, and fabric relationships.

· Unauthorized peering can create a trust problem that may not look like ordinary external intrusion once the activity appears as infrastructure behavior.

· Administrative authentication from unfamiliar sources creates elevated risk when it follows suspicious control-plane activity or peer-state change.

· NETCONF access can represent privileged SD-WAN management activity and should be treated as high value when source, timing, peer-state, or topology context is abnormal.

· Route, tunnel, policy, certificate, device-registration, peer-state, or fabric-trust changes can create business-impacting connectivity and segmentation consequences.

· Incomplete peer inventory makes it difficult to distinguish legitimate edge onboarding, controller relationships, provider activity, and rogue infrastructure.

· Weak administrative-source baselines can cause unauthorized access to blend with VPN, cloud, service-provider, managed-service, automation, or emergency-access workflows.

· Encrypted control-plane traffic reduces the value of payload inspection and increases dependence on topology-aware behavioral correlation.

· Configuration audit gaps can prevent responders from determining whether SD-WAN fabric state changed after suspicious access.

· Change-management gaps can create false confidence during controller migration, disaster recovery, edge onboarding, emergency maintenance, or service-provider support.

· Network-only visibility is insufficient because confirmation depends on controller-side logs, manager logs, authentication records, NETCONF evidence, configuration audit data, and approved topology context.

S8 — Bottom Line for Executives

Cisco Catalyst SD-WAN Controller Authentication Bypass should be treated as a high-priority network-control-plane and business-connectivity risk. The key executive concern is not only whether a vulnerable controller exists, but whether SD-WAN trust relationships, administrative access, NETCONF management, routing behavior, policy enforcement, and fabric changes remain authorized and explainable. Risk reduction depends on approved-peer validation, administrative-source governance, NETCONF restriction, configuration-audit readiness, topology inventory, service-provider access control, and SOC workflows that can correlate suspicious peering with administrative and configuration activity. Organizations should prioritize this report as an SD-WAN trust assurance issue because unauthorized control-plane activity can create routing disruption, segmentation exposure, branch impact, cloud and data-center access risk, compliance pressure, and board-level governance requirements.

S9 — Board-Level Takeaway

Cisco Catalyst SD-WAN Controller Authentication Bypass can turn trusted network-control-plane infrastructure into a business-risk amplifier. The board-level concern is that attackers may establish unauthorized trust, gain administrative control, manipulate SD-WAN configuration, or alter connectivity before the organization can confidently distinguish malicious activity from normal provider, migration, emergency, or branch operations. Leadership should require evidence that SD-WAN topology is known, peer relationships are approved, administrative access is governed, NETCONF sources are restricted, configuration changes are auditable, service-provider paths are controlled, and suspicious fabric activity can be investigated with sufficient evidence. This report supports governance decisions around SD-WAN resilience, segmentation assurance, privileged-access control, third-party administration, telemetry readiness, incident response maturity, and executive oversight of network-control-plane exposure.

Figure 2

S10 — Threat Overview

Cisco Catalyst SD-WAN Controller Authentication Bypass represents a high-impact network-control-plane exposure because successful abuse may allow unauthorized activity to move from external or unapproved access into trusted SD-WAN fabric behavior. The core risk is not limited to exploitation of a single controller. The broader concern is whether an attacker can establish or influence SD-WAN trust relationships, appear as a valid peer, access administrative functions, use NETCONF management paths, or manipulate configuration objects that affect routing, tunnels, policy, device registration, certificates, peer state, or fabric trust.

This activity is operationally significant because SD-WAN Controllers and Managers influence how distributed enterprise locations connect to internal systems, cloud environments, data centers, third-party networks, and sensitive business services. Unauthorized control-plane trust or administrative access can create downstream exposure across branch operations, segmentation boundaries, traffic routing, remote-site connectivity, and managed-service trust paths.

The threat model should be treated as behavior-led rather than indicator-led. The most important evidence is not a CVE string, scanner output, port observation, or advisory reference. The most important evidence is suspicious sequencing between control-plane activity, peer-state change, administrative authentication, NETCONF access, configuration modification, and SD-WAN fabric impact.

Detection and response should assume that successful activity may not look obviously malicious after trust is established. Once an attacker appears as a trusted peer or gains administrative access, activity may resemble controller migration, service-provider troubleshooting, emergency maintenance, automation, edge onboarding, or normal SD-WAN operations unless validated against approved topology, peer inventory, administrative-source baselines, and change-management records.

S11 — Threat Classification and Type

Threat Type

Network-control-plane exploitation and administrative-control abuse.

Threat Sub-Type

Cisco SD-WAN Controller authentication bypass enabling unauthorized peering, privileged management access, NETCONF activity, and configuration manipulation.

Operational Classification

High-impact infrastructure trust compromise affecting SD-WAN control-plane integrity, administrative assurance, routing confidence, segmentation reliability, and enterprise connectivity.

Primary Function

The primary function is to obtain unauthorized SD-WAN control-plane or management-plane positioning that may allow the attacker to appear trusted, access administrative workflows, interact with NETCONF-exposed infrastructure, alter SD-WAN configuration, or influence distributed enterprise connectivity.

S12 — Campaign or Activity Overview

This report does not require attribution to a specific threat actor or named campaign. The assessed activity model is based on the operational risk created by Cisco Catalyst SD-WAN Controller authentication bypass conditions and the post-access behaviors that matter most to enterprise defenders.

The most relevant activity pattern is a progression from unauthorized control-plane interaction toward trusted SD-WAN positioning or privileged management activity. This may include suspicious source access to Controller or Manager services, peer-state anomalies, unexpected peer identity fields, administrative authentication from unfamiliar infrastructure, NETCONF access, and configuration changes affecting SD-WAN fabric behavior.

A likely operational sequence may include:

· External or unauthorized access to Cisco SD-WAN Controller or Manager control-plane services.

· Attempted or successful interaction with SD-WAN peer-establishment or control-connection workflows.

· Appearance of unfamiliar source IPs, public IPs, System IPs, site IDs, domain IDs, peer types, device identities, or controller relationships.

· Successful administrative authentication from an unfamiliar, unauthorized, or poorly governed source path.

· NETCONF access to SD-WAN infrastructure from a source not aligned with approved administration, automation, emergency access, or service-provider workflows.

· Configuration changes affecting routes, tunnels, policies, certificates, templates, device registration, peer state, controller relationships, or fabric trust.

· New or unexpected traffic-flow behavior after suspicious control-plane, administrative, NETCONF, or configuration activity.

The activity should be assessed as an enterprise control-plane trust issue rather than a simple perimeter-access event. The operational concern is whether the attacker can use SD-WAN trust, management, or configuration pathways to affect connectivity, segmentation, data-center reachability, cloud access, branch operations, or sensitive internal environments.

S13 — Targets and Exposure Surface

The highest-risk targets are organizations where Cisco Catalyst SD-WAN infrastructure supports distributed connectivity, centralized routing and policy enforcement, managed-service administration, sensitive segmentation, or business-critical branch and data-center operations.

Primary exposure surfaces include:

· Cisco SD-WAN Controllers and Managers reachable from external, service-provider, managed-service, VPN, emergency-access, or administrative networks.

· Cisco SD-WAN control-plane services that support peering, control connections, peer-state changes, device registration, controller relationships, and fabric-trust workflows.

· SD-WAN administrative interfaces used for controller, manager, route, tunnel, policy, certificate, template, device-registration, peer-state, and fabric-trust administration.

· NETCONF-exposed SD-WAN infrastructure reachable from administrative, automation, provider, or insufficiently restricted source networks.

· Approved and expected peer relationships involving Controllers, Validators, Managers, edge devices, System IPs, site IDs, domain IDs, public IPs, device identities, and controller relationships.

· Administrative source networks, VPN paths, service-provider access paths, emergency-access paths, automation systems, and management networks.

· Configuration audit sources, topology inventories, change-management records, and maintenance-window records needed to validate whether observed SD-WAN changes were authorized.

· Branch, data-center, cloud, remote-site, and sensitive internal segments whose connectivity may be affected by route, tunnel, policy, certificate, or fabric-trust manipulation.

Exposure is highest where SD-WAN infrastructure is internet-reachable, externally administered, provider-managed, poorly baselined, weakly logged, or connected to sensitive internal routing and segmentation paths.

S14 — Sectors / Countries Affected

Sectors Affected

· Financial services, banking, insurance, payment-processing, and capital-markets organizations using SD-WAN for branch, data-center, cloud, or regulated network connectivity.

· Healthcare, life sciences, hospitals, clinics, medical research, and regulated care-delivery environments relying on SD-WAN for site connectivity and sensitive data access.

· Government, defense, public-sector, municipal, and critical public-service organizations using distributed network infrastructure and centralized policy enforcement.

· Telecommunications, managed service providers, network service providers, and enterprise IT service organizations administering or supporting SD-WAN infrastructure for customers.

· Energy, utilities, transportation, logistics, manufacturing, and industrial organizations relying on SD-WAN for operational sites, remote facilities, and business-continuity connectivity.

· Retail, ecommerce, hospitality, and distributed branch organizations using SD-WAN to connect stores, payment environments, warehouses, call centers, and corporate services.

· Technology, software development, cloud operations, SaaS, and engineering organizations with SD-WAN connectivity into development, production, management, or cloud environments.

· Education, research institutions, university systems, and shared campus environments with distributed sites and mixed administrative ownership.

· Legal, consulting, accounting, professional services, and business-services firms with distributed offices and sensitive client data access.

· Organizations with large branch networks, remote-site operations, third-party administered SD-WAN, provider-managed SD-WAN, centralized routing policy, sensitive segmentation requirements, or incomplete peer inventory.

· Organizations relying on Cisco Catalyst SD-WAN Controllers, Managers, Validators, NETCONF workflows, service-provider administration, automation, or centralized configuration management to operate enterprise connectivity.

Countries Affected

· Global.

· Exposure is not limited to a single country or region because Cisco SD-WAN infrastructure, distributed enterprise connectivity, service-provider administration, cloud connectivity, branch networking, and managed-service workflows are used globally.

· Countries with large financial, healthcare, government, telecommunications, energy, manufacturing, transportation, technology, retail, or managed-service sectors may face elevated operational exposure.

· Country-specific impact should be assessed by Cisco SD-WAN footprint, controller exposure, approved peer inventory, administrative-source governance, NETCONF restriction, topology quality, configuration-audit visibility, service-provider dependency, branch criticality, cloud and data-center connectivity, and incident-response readiness rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High.

Technical Sophistication

Moderate to High. Successful operational use requires understanding of Cisco SD-WAN control-plane behavior, peer relationships, administrative workflows, NETCONF access patterns, configuration objects, and post-access routing or policy impact. The initial vulnerability may reduce access complexity, but meaningful exploitation and persistence of impact require network-control-plane awareness.

Infrastructure Maturity

Moderate. The actor may need infrastructure capable of reaching exposed SD-WAN services, rotating through cloud, VPN, hosting, provider, or unmanaged networks, and sustaining access paths that can blend with administrative or service-provider activity. Higher maturity is required to maintain low-noise activity across peer establishment, administrative authentication, NETCONF access, and configuration manipulation.

Operational Scale

Moderate to High. Single-environment activity may be targeted and narrow, but the same operating model can scale across organizations with similar SD-WAN exposure, provider-managed access patterns, incomplete peer inventories, or weak configuration-audit practices. Broad scaling is most plausible where exposed controllers, common administrative patterns, or repeatable NETCONF and SD-WAN management workflows exist.

Escalation Likelihood

High when suspicious control-plane activity is followed by administrative authentication, NETCONF access, configuration changes, route or tunnel manipulation, policy changes, certificate changes, device-registration changes, peer-state changes, or new connectivity into sensitive internal environments. Lower confidence should be assigned when activity is limited to isolated access attempts without peer-state, authentication, NETCONF, configuration, or fabric-impact evidence.

S16 — Targeting Probability Assessment

Overall Targeting Probability

Medium to High.

Targeting Drivers

· Cisco SD-WAN Controllers and Managers occupy a high-trust position within enterprise network architecture.

· Successful abuse may provide access to routing, policy, device-registration, peer-state, NETCONF, certificate, and fabric-trust workflows.

· SD-WAN infrastructure often connects branch sites, data centers, cloud environments, remote sites, and sensitive internal systems.

· Externally reachable or provider-accessible SD-WAN services create attractive access paths for adversaries seeking infrastructure-level control.

· Managed-service, service-provider, VPN, automation, and emergency-access workflows may create ambiguity that attackers can exploit to blend with legitimate administration.

· Incomplete peer inventory, weak administrative-source governance, limited configuration-audit visibility, and poor change-management linkage increase attacker opportunity.

· Unauthorized SD-WAN configuration changes can affect segmentation, traffic routing, branch connectivity, cloud reachability, and access to sensitive internal environments.

· Encrypted control-plane traffic and limited payload visibility can delay detection if organizations depend on static indicators or port-only monitoring.

Most Likely Targets

· Organizations with internet-exposed or externally reachable Cisco SD-WAN Controllers or Managers.

· Large distributed enterprises with many branch, data-center, cloud, remote-site, or third-party connectivity dependencies.

· Financial services, healthcare, government, telecommunications, energy, transportation, retail, manufacturing, technology, and managed-service environments.

· Organizations with provider-managed, co-managed, or third-party administered SD-WAN infrastructure.

· Environments with incomplete peer inventory, weak administrative-source baselines, broad NETCONF access, or limited configuration audit retention.

· Organizations where SD-WAN routing, tunnel, policy, certificate, device-registration, or fabric-trust manipulation could affect sensitive internal network access.

· Environments with critical segmentation, regulated systems, cloud connectivity, high-value business services, or operational dependency on centralized SD-WAN policy enforcement.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Exposure and Remote Access Path

Cisco Catalyst SD-WAN Controller Authentication Bypass begins with a reachable SD-WAN control-plane or management-plane access path. This may include internet-facing controller exposure, provider-accessible infrastructure, VPN or managed-service paths, emergency-access workflows, or administrative networks with insufficient source restriction.

· ATT&CK mapping: External Remote Services T1133.

· Confidence: Conditional. Reachability is a relevant precondition, but exposure alone should not be treated as compromise.

Stage 2 — Unauthorized Control-Plane Interaction

The next stage is suspicious interaction with Cisco SD-WAN Controller or Manager control-plane services. This may include unknown source access, unexpected peer-state activity, control-connection anomalies, or unfamiliar peer identity fields. The operational concern is unauthorized interaction with SD-WAN trust-establishment behavior, not generic scanning.

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

· Confidence: Conditional to likely. Suspicious control-plane interaction is central to the report model, but it requires source, peer, timing, topology, and controller-side context.

Stage 3 — Administrative Authentication or NETCONF Management Access

If activity progresses, the actor may obtain or use administrative access, or interact with NETCONF-exposed SD-WAN infrastructure. This stage is higher priority when the source is unfamiliar, newly observed, external, unauthorized, or not aligned with approved administration, automation, service-provider, or emergency-access workflows.

· ATT&CK mapping: Valid Accounts T1078.

· ATT&CK mapping: Remote Services T1021.

· Confidence: Likely when successful administrative authentication or NETCONF access follows suspicious peering, peer-state activity, or control-plane anomalies.

Stage 4 — SD-WAN Topology or Configuration Review

After trusted or administrative positioning, the actor may review SD-WAN topology, peer relationships, route state, tunnel configuration, policy objects, controller relationships, device registration, certificate state, or fabric-trust context. This stage supports decision-making before configuration manipulation or fabric-impact activity.

· ATT&CK mapping: System Network Configuration Discovery T1016.

· Confidence: Conditional. Configuration or topology review should be assessed through SD-WAN Manager logs, Controller logs, NETCONF records, audit records, and administrative-session context.

Stage 5 — SD-WAN Configuration or Trust Manipulation

The actor may alter routes, tunnels, policies, certificates, templates, device-registration state, peer state, controller relationships, account or access artifacts, or fabric-trust objects. Configuration change becomes more concerning when the actor, source, object, timing, peer context, or approval record does not align with expected SD-WAN operations.

· ATT&CK mapping: Account Manipulation T1098.

· Confidence: Conditional. T1098 is applicable only where account, access, certificate, trust, or administrative-control artifacts are modified. Route, tunnel, policy, or peer-state manipulation should be described in SD-WAN operational terms and not forced into an ATT&CK mapping.

Stage 6 — Fabric Impact and Business Assurance Exposure

The final operational outcome is uncertainty over whether SD-WAN control-plane trust, administrative control, routing behavior, segmentation, branch connectivity, cloud access, and data-center reachability remained authorized and intact. This stage is most severe when affected infrastructure supports regulated environments, critical branches, sensitive segmentation, managed-service administration, or high-value internal systems.

· Confidence: High where suspicious peering, administrative authentication, NETCONF access, configuration change, topology mismatch, or traffic-flow change overlaps with critical SD-WAN infrastructure.

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

Cisco Catalyst SD-WAN Controller Authentication Bypass should be understood as a control-plane trust abuse path rather than a conventional malware execution chain. The attacker objective is to move from unauthorized reachability into trusted SD-WAN positioning, administrative access, NETCONF management activity, configuration manipulation, or fabric-impact behavior.

Stage 1 — SD-WAN Control-Plane Reachability

The attack path begins when Cisco SD-WAN Controller or Manager infrastructure is reachable from an external, provider, VPN, managed-service, emergency-access, automation, or otherwise unapproved source path. Reachability alone does not indicate compromise, but it creates the condition under which authentication bypass or unauthorized control-plane interaction may become operationally meaningful.

· Unauthorized peering can allow attacker-controlled infrastructure to appear operationally trusted.

· Administrative authentication or NETCONF access indicates movement from exposure into privileged SD-WAN management.

· Fabric-impacting changes can affect segmentation, traffic direction, branch reachability, data-center access, and cloud connectivity.

· Weak provider, VPN, automation, emergency-access, and managed-service governance can obscure attacker activity.

· Encrypted control-plane traffic and incomplete audit visibility can delay confirmation and increase scoping burden.

· Persistent unfamiliar access after remediation may indicate that trust, account, certificate, peer, or configuration artifacts remain active.

Highest-Risk Escalation Pattern

The highest-risk pattern is suspicious SD-WAN peering or control-plane activity followed by successful administrative authentication, NETCONF access, configuration modification, and new traffic-flow behavior affecting sensitive internal segments or critical connectivity paths.

Business Impact Path

The business impact path moves from infrastructure exposure to loss of confidence in SD-WAN trust, then to potential routing or policy manipulation, then to segmentation or connectivity impact. At that point, response may require emergency control-plane containment, route and policy validation, branch connectivity review, service-provider escalation, privileged-access review, and executive incident governance.

S20 — Tactics, Techniques, and Procedures

Figure 3

Access and Control-Plane Positioning

· Interact with externally reachable or provider-accessible Cisco SD-WAN control-plane services.

· Attempt to appear as approved SD-WAN infrastructure through unfamiliar peer identity, device-registration, or controller-relationship values.

· Use source infrastructure that blends with cloud, VPN, hosting, service-provider, managed-service, or emergency-access paths.

Administrative and NETCONF Activity

· Use administrative or NETCONF access paths from unfamiliar or unauthorized sources.

· Sequence management activity near peer-state anomalies, control-plane instability, or unexpected controller events.

· Blend activity into automation, service-provider support, emergency access, or normal management workflows where baselines are weak.

Configuration and Fabric Manipulation

· Review or alter routes, tunnels, policies, certificates, templates, device registration, peer state, controller relationships, or fabric-trust objects.

· Create configuration drift that lacks clear change-ticket, maintenance-window, service-provider, automation, or emergency-access justification.

· Preserve access through account, key, certificate, peer, trust, or configuration artifacts where access allows.

Impact and Persistence-Oriented Behavior

· Create or preserve new access paths between SD-WAN-managed environments and sensitive internal systems.

· Alter branch, data-center, cloud, or remote-site connectivity through SD-WAN fabric changes.

· Maintain recurring access from unfamiliar sources after initial suspicious activity.

Evasion and Blending Factors

· Operate during activity windows that resemble maintenance, migration, disaster recovery, edge onboarding, automation, or provider support.

· Benefit from encrypted control-plane traffic where packet-level visibility is limited.

· Exploit weak topology inventory, administrative-source baselines, NETCONF visibility, or configuration-audit retention.

S20A — Adversary Tradecraft Summary

Cisco Catalyst SD-WAN Controller Authentication Bypass tradecraft is best characterized as infrastructure-trust abuse. The attacker does not need to rely on noisy malware behavior if SD-WAN trust, administrative access, NETCONF workflows, or configuration pathways can be misused.

The most important tradecraft feature is the ability to make suspicious activity resemble legitimate SD-WAN operations. Rogue peer behavior may look like edge onboarding, provider troubleshooting, controller migration, or disaster recovery. Administrative and NETCONF access may look like automation, service-provider support, emergency access, or normal management activity. Configuration changes may appear routine unless actor, source, object, timing, peer-state context, and approval records are correlated.

The strongest defensive interpretation is behavior-led. Single signals should be handled carefully, but clustered activity involving peering, authentication, NETCONF access, configuration change, and traffic-flow impact should be treated as a high-priority escalation path.

The most consequential outcome is loss of assurance in SD-WAN fabric integrity. If unauthorized trust or configuration changes cannot be ruled out, organizations may need to validate route state, tunnel state, policy behavior, certificate posture, device registration, peer relationships, branch connectivity, segmentation boundaries, and access paths into sensitive internal environments before returning to normal operational confidence.

S21 — Detection Strategy Overview

Detection Philosophy

Behavioral detection for CVE-2026-20182 should focus on unauthorized SD-WAN control-plane trust establishment, rogue peering behavior, suspicious administrative authentication, NETCONF access, SD-WAN configuration manipulation, and post-access fabric impact.

The detection objective is not to identify the CVE name alone. The objective is to identify activity suggesting that an attacker has abused the Cisco SD-WAN control-plane authentication pathway to appear as a trusted peer, gain privileged access, or manipulate SD-WAN fabric behavior.

Detection content should be correlation-led, topology-aware, and resistant to minor implementation changes. Static advisory references, scanner findings, port activity, or CVE-string matches should not be treated as durable primary detection anchors.

Primary Detection Anchors

· Unauthorized SD-WAN Controller or Manager peering from unknown, unexpected, or unapproved source IP addresses.

· Rogue peer registration or peer-state changes inconsistent with approved SD-WAN topology.

· New or unexpected peer identity fields, including System IP, site ID, domain ID, peer type, public IP, device identity, or controller relationship.

· Successful administrative authentication from source networks not approved for SD-WAN administration.

· Successful SD-WAN administrative-account authentication from unknown, external, or unauthorized source IP addresses.

· NETCONF access to SD-WAN infrastructure from unfamiliar, newly observed, or unauthorized source networks.

· NETCONF access following suspicious peering, peer-state changes, administrative authentication, or control-plane instability.

· SD-WAN configuration changes following anomalous peering or administrative access.

· Route, tunnel, policy, device-registration, certificate, peer-state, or fabric-trust changes following suspicious control-plane activity.

· Persistent or recurring access from unfamiliar sources after initial peering or administrative-access anomalies.

· Administrative activity occurring outside approved maintenance windows, change windows, or emergency-access procedures.

Detection Prioritization Model

Detection priority should be based on the relationship between suspicious control-plane trust activity, administrative authentication, NETCONF access, SD-WAN configuration changes, and approved topology context.

Single-event alerts should be treated as lower confidence unless they directly confirm unauthorized successful administrative access or are correlated with supporting control-plane, authentication, NETCONF, or configuration-change signals.

· Highest priority should be assigned to suspicious SD-WAN peering followed by successful administrative authentication, NETCONF access, or SD-WAN configuration modification.

· Highest priority should be assigned to rogue peer activity followed by route, tunnel, policy, device-registration, certificate, peer-state, or fabric-trust changes.

· High priority should be assigned to unfamiliar peer identity fields that do not match approved SD-WAN inventory.

· High priority should be assigned to unfamiliar sources accessing NETCONF after control-plane anomalies.

· Medium priority should be assigned to repeated access attempts against SD-WAN control-plane services from unfamiliar sources without confirmed peering or authentication success.

· Medium priority should be assigned to peer churn, control-connection instability, or abnormal negotiation activity outside approved maintenance windows.

· Lower priority should be assigned to isolated failed access attempts that do not result in peering, authentication success, NETCONF access, configuration change, persistence activity, or repeated targeting.

Correlation Strategy

Strict correlation is required.

Cisco SD-WAN control-plane abuse can appear as trusted infrastructure behavior after successful exploitation. Detection logic should not rely on isolated port activity, vulnerability exposure, scanner output, or advisory references as compromise evidence.

Detection logic should prioritize combinations of the following:

· Suspicious SD-WAN peering followed by administrative authentication from the same source, related source, infrastructure cluster, ASN, VPN provider, cloud provider, or access path.

· Unknown peer identity fields followed by NETCONF access.

· Successful administrative authentication followed by SD-WAN configuration changes.

· UDP control-plane activity followed by TCP NETCONF access from the same or related source.

· New or unfamiliar System IP, site ID, domain ID, peer type, public IP, or device identity followed by route, tunnel, policy, certificate, registration, or fabric-trust changes.

· Control-plane instability followed by external access attempts and administrative activity.

· Unusual administrative access followed by device-registration, peer-state, configuration, or SD-WAN fabric changes.

· Authentication-log anomalies that align with SD-WAN Manager audit-log activity.

· Network-flow anomalies that align with controller-side logs, especially where encrypted control-plane traffic limits packet-level visibility.

· High-priority findings that do not align with approved topology, known peer inventory, administrative source networks, maintenance windows, or change-management records.

Telemetry Prioritization

Primary telemetry should come from SD-WAN Controller logs, SD-WAN Manager logs, authentication records, NETCONF records, configuration audit sources, topology inventory, and network-flow metadata.

Network telemetry should be used as high-value supporting context, but controller-side, authentication, and configuration-change records should drive final severity.

Highest-Value Telemetry

· SD-WAN Controller and Manager logs for peering, control-connection, peer-state, device-identity, and fabric-trust activity.

· Authentication logs for administrative-account access, source IP validation, authentication method, successful access, and failed-to-successful access patterns.

· NETCONF logs and network-flow telemetry for TCP port 830 access to SD-WAN management and control-plane infrastructure.

· SD-WAN configuration audit logs for policy, route, tunnel, device-registration, certificate, peer-state, and fabric-trust changes.

· Inventory and topology data for validation of approved System IPs, site IDs, domain IDs, peer types, public IPs, controller identities, device identities, and administrative source networks.

· Historical configuration snapshots for identifying unauthorized fabric drift after suspicious access.

Supporting Telemetry

· Network-flow telemetry for UDP control-plane activity to Cisco SD-WAN Controller and Manager systems.

· Firewall and NDR telemetry for external access paths, newly observed sources, abnormal timing, and repeated connection attempts.

· Change-management records for distinguishing authorized maintenance from suspicious control-plane behavior.

· File and persistence telemetry where supportable for unauthorized key, account, configuration, or persistence artifacts on SD-WAN infrastructure.

· Service-provider, managed-service, VPN, and emergency-access records where those paths are approved for SD-WAN administration.

Detection Design Constraints

Detection content must remain behavior-led and should not overfit to CVE text, public advisory language, scanner output, port-only activity, or payload signatures.

Rules should avoid treating normal SD-WAN peering, NETCONF administration, controller migration, service-provider access, disaster-recovery activity, emergency maintenance, or planned topology changes as compromise by default.

Rules should require context from at least one of the following:

· Abnormal peer identity context.

· Abnormal administrative source context.

· Abnormal control-plane trust context.

· Abnormal NETCONF access context.

· Abnormal configuration-change context.

· Abnormal timing or maintenance-window context.

· Abnormal topology or inventory context.

· Abnormal controller relationship context.

· Abnormal route, tunnel, policy, certificate, or fabric-trust context.

· Abnormal persistence or recurring-access context.

Baseline and Deployment Requirements

Organizations should establish SD-WAN topology, administrative-access, NETCONF, and configuration-change baselines before promoting this detection model into high-severity production alerts.

Required baselines include:

· Approved Cisco Catalyst SD-WAN Controllers, Managers, Validators, edge devices, and control-plane components.

· Approved System IPs, site IDs, domain IDs, peer types, public IPs, device identities, controller relationships, and expected peer relationships.

· Approved administrative source networks, VPN paths, service-provider access paths, emergency-access paths, and automation sources.

· Approved NETCONF source networks and expected NETCONF administrative workflows.

· Normal SD-WAN peering, control-connection state changes, peer churn, controller-to-edge communication, administrative authentication, NETCONF access, and configuration-change patterns.

· Normal UDP control-plane and TCP NETCONF communication to SD-WAN infrastructure.

· Normal route, tunnel, policy, certificate, device-registration, peer-state, and fabric-trust change activity.

· Normal maintenance windows, emergency-change procedures, and change-management references for SD-WAN activity.

· Normal logging retention and field availability for delayed discovery, repeated access, persistence activity, configuration drift, and post-exploitation review.

Deployment should prioritize SD-WAN environments where control-plane compromise would create material business or operational impact.

· Internet-exposed SD-WAN Controller or Manager infrastructure.

· Large distributed branch environments.

· Critical network segmentation environments.

· Financial, healthcare, government, telecommunications, energy, transportation, and managed-service environments.

· Environments with high reliance on centralized SD-WAN policy enforcement.

· Environments with third-party or service-provider SD-WAN administration.

· Environments with incomplete peer inventory, weak change-management linkage, or limited configuration-audit visibility.

· Environments where SD-WAN routing, tunnel, or policy manipulation could affect sensitive internal network access.

Variant Resilience Requirements

Detection content must remain useful if the exploit implementation changes.

Variant-resilient detection should focus on:

· Unauthorized control-plane trust establishment.

· Rogue or unexpected SD-WAN peering.

· Unexpected peer identity fields.

· Administrative authentication from unfamiliar sources.

· NETCONF access after suspicious peering or authentication.

· SD-WAN configuration manipulation.

· Route, tunnel, policy, certificate, device-registration, peer-state, or fabric-trust changes.

· Persistent or recurring access from unfamiliar sources.

· Unauthorized key, account, peer, or configuration artifacts where telemetry allows.

· Post-access SD-WAN fabric drift or traffic-flow manipulation.

Detection content should not rely on:

· A specific CVE string as the primary detection condition.

· A specific scanner result.

· A specific advisory reference.

· A single port observation without surrounding context.

· Encrypted DTLS payload visibility.

· A single NETCONF session without source, identity, timing, peer-state, or configuration-change context.

· Assumptions that exploitation will always originate from the public internet.

· Assumptions that attacker activity will appear obviously malicious after trusted peer status is obtained.

Operational Detection Model

The operational model should use a staged approach.

Stage One - Exposure and Topology Identification

· Identify Cisco SD-WAN Controllers, Managers, Validators, edge devices, and control-plane components.

· Identify internet-exposed or externally reachable SD-WAN control-plane and management-plane services.

· Identify approved peers, System IPs, site IDs, domain IDs, peer types, public IPs, device identities, and controller relationships.

· Identify approved administrative source networks, NETCONF sources, service-provider paths, VPN paths, emergency-access paths, and automation sources.

· Identify environments where SD-WAN compromise would create high operational, segmentation, routing, or business-continuity impact.

Stage Two - Peering and Control-Plane Anomaly Detection

· Detect unauthorized SD-WAN peering from unknown, unexpected, or unapproved sources.

· Detect rogue peer registration or peer-state changes inconsistent with approved topology.

· Detect unfamiliar System IP, site ID, domain ID, peer type, public IP, device identity, or controller relationship values.

· Detect abnormal control-connection state changes, peer churn, or negotiation activity outside approved maintenance windows.

· Detect repeated control-plane access attempts from unfamiliar sources.

Stage Three - Administrative and NETCONF Access Detection

· Detect successful administrative authentication from unfamiliar or unauthorized source networks.

· Detect SD-WAN administrative-account authentication from unexpected sources.

· Detect NETCONF access from unfamiliar, newly observed, or unauthorized source networks.

· Detect NETCONF access following suspicious peering, control-plane instability, or administrative authentication.

· Detect authentication or NETCONF activity that does not align with approved maintenance, automation, service-provider, or emergency-access workflows.

Stage Four - Fabric Impact and Persistence Detection

· Detect SD-WAN configuration changes following suspicious peering or administrative access.

· Detect route, tunnel, policy, certificate, device-registration, peer-state, or fabric-trust changes after anomalous control-plane activity.

· Detect persistent or recurring access from unfamiliar sources after initial peering or authentication anomalies.

· Detect unauthorized key, account, peer, or configuration artifacts where telemetry allows.

· Detect SD-WAN fabric drift, unexpected traffic-flow changes, or new access paths created after suspicious control-plane activity.

Signal Usage Constraints

· Do not treat normal SD-WAN peering, NETCONF administration, control-plane communication, or configuration activity as suspicious by itself.

· Do not treat UDP control-plane traffic, NETCONF access, scanner output, advisory references, or vulnerability exposure as confirmed exploitation by itself.

· Do not rely on CVE text, port-only logic, or encrypted DTLS payload inspection as the primary detection method.

· Do not suppress unknown peer activity solely because the source belongs to a cloud, VPN, managed-service, or service-provider ASN.

· Do not ignore approved maintenance windows, disaster-recovery activity, emergency access, managed-service activity, or planned SD-WAN topology changes.

· Do not assign high-severity control-plane findings without baselines for approved peers, System IPs, site IDs, domain IDs, public IPs, device identities, controller relationships, NETCONF sources, and administrative source networks.

· Do not treat configuration changes as compromise indicators without correlating actor, source, time, object changed, change type, peer-state context, and change authorization.

· Do not assign compromise-level severity from a single weak signal unless the signal directly confirms unauthorized successful administrative access.

· Do not include actor-attribution language unless independent actor-specific intelligence supports attribution.

· Do not treat control-plane activity as malicious unless it can be distinguished from normal SD-WAN operations, approved peer behavior, and authorized fabric-impacting activity.

S22 — Primary Detection Signals

Primary Detection Signals

Primary detection signals for CVE-2026-20182 should focus on unauthorized SD-WAN control-plane trust establishment, rogue peering behavior, suspicious administrative authentication, NETCONF access, SD-WAN configuration manipulation, and fabric-impact activity.

The strongest signals are not advisory references, scanner findings, or CVE-string matches. The strongest signals are behavior patterns showing that an attacker may have gained trusted control-plane positioning or used that positioning to alter SD-WAN management, routing, policy, or fabric state.

· Unauthorized SD-WAN Controller or Manager peering from an unknown, unexpected, or unapproved source.

· Rogue peer registration or peer-state change inconsistent with approved SD-WAN topology.

· New or unfamiliar System IP, site ID, domain ID, peer type, public IP, device identity, or controller relationship.

· Successful SD-WAN administrative authentication from an unfamiliar, external, or unauthorized source network.

· Administrative authentication from a source not aligned with approved VPN, service-provider, automation, emergency-access, or management paths.

· NETCONF access to SD-WAN infrastructure from an unfamiliar, newly observed, or unauthorized source.

· NETCONF access following suspicious peering, control-plane instability, or administrative authentication.

· SD-WAN configuration changes following anomalous control-plane or administrative activity.

· Route, tunnel, policy, certificate, device-registration, peer-state, or fabric-trust changes following suspicious access.

· Persistent or recurring access from unfamiliar sources after initial peering or administrative-access anomalies.

Supporting Detection Signals

Supporting signals should provide context around source behavior, sequencing, operational timing, topology mismatch, and configuration drift. These signals should strengthen investigation confidence but should not be treated as standalone confirmation of exploitation.

· Repeated UDP control-plane access attempts against Cisco SD-WAN Controller or Manager infrastructure.

· Repeated TCP NETCONF access attempts against SD-WAN management or control-plane infrastructure.

· Newly observed source IPs communicating with SD-WAN control-plane or management-plane services.

· Control-plane communication from geographies, ASNs, VPN providers, cloud providers, or managed-service paths not normally associated with SD-WAN administration.

· Administrative access outside approved maintenance windows, change windows, emergency-access procedures, or service-provider support periods.

· Failed-to-successful administrative authentication patterns involving SD-WAN management accounts.

· Peer churn, control-connection instability, or abnormal negotiation activity near suspicious access attempts.

· Configuration changes without matching change ticket, maintenance record, emergency-access record, service-provider record, or expected automation event.

· SD-WAN inventory drift involving peer identity, controller relationships, registered devices, certificates, or fabric-trust state.

· Network-flow anomalies that align with SD-WAN Controller, Manager, authentication, or configuration-audit events.

Exploit Attempt and Instability Signals

Exploit-attempt and instability signals should be treated as early warning or triage context unless they are correlated with peer establishment, authentication success, NETCONF access, or configuration change.

· Repeated connection attempts to SD-WAN control-plane services from unfamiliar external sources.

· Abnormal control-connection negotiation attempts involving unknown or unexpected peer identity fields.

· Unexpected peer-state transitions near unusual external access activity.

· Sudden peer churn, controller instability, or control-plane state changes outside maintenance windows.

· Repeated failed authentication or negotiation activity followed by successful administrative access.

· Control-plane instability followed by NETCONF access or SD-WAN configuration activity.

· Access attempts from infrastructure that has not previously interacted with the SD-WAN control plane.

· Suspicious sequencing between external access, peer-state change, administrative authentication, and configuration modification.

· Unusual access patterns targeting SD-WAN control-plane and management-plane services within the same operational window.

Outbound Communication Signals

Outbound and post-access communication signals should be used to identify possible SD-WAN fabric manipulation, new access paths, traffic-flow changes, or infrastructure relationships created after suspicious control-plane activity.

· New or unexpected outbound connections from SD-WAN infrastructure after suspicious peering or administrative access.

· New traffic flows associated with unfamiliar peers, public IPs, controller relationships, or fabric-trust changes.

· Unexpected route, tunnel, or policy changes that redirect traffic toward unfamiliar destinations.

· New communication paths between SD-WAN-managed environments and sensitive internal network segments.

· Unexpected connectivity from SD-WAN infrastructure to cloud, VPN, hosting, or unmanaged external networks.

· New or abnormal management-plane communication following SD-WAN configuration changes.

· Changes in branch, data-center, cloud, or remote-site connectivity following suspicious control-plane activity.

· Unexpected traffic-flow changes after route, tunnel, certificate, policy, or fabric-trust modification.

· Outbound activity that aligns with persistent unfamiliar peer access or recurring administrative sessions.

Persistence and Post-Exploitation Signals (Conditional)

Persistence and post-exploitation signals should be evaluated when telemetry is available. These signals should be treated as high value when they follow suspicious peering, administrative authentication, NETCONF access, or configuration manipulation.

· Persistent rogue peer relationships or unauthorized device registrations.

· Repeated administrative access from unfamiliar sources after initial suspicious control-plane activity.

· Unauthorized key, account, certificate, peer, or configuration artifacts associated with SD-WAN infrastructure.

· Configuration changes that preserve access, weaken trust boundaries, or alter SD-WAN control-plane behavior.

· Recurring NETCONF access from sources not aligned with approved administrative workflows.

· Fabric-trust changes that survive maintenance, restart, policy refresh, or configuration review.

· Route, tunnel, or policy changes that create new access paths into sensitive internal environments.

· SD-WAN configuration drift that cannot be tied to approved maintenance, automation, service-provider activity, or emergency access.

· Continued administrative or peer activity after remediation actions, patching, or configuration rollback.

Lateral Movement and Expansion Signals (Conditional)

Lateral movement and expansion signals should focus on whether SD-WAN control-plane abuse enabled access to additional network segments, management systems, or sensitive environments.

· New SD-WAN routes or policies enabling access to internal segments not previously reachable from the observed source path.

· Traffic from suspicious or newly observed SD-WAN peer contexts toward identity, management, monitoring, backup, hypervisor, or network-administration systems.

· New connectivity between branch, data-center, cloud, or remote-site environments after suspicious control-plane activity.

· Access attempts to sensitive internal services following SD-WAN configuration manipulation.

· East-west traffic changes following route, tunnel, policy, certificate, or fabric-trust modification.

· Administrative access to additional network infrastructure after SD-WAN control-plane anomalies.

· New service reachability from locations, peers, or access paths not normally permitted by SD-WAN policy.

· Follow-on authentication, scanning, or management activity from paths enabled by suspicious SD-WAN configuration changes.

Signal Usage Constraints

· Do not treat control-plane exposure, scanner output, advisory references, or CVE-string matches as primary detection signals.

· Do not treat UDP control-plane traffic or NETCONF access as malicious without source, identity, timing, topology, and configuration-change context.

· Do not treat normal SD-WAN peering, control-plane communication, NETCONF administration, or configuration activity as suspicious by itself.

· Do not assign high confidence to instability signals unless they align with suspicious access, peer-state change, authentication, NETCONF, or configuration activity.

· Do not assume unfamiliar cloud, VPN, service-provider, or managed-service traffic is benign without validating approved administrative paths.

· Do not assume suspicious control-plane activity must originate from the public internet.

· Do not rely on encrypted payload visibility as the primary validation method.

· Do not treat configuration changes as compromise indicators without actor, source, object, timing, peer-state, and change-authorization context.

· Do not treat persistence or expansion signals as applicable unless the required telemetry exists.

· Do not use actor-attribution language unless independent actor-specific evidence supports attribution.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

Endpoint and process execution telemetry should be treated as supporting context for CVE-2026-20182. The highest-value evidence will usually come from SD-WAN Controller logs, Manager logs, authentication records, NETCONF records, configuration audit sources, topology inventory, and network-flow metadata.

Where appliance, host, or managed-infrastructure telemetry is available, collection should prioritize activity that supports investigation of unauthorized administrative access, configuration manipulation, persistence, and post-access SD-WAN fabric impact.

· Administrative process execution associated with SD-WAN Controller or Manager systems.

· Command execution tied to SD-WAN administrative accounts or service accounts.

· Administrative shell activity on SD-WAN infrastructure where supported.

· Process activity related to configuration export, import, rollback, synchronization, or policy deployment.

· Process activity that aligns with suspicious authentication, NETCONF access, or configuration changes.

· Unusual use of native administrative utilities on SD-WAN infrastructure.

· Execution activity occurring outside approved maintenance, automation, service-provider, or emergency-access workflows.

· Process activity followed by SD-WAN configuration drift, peer-state changes, route changes, tunnel changes, or policy modification.

Memory and Execution Telemetry

Memory telemetry should not be required for production detection of this activity.

Detection should not depend on memory inspection, exploit payload recovery, or low-level runtime visibility. The durable detection surface is the operational behavior that follows control-plane trust abuse.

· Memory telemetry may provide supplemental investigative value if available.

· Memory telemetry should not be treated as a baseline requirement for detection viability.

· Execution telemetry should support administrative-access and configuration-change review where available.

· Detection logic should remain viable in environments where SD-WAN appliances do not provide memory-level visibility.

· Detection logic should prioritize peer-state, authentication, NETCONF, configuration, inventory, and network-flow evidence over memory artifacts.

· Absence of memory telemetry should not prevent investigation of suspicious SD-WAN peering, administrative access, or fabric modification.

Crash and Fault Telemetry

Crash and fault telemetry should be used to identify control-plane instability, abnormal negotiation behavior, service disruption, and timing relationships around suspicious access.

Crash or instability events should not be treated as exploitation evidence by themselves. They become more valuable when they align with unusual external access, rogue peering, administrative authentication, NETCONF activity, or configuration changes.

· SD-WAN control-plane service faults where available.

· SD-WAN Controller or Manager service restarts.

· Unexpected control-connection drops or resets.

· Sudden peer churn or repeated peer-state transitions.

· Abnormal control-plane negotiation failures.

· Controller instability outside approved maintenance windows.

· Device registration or peer-state errors near suspicious access attempts.

· Fault events followed by administrative authentication or NETCONF access.

· Fault events followed by route, tunnel, policy, certificate, peer-state, or fabric-trust changes.

· Monitoring gaps or telemetry interruptions that align with suspicious control-plane activity.

File and Persistence Telemetry

File and persistence telemetry should be collected where supportable, but it should not be assumed to be available in every SD-WAN deployment.

This telemetry is most valuable when it helps identify unauthorized administrative artifacts, persistent access, configuration drift, or changes that survive maintenance, restart, policy refresh, or configuration review.

· Authentication logs showing administrative-account access, source IP, authentication method, and outcome.

· Configuration files or configuration snapshots before and after suspicious access.

· Authorized-key, account, certificate, peer, or trust-artifact changes where visibility is available.

· SD-WAN policy, route, tunnel, device-registration, peer-state, and fabric-trust configuration changes.

· Configuration export, import, rollback, or synchronization activity.

· Unauthorized or unexpected administrative account changes.

· Persistent peer, device, certificate, or controller relationship artifacts.

· File or configuration changes that align with suspicious peering or NETCONF access.

· Configuration drift that cannot be tied to approved maintenance, automation, service-provider activity, or emergency access.

· Artifacts that remain active after patching, restart, rollback, or remediation activity.

Network and Outbound Communication Telemetry

Network telemetry is a high-value source for identifying suspicious control-plane access, NETCONF activity, source behavior, sequencing, and post-access fabric changes.

Network telemetry should be correlated with controller-side, authentication, inventory, and configuration-audit sources. Port activity alone should not be treated as confirmed exploitation.

· UDP control-plane traffic to Cisco SD-WAN Controller or Manager systems.

· TCP NETCONF traffic to SD-WAN management or control-plane infrastructure.

· Source IP, destination IP, port, protocol, timestamp, session duration, and connection volume.

· Newly observed sources communicating with SD-WAN control-plane or management-plane services.

· Traffic from geographies, ASNs, VPN providers, cloud providers, or managed-service paths not normally associated with SD-WAN administration.

· Control-plane access attempts outside approved administrative, service-provider, automation, or emergency-access paths.

· Network-flow sequences showing control-plane activity followed by NETCONF access.

· New or unexpected outbound connections from SD-WAN infrastructure after suspicious peering or administrative access.

· Traffic-flow changes following route, tunnel, policy, certificate, peer-state, or fabric-trust modification.

· New communication paths between SD-WAN-managed environments and sensitive internal segments.

· Repeated external access attempts that align with controller-side peer, authentication, or configuration events.

Web and Application Telemetry (Conditional Availability)

Web and application telemetry should be collected from SD-WAN Manager and related administrative interfaces when available.

This telemetry is most useful when it identifies administrative sessions, configuration changes, device-registration activity, policy changes, and user or automation context associated with suspicious control-plane behavior.

· SD-WAN Manager administrative session records.

· SD-WAN Manager audit logs.

· User, role, source IP, authentication method, and session outcome.

· API activity associated with SD-WAN administration or automation.

· Device registration, inventory, controller relationship, and peer-state changes.

· Policy, route, tunnel, certificate, peer-state, and fabric-trust changes.

· Configuration push, rollback, synchronization, or template activity.

· Failed-to-successful administrative access patterns.

· Administrative activity outside approved maintenance, automation, service-provider, or emergency-access workflows.

· Change activity that lacks corresponding approval, ticketing, or operational justification.

Telemetry Availability Requirements

Organizations should validate telemetry availability before promoting this detection model into high-severity alerting.

The required telemetry model should support correlation across SD-WAN control-plane activity, administrative authentication, NETCONF access, configuration changes, topology inventory, and network-flow evidence.

· SD-WAN Controller and Manager logs should be centrally collected or rapidly retrievable.

· Authentication logs should include username, source IP, timestamp, authentication method, and outcome.

· NETCONF telemetry should identify source, destination, timestamp, and session context where available.

· Network-flow telemetry should identify UDP control-plane and TCP NETCONF access to SD-WAN infrastructure.

· Configuration audit records should identify actor, source, object changed, change type, timestamp, and authorization context.

· Inventory data should identify approved Controllers, Managers, Validators, edge devices, System IPs, site IDs, domain IDs, peer types, public IPs, device identities, and controller relationships.

· Administrative-source baselines should identify approved VPN paths, service-provider paths, automation sources, emergency-access paths, and management networks.

· Change-management records should be available to validate planned maintenance, emergency activity, service-provider activity, and approved topology changes.

· Logging retention should support delayed discovery, repeated access review, configuration-drift investigation, and post-exploitation timeline reconstruction.

· SOC workflows should support correlation between network-flow, controller, authentication, NETCONF, configuration, and inventory sources.

Telemetry Limitations and Gaps

Telemetry limitations should be accounted for before assigning compromise-level severity.

Cisco SD-WAN control-plane abuse may appear as trusted peer or administrative behavior after successful exploitation. Detection therefore depends on strong baselines, controller-side visibility, authentication context, and configuration-change review.

· Encrypted control-plane traffic may limit packet-level inspection.

· SD-WAN appliance telemetry may vary by deployment model, version, hosting model, and management architecture.

· Some environments may not provide direct host-level, file-level, or memory-level visibility into SD-WAN infrastructure.

· Cloud-managed or provider-managed SD-WAN environments may require service-provider assistance for log access and investigation.

· NETCONF activity may be difficult to classify without source, identity, timing, peer-state, and configuration-change context.

· Network telemetry may identify suspicious access paths but may not confirm peer establishment or administrative success.

· Configuration audit visibility may be incomplete if logging is not centralized or retention is limited.

· Missing topology inventory can reduce confidence in identifying unauthorized peers or unexpected device identities.

· Legitimate maintenance, migration, disaster recovery, service-provider access, or emergency access may resemble suspicious control-plane behavior.

· Absence of a single telemetry source should not end investigation when other sources show suspicious peering, administrative authentication, NETCONF access, or SD-WAN fabric change.

S24 — Detection Opportunities and Gaps

Figure 4

Detection Opportunities

Detection opportunities for CVE-2026-20182 should focus on observable behavior created by unauthorized SD-WAN control-plane trust abuse rather than on CVE text, scanner output, or exploit-specific indicators.

The strongest opportunities come from correlating suspicious peering, administrative authentication, NETCONF access, configuration changes, topology mismatch, and post-access SD-WAN fabric impact.

· Unauthorized SD-WAN peering can be detected by comparing observed peer activity against approved topology, peer inventory, System IPs, site IDs, domain IDs, public IPs, device identities, and controller relationships.

· Rogue peer registration or peer-state changes can expose attempts to appear as trusted SD-WAN infrastructure.

· Administrative authentication from unfamiliar or unauthorized sources can identify activity that has moved beyond probing or exposure.

· NETCONF access following suspicious peering or administrative authentication can provide strong evidence of privileged SD-WAN management activity.

· SD-WAN configuration changes following anomalous control-plane activity can identify possible impact to routing, tunnels, policy, certificates, device registration, peer state, or fabric trust.

· Network-flow telemetry can identify suspicious sequencing between UDP control-plane activity, TCP NETCONF access, and post-access communication changes.

· Configuration audit logs can identify unauthorized or unexplained changes that affect SD-WAN fabric behavior.

· Historical configuration snapshots can expose fabric drift after suspicious access.

· Change-management, maintenance-window, emergency-access, and service-provider records can help separate authorized SD-WAN operations from suspicious activity.

· Inventory and topology baselines can increase confidence when unfamiliar peers, sources, or device identities appear in controller-side telemetry.

High-Value Detection Opportunities

· Suspicious peering followed by successful SD-WAN administrative authentication.

· Suspicious peering followed by NETCONF access.

· Suspicious peering followed by SD-WAN configuration changes.

· Unknown peer identity fields followed by route, tunnel, policy, certificate, device-registration, peer-state, or fabric-trust changes.

· Administrative authentication from unfamiliar sources followed by configuration export, import, rollback, synchronization, or policy deployment activity.

· Repeated control-plane access attempts followed by peer-state changes or authentication success.

· Control-plane instability followed by NETCONF access or configuration modification.

· Persistent or recurring access from unfamiliar sources after initial anomalous peering.

· SD-WAN configuration drift that does not align with approved maintenance, automation, service-provider activity, or emergency access.

· New traffic-flow patterns, access paths, or internal reachability changes following suspicious control-plane activity.

Detection Gaps

Detection gaps are most likely when organizations lack complete SD-WAN topology baselines, centralized controller logs, authentication records, NETCONF visibility, configuration audit history, or change-management context.

The largest detection risk is misclassifying attacker activity as normal SD-WAN control-plane behavior after an attacker obtains trusted peer positioning.

· Encrypted control-plane traffic may prevent payload-level inspection.

· Network telemetry may show access to SD-WAN services but may not confirm peer establishment, authentication success, or configuration impact.

· Some SD-WAN deployments may not provide direct host-level, file-level, memory-level, or appliance-level telemetry.

· Cloud-managed or provider-managed SD-WAN environments may limit direct access to controller, authentication, or configuration audit logs.

· Incomplete peer inventory may reduce confidence when identifying rogue peer activity.

· Incomplete administrative-source baselines may make it difficult to distinguish unauthorized access from service-provider, automation, VPN, or emergency-access activity.

· Limited NETCONF logging may reduce visibility into privileged management activity.

· Limited configuration audit retention may make it difficult to reconstruct fabric changes after suspicious access.

· Missing change-management linkage may create false positives during planned migrations, disaster recovery, emergency maintenance, or service-provider support.

· SD-WAN configuration changes may be difficult to classify without actor, source, object, timestamp, peer-state context, and authorization context.

· Post-access traffic changes may be difficult to attribute to malicious activity without configuration, routing, tunnel, or policy-change context.

· Absence of a single telemetry source may delay investigation if teams do not correlate across controller, authentication, configuration, inventory, and network-flow sources.

False Positive Considerations

Legitimate SD-WAN operations may resemble suspicious control-plane activity when viewed without topology, inventory, timing, or change-management context.

Common false-positive drivers include:

· Planned SD-WAN controller migration.

· Branch, data-center, cloud, or remote-site onboarding.

· Service-provider maintenance or troubleshooting.

· Managed-service administrative access.

· Disaster-recovery testing.

· Emergency access during outage response.

· Automation-driven configuration deployment.

· Certificate renewal or trust-store maintenance.

· Policy, route, tunnel, or template updates during approved change windows.

· Temporary peer churn during upgrades, patching, or network instability.

False Negative Considerations

False negatives are most likely when attacker activity blends into trusted SD-WAN control-plane behavior or when required telemetry is unavailable.

Common false-negative drivers include:

· Missing or incomplete SD-WAN Controller and Manager logs.

· Missing authentication source context.

· Missing NETCONF visibility.

· Missing configuration audit records.

· Incomplete topology or peer inventory.

· Incomplete administrative-source baselines.

· Insufficient logging retention.

· Lack of correlation between controller logs, network flows, authentication records, configuration changes, and change-management data.

· Overly broad suppression of cloud, VPN, managed-service, or service-provider traffic.

· Treating trusted peer behavior as benign without validating topology and authorization context.

· Assuming exploitation must originate from the public internet.

· Assuming encrypted control-plane traffic prevents meaningful detection.

Operational Gaps

Operational gaps can reduce detection effectiveness even when technical telemetry exists.

· SOC teams may not have direct access to SD-WAN topology inventory.

· SOC teams may not have rapid access to SD-WAN Manager audit logs or configuration history.

· Network, security, and service-provider teams may maintain separate records that are not easily correlated during investigation.

· Change-management records may not include enough detail to validate peer-state, routing, tunnel, certificate, or policy changes.

· Emergency-access procedures may not produce consistent approval or after-action records.

· Managed-service or provider-administered environments may require escalation outside normal SOC workflows.

· SD-WAN configuration backups may not be frequent enough to identify short-lived or rolled-back changes.

· Asset ownership may be unclear for externally reachable SD-WAN infrastructure.

· Teams may lack predefined investigation steps for suspicious SD-WAN peering, NETCONF access, or fabric-trust changes.

Detection Engineering Implications

Detection engineering should prioritize resilient behavioral correlation over isolated indicators.

Rules and analytic logic should identify suspicious control-plane trust activity and follow-on fabric-impact behavior while avoiding high-severity conclusions from weak single signals.

· Prioritize correlation between suspicious peering, administrative authentication, NETCONF access, and configuration changes.

· Use topology and inventory baselines to validate peer identity, source legitimacy, and controller relationships.

· Treat network-flow telemetry as supporting evidence unless paired with controller-side, authentication, or configuration-change records.

· Treat configuration changes as high value only when actor, source, object, timing, peer-state context, and authorization context can be assessed.

· Preserve investigation pathways when memory, file-level, or host-level telemetry is unavailable.

· Avoid overfitting to advisory text, scanner output, CVE strings, ports, or payload assumptions.

· Avoid suppressing unfamiliar peer or administrative activity solely because the source appears to be cloud, VPN, service-provider, or managed-service infrastructure.

· Maintain separate triage handling for exposure, suspicious control-plane behavior, and confirmed fabric-impact activity.

· Ensure detections can be tuned for legitimate maintenance, migration, disaster recovery, emergency access, automation, and provider-supported operations.

S25 Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

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

· NDR / Network Behavioral Analytics is viable for detecting suspicious SD-WAN control-plane access, NETCONF access, newly observed source behavior, peer-adjacent traffic patterns, and post-access traffic-flow changes affecting Cisco SD-WAN infrastructure.

· NDR / Network Behavioral Analytics is strongest where network-flow metadata, firewall telemetry, asset inventory, approved-peer baselines, administrative-source baselines, and SD-WAN Controller or Manager context can be correlated.

· NDR / Network Behavioral Analytics can identify suspicious sequencing between UDP control-plane activity, TCP NETCONF access, new source infrastructure, and follow-on communication changes.

· NDR / Network Behavioral Analytics is not a standalone source for confirming successful CVE-2026-20182 exploitation because encrypted control-plane traffic, trusted peer behavior, and limited payload visibility may prevent direct exploitation confirmation.

· NDR / Network Behavioral Analytics rules should be correlated with Cisco SD-WAN Controller logs, Manager logs, authentication records, NETCONF records, configuration audit logs, topology inventory, and change-management context before classifying activity as confirmed compromise.

· NDR / Network Behavioral Analytics detection content should be treated as high-value behavioral coverage for suspicious control-plane access and fabric-impact support, not direct exploit confirmation by itself.

Rule 1

Cisco SD-WAN Control-Plane Access From Unapproved or Newly Observed Source

Rule Format

NDR behavioral analytics rule suitable for network-flow, firewall, asset-inventory, topology, and approved-peer correlation after sensor coverage validation, SD-WAN asset tagging, control-plane service validation, source-baseline validation, and environment-specific tuning.

Detection Purpose

· Detect traffic to Cisco SD-WAN Controller or Manager control-plane services from sources that are unknown, newly observed, external, or not approved for SD-WAN peer communication.

· Identify possible precursor activity associated with unauthorized SD-WAN control-plane trust establishment.

· Prioritize activity involving unfamiliar source IPs, cloud infrastructure, VPN egress, hosting providers, unmanaged networks, unusual geographies, unusual ASNs, or sources not present in approved SD-WAN topology.

· Support investigation of exploited SD-WAN control-plane trust abuse without relying on CVE-string matches, scanner output, advisory references, payload visibility, or exploit-specific indicators.

· This rule does not prove successful rogue peering, administrative access, NETCONF use, or SD-WAN configuration manipulation without supporting controller-side, authentication, NETCONF, topology, or configuration-audit evidence.

Detection Logic

· Identify UDP control-plane traffic to Cisco SD-WAN Controller or Manager infrastructure from a source not present in approved SD-WAN peer inventories.

· Prioritize sources that are newly observed, external, associated with cloud or hosting infrastructure, associated with VPN egress, geographically unusual, ASN-unusual, or not linked to approved service-provider paths.

· Increase confidence when the source communicates with multiple SD-WAN Controller or Manager systems within the same operational window.

· Increase confidence when control-plane traffic is followed by TCP NETCONF access from the same source, related source, infrastructure cluster, ASN, cloud provider, VPN provider, or access path.

· Increase confidence when controller-side logs show unknown peer identity fields, peer-state changes, control-connection instability, or unexpected device-registration activity near the network event.

· Increase confidence when activity occurs outside approved maintenance, migration, disaster-recovery, service-provider, automation, or emergency-access windows.

· Reduce severity for approved peers, known controller relationships, expected edge-device communication, sanctioned service-provider access, planned topology changes, and documented maintenance activity.

· Do not classify UDP control-plane traffic as compromise without corroborating peer-state, authentication, NETCONF, configuration, topology, or change-management evidence.

Required Telemetry

· Network-flow telemetry.

· Firewall logs.

· NDR session metadata.

· Source IP.

· Destination IP.

· Destination port.

· Protocol.

· Timestamp.

· Session duration.

· Connection count.

· Directionality.

· Asset identity for Cisco SD-WAN Controller or Manager systems.

· Approved SD-WAN peer inventory.

· Approved System IP, site ID, domain ID, public IP, peer type, and device-identity context where available.

· Approved administrative and service-provider source networks.

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

· Maintenance-window and change-management context.

· Cisco SD-WAN Controller or Manager log correlation where available.

· Authentication, NETCONF, and configuration-audit correlation where available.

Engineering Implementation Instructions

· Build an asset group for Cisco SD-WAN Controller and Manager infrastructure.

· Validate the control-plane service ports used by the organization’s Cisco SD-WAN deployment before production deployment.

· Build and maintain allowlists for approved SD-WAN peers, controller relationships, service-provider paths, automation sources, emergency-access paths, and management networks.

· Add enrichment for source geography, ASN, cloud provider, hosting provider, VPN provider, and first-seen timestamp.

· Tune the rule to distinguish approved edge-device and controller-to-controller traffic from unknown or newly observed external sources.

· Correlate suspicious source activity with controller-side peer-state, control-connection, device-registration, authentication, NETCONF, and configuration events.

· Use shorter correlation windows for rapid source-to-NETCONF sequencing and longer windows for slow control-plane probing or repeated access attempts.

· Avoid broad suppression for cloud, VPN, managed-service, or service-provider infrastructure because attacker and legitimate administrative paths may overlap.

· Treat this rule as higher priority when the source also performs NETCONF access, repeated control-plane access, or traffic toward multiple SD-WAN management assets.

· Use change-management and maintenance records as triage evidence before classifying the event as suspicious or confirmed control-plane abuse.

DRI Assessment

DRI

8.0 / 10

· The rule is behaviorally anchored to unauthorized or newly observed access to SD-WAN control-plane services rather than static exploit indicators.

· The rule remains useful if exploit delivery changes but the attacker still needs to interact with SD-WAN control-plane infrastructure.

· The score is supported by the durability of source, destination, protocol, timing, asset, topology, and peer-inventory mismatch as observable network behaviors.

· The score is constrained by legitimate service-provider access, controller migration, disaster recovery, edge onboarding, cloud-hosted administration, and incomplete peer inventories.

TCR Assessment

Operational TCR

7.0 / 10

Full-Telemetry TCR

8.5 / 10

· Operational confidence depends on NDR sensor coverage, network-flow fidelity, accurate SD-WAN asset tagging, approved-peer inventory, administrative-source baselines, and maintenance-window context.

· Operational confidence is reduced where SD-WAN peer inventories are incomplete, service-provider access paths are poorly documented, or cloud and VPN egress overlap heavily with legitimate administration.

· Full-telemetry confidence improves when NDR events are enriched with Cisco SD-WAN Controller logs, Manager logs, authentication records, NETCONF records, configuration audit logs, and change-management context.

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

Limitations

· This rule detects suspicious control-plane access, not successful exploitation.

· Encrypted control-plane traffic may limit payload visibility and prevent direct inspection of authentication behavior.

· Legitimate SD-WAN operations, edge onboarding, controller migration, managed-service activity, and disaster-recovery testing may overlap with the same network patterns.

· The rule requires accurate SD-WAN asset inventory, approved-peer baselines, and administrative-source baselines to remain reliable.

· Confirmation requires correlation with peer-state changes, administrative authentication, NETCONF access, SD-WAN configuration changes, topology mismatch, or unauthorized fabric-impact activity.

Detection Query Pattern

NDR behavioral query pattern requiring platform syntax validation, SD-WAN asset tagging, approved-peer validation, service-port validation, source-enrichment validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NetworkEvent
WHERE DestinationAsset IN ASSET_GROUP(
"Cisco SD-WAN Controllers",
"Cisco SD-WAN Managers"
)
AND Protocol = "UDP"
AND DestinationPort IN ENV_CISCO_SDWAN_CONTROL_PLANE_PORTS
AND SourceIP NOT IN ASSET_GROUP(
"Approved SD-WAN Peers",
"Approved SD-WAN Controllers",
"Approved SD-WAN Edge Devices",
"Approved Service Provider SD-WAN Sources",
"Approved Automation Sources",
"Approved Emergency Access Sources"
)
AND (
SourceFirstSeen WITHIN ENV_NEW_SOURCE_WINDOW
OR SourceGeo NOT IN ENV_APPROVED_SDWAN_ADMIN_GEOS
OR SourceASN NOT IN ENV_APPROVED_SDWAN_ADMIN_ASNS
OR SourceProviderType IN ANY (
    "cloud_hosting",
    "vpn_provider",
    "hosting_provider",
    "unknown_external"
)
OR ConnectionCount >= ENV_SDWAN_CONTROL_PLANE_ATTEMPT_THRESHOLD
)
AND EVENT_NEAR WITHIN ENV_SDWAN_CORRELATION_WINDOW (
NetworkEvent.DestinationPort = 830
OR ControllerEvent.EventType IN ANY (
    "Unknown Peer Observed",
    "Peer State Changed",
    "Control Connection Anomaly",
    "Unexpected Device Registration",
    "Unexpected Peer Identity"
)
OR AuthEvent.EventType IN ANY (
    "Administrative Authentication Success",
    "Failed To Successful Administrative Authentication"
)
)
AND NOT ChangeContext IN ANY (
"approved_sdwan_maintenance",
"approved_controller_migration",
"approved_edge_onboarding",
"approved_disaster_recovery",
"approved_service_provider_activity",
"approved_emergency_access"
)

Rule 2

Control-Plane Activity Followed by NETCONF Access to Cisco SD-WAN Infrastructure

Rule Format

NDR behavioral correlation rule suitable for network-flow and session-sequence detection after SD-WAN asset tagging, NETCONF service validation, source-relationship validation, baseline validation, and environment-specific tuning.

Detection Purpose

· Detect suspicious sequencing where control-plane access to Cisco SD-WAN infrastructure is followed by NETCONF access from the same or related source.

· Identify behavior consistent with progression from control-plane interaction to privileged SD-WAN management activity.

· Prioritize sources that are unfamiliar, newly observed, external, unauthorized, or not aligned with approved administrative and automation paths.

· Support investigation of possible SD-WAN control-plane trust abuse without requiring encrypted payload visibility.

· This rule does not prove successful exploitation or configuration manipulation without supporting SD-WAN Controller, Manager, authentication, NETCONF, or configuration-audit evidence.

Detection Logic

· Identify UDP control-plane traffic to Cisco SD-WAN Controller or Manager systems followed by TCP NETCONF access to SD-WAN management or control-plane infrastructure.

· Correlate events by source IP, related source IP, subnet, ASN, cloud provider, VPN provider, service-provider path, or infrastructure cluster.

· Prioritize activity where the source is not part of approved peer inventories, approved NETCONF source lists, administrative VPN paths, service-provider paths, automation sources, or emergency-access paths.

· Increase confidence when the source is newly observed or when the source accesses multiple SD-WAN Controller, Manager, or NETCONF destinations.

· Increase confidence when the sequence occurs near peer-state changes, control-connection instability, administrative authentication success, or configuration-audit activity.

· Increase confidence when activity occurs outside approved maintenance windows or lacks change-management justification.

· Reduce severity for approved automation, approved NETCONF management workflows, service-provider maintenance, planned migration, and documented emergency access.

· Do not classify NETCONF access as malicious without source, identity, timing, peer-state, topology, and configuration-change context.

Required Telemetry

· Network-flow telemetry.

· NDR session metadata.

· Firewall logs where available.

· Source IP.

· Destination IP.

· Destination port.

· Protocol.

· Timestamp.

· Session duration.

· Session count.

· Asset identity for Cisco SD-WAN Controller and Manager systems.

· Asset identity for NETCONF-exposed SD-WAN infrastructure.

· Approved NETCONF source lists.

· Approved SD-WAN administrative source networks.

· Approved peer and controller inventories.

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

· Cisco SD-WAN Controller or Manager peer-state correlation where available.

· Authentication and configuration-audit correlation where available.

· Maintenance-window, automation, service-provider, and change-management context.

Engineering Implementation Instructions

· Build asset groups for Cisco SD-WAN Controller, Manager, and NETCONF-exposed SD-WAN infrastructure.

· Validate the organization’s NETCONF exposure and expected NETCONF source networks before enabling high-severity alerting.

· Correlate UDP control-plane activity and TCP NETCONF access by source, related source, source subnet, infrastructure cluster, ASN, VPN provider, cloud provider, or service-provider path.

· Tune correlation windows based on normal SD-WAN control-plane and NETCONF administrative workflows.

· Add allowlists for approved automation systems, administrative jump hosts, service-provider sources, emergency-access paths, and planned maintenance workflows.

· Avoid suppressing all NETCONF activity from broad infrastructure categories because both legitimate administrators and attackers may use cloud, VPN, or provider egress.

· Increase severity when NETCONF access follows unknown peer activity, peer-state changes, administrative authentication, or configuration modifications.

· Use Cisco SD-WAN Controller logs, Manager logs, authentication records, NETCONF records, and configuration audit logs to determine whether the sequence indicates suspicious activity or authorized administration.

DRI Assessment

DRI

8.5 / 10

· The rule is behaviorally anchored to a durable sequence: control-plane access followed by NETCONF access.

· The rule remains useful if the exploit implementation changes but the attacker still proceeds from SD-WAN control-plane interaction to privileged management activity.

· The score is supported by the operational significance of NETCONF access following suspicious control-plane behavior.

· The score is constrained by legitimate automation, service-provider maintenance, emergency access, and environments where NETCONF is routinely used for authorized administration.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

· Operational confidence depends on network-flow fidelity, SD-WAN asset tagging, NETCONF source baselines, correlation timing, and approved administrative workflow documentation.

· Operational confidence is reduced where NETCONF source lists are incomplete, automation paths are poorly documented, or SD-WAN management traffic is not consistently visible to NDR sensors.

· Full-telemetry confidence improves when network sequencing is correlated with peer-state changes, authentication success, NETCONF records, configuration audit logs, and change-management context.

· Under full telemetry conditions, this rule can provide strong evidence of suspicious SD-WAN management activity, but confirmed exploitation still requires Cisco SD-WAN telemetry or configuration-impact evidence.

Limitations

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

· NETCONF may be legitimate in environments with approved automation, service-provider management, or administrative workflows.

· Encrypted traffic and limited session metadata may restrict insight into command content or configuration intent.

· Related-source correlation may be imperfect when attackers rotate infrastructure or use shared cloud, VPN, or provider egress.

· Confirmation requires correlation with peer-state anomalies, administrative authentication, configuration changes, unauthorized source context, or topology mismatch.

Detection Query Pattern

NDR behavioral query pattern requiring platform syntax validation, SD-WAN asset tagging, NETCONF-source validation, related-source correlation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NetworkEvent AS ControlPlaneEvent
WHERE ControlPlaneEvent.DestinationAsset IN ASSET_GROUP(
"Cisco SD-WAN Controllers",
"Cisco SD-WAN Managers"
)
AND ControlPlaneEvent.Protocol = "UDP"
AND ControlPlaneEvent.DestinationPort IN ENV_CISCO_SDWAN_CONTROL_PLANE_PORTS
AND ControlPlaneEvent.SourceIP NOT IN ASSET_GROUP(
"Approved SD-WAN Peers",
"Approved SD-WAN Controllers",
"Approved SD-WAN Edge Devices",
"Approved Service Provider SD-WAN Sources"
)
AND EVENT_NEAR WITHIN ENV_SDWAN_NETCONF_SEQUENCE_WINDOW (
NetworkEvent AS NetconfEvent
WHERE NetconfEvent.Protocol = "TCP"
AND NetconfEvent.DestinationPort = 830
AND NetconfEvent.DestinationAsset IN ASSET_GROUP(
    "Cisco SD-WAN Controllers",
    "Cisco SD-WAN Managers",
    "NETCONF Exposed SD-WAN Infrastructure"
)
AND RELATED_SOURCE(
    ControlPlaneEvent.SourceIP,
    NetconfEvent.SourceIP,
    "same_ip",
    "same_subnet",
    "same_asn",
    "same_cloud_provider",
    "same_vpn_provider",
    "same_infrastructure_cluster"
)
AND NetconfEvent.SourceIP NOT IN ASSET_GROUP(
    "Approved NETCONF Sources",
    "Approved SD-WAN Admin Sources",
    "Approved Automation Sources",
    "Approved Service Provider Sources",
    "Approved Emergency Access Sources"
)
)
AND (
ControlPlaneEvent.SourceFirstSeen WITHIN ENV_NEW_SOURCE_WINDOW
OR ControlPlaneEvent.ConnectionCount >= ENV_SDWAN_CONTROL_PLANE_ATTEMPT_THRESHOLD
OR NetconfEvent.ConnectionCount >= ENV_NETCONF_ATTEMPT_THRESHOLD
OR SourceProviderType IN ANY (
    "cloud_hosting",
    "vpn_provider",
    "hosting_provider",
    "unknown_external"
)
)
AND NOT ChangeContext IN ANY (
"approved_sdwan_maintenance",
"approved_netconf_automation",
"approved_service_provider_activity",
"approved_emergency_access",
"approved_controller_migration"
)

Rule 3

Suspicious SD-WAN Traffic-Flow Change After Control-Plane or NETCONF Activity

Rule Format

NDR behavioral analytics and traffic-change correlation rule suitable for network-flow baselining, SD-WAN asset tagging, route or tunnel-impact inference, and post-access communication monitoring after baseline validation, topology validation, and environment-specific tuning.

Detection Purpose

· Detect new or unusual traffic-flow behavior after suspicious SD-WAN control-plane or NETCONF activity.

· Identify possible SD-WAN fabric-impact behavior, including new access paths, traffic redirection, unexpected internal reachability, or communication with unfamiliar external infrastructure.

· Prioritize activity where suspicious control-plane or NETCONF activity is followed by new flows involving sensitive internal segments, management systems, cloud networks, branch environments, data-center systems, or remote-site infrastructure.

· Support investigation of post-access impact without assuming that network telemetry alone can confirm configuration manipulation.

· This rule does not prove successful SD-WAN compromise without supporting configuration audit, controller-side, authentication, NETCONF, or change-management evidence.

Detection Logic

· Identify suspicious control-plane or NETCONF activity involving Cisco SD-WAN infrastructure.

· Detect new or unusual traffic flows after the suspicious access window.

· Prioritize flows involving sensitive internal segments, identity systems, management systems, monitoring systems, backup systems, hypervisor systems, network-administration systems, data-center systems, cloud networks, branch environments, or remote-site infrastructure.

· Increase confidence when traffic-flow changes involve unfamiliar peers, new public IPs, new controller relationships, newly reachable destinations, or previously unseen source-to-destination pairs.

· Increase confidence when flow changes occur after route, tunnel, policy, certificate, peer-state, or fabric-trust changes observed in SD-WAN Controller or Manager logs.

· Increase confidence when new access paths persist across multiple sessions or recur after remediation, rollback, patching, or maintenance.

· Reduce severity for approved routing changes, tunnel changes, policy deployments, migrations, disaster-recovery testing, service-provider maintenance, and documented network changes.

· Do not classify post-access traffic-flow change as compromise without correlating source, timing, topology, authorization context, and configuration-change evidence.

Required Telemetry

· Network-flow telemetry.

· NDR behavioral baselines.

· Firewall logs where available.

· Source IP.

· Destination IP.

· Destination port.

· Protocol.

· Timestamp.

· Session duration.

· Connection count.

· First-seen source-to-destination pair.

· Asset identity and asset criticality.

· Sensitive segment tags.

· SD-WAN Controller and Manager asset tags.

· Approved SD-WAN peer and controller relationship inventory.

· Approved route, tunnel, policy, and fabric-change context where available.

· Configuration audit correlation where available.

· Change-management and maintenance-window context.

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

· Post-remediation and rollback timing context where available.

Engineering Implementation Instructions

· Build asset groups for Cisco SD-WAN infrastructure, sensitive internal segments, identity systems, management systems, backup systems, hypervisor systems, network-administration systems, data-center environments, branch environments, cloud environments, and remote-site infrastructure.

· Establish baselines for normal SD-WAN-related traffic flows, expected branch-to-data-center communication, expected cloud connectivity, expected management access, and expected route or tunnel-driven traffic patterns.

· Correlate suspicious control-plane or NETCONF activity with subsequent first-seen or abnormal source-to-destination flows.

· Tune timing windows to account for immediate configuration impact and delayed traffic-flow changes after policy deployment or route propagation.

· Add allowlists for approved network changes, route deployments, tunnel deployments, policy pushes, migrations, disaster-recovery tests, service-provider maintenance, and emergency changes.

· Avoid broad suppression of new flows from SD-WAN environments because fabric compromise may create traffic that resembles legitimate route or policy changes.

· Increase severity when new traffic flows target sensitive internal services or create new reachability between previously unrelated environments.

· Use SD-WAN configuration audit logs and change-management records to determine whether the traffic change was authorized.

· Map abstract enrichment concepts such as peer context, site context, and fabric context to platform-specific fields before production use.

DRI Assessment

DRI

7.5 / 10

· The rule is behaviorally anchored to post-access traffic-flow changes that may follow SD-WAN control-plane trust abuse.

· The rule remains useful if the exploit implementation changes but the attacker uses SD-WAN fabric control to create new access paths or alter routing behavior.

· The score is supported by the durability of traffic-flow changes, new reachability, and sensitive-segment access as observable network outcomes.

· The score is constrained by legitimate network changes, route updates, tunnel adjustments, cloud connectivity changes, disaster-recovery testing, and incomplete flow baselines.

TCR Assessment

Operational TCR

6.5 / 10

Full-Telemetry TCR

8.5 / 10

· Operational confidence depends on flow coverage, sensitive-asset tagging, SD-WAN topology baselines, route and tunnel baselines, change-management linkage, and correlation with suspicious control-plane or NETCONF activity.

· Operational confidence is reduced where SD-WAN flow baselines are immature, sensitive-segment tagging is incomplete, or legitimate routing and policy changes are frequent.

· Full-telemetry confidence improves when traffic-flow changes are correlated with SD-WAN configuration audit logs, peer-state changes, authentication records, NETCONF activity, route changes, tunnel changes, policy changes, and change-management context.

· Even under full telemetry conditions, traffic-flow change should be treated as impact-supporting evidence rather than standalone proof of exploitation.

Limitations

· This rule detects suspicious post-access traffic-flow changes, not exploit execution.

· Legitimate route, tunnel, policy, migration, service-provider, disaster-recovery, and emergency network changes may overlap with the same behavior.

· NDR may not directly observe SD-WAN configuration intent or peer-state context.

· Incomplete sensitive-asset tagging or weak flow baselines may reduce confidence.

· Confirmation requires correlation with suspicious control-plane activity, NETCONF access, SD-WAN configuration changes, topology mismatch, or unauthorized change context.

Detection Query Pattern

NDR behavioral query pattern requiring platform syntax validation, SD-WAN asset tagging, sensitive-segment tagging, flow-baseline validation, change-context validation, timing-window tuning, and environment-specific allowlisting before production deployment.

NetworkEvent AS AccessEvent
WHERE AccessEvent.DestinationAsset IN ASSET_GROUP(
"Cisco SD-WAN Controllers",
"Cisco SD-WAN Managers",
"NETCONF Exposed SD-WAN Infrastructure"
)
AND (
(
    AccessEvent.Protocol = "UDP"
    AND AccessEvent.DestinationPort IN ENV_CISCO_SDWAN_CONTROL_PLANE_PORTS
)
OR (
    AccessEvent.Protocol = "TCP"
    AND AccessEvent.DestinationPort = 830
)
)
AND AccessEvent.SourceIP NOT IN ASSET_GROUP(
"Approved SD-WAN Peers",
"Approved SD-WAN Admin Sources",
"Approved NETCONF Sources",
"Approved Automation Sources",
"Approved Service Provider Sources",
"Approved Emergency Access Sources"
)
AND EVENT_AFTER WITHIN ENV_SDWAN_POST_ACCESS_WINDOW (
NetworkEvent AS PostAccessFlow
WHERE PostAccessFlow.IsFirstSeenFlow = true
OR PostAccessFlow.BaselineDeviation >= ENV_SDWAN_FLOW_DEVIATION_THRESHOLD
OR PostAccessFlow.DestinationAsset IN ASSET_GROUP(
    "Identity Systems",
    "Management Systems",
    "Monitoring Systems",
    "Backup Systems",
    "Hypervisor Systems",
    "Network Administration Systems",
    "Sensitive Internal Segments",
    "Critical Data Center Systems",
    "Critical Cloud Systems"
)
OR PostAccessFlow.SourceToDestinationPair NOT IN BASELINE(
    "Approved SD-WAN Traffic Flows"
)
)
AND (
RELATED_SOURCE(
    AccessEvent.SourceIP,
    PostAccessFlow.SourceIP,
    "same_ip",
    "same_subnet",
    "same_sdwan_peer_context",
    "same_site_context",
    "same_fabric_context"
)
OR PostAccessFlow.SourceAsset IN ASSET_GROUP(
    "Cisco SD-WAN Managed Branches",
    "Cisco SD-WAN Managed Data Centers",
    "Cisco SD-WAN Managed Cloud Segments",
    "Cisco SD-WAN Managed Remote Sites"
)
)
AND NOT ChangeContext IN ANY (
"approved_route_change",
"approved_tunnel_change",
"approved_policy_deployment",
"approved_controller_migration",
"approved_disaster_recovery_test",
"approved_service_provider_activity",
"approved_emergency_change"
)

SentinelOne

Detection Viability Assessment

SentinelOne has three rules for this EXP report.

· SentinelOne is viable where Cisco SD-WAN Controller, Manager, or supporting infrastructure is deployed on monitored hosts, cloud workloads, virtual appliances, or adjacent management systems with endpoint or workload telemetry available.

· SentinelOne is strongest where process execution, command-line capture, process ancestry, file activity, account activity, network connection telemetry, endpoint identity, workload tags, and administrative-session context can be correlated.

· SentinelOne can support detection of suspicious administrative activity, unauthorized key or account artifacts, configuration export or manipulation behavior, and post-access persistence-adjacent activity on monitored SD-WAN infrastructure.

· SentinelOne is not a standalone source for confirming successful CVE-2026-20182 exploitation because the core behavior may occur through SD-WAN control-plane peering, NETCONF access, and controller-side configuration changes that may not always produce endpoint-level artifacts.

· SentinelOne rules should be correlated with Cisco SD-WAN Controller logs, Manager logs, authentication records, NETCONF records, configuration audit logs, topology inventory, network-flow telemetry, and change-management context before classifying activity as confirmed compromise.

· SentinelOne detection content should be treated as high-value workload and endpoint behavioral coverage, not direct exploit confirmation by itself.

Rule 1

Suspicious Administrative Shell or Process Activity on Cisco SD-WAN Infrastructure

Rule Format

SentinelOne Deep Visibility query pattern suitable for STAR-style alerting after tenant syntax validation, field validation, SD-WAN workload tagging, administrative-tool baselining, approved-management-channel validation, and environment-specific tuning.

Detection Purpose

Detect suspicious administrative shell, process, or command activity on monitored Cisco SD-WAN Controller, Manager, or supporting infrastructure.

· Identify activity that may follow unauthorized SD-WAN control-plane trust establishment, suspicious administrative authentication, or NETCONF access.

· Prioritize activity involving unfamiliar users, unusual parent processes, interactive shells, remote sessions, temporary paths, user-writable paths, configuration directories, or unapproved administrative channels.

· Support investigation of post-access SD-WAN administrative behavior without relying on CVE-string matches, scanner output, advisory references, payload artifacts, or exploit branding.

· This rule does not prove successful SD-WAN exploitation, rogue peering, NETCONF misuse, or configuration manipulation without supporting controller-side, authentication, NETCONF, configuration-audit, topology, or network-flow evidence.

Detection Logic

Identify administrative shell or process execution on monitored Cisco SD-WAN Controller, Manager, or supporting infrastructure.

· Prioritize commands associated with configuration review, configuration export, configuration import, service manipulation, account review, authorized-key access, certificate handling, network inspection, or administrative file access.

· Increase confidence when execution occurs from unusual users, unusual parent processes, remote sessions, temporary paths, user-writable paths, or nonstandard administrative channels.

· Increase confidence when the same host or workload also shows suspicious network connections, NETCONF activity, controller-side peer anomalies, administrative authentication anomalies, or configuration audit events.

· Increase confidence when execution occurs outside approved maintenance, service-provider, automation, emergency-access, or change-management windows.

· Reduce severity for approved automation, documented service-provider activity, controller maintenance, planned migration, patching, backup operations, and authorized administrative runbooks.

· Do not classify administrative shell or process activity as compromise without corroborating SD-WAN control-plane, authentication, NETCONF, configuration, topology, or network-flow evidence.

Required Telemetry

SentinelOne process creation telemetry.

· Full command-line capture.

· Process ancestry.

· Source process name.

· Source process path.

· Parent process name.

· Parent process path.

· User and administrative context.

· Logon session context where available.

· Endpoint or workload identity.

· Endpoint or workload role tag.

· Operating system.

· File activity near the process event where available.

· Network connection telemetry where available.

· Endpoint agent status and heartbeat where available.

· SD-WAN Controller or Manager asset tagging.

· Approved administrative workflow context.

· Maintenance-window and change-management context.

· Timestamp.

Engineering Implementation Instructions

Validate SentinelOne tenant syntax and tenant field names for process event type, source process, target process, command line, user, parent process, endpoint identity, workload tag, network connection context, and timestamp before deployment.

· Scope the rule to monitored Cisco SD-WAN Controller, Manager, and supporting management infrastructure where SentinelOne telemetry is available.

· Tag SD-WAN workloads and supporting infrastructure separately from general servers to prevent broad alerting.

· Baseline approved administrative tools, service-provider access, automation tasks, backup workflows, patching activity, controller maintenance, and emergency-access procedures.

· Add allowlists for approved automation accounts, service-provider runbooks, maintenance scripts, backup utilities, monitoring tools, patching workflows, and sanctioned administrative paths.

· Avoid allowlisting broad shell, service, or account-management activity that could suppress suspicious use of the same utilities outside approved workflows.

· Treat activity as higher priority when paired with suspicious SD-WAN peering, administrative authentication, NETCONF access, configuration change, unauthorized key changes, or unusual outbound connections.

· Use Cisco SD-WAN Controller logs, Manager logs, authentication records, NETCONF records, configuration audit logs, and NDR telemetry as triage evidence before classifying the case as confirmed SD-WAN compromise.

DRI Assessment

DRI

7.5 / 10

· The rule is behaviorally anchored to suspicious administrative activity on monitored SD-WAN infrastructure rather than static exploit indicators.

· The rule remains useful if the exploit implementation changes but attacker activity still produces administrative shell, process, service, account, or configuration-adjacent behavior on monitored infrastructure.

· The score is supported by the durability of process lineage, command-line, administrative context, and workload-role anomalies as observable endpoint behaviors.

· The score is constrained by legitimate maintenance, service-provider activity, automation, backup workflows, patching, controller migration, and inconsistent host-level telemetry on SD-WAN appliances.

TCR Assessment

Operational TCR

6.5 / 10

Full-Telemetry TCR

8.0 / 10

· Operational confidence depends on SentinelOne coverage for SD-WAN infrastructure, command-line capture, process lineage, workload tagging, approved administrative baselines, and maintenance-window context.

· Operational confidence is reduced where SD-WAN infrastructure is appliance-locked, provider-managed, cloud-managed, or not instrumented with SentinelOne.

· Full-telemetry confidence improves when SentinelOne events are enriched with Cisco SD-WAN Controller logs, Manager logs, authentication records, NETCONF records, configuration audit logs, NDR telemetry, and change-management context.

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

Limitations

This rule detects suspicious administrative process behavior on monitored infrastructure, not successful exploitation.

· SentinelOne may not observe activity occurring entirely within SD-WAN control-plane logic, provider-managed infrastructure, encrypted peering flows, or systems where the agent is not deployed.

· Legitimate controller maintenance, service-provider support, automation, backup activity, patching, migration, and emergency administration may overlap with this behavior.

· The rule requires accurate SD-WAN asset tagging, process lineage, command-line capture, and administrative workflow baselines to remain reliable.

· Confirmation requires correlation with SD-WAN peer-state anomalies, administrative authentication, NETCONF access, configuration changes, topology mismatch, or network-flow evidence.

Detection Query Pattern

SentinelOne Deep Visibility query pattern requiring tenant syntax validation, SD-WAN workload tagging, administrative-tool validation, workflow allowlisting, timing-window validation, and environment-specific tuning before production deployment.

EndpointOS IN ANY (
"linux",
"windows"
)
AND EventType IN ANY (
"Process Creation",
"Process Execution"
)
AND AgentComputerName IN ASSET_GROUP (
"Cisco SD-WAN Controllers",
"Cisco SD-WAN Managers",
"Cisco SD-WAN Supporting Infrastructure",
"NETCONF Exposed SD-WAN Infrastructure"
)
AND (
SrcProcName IN ANY (
    "bash",
    "sh",
    "zsh",
    "dash",
    "sudo",
    "su",
    "ssh",
    "scp",
    "sftp",
    "python",
    "python3",
    "perl",
    "curl",
    "wget",
    "openssl",
    "systemctl",
    "service",
    "journalctl",
    "netstat",
    "ss",
    "ip",
    "ifconfig",
    "tcpdump",
    "vi",
    "vim",
    "nano",
    "cat",
    "cp",
    "mv",
    "chmod",
    "chown",
    "tar",
    "gzip"
)
OR SrcProcCmdLine CONTAINS ANY (
    "netconf",
    "sdwan",
    "vmanage",
    "configuration",
    "config",
    "certificate",
    "authorized_keys",
    ".ssh",
    "systemctl",
    "service",
    "journalctl",
    "tcpdump",
    "route",
    "policy",
    "tunnel",
    "peer",
    "controller"
)
)
AND (
SrcProcParentName IN ANY (
    "bash",
    "sh",
    "zsh",
    "dash",
    "sudo",
    "su",
    "ssh",
    "python",
    "python3",
    "cron",
    "systemd"
)
OR SrcProcCmdLine CONTAINS ANY (
    "/tmp/",
    "/var/tmp/",
    "/dev/shm/",
    "/home/",
    "/root/",
    "curl ",
    "wget ",
    "chmod +x",
    "authorized_keys",
    ".ssh/"
)
OR UserName NOT IN ASSET_GROUP (
    "Approved SD-WAN Administrators",
    "Approved SD-WAN Automation Accounts",
    "Approved Service Provider Accounts"
)
)
AND EVENT_NEAR WITHIN ENV_SDWAN_ENDPOINT_CORRELATION_WINDOW (
NetworkEvent.DstPort = 830
OR NetworkEvent.DstPort IN ENV_CISCO_SDWAN_CONTROL_PLANE_PORTS
OR FileEvent.TgtFilePath CONTAINS ANY (
    ".ssh",
    "authorized_keys",
    "certificate",
    "config",
    "backup",
    "policy",
    "template"
)
OR AuthEvent.EventType IN ANY (
    "Administrative Authentication Success",
    "Failed To Successful Administrative Authentication"
)
)
AND NOT ApprovedWorkflowContext IN ANY (
"approved_sdwan_maintenance",
"approved_backup_workflow",
"approved_patch_workflow",
"approved_controller_migration",
"approved_service_provider_activity",
"approved_automation_workflow",
"approved_emergency_access"
)

Rule 2

Unauthorized Key, Account, Certificate, or Configuration Artifact Activity on SD-WAN Infrastructure

Rule Format

SentinelOne Deep Visibility query pattern suitable for file, account, process, and configuration-adjacent activity correlation after tenant syntax validation, SD-WAN asset tagging, file-path validation, approved-workflow validation, and environment-specific tuning.

Detection Purpose

Detect unauthorized key, account, certificate, peer, or configuration artifact activity on monitored Cisco SD-WAN infrastructure.

· Identify persistence-adjacent or access-preservation behavior that may follow suspicious SD-WAN control-plane activity.

· Prioritize changes involving administrative keys, service accounts, certificates, configuration files, backup files, peer-related files, or controller relationship artifacts.

· Support investigation of post-access persistence and configuration drift without relying on exploit-specific files, payload hashes, public proof-of-concept artifacts, or CVE-string matches.

· This rule does not prove successful exploitation or persistent compromise without supporting authentication, controller-side, NETCONF, configuration-audit, topology, or network-flow evidence.

Detection Logic

Identify file creation, file modification, file rename, file deletion, account activity, or process activity affecting administrative key, account, certificate, or configuration-adjacent paths on monitored SD-WAN infrastructure.

· Prioritize activity involving .ssh, authorized_keys, certificate stores, configuration backups, policy files, template files, controller relationship artifacts, or service-account material.

· Increase confidence when activity is performed by unusual users, unusual parent processes, interactive shells, remote sessions, temporary paths, or nonstandard administrative channels.

· Increase confidence when artifact activity occurs near suspicious administrative authentication, NETCONF access, controller-side peer anomalies, or SD-WAN configuration changes.

· Increase confidence when changes persist after restart, policy refresh, rollback, patching, or remediation activity.

· Reduce severity for approved certificate renewal, backup workflows, configuration export, controller maintenance, service-provider activity, automation, and documented emergency access.

· Do not classify key, account, certificate, or configuration artifact activity as compromise without corroborating authentication, NETCONF, controller, configuration, topology, or network evidence.

Required Telemetry

SentinelOne file creation telemetry.

· SentinelOne file modification telemetry.

· File rename and file deletion telemetry where available.

· Process creation telemetry.

· Process ancestry.

· Source process name.

· Source process path.

· Source process command line.

· Parent process name.

· Parent process path.

· Target file path.

· Target file hash where available.

· User and administrative context.

· Account activity where available.

· Endpoint or workload identity.

· Endpoint or workload role tag.

· SD-WAN Controller or Manager asset tagging.

· Network connection telemetry where available.

· Agent heartbeat and endpoint availability telemetry where available.

· Maintenance-window and change-management context.

· Timestamp.

Engineering Implementation Instructions

Validate SentinelOne tenant syntax and tenant field names for file events, account events, source process, command line, target file path, user, endpoint identity, workload tag, network connection context, and timestamp before deployment.

· Validate how monitored SD-WAN infrastructure exposes administrative key paths, certificate paths, configuration paths, backup paths, and service-account activity.

· Scope the rule to Cisco SD-WAN Controller, Manager, and supporting management infrastructure where SentinelOne telemetry is available.

· Add allowlists for approved certificate renewal, backup workflows, configuration export, controller maintenance, patching, automation tasks, service-provider workflows, and emergency-access activity.

· Avoid suppressing broad key, certificate, or configuration paths because those same locations may be modified during suspicious post-access activity.

· Tune correlation windows around suspicious authentication, NETCONF access, peer-state change, configuration modification, restart, rollback, and remediation events.

· Treat activity as higher priority when paired with suspicious SD-WAN peering, unknown administrative source, NETCONF access, unauthorized configuration change, or recurring access from unfamiliar infrastructure.

· Use Cisco SD-WAN Controller logs, Manager logs, authentication records, NETCONF records, configuration audit logs, topology inventory, and NDR telemetry as triage evidence before classifying the case as confirmed persistence or compromise.

DRI Assessment

DRI

8.0 / 10

· The rule is behaviorally anchored to durable access-preservation and configuration-adjacent artifacts rather than exploit-specific payloads.

· The rule remains useful if attackers change the initial exploit path but still attempt to preserve access, alter trust, modify configuration, or maintain administrative reachability.

· The score is supported by the durability of administrative key, account, certificate, and configuration artifact changes as post-access behaviors.

· The score is constrained by legitimate certificate renewal, backup workflows, configuration export, service-provider maintenance, automation, patching, and inconsistent file visibility on SD-WAN infrastructure.

TCR Assessment

Operational TCR

6.5 / 10

Full-Telemetry TCR

8.5 / 10

· Operational confidence depends on file-event visibility, account-event visibility, process lineage, SD-WAN workload tagging, administrative workflow baselines, and path validation.

· Operational confidence is reduced where SD-WAN infrastructure is appliance-locked, provider-managed, cloud-managed, or does not expose file-level telemetry to SentinelOne.

· Full-telemetry confidence improves when file and account activity is correlated with controller logs, authentication records, NETCONF access, configuration audit logs, NDR telemetry, and change-management records.

· Even under full telemetry conditions, artifact changes should be treated as suspicious behavior requiring correlation rather than standalone confirmation of exploitation.

Limitations

This rule detects suspicious artifact activity, not successful exploitation by itself.

· Legitimate certificate renewal, backup activity, configuration export, controller maintenance, service-provider activity, and automation may overlap with this behavior.

· SentinelOne may not observe artifact activity on appliance-locked, provider-managed, or uninstrumented SD-WAN infrastructure.

· File path conventions may vary across versions, deployment models, and hosting architectures.

· Confirmation requires correlation with suspicious peering, administrative authentication, NETCONF access, configuration changes, topology mismatch, or unauthorized source context.

Detection Query Pattern

SentinelOne Deep Visibility query pattern requiring tenant syntax validation, SD-WAN asset tagging, file-path validation, account-event validation, approved workflow allowlisting, and timing-window tuning before production deployment.

EndpointOS IN ANY (
"linux",
"windows"
)
AND EventType IN ANY (
"File Creation",
"File Modification",
"File Rename",
"File Deletion",
"Process Creation",
"Account Modified",
"Account Created"
)
AND AgentComputerName IN ASSET_GROUP (
"Cisco SD-WAN Controllers",
"Cisco SD-WAN Managers",
"Cisco SD-WAN Supporting Infrastructure",
"NETCONF Exposed SD-WAN Infrastructure"
)
AND (
TgtFilePath CONTAINS ANY (
    ".ssh",
    "authorized_keys",
    "id_rsa",
    "id_ed25519",
    "certificate",
    "cert",
    "key",
    "config",
    "configuration",
    "backup",
    "template",
    "policy",
    "route",
    "tunnel",
    "peer",
    "controller"
)
OR SrcProcCmdLine CONTAINS ANY (
    "authorized_keys",
    ".ssh",
    "certificate",
    "cert",
    "key",
    "config",
    "backup",
    "template",
    "policy",
    "route",
    "tunnel",
    "peer",
    "controller",
    "useradd",
    "usermod",
    "passwd",
    "chmod",
    "chown"
)
)
AND (
SrcProcParentName IN ANY (
    "bash",
    "sh",
    "zsh",
    "dash",
    "sudo",
    "su",
    "ssh",
    "python",
    "python3",
    "cron",
    "systemd"
)
OR SrcProcCmdLine CONTAINS ANY (
    "/tmp/",
    "/var/tmp/",
    "/dev/shm/",
    "/home/",
    "/root/",
    "chmod",
    "chown",
    "echo ",
    "cat ",
    "cp ",
    "mv "
)
OR UserName NOT IN ASSET_GROUP (
    "Approved SD-WAN Administrators",
    "Approved SD-WAN Automation Accounts",
    "Approved Service Provider Accounts"
)
)
AND EVENT_NEAR WITHIN ENV_SDWAN_PERSISTENCE_CORRELATION_WINDOW (
NetworkEvent.DstPort = 830
OR NetworkEvent.DstPort IN ENV_CISCO_SDWAN_CONTROL_PLANE_PORTS
OR AuthEvent.EventType IN ANY (
    "Administrative Authentication Success",
    "Failed To Successful Administrative Authentication"
)
OR ProcessEvent.SrcProcCmdLine CONTAINS ANY (
    "config",
    "backup",
    "template",
    "policy",
    "route",
    "tunnel",
    "peer",
    "controller"
)
)
AND NOT ApprovedWorkflowContext IN ANY (
"approved_certificate_renewal",
"approved_backup_workflow",
"approved_configuration_export",
"approved_controller_maintenance",
"approved_patch_workflow",
"approved_service_provider_activity",
"approved_automation_workflow",
"approved_emergency_access"
)

Rule 3

Suspicious Network Connection From SD-WAN Infrastructure After Administrative or Configuration Activity

Rule Format

SentinelOne Deep Visibility query pattern suitable for endpoint network-connection, process, file, and workload-context correlation after tenant syntax validation, network-event validation, SD-WAN asset tagging, approved-destination baselining, and environment-specific tuning.

Detection Purpose

Detect suspicious outbound or lateral network connections from monitored Cisco SD-WAN infrastructure after administrative, NETCONF, configuration, or artifact activity.

· Identify possible post-access behavior involving new destinations, sensitive internal segments, management systems, cloud infrastructure, or recurring external infrastructure.

· Prioritize connections from SD-WAN infrastructure to destinations not normally associated with approved management, monitoring, backup, service-provider, automation, or update workflows.

· Support investigation of possible SD-WAN fabric-impact or persistence behavior without assuming endpoint network telemetry alone confirms compromise.

· This rule does not prove successful exploitation or SD-WAN fabric manipulation without supporting controller-side, authentication, NETCONF, configuration-audit, topology, or NDR evidence.

Detection Logic

Identify outbound or lateral network connections from monitored Cisco SD-WAN Controller, Manager, or supporting infrastructure.

· Prioritize connections to newly observed destinations, unfamiliar cloud or hosting providers, unmanaged external networks, sensitive internal segments, identity systems, management systems, monitoring systems, backup systems, hypervisor systems, or network-administration systems.

· Increase confidence when the connection follows suspicious administrative shell activity, configuration file activity, account changes, certificate changes, NETCONF access, or controller-side configuration events.

· Increase confidence when the destination has not been historically contacted by the SD-WAN infrastructure or is not part of approved management, monitoring, update, automation, backup, or service-provider paths.

· Increase confidence when connections recur after remediation, rollback, patching, restart, or maintenance activity.

· Reduce severity for approved monitoring, backup, update, service-provider, automation, management, patching, and emergency-access workflows.

· Do not classify outbound or lateral connection activity as compromise without corroborating source, timing, administrative, configuration, topology, and authorization context.

Required Telemetry

SentinelOne network connection telemetry.

· Process creation telemetry.

· Process ancestry.

· Source process name.

· Source process path.

· Source process command line.

· User and administrative context.

· Endpoint or workload identity.

· Endpoint or workload role tag.

· Destination IP.

· Destination port.

· Protocol.

· Destination domain where available.

· Destination reputation where available.

· First-seen destination context.

· GeoIP, ASN, cloud-provider, VPN-provider, hosting-provider, and managed-service enrichment.

· File activity near the connection where available.

· Authentication and administrative context where available.

· Maintenance-window and change-management context.

· Timestamp.

Engineering Implementation Instructions

Validate SentinelOne tenant syntax and tenant field names for network connection events, process events, file events, source process, destination IP, destination port, destination domain, user, endpoint identity, workload tag, and timestamp before deployment.

· Scope the rule to monitored Cisco SD-WAN Controller, Manager, and supporting management infrastructure.

· Build approved destination baselines for monitoring, backup, update, logging, service-provider, automation, emergency-access, and management workflows.

· Add enrichment for destination reputation, first-seen destination, geography, ASN, cloud provider, hosting provider, VPN provider, and managed-service context.

· Tune the rule to distinguish approved platform communication from suspicious outbound or lateral behavior after administrative or configuration activity.

· Correlate suspicious connections with process execution, file activity, account activity, NETCONF access, configuration audit records, and NDR flow changes.

· Avoid broad suppression for cloud, VPN, hosting, or managed-service destinations because attacker infrastructure may use the same categories.

· Treat activity as higher priority when paired with suspicious SD-WAN peering, administrative authentication, NETCONF access, configuration changes, or persistence-adjacent artifact activity.

DRI Assessment

DRI

7.0 / 10

· The rule is behaviorally anchored to suspicious post-access network connections from monitored SD-WAN infrastructure.

· The rule remains useful if the exploit implementation changes but attacker activity creates new outbound, lateral, or recurring communication from SD-WAN infrastructure.

· The score is supported by the durability of first-seen destinations, unusual connection paths, and post-administrative network activity as observable endpoint behaviors.

· The score is constrained by legitimate monitoring, backup, update, service-provider, automation, management, and emergency-access communication that may overlap with the same patterns.

TCR Assessment

Operational TCR

6.0 / 10

Full-Telemetry TCR

8.0 / 10

· Operational confidence depends on SentinelOne network telemetry, destination baselines, SD-WAN workload tagging, process-to-connection linkage, destination enrichment, and maintenance-window context.

· Operational confidence is reduced where SD-WAN infrastructure has broad outbound communication, cloud-hosted workflows, service-provider access, or incomplete destination baselines.

· Full-telemetry confidence improves when SentinelOne network events are enriched with Cisco SD-WAN Controller logs, Manager logs, authentication records, NETCONF records, configuration audit logs, NDR telemetry, and change-management context.

· Even under full telemetry conditions, this rule should be treated as post-access behavioral support rather than standalone proof of exploitation.

Limitations

This rule detects suspicious network connections from monitored SD-WAN infrastructure, not successful exploitation.

· Legitimate monitoring, backup, update, logging, service-provider, automation, management, patching, and emergency-access workflows may overlap with the same behavior.

· SentinelOne network telemetry may not show SD-WAN peer-state context, NETCONF command content, or configuration intent.

· Incomplete destination baselines may increase false positives.

· Confirmation requires correlation with suspicious peering, administrative authentication, NETCONF access, configuration changes, artifact activity, topology mismatch, or NDR flow evidence.

Detection Query Pattern

SentinelOne Deep Visibility query pattern requiring tenant syntax validation, SD-WAN asset tagging, network-event validation, destination-baseline validation, workflow allowlisting, and timing-window tuning before production deployment.

EndpointOS IN ANY (
"linux",
"windows"
)
AND EventType IN ANY (
"Network Connection",
"Process Creation",
"File Modification",
"File Creation"
)
AND AgentComputerName IN ASSET_GROUP (
"Cisco SD-WAN Controllers",
"Cisco SD-WAN Managers",
"Cisco SD-WAN Supporting Infrastructure",
"NETCONF Exposed SD-WAN Infrastructure"
)
AND (
DstIP NOT IN ASSET_GROUP (
    "Approved SD-WAN Management Destinations",
    "Approved Monitoring Destinations",
    "Approved Backup Destinations",
    "Approved Update Destinations",
    "Approved Logging Destinations",
    "Approved Automation Destinations",
    "Approved Service Provider Destinations",
    "Approved Emergency Access Destinations"
)
OR DstFirstSeen WITHIN ENV_NEW_DESTINATION_WINDOW
OR DstProviderType IN ANY (
    "cloud_hosting",
    "vpn_provider",
    "hosting_provider",
    "unknown_external"
)
OR DstAsset IN ASSET_GROUP (
    "Identity Systems",
    "Management Systems",
    "Monitoring Systems",
    "Backup Systems",
    "Hypervisor Systems",
    "Network Administration Systems",
    "Sensitive Internal Segments"
)
)
AND EVENT_NEAR WITHIN ENV_SDWAN_POST_ADMIN_NETWORK_WINDOW (
ProcessEvent.SrcProcCmdLine CONTAINS ANY (
    "netconf",
    "config",
    "configuration",
    "backup",
    "template",
    "policy",
    "route",
    "tunnel",
    "peer",
    "controller",
    "certificate",
    "authorized_keys"
)
OR FileEvent.TgtFilePath CONTAINS ANY (
    ".ssh",
    "authorized_keys",
    "certificate",
    "config",
    "backup",
    "template",
    "policy"
)
OR AuthEvent.EventType IN ANY (
    "Administrative Authentication Success",
    "Failed To Successful Administrative Authentication"
)
)
AND NOT ApprovedWorkflowContext IN ANY (
"approved_monitoring_workflow",
"approved_backup_workflow",
"approved_update_workflow",
"approved_logging_workflow",
"approved_service_provider_activity",
"approved_automation_workflow",
"approved_emergency_access",
"approved_patch_workflow"
)

Splunk

Detection Viability Assessment

Splunk has three rules for this EXP report.

· Splunk is highly viable for detecting suspicious Cisco SD-WAN control-plane behavior because it can correlate SD-WAN Controller logs, Manager logs, authentication records, NETCONF telemetry, configuration audit records, network-flow data, firewall logs, topology inventory, and change-management context.

· Splunk is strongest where Cisco SD-WAN log sources are normalized, administrative source networks are baselined, SD-WAN assets are tagged, and peer identity fields can be enriched against approved topology.

· Splunk can identify high-confidence behavioral sequences involving suspicious peering, administrative authentication, NETCONF access, configuration modification, and post-access SD-WAN fabric impact.

· Splunk is not a standalone proof source unless the required Cisco SD-WAN telemetry and configuration context are available.

· Splunk rules should distinguish exposure, suspicious control-plane behavior, privileged management activity, and confirmed fabric-impact activity.

· Splunk detection content should be treated as high-value correlation coverage for exploited SD-WAN control-plane trust abuse.

Rule 1

Suspicious Cisco SD-WAN Peering or Control-Plane Activity From Unapproved Source

Rule Format

Splunk SPL correlation search suitable for Enterprise Security or scheduled alerting after index validation, source-type validation, SD-WAN field normalization, asset tagging, approved-peer baselining, and environment-specific tuning.

Detection Purpose

· Detect suspicious Cisco SD-WAN control-plane activity from sources that are unknown, newly observed, external, or not approved for SD-WAN peer communication.

· Identify possible unauthorized SD-WAN control-plane trust establishment.

· Prioritize events involving unfamiliar source IPs, unexpected peer identity fields, unusual geographies, unusual ASNs, cloud or VPN egress, or sources not present in approved SD-WAN topology.

· Support investigation of exploited SD-WAN control-plane trust abuse without relying on CVE-string matches, scanner output, advisory references, or exploit-specific indicators.

· This rule does not prove successful exploitation without supporting peer-state, authentication, NETCONF, configuration, topology, or change-management evidence.

Detection Logic

· Identify Cisco SD-WAN Controller or Manager control-plane events involving unknown, unexpected, or unapproved source IP addresses.

· Prioritize events where observed peer identity fields do not match approved SD-WAN inventory.

· Increase confidence when the source is newly observed or associated with cloud, VPN, hosting, unmanaged, unusual geography, or unusual ASN context.

· Increase confidence when the same source is associated with control-connection anomalies, peer-state changes, unexpected device registration, or unexpected peer identity fields.

· Increase confidence when activity is followed by administrative authentication, NETCONF access, or SD-WAN configuration changes.

· Increase confidence when activity occurs outside approved maintenance, migration, disaster-recovery, service-provider, automation, or emergency-access windows.

· Reduce severity for approved peers, known controller relationships, expected edge-device communication, sanctioned service-provider activity, planned topology changes, and documented maintenance activity.

· Do not classify control-plane activity as compromise without corroborating authentication, NETCONF, configuration, topology, or change-management evidence.

Required Telemetry

· Cisco SD-WAN Controller logs.

· Cisco SD-WAN Manager logs.

· Control-connection events.

· Peer-state events.

· Device-registration events.

· Source IP.

· Destination IP.

· Peer type.

· System IP.

· Site ID.

· Domain ID.

· Public IP.

· Device identity.

· Controller relationship.

· Event outcome.

· Timestamp.

· Network-flow telemetry where available.

· Firewall logs where available.

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

· Approved SD-WAN peer inventory.

· Approved administrative and service-provider source networks.

· Maintenance-window and change-management context.

Engineering Implementation Instructions

· Validate Splunk indexes, source types, field names, and CIM alignment for Cisco SD-WAN Controller, Manager, network-flow, firewall, authentication, NETCONF, and configuration-audit sources.

· Normalize peer identity fields, including source IP, public IP, System IP, site ID, domain ID, peer type, device identity, controller relationship, and event outcome.

· Build lookup tables for approved SD-WAN peers, Controllers, Managers, edge devices, service-provider paths, automation sources, emergency-access paths, and administrative networks.

· Add enrichment for first-seen source, geography, ASN, cloud provider, VPN provider, and hosting provider.

· Correlate suspicious control-plane activity with authentication, NETCONF, configuration, and change-management records.

· Tune suppression logic for approved maintenance, migration, edge onboarding, disaster recovery, service-provider work, and emergency access.

· Avoid broad suppression for cloud, VPN, or service-provider sources because attacker and legitimate administrative paths may overlap.

· Use risk-based alerting where available to elevate events that combine peer anomalies, authentication success, NETCONF access, and configuration changes.

DRI Assessment

DRI

8.5 / 10

· The rule is behaviorally anchored to suspicious SD-WAN control-plane activity and peer identity mismatch rather than static exploit indicators.

· The rule remains useful if exploit delivery changes but the attacker still needs to interact with SD-WAN control-plane infrastructure.

· The score is supported by durable telemetry relationships across peer identity, source behavior, topology, and timing.

· The score is constrained by incomplete SD-WAN field normalization, incomplete peer inventories, service-provider activity, migrations, and legitimate edge onboarding.

TCR Assessment

Operational TCR

7.5 / 10

Full-Telemetry TCR

9.0 / 10

· Operational confidence depends on Cisco SD-WAN log ingestion, field normalization, approved-peer baselines, administrative-source baselines, and maintenance-window context.

· Operational confidence is reduced where Controller or Manager logs are incomplete, peer identity fields are not parsed, or service-provider paths are poorly documented.

· Full-telemetry confidence improves when Splunk correlates SD-WAN Controller logs, Manager logs, network-flow records, authentication logs, NETCONF telemetry, configuration audit logs, and change-management data.

· Even under full telemetry conditions, this rule should support investigation unless paired with authentication, NETCONF, or configuration-impact evidence.

Limitations

· This rule detects suspicious control-plane or peering behavior, not successful exploitation by itself.

· Legitimate SD-WAN operations, edge onboarding, controller migration, service-provider activity, and disaster-recovery testing may overlap with the same behavior.

· Incomplete topology inventory can reduce confidence in peer validation.

· Field normalization gaps may reduce detection accuracy.

· Confirmation requires correlation with administrative authentication, NETCONF access, configuration changes, topology mismatch, or unauthorized fabric-impact activity.

Detection Query Pattern

Splunk SPL pattern requiring index validation, source-type validation, Cisco SD-WAN field normalization, peer-inventory lookup validation, source-enrichment validation, and environment-specific tuning before production deployment.

index=sdwan sourcetype IN ("cisco:sdwan:controller","cisco:sdwan:manager")
(
event_type IN (
    "peer_state_change",
    "control_connection",
    "device_registration",
    "peer_identity",
    "control_plane_event"
)
OR message IN (
    "*peer*",
    "*control connection*",
    "*device registration*",
    "*system-ip*",
    "*site-id*",
    "*domain-id*"
)
)
| eval src_ip=coalesce(src_ip, source_ip, public_ip, remote_ip)
| eval peer_type=coalesce(peer_type, remote_peer_type)
| eval system_ip=coalesce(system_ip, remote_system_ip)
| eval site_id=coalesce(site_id, remote_site_id)
| eval domain_id=coalesce(domain_id, remote_domain_id)
| lookup approved_sdwan_peers src_ip OUTPUT approved_peer, approved_peer_type, approved_site_id, approved_system_ip
| lookup approved_sdwan_admin_sources src_ip OUTPUT approved_admin_source
| lookup source_enrichment src_ip OUTPUT src_first_seen, src_geo, src_asn, src_provider_type
| where isnull(approved_peer)
OR approved_peer!="true"
OR peer_type!=approved_peer_type
OR site_id!=approved_site_id
OR system_ip!=approved_system_ip
OR src_first_seen>=relative_time(now(), "-7d")
OR src_provider_type IN ("cloud_hosting","vpn_provider","hosting_provider","unknown_external")
| lookup approved_sdwan_change_windows _time OUTPUT approved_change_context
| where isnull(approved_change_context)
| stats
    min(_time) as first_seen
    max(_time) as last_seen
    values(event_type) as event_types
    values(peer_type) as peer_types
    values(system_ip) as system_ips
    values(site_id) as site_ids
    values(domain_id) as domain_ids
    values(src_geo) as src_geos
    values(src_asn) as src_asns
    count as event_count
by src_ip dest host
| where event_count >= ENV_SDWAN_CONTROL_PLANE_EVENT_THRESHOLD

Rule 2

Cisco SD-WAN Control-Plane Activity Followed by NETCONF or Administrative Authentication

Rule Format

Splunk SPL correlation search suitable for Enterprise Security, risk-based alerting, or scheduled alerting after index validation, field normalization, authentication-source validation, NETCONF-source validation, timing-window validation, and environment-specific tuning.

Detection Purpose

· Detect suspicious sequencing where Cisco SD-WAN control-plane activity is followed by NETCONF access or administrative authentication.

· Identify behavior consistent with progression from control-plane interaction to privileged SD-WAN management activity.

· Prioritize sources that are unfamiliar, newly observed, external, unauthorized, or not aligned with approved administrative workflows.

· Support investigation of potential SD-WAN control-plane trust abuse without relying on encrypted payload inspection.

· This rule does not prove successful exploitation or configuration manipulation without supporting controller-side, authentication, NETCONF, configuration-audit, topology, or change-management evidence.

Detection Logic

· Identify suspicious SD-WAN control-plane or peer-state activity involving an unknown or unapproved source.

· Correlate the source or related source with successful administrative authentication or NETCONF access within the same operational window.

· Increase confidence when the source is newly observed, external, cloud-hosted, VPN-associated, hosting-provider-associated, or not part of approved administrative source lists.

· Increase confidence when the sequence occurs near peer-state changes, control-connection instability, device-registration activity, or unexpected peer identity fields.

· Increase confidence when NETCONF or authentication activity occurs outside approved maintenance, automation, service-provider, or emergency-access windows.

· Increase confidence when the sequence is followed by configuration audit activity.

· Reduce severity for approved automation, approved NETCONF management workflows, service-provider maintenance, planned migration, and documented emergency access.

· Do not classify NETCONF or administrative authentication as malicious without source, identity, timing, peer-state, topology, and configuration-change context.

Required Telemetry

· Cisco SD-WAN Controller logs.

· Cisco SD-WAN Manager logs.

· Authentication logs.

· NETCONF records or network-flow records for TCP port 830.

· Source IP.

· Destination IP.

· Username.

· Authentication method.

· Authentication outcome.

· NETCONF source.

· NETCONF destination.

· Peer-state context.

· Control-connection context.

· Device-registration context.

· Timestamp.

· Approved NETCONF source list.

· Approved SD-WAN administrative source networks.

· Approved peer and controller inventories.

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

· Maintenance-window, automation, service-provider, and change-management context.

Engineering Implementation Instructions

· Validate Splunk indexes, source types, and field mappings for SD-WAN Controller, Manager, authentication, NETCONF, network-flow, and configuration-audit telemetry.

· Normalize source IP, destination IP, username, authentication outcome, NETCONF destination, peer identity fields, and timestamps.

· Build lookup tables for approved SD-WAN peers, approved administrative sources, approved NETCONF sources, automation sources, service-provider sources, and emergency-access paths.

· Correlate suspicious control-plane events with NETCONF and authentication events by source IP, related source IP, subnet, ASN, VPN provider, cloud provider, or infrastructure cluster.

· Tune correlation windows around normal SD-WAN administrative workflows and emergency-access procedures.

· Add suppression logic for approved maintenance, automation, service-provider operations, disaster recovery, controller migration, and emergency access.

· Avoid suppressing all NETCONF or administrative activity from broad infrastructure categories because attackers may use cloud, VPN, or provider egress.

· Use risk-based alerting to increase severity when the sequence is followed by configuration change or fabric-impact activity.

DRI Assessment

DRI

9.0 / 10

· The rule is behaviorally anchored to a durable progression from suspicious control-plane activity to privileged access.

· The rule remains useful if the exploit implementation changes but the attacker proceeds from control-plane interaction to administrative or NETCONF activity.

· The score is supported by the operational significance of NETCONF access or authentication following suspicious peering or peer-state activity.

· The score is constrained by legitimate automation, provider maintenance, emergency access, and incomplete NETCONF or authentication telemetry.

TCR Assessment

Operational TCR

8.0 / 10

Full-Telemetry TCR

9.5 / 10

· Operational confidence depends on reliable SD-WAN log ingestion, authentication visibility, NETCONF visibility, correlation timing, and approved administrative workflow documentation.

· Operational confidence is reduced where NETCONF records are unavailable, authentication logs lack source IP context, or approved source lists are incomplete.

· Full-telemetry confidence improves when the sequence is correlated with configuration audit records, peer-state changes, topology mismatch, and change-management context.

· Under full telemetry conditions, this rule provides strong suspicious-activity coverage, but confirmed exploitation still requires evidence of unauthorized peer status, configuration impact, or fabric change.

Limitations

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

· NETCONF and administrative authentication may be legitimate in approved automation, service-provider, and emergency workflows.

· Related-source correlation may be imperfect when attackers rotate infrastructure or use shared cloud, VPN, or provider egress.

· Missing authentication or NETCONF fields can reduce confidence.

· Confirmation requires correlation with peer-state anomalies, unauthorized source context, configuration changes, topology mismatch, or fabric-impact evidence.

Detection Query Pattern

Splunk SPL pattern requiring index validation, source-type validation, authentication-field validation, NETCONF-field validation, lookup validation, related-source correlation validation, timing-window tuning, and environment-specific allowlisting before production deployment.

(
search index=sdwan sourcetype IN ("cisco:sdwan:controller","cisco:sdwan:manager")
(
    event_type IN (
      "peer_state_change",
      "control_connection",
      "device_registration",
      "unexpected_peer_identity",
      "control_plane_event"
    )
    OR message IN (
      "*peer*",
      "*control connection*",
      "*device registration*",
      "*unexpected peer*"
    )
)
| eval src_ip=coalesce(src_ip, source_ip, public_ip, remote_ip)
| eval event_category="sdwan_control_plane"
| fields _time src_ip dest host event_category event_type message
)
| append [
search index=auth sourcetype IN ("linux_secure","cisco:sdwan:auth","auth_logs")
(
    action="success"
    OR outcome="success"
    OR message="*authentication success*"
)
| eval src_ip=coalesce(src_ip, source_ip, remote_ip)
| eval user=coalesce(user, username, account)
| eval event_category="admin_authentication"
| fields _time src_ip dest host user event_category action outcome message
]
| append [
search index=netflow
(
    dest_port=830
    OR dport=830
)
| eval src_ip=coalesce(src_ip, source_ip)
| eval event_category="netconf_access"
| fields _time src_ip dest dest_port dport host event_category
]
| lookup approved_sdwan_peers src_ip OUTPUT approved_peer
| lookup approved_sdwan_admin_sources src_ip OUTPUT approved_admin_source
| lookup approved_netconf_sources src_ip OUTPUT approved_netconf_source
| lookup source_enrichment src_ip OUTPUT src_first_seen, src_geo, src_asn, src_provider_type
| bin _time span=ENV_SDWAN_SEQUENCE_BIN
| stats
    values(event_category) as event_categories
    values(user) as users
    values(src_provider_type) as provider_types
    values(src_geo) as geos
    values(src_asn) as asns
    count as event_count
by _time src_ip dest
| where mvfind(event_categories, "sdwan_control_plane") >= 0
AND (
    mvfind(event_categories, "admin_authentication") >= 0
    OR mvfind(event_categories, "netconf_access") >= 0
)
| where isnull(approved_peer)
OR approved_peer!="true"
OR isnull(approved_admin_source)
OR approved_admin_source!="true"
OR isnull(approved_netconf_source)
OR approved_netconf_source!="true"
OR src_first_seen>=relative_time(now(), "-7d")
OR provider_types IN ("cloud_hosting","vpn_provider","hosting_provider","unknown_external")
| lookup approved_sdwan_change_windows _time OUTPUT approved_change_context
| where isnull(approved_change_context)

Rule 3

Cisco SD-WAN Configuration Change Following Suspicious Control-Plane or Administrative Activity

Rule Format

Splunk SPL correlation search suitable for Enterprise Security, risk-based alerting, or scheduled alerting after configuration-audit source validation, SD-WAN field normalization, change-management lookup validation, asset tagging, and environment-specific tuning.

Detection Purpose

· Detect SD-WAN configuration changes that occur after suspicious control-plane activity, administrative authentication, or NETCONF access.

· Identify possible fabric-impact behavior involving routes, tunnels, policies, certificates, device registration, peer state, or fabric-trust relationships.

· Prioritize configuration changes involving unfamiliar sources, unauthorized users, unexpected peer identity fields, or changes lacking approval context.

· Support investigation of post-access SD-WAN fabric manipulation without treating configuration change alone as proof of compromise.

· This rule does not prove successful exploitation without supporting peering, authentication, NETCONF, topology, or authorization evidence.

Detection Logic

· Identify suspicious SD-WAN control-plane activity, administrative authentication, or NETCONF access.

· Correlate the activity with SD-WAN configuration changes within the same operational window.

· Prioritize changes affecting routes, tunnels, policies, certificates, templates, device registration, peer state, controller relationships, or fabric trust.

· Increase confidence when the actor, source, object changed, or change type does not align with approved administrative workflows.

· Increase confidence when the change lacks a matching change ticket, maintenance window, emergency-access record, automation record, or service-provider record.

· Increase confidence when the configuration change is followed by new traffic-flow patterns, newly reachable destinations, or persistent unfamiliar access.

· Reduce severity for approved maintenance, automation, service-provider activity, controller migration, disaster recovery, policy deployment, and emergency changes.

· Do not classify configuration changes as compromise without source, actor, timing, peer-state, topology, and change-authorization context.

Required Telemetry

· Cisco SD-WAN configuration audit logs.

· Cisco SD-WAN Manager audit logs.

· Cisco SD-WAN Controller logs.

· Authentication logs.

· NETCONF records or network-flow records for TCP port 830.

· Route change events.

· Tunnel change events.

· Policy change events.

· Certificate change events.

· Device-registration events.

· Peer-state events.

· Template or configuration push events.

· Actor.

· Source IP.

· Destination IP.

· Object changed.

· Change type.

· Change outcome.

· Timestamp.

· Approved change-management records.

· Approved automation records.

· Approved service-provider records.

· Approved emergency-access records.

· Topology and peer inventory.

Engineering Implementation Instructions

· Validate Splunk indexes, source types, and field mappings for SD-WAN configuration audit records, Manager audit records, Controller logs, authentication records, NETCONF records, and network-flow data.

· Normalize actor, source IP, object changed, change type, change outcome, peer identity, and timestamp fields.

· Build lookup tables for approved maintenance windows, change tickets, automation jobs, service-provider activity, emergency access, approved peers, and approved administrative sources.

· Correlate configuration changes with suspicious control-plane activity, authentication, and NETCONF access by source, actor, host, peer identity, and time window.

· Tag high-impact configuration objects such as routes, tunnels, policies, templates, certificates, device-registration objects, peer-state objects, and fabric-trust objects.

· Tune suppression logic for approved policy deployments, controller migrations, disaster recovery, provider maintenance, and emergency access.

· Avoid suppressing all configuration changes from automation accounts because automation credentials may be abused after control-plane compromise.

· Use risk-based alerting to elevate changes that follow suspicious peering or NETCONF access and affect fabric-impacting objects.

DRI Assessment

DRI

9.0 / 10

· The rule is behaviorally anchored to configuration change following suspicious control-plane or privileged access activity.

· The rule remains useful if exploit implementation changes but attacker objectives still include SD-WAN fabric manipulation.

· The score is supported by the durability of fabric-impacting configuration changes as observable post-access behavior.

· The score is constrained by legitimate automation, policy deployment, provider maintenance, migrations, and incomplete configuration audit visibility.

TCR Assessment

Operational TCR

8.0 / 10

Full-Telemetry TCR

9.5 / 10

· Operational confidence depends on configuration audit visibility, actor and source normalization, change-management linkage, SD-WAN topology inventory, and correlation with control-plane or privileged-access events.

· Operational confidence is reduced where configuration audit logs are incomplete, automation context is weak, or change-management records lack object-level detail.

· Full-telemetry confidence improves when configuration changes are correlated with suspicious peering, authentication, NETCONF access, network-flow changes, topology mismatch, and post-access fabric impact.

· Under full telemetry conditions, this rule can provide high-confidence evidence of suspicious SD-WAN fabric manipulation, but confirmed exploitation still requires unauthorized access or trust-establishment context.

Limitations

· This rule detects suspicious configuration change after suspicious access, not exploit execution.

· Legitimate policy deployment, route changes, tunnel changes, certificate renewal, service-provider activity, automation, disaster recovery, and emergency changes may overlap with the same behavior.

· Configuration audit records may vary by deployment model, logging configuration, and retention.

· Automation activity may obscure the original actor unless identity and source context are preserved.

· Confirmation requires correlation with suspicious peering, administrative authentication, NETCONF access, topology mismatch, unauthorized source context, or fabric-impact evidence.

Detection Query Pattern

Splunk SPL pattern requiring index validation, source-type validation, configuration-audit validation, actor-field validation, source-field validation, change-management lookup validation, and environment-specific tuning before production deployment.

(
search index=sdwan sourcetype IN ("cisco:sdwan:controller","cisco:sdwan:manager")
(
    event_type IN (
      "peer_state_change",
      "control_connection",
      "device_registration",
      "unexpected_peer_identity",
      "control_plane_event"
    )
    OR message IN (
      "*peer*",
      "*control connection*",
      "*device registration*",
      "*unexpected peer*"
    )
)
| eval src_ip=coalesce(src_ip, source_ip, public_ip, remote_ip)
| eval actor=coalesce(user, username, account, actor)
| eval event_category="suspicious_access_context"
| fields _time src_ip actor dest host event_category event_type message
)
| append [
search index=auth sourcetype IN ("linux_secure","cisco:sdwan:auth","auth_logs")
(
    action="success"
    OR outcome="success"
    OR message="*authentication success*"
)
| eval src_ip=coalesce(src_ip, source_ip, remote_ip)
| eval actor=coalesce(user, username, account)
| eval event_category="admin_authentication"
| fields _time src_ip actor dest host event_category action outcome message
]
| append [
search index=netflow
(
    dest_port=830
    OR dport=830
)
| eval src_ip=coalesce(src_ip, source_ip)
| eval event_category="netconf_access"
| fields _time src_ip dest host event_category dest_port dport
]
| append [
search index=sdwan sourcetype IN ("cisco:sdwan:audit","cisco:sdwan:manager")
(
    event_type IN (
      "configuration_change",
      "policy_change",
      "route_change",
      "tunnel_change",
      "certificate_change",
    "template_push",
      "device_registration_change",
      "fabric_trust_change"
    )
    OR message IN (
      "*configuration*",
      "*policy*",
      "*route*",
      "*tunnel*",
      "*certificate*",
      "*template*",
      "*fabric trust*"
    )
)
| eval src_ip=coalesce(src_ip, source_ip, remote_ip)
| eval actor=coalesce(user, username, account, actor)
| eval object_changed=coalesce(object, object_name, target, config_object)
| eval change_type=coalesce(change_type, action, operation)
| eval event_category="sdwan_configuration_change"
| fields _time src_ip actor dest host object_changed change_type event_category event_type message
]
| lookup approved_sdwan_admin_sources src_ip OUTPUT approved_admin_source
| lookup approved_sdwan_change_windows _time OUTPUT approved_change_context
| lookup approved_sdwan_change_records actor object_changed change_type OUTPUT approved_change_record
| bin _time span=ENV_SDWAN_CONFIG_CORRELATION_BIN
| stats
    values(event_category) as event_categories
    values(actor) as actors
    values(object_changed) as objects_changed
    values(change_type) as change_types
    values(approved_admin_source) as approved_admin_sources
    values(approved_change_context) as approved_change_contexts
    values(approved_change_record) as approved_change_records
    count as event_count
by _time src_ip dest host
| where mvfind(event_categories, "sdwan_configuration_change") >= 0
AND (
    mvfind(event_categories, "suspicious_access_context") >= 0
    OR mvfind(event_categories, "admin_authentication") >= 0
    OR mvfind(event_categories, "netconf_access") >= 0
)
| where mvfind(approved_admin_sources, "true") < 0
OR mvcount(approved_change_contexts)=0
OR mvcount(approved_change_records)=0

Elastic

Detection Viability Assessment

Elastic has three rules for this EXP report.

· Elastic is viable for detecting suspicious Cisco SD-WAN control-plane behavior when SD-WAN Controller logs, Manager logs, authentication records, NETCONF telemetry, configuration audit records, network-flow data, firewall logs, topology inventory, and asset context are ingested and normalized.

· Elastic is strongest where ECS-aligned fields, custom SD-WAN fields, host and network enrichment, approved-peer lookups, administrative-source baselines, and configuration-change context are available.

· Elastic can identify behavioral sequences involving suspicious peering, administrative authentication, NETCONF access, configuration modification, and post-access SD-WAN fabric impact.

· Elastic is not a standalone proof source unless the required Cisco SD-WAN telemetry and configuration context are available.

· Elastic rules should distinguish exposure, suspicious control-plane behavior, privileged management activity, and confirmed fabric-impact activity.

· Elastic detection content should be treated as high-value behavioral correlation coverage for exploited SD-WAN control-plane trust abuse.

Rule 1

Suspicious Cisco SD-WAN Control-Plane or Peer Activity From Unapproved Source

Rule Format

Elastic KQL / EQL-style detection rule suitable for Elastic Security after index validation, ECS field validation, Cisco SD-WAN field mapping, SD-WAN asset tagging, approved-peer enrichment, source-baseline validation, exception-list validation, and environment-specific tuning.

Detection Purpose

· Detect suspicious Cisco SD-WAN control-plane or peer activity from sources that are unknown, newly observed, external, or not approved for SD-WAN peer communication.