Defender for Cloud attack path shows "internet exposure: TCP 3389 from 0.0.0.0/0" on a VM that has no public IP — insight never refreshes, Critical alert keeps re-notifying

Because the unchanged attack path has persisted for four days—well beyond the documented “up to 24 hours” removal period—capture its Azure Resource Graph payload and open an Azure support request for a stale or inconsistent Defender CSPM attack path rather than changing the already-correct NSG configuration.^1^

Capture the evidence before escalation

Run this in Azure portal → Resource Graph Explorer, replacing the placeholders:

securityresources
| where type =~ "microsoft.security/attackpaths"
| where subscriptionId == "<subscription-id>"
| where name == "<attack-path-id>"
| project
    id,
    name,
    displayName = tostring(properties.displayName),
    refreshInterval = tostring(properties.refreshInterval),
    attackPathId = tostring(properties.AttackPathID),
    assessments = properties.assessments,
    graphComponent = properties.graphComponent

Attack-path resources expose properties.refreshInterval, assessments, graph components, entities, connections, and insights through Azure Resource Graph.^2^

Attach these items to the support request:

• The ARG result, including refreshInterval and the complete exposedToInternet insight.
• The attack-path ID, edge IDs, node IDs, and first/last observed timestamps.
• Output from Get-AzEffectiveNetworkSecurityGroup.
• NIC and subnet configuration showing no public IP, load balancer, peering, or other ingress path.
• The JIT policy change timestamp.
• Screenshots or exports showing the 9.8 insight versus the currently listed 9.6/9.1 findings.
• Confirmation that the VM remained running long enough for scheduled vulnerability scanning. Agentless scanning runs once every 24 hours and stopped machines can retain outdated results.^3^

How exposedToInternet is computed

A missing public IP alone does not determine the result. Defender for Cloud evaluates:

1. Control-plane configuration, such as public IPs and load balancers.
2. Network-path reachability, including routing, firewalls, NSGs, VNets, and subnets.
3. For attack paths, cloud-security-graph context and active reachability signals.^4^^5^

“High” or wide exposure means the calculated exposure is broad according to networking rules; it is then used in attack-path generation and risk prioritization.^4^

Nothing in the published behavior establishes that Defender interprets a JIT Deny rule as an allow rule. The matching 0.0.0.0/0:3389 values are therefore evidence of a potentially stale or incorrectly classified graph component, not proof that the deny rule caused the exposure. Do not remove the JIT deny rule merely to test that theory.

Refresh and forced reassessment

Cloud Security Explorer publishes workload-configuration snapshots at regular intervals and refreshes that data daily.^6^ Attack-path documentation says a resolved path can take up to 24 hours to disappear.^1^

The documented UI and API do not provide a button or operation to force recomputation of one attack path. The refreshInterval property is informational metadata; querying the resource does not trigger a refresh.

Since the path remained unchanged across several expected cycles, waiting longer is no longer the useful next step.

CVSS 9.8 versus 9.6/9.1

The attack path is built from graph insights and mapped security assessments, while the Recommendations page displays the currently available recommendation findings. A mismatch can therefore occur when those datasets are on different assessment cycles. The available documentation does not define exactly how maxCvssScore is selected or prove which historical/current CVE supplied 9.8.

Include the properties.assessments mapping and the full highRiskVulnerabilityInsights object in the support case. That lets support determine whether 9.8 refers to:

• a stale remediated finding,
• another assessment not currently visible in the VM recommendation list, or
• incorrect score normalization.

False-positive and email controls

There is no documented control to mark one Defender for Cloud attack-path instance as a false positive or suppress only its notifications.

Email configuration supports:

• recipients or Azure roles;
• alert severity threshold;
• attack-path risk threshold.

It does not document filtering by attack-path ID, VM, recommendation, or subscription resource. Configure it under Defender for Cloud → Environment settings → subscription → Email notifications. Critical attack-path email volume is limited to one email per 30 minutes per address.^7^

Consequently, changing the threshold would suppress every path below the selected risk level, not only this path. If retaining other Critical notifications is required, leave the threshold unchanged and use an inbox/mail-flow rule keyed to this path ID as a temporary external workaround; remove it after Microsoft clears or recalculates the path.

References

1. Identify and remediate attack paths in Microsoft Defender for Cloud (defender-portal)
2. Retrieve attack path data with API
3. Enable agentless machine scanning
4. Internet exposure analysis
5. Security explorer and attack paths in Microsoft Defender for Cloud
6. Build queries with cloud security explorer - Microsoft Defender for ...
7. Configure email notifications for alerts and attack paths