Hunt Exposed Attack Surfaces with DVM

📋 Overview

About This Lab

Exposed attack surfaces are the external-facing entry points attackers can target: internet-facing services, misconfigured firewall rules, vulnerable applications, and exposed management interfaces. DVM provides attack surface insights that go beyond traditional vulnerability scanning to show how your organisation looks from an attacker''s perspective.

🏢 Enterprise Use Case

A penetration test reveals that 15 internet-facing servers have known vulnerabilities, 8 endpoints expose RDP to the internet, and 3 web applications have critical CVEs. The security team must use DVM to identify and prioritise these exposed attack surfaces, create remediation tasks, and monitor reduction over time.

🎯 What You Will Learn

Understand attack surface concepts in DVM
Review internet-facing device exposure
Identify exposed services and ports
Assess vulnerable internet-facing applications
Review browser extension risks
Create attack surface reduction recommendations
Track exposure score trends
Build KQL queries for attack surface monitoring
Integrate with network security controls
Generate attack surface reports for leadership

🔑 Why This Matters

Attackers follow the path of least resistance. Internet-facing vulnerabilities and exposed services are the first targets in any attack campaign. Reducing your exposed attack surface is the single most impactful security action you can take.

⚙️ Prerequisites

Licensing: Microsoft Defender Vulnerability Management add-on or Defender for Endpoint P2
Roles: Security Administrator or Security Reader for portal access; Global Administrator for remediation task creation
Data Sources: Devices onboarded to Microsoft Defender for Endpoint with active sensors reporting
Network Visibility: DeviceNetworkInfo table populated (requires MDE sensor on endpoints)
Portal Access: Microsoft Defender portal (security.microsoft.com) - Advanced Hunting enabled
Tooling: PowerShell 7+ with Microsoft.Graph module for exposure report automation

Step 1 · Review Internet-Facing Exposure

Your exposure score is the single metric that captures how vulnerable your organisation looks from the outside. Before diving into specific attack surfaces, you need to understand the overall exposure landscape: which devices carry the most risk, how many are internet-facing, and where the critical exploitable vulnerabilities cluster.

Navigate to Vulnerability management > Dashboard
Review the Exposure score and understand its components
Navigate to Weaknesses and filter by Internet facing: Yes
Identify devices with the highest exposure scores

// ============================================================
// Internet-Facing Devices with Critical Vulnerabilities
// ============================================================
// WHAT: Identifies devices marked as internet-facing that have
//       critical or high severity vulnerabilities with exploits.
// WHY:  Internet-facing + exploitable = attacker's first target.
//       These devices should be patched within 24–72 hours.
// TABLE: DeviceTvmSoftwareVulnerabilities
// KEY FIELDS:
//   IsInternetFacing   - DVM flag based on network topology analysis
//   IsExploitAvailable  - public exploit exists for this CVE
//   VulnerabilitySeverityLevel - Critical/High/Medium/Low
DeviceTvmSoftwareVulnerabilities
| where IsInternetFacing == true
| where VulnerabilitySeverityLevel in ("Critical", "High")
| where IsExploitAvailable == true
| summarize
    ExploitableVulns = dcount(CveId),
    CveList          = make_set(CveId, 5)
    by DeviceName, DeviceId, SoftwareName
| order by ExploitableVulns desc
| project DeviceName, SoftwareName, ExploitableVulns, CveList

💡 Pro Tip: The exposure score weighs internet-facing devices more heavily. If your score seems disproportionately high, check whether DVM has correctly classified your devices. VPN concentrators and proxy servers may be flagged as internet-facing when they are behind a WAF.

Step 2 · Identify Exposed Services and Ports

Exposed services are the doors attackers walk through. RDP exposed to the internet is responsible for over 50% of ransomware initial access. This step combines vulnerability data with network information to discover exactly which services are listening on internet-facing interfaces and which of those services have known vulnerabilities.

Use Advanced Hunting to query for exposed services
Identify devices with RDP, SSH, SMB, or HTTP exposed to the internet
Cross-reference with firewall rules and network segmentation policies
Flag any management interfaces (RDP, WinRM) accessible from the internet

// ============================================================
// Discover Internet-Facing Services with Vulnerable Software
// ============================================================
// WHAT: Joins DeviceTvmSoftwareVulnerabilities with
//       DeviceNetworkInfo to find devices that have both
//       vulnerable software AND network interfaces with
//       public-facing IP addresses.
// WHY:  A vulnerability on an internal-only device is far less
//       urgent than the same vulnerability on a device with a
//       public IP. This query surfaces the highest-risk combo.
// TABLES: DeviceTvmSoftwareVulnerabilities + DeviceNetworkInfo
let vulnerableDevices = DeviceTvmSoftwareVulnerabilities
| where VulnerabilitySeverityLevel in ("Critical", "High")
| where IsExploitAvailable == true
| summarize
    CriticalCVEs    = dcount(CveId),
    VulnSoftware    = make_set(SoftwareName, 5)
    by DeviceId, DeviceName;
let networkInfo = DeviceNetworkInfo
| where Timestamp > ago(1d)
| mvexpand todynamic(IPAddresses)
| extend IPAddress = tostring(IPAddresses.IPAddress)
| extend IsPublicIP = not(
    IPAddress startswith "10." or
    IPAddress startswith "172.16." or
    IPAddress startswith "172.17." or
    IPAddress startswith "172.18." or
    IPAddress startswith "172.19." or
    IPAddress startswith "172.20." or
    IPAddress startswith "172.21." or
    IPAddress startswith "172.22." or
    IPAddress startswith "172.23." or
    IPAddress startswith "172.24." or
    IPAddress startswith "172.25." or
    IPAddress startswith "172.26." or
    IPAddress startswith "172.27." or
    IPAddress startswith "172.28." or
    IPAddress startswith "172.29." or
    IPAddress startswith "172.30." or
    IPAddress startswith "172.31." or
    IPAddress startswith "192.168." or
    IPAddress startswith "127." or
    IPAddress startswith "169.254.")
| where IsPublicIP == true
| summarize PublicIPs = make_set(IPAddress, 3) by DeviceId;
vulnerableDevices
| join kind=inner networkInfo on DeviceId
| project DeviceName, CriticalCVEs, VulnSoftware, PublicIPs
| order by CriticalCVEs desc

// Find devices with exposed services
DeviceTvmSoftwareVulnerabilities
| where VulnerabilitySeverityLevel == "Critical"
| where IsExploitAvailable == true
| summarize CriticalExploitable = count() by DeviceName, DeviceId
| top 20 by CriticalExploitable

💡 Pro Tip: Any device with RDP (port 3389) or SMB (port 445) exposed to a public IP address should be treated as a P0 emergency. These services are the #1 and #2 most exploited entry points in ransomware attacks. Block them at the network edge and use VPN or Azure Bastion instead.

Step 3 · Assess Browser Extension Risks

Browser extensions are a blind spot in most security programmes. A single malicious or overly permissive extension can exfiltrate credentials, inject ads into banking sites, or act as a keylogger. DVM's browser extension inventory lets you see every extension installed across your fleet, assess their permissions, and identify the ones that pose the greatest risk.

Navigate to Vulnerability management > Software inventory > Browser extensions
Review installed extensions across your fleet
Identify extensions with excessive permissions (e.g., read/modify all website data)
Flag extensions from unverified publishers
Create policies to block risky browser extensions

// ============================================================
// Browser Extension Risk Assessment
// ============================================================
// WHAT: Queries the software inventory for browser extensions
//       and counts installations across the fleet.
// WHY:  Extensions with broad permissions installed on many
//       devices represent high-value targets for supply chain
//       attacks. An extension update can push malware to
//       thousands of devices in minutes.
DeviceTvmBrowserExtensions
| summarize
    InstalledOn   = dcount(DeviceId),
    SampleDevices = make_set(DeviceName, 3)
    by ExtensionName, BrowserName, ExtensionId
| order by InstalledOn desc
| project ExtensionName, BrowserName, InstalledOn, SampleDevices

💡 Pro Tip: Create an approved extensions allowlist in Edge or Chrome management policies. Block all extensions by default and only permit those that have been reviewed and approved by your security team. This dramatically reduces your browser-based attack surface.

Step 4 · Create Attack Surface Reduction Plans

Attack surface reduction goes beyond patching individual CVEs - it means systematically eliminating the exposure vectors attackers use. This step builds a KQL-based attack surface scoring model that combines vulnerability count, exploit availability, and internet exposure into a single per-device risk score, enabling you to prioritise which devices need attention first.

Navigate to Vulnerability management > Recommendations
Filter by recommendations that reduce internet exposure
Create remediation tasks for the top 10 exposure-reducing recommendations
Prioritise: patch internet-facing critical CVEs first, then reduce exposed services

// ============================================================
// Attack Surface Risk Score per Device
// ============================================================
// WHAT: Calculates a composite risk score for each device based
//       on weighted factors: critical vulns, exploit availability,
//       internet exposure, and configuration compliance.
// WHY:  A single score per device lets you stack-rank your fleet
//       and allocate remediation resources where they matter most.
// SCORING MODEL:
//   +10 points per Critical CVE with exploit available
//   +5  points per High CVE with exploit available
//   +3  points per Critical CVE without exploit
//   +20 bonus if device is internet-facing
//   +15 bonus if device has failed secure config checks
let vulnScores = DeviceTvmSoftwareVulnerabilities
| summarize
    CritExploit   = countif(VulnerabilitySeverityLevel == "Critical" and IsExploitAvailable == true),
    HighExploit   = countif(VulnerabilitySeverityLevel == "High" and IsExploitAvailable == true),
    CritNoExploit = countif(VulnerabilitySeverityLevel == "Critical" and IsExploitAvailable == false),
    IsInternetFacing = max(iff(IsInternetFacing == true, 1, 0))
    by DeviceId, DeviceName;
let configScores = DeviceTvmSecureConfigurationAssessment
| where IsApplicable == true and IsCompliant == false
| summarize FailedConfigs = dcount(ConfigurationId) by DeviceId;
vulnScores
| join kind=leftouter configScores on DeviceId
| extend FailedConfigs = coalesce(FailedConfigs, 0)
| extend RiskScore =
    (CritExploit * 10) +
    (HighExploit * 5) +
    (CritNoExploit * 3) +
    (IsInternetFacing * 20) +
    (iff(FailedConfigs > 5, 15, 0))
| extend RiskTier = case(
    RiskScore >= 100, "🔴 Critical",
    RiskScore >= 50,  "🟠 High",
    RiskScore >= 20,  "🟡 Medium",
    "🟢 Low")
| order by RiskScore desc
| project RiskTier, DeviceName, RiskScore, CritExploit,
          HighExploit, IsInternetFacing, FailedConfigs
| take 50

💡 Pro Tip: Adjust the scoring weights based on your threat model. If you're in healthcare, increase the internet-facing multiplier. If you're in financial services, increase the weight for configuration failures. The model should reflect your organisation's risk tolerance, not a generic framework.

Step 5 · Track Exposure Score Trends

The exposure score is your north-star metric for attack surface management. Tracking it over time reveals whether your remediation efforts are outpacing new vulnerabilities, whether new deployments are introducing risk, and whether your overall security posture is improving or degrading.

Monitor the organisation exposure score weekly
Track the impact of remediation activities on the score
Set targets: reduce exposure score by 20% per quarter
Report on exposure score trends to leadership monthly

// ============================================================
// Exposure Trend: Exploitable Vulnerability Count Over Time
// ============================================================
// WHAT: Tracks the daily count of unique exploitable CVEs
//       across the fleet over the past 30 days.
// WHY:  If the line is going up, new vulns are outpacing your
//       patching. If it's going down, remediation is winning.
DeviceTvmSoftwareVulnerabilities
| where Timestamp > ago(30d)
| where IsExploitAvailable == true
| where VulnerabilitySeverityLevel in ("Critical", "High")
| summarize
    UniqueCVEs     = dcount(CveId),
    AffectedDevices = dcount(DeviceId)
    by Day = bin(Timestamp, 1d)
| order by Day asc
| project Day, UniqueCVEs, AffectedDevices

💡 Pro Tip: Present the exposure trend as a chart in your monthly security review. Leadership responds better to trend lines than raw numbers. A declining curve proves your programme is working; a flat or rising curve justifies additional budget for remediation resources.

Step 6 · Build Attack Surface KQL Queries

KQL is the powerhouse behind proactive attack surface monitoring. Beyond the pre-built dashboard, custom queries let you build remediation priority lists that combine vulnerability severity, exploit availability, device criticality, and business context. This step creates a remediation prioritisation query that ranks every open vulnerability by real-world risk.

// ============================================================
// Remediation Prioritisation: Top CVEs by Fleet Impact
// ============================================================
// WHAT: Ranks CVEs by the number of affected devices, showing
//       which single patch would remediate the most devices.
// WHY:  Patching one widely-deployed CVE can remediate hundreds
//       of devices in a single maintenance window - maximum ROI.
DeviceTvmSoftwareVulnerabilities
| where VulnerabilitySeverityLevel in ("Critical", "High")
| summarize
    AffectedDevices = dcount(DeviceId),
    ExploitAvail    = max(iff(IsExploitAvailable == true, "Yes", "No")),
    InternetFacing  = dcountif(DeviceId, IsInternetFacing == true),
    Software        = make_set(SoftwareName, 3)
    by CveId, VulnerabilitySeverityLevel
| extend Priority = case(
    ExploitAvail == "Yes" and InternetFacing > 0, "🔴 P0 - Immediate",
    ExploitAvail == "Yes", "🟠 P1 - Urgent",
    InternetFacing > 0, "🟡 P2 - High",
    "🟢 P3 - Standard")
| order by AffectedDevices desc
| project Priority, CveId, VulnerabilitySeverityLevel,
          AffectedDevices, InternetFacing, ExploitAvail, Software
| take 30

// WHAT: Summarize exploitable vulnerability exposure by device group (MachineGroup)
// WHY: Shows which business units or device groups carry the most risk,
//      enabling targeted remediation campaigns per team/department.
// HOW: Joins DeviceInfo (latest device metadata) with vulnerability data
//   filtered to Critical/High severity CVEs with known exploits
// KEY FIELDS:
//   MachineGroup - the device group assigned in Defender portal (e.g., "Finance Servers",
//     "Engineering Workstations") - used for RBAC and reporting segmentation
//   IsExploitAvailable - true means a public exploit exists for this CVE
// OUTPUT: Device group, total devices, and total exploitable vulnerabilities per group
DeviceInfo
| where Timestamp > ago(1d)
| summarize arg_max(Timestamp, *) by DeviceId
| join kind=inner (
    DeviceTvmSoftwareVulnerabilities
    | where VulnerabilitySeverityLevel in ("Critical", "High")
    | where IsExploitAvailable == true
    | summarize ExploitableVulns = count() by DeviceId
) on DeviceId
| summarize TotalDevices = count(), TotalExploitableVulns = sum(ExploitableVulns) by MachineGroup
| order by TotalExploitableVulns desc

💡 Pro Tip: Create a custom detection rule from the P0 priority query. When a new CVE appears that is both exploitable AND on an internet-facing device, you want an immediate alert - not a weekly review. These are the vulnerabilities that get exploited within hours of disclosure.

Step 7 · Integrate with Network Security

Vulnerability data is most powerful when it informs network segmentation decisions. By sharing DVM exposure findings with your network security team, you can validate that firewall rules actually protect the assets DVM identifies as vulnerable, and create micro-segmentation plans that isolate high-risk devices until they can be patched.

Share exposure findings with the network security team
Validate firewall rules against DVM-identified exposed services
Create network segmentation recommendations for high-exposure devices
Coordinate with cloud security for Azure NSG and AWS security group alignment

// ============================================================
// Network Exposure Correlation: Vulnerable Devices by Subnet
// ============================================================
// WHAT: Groups vulnerable devices by their network subnet to
//       identify which network segments carry the most risk.
// WHY:  Network segmentation is a compensating control. If you
//       can't patch immediately, isolating the vulnerable subnet
//       limits blast radius until remediation is complete.
DeviceTvmSoftwareVulnerabilities
| where VulnerabilitySeverityLevel in ("Critical", "High")
| where IsExploitAvailable == true
| summarize ExploitableVulns = dcount(CveId) by DeviceId, DeviceName
| join kind=inner (
    DeviceNetworkInfo
    | where Timestamp > ago(1d)
    | mvexpand todynamic(IPAddresses)
    | extend IPAddress = tostring(IPAddresses.IPAddress)
    | extend Subnet = strcat(
        extract("^(\\d+\\.\\d+\\.\\d+)", 1, IPAddress), ".0/24")
    | where IPAddress !startswith "127."
    | summarize arg_max(Timestamp, Subnet) by DeviceId
) on DeviceId
| summarize
    DevicesAtRisk = dcount(DeviceId),
    TotalVulns    = sum(ExploitableVulns),
    Devices       = make_set(DeviceName, 5)
    by Subnet
| order by TotalVulns desc
| project Subnet, DevicesAtRisk, TotalVulns, Devices

💡 Pro Tip: Share this subnet-level risk view with your firewall team. If a subnet has 10+ critical exploitable vulnerabilities, consider adding an emergency ACL to block inbound connections until those devices are patched. This buys time without requiring a full patching cycle.

Step 8 · Monitor Newly Exposed Assets

New assets appear constantly: a developer spins up a test VM, a vendor installs monitoring software, or a cloud migration adds internet-facing services. This step uses PowerShell to generate a comprehensive exposure report that can be emailed to leadership weekly, providing visibility into new and changing attack surfaces.

Set up custom detection rules for newly discovered internet-facing vulnerabilities
Create alerts for new devices with critical exposure scores
Monitor for newly discovered software with known exploits
Schedule weekly reviews of new recommendations

# ============================================================
# Generate Weekly Exposure Report
# ============================================================
# WHAT: Pulls exposure data from the Defender API and generates
#       a CSV report with per-device vulnerability summaries,
#       internet-facing status, and risk scores.
# WHY:  Automated weekly reports ensure leadership has continuous
#       visibility into the attack surface without relying on
#       manual portal exports.
# PREREQ: Connect-MgGraph -Scopes "SecurityEvents.Read.All"
# ============================================================

Connect-MgGraph -Scopes "SecurityEvents.Read.All"

# Pull vulnerability data
$vulns = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/security/vulnerabilities/softwareVulnerabilities?`$top=5000" `
    -OutputType PSObject

# Build exposure summary per device
$deviceExposure = $vulns.value |
    Group-Object -Property deviceName |
    ForEach-Object {
        $criticalCount = ($_.Group | Where-Object {
            $_.vulnerabilitySeverityLevel -eq 'Critical' -and
            $_.isExploitAvailable -eq $true
        }).Count
        $highCount = ($_.Group | Where-Object {
            $_.vulnerabilitySeverityLevel -eq 'High' -and
            $_.isExploitAvailable -eq $true
        }).Count
        $internetFacing = ($_.Group | Where-Object {
            $_.isInternetFacing -eq $true
        }).Count -gt 0

        [PSCustomObject]@{
            DeviceName       = $_.Name
            TotalVulns       = $_.Count
            CritExploitable  = $criticalCount
            HighExploitable  = $highCount
            InternetFacing   = $internetFacing
            RiskScore        = ($criticalCount * 10) + ($highCount * 5) +
                              $(if ($internetFacing) { 20 } else { 0 })
        }
    } |
    Sort-Object RiskScore -Descending

# Export report
$reportPath = "C:\Reports\DVM-Exposure-$(Get-Date -Format 'yyyy-MM-dd').csv"
$deviceExposure | Export-Csv -Path $reportPath -NoTypeInformation
Write-Host "✅ Exposure report: $reportPath" -ForegroundColor Green
Write-Host "   Devices analysed:  $($deviceExposure.Count)"
Write-Host "   Critical risk:     $(($deviceExposure | Where-Object { $_.RiskScore -ge 100 }).Count)"
Write-Host "   Internet-facing:   $(($deviceExposure | Where-Object { $_.InternetFacing }).Count)"

💡 Pro Tip: Schedule this script as a weekly Azure Automation runbook or a scheduled task on your security operations server. Email the CSV to the security leadership distribution list every Monday morning so they start the week with fresh attack surface data.

Step 9 · Generate Attack Surface Reports

Executive-level attack surface reports must speak the language of risk, not CVE IDs. This step transforms raw vulnerability data into business-relevant metrics: exposure score trends, devices at risk from active campaigns, remediation progress as a percentage, and estimated risk reduction from planned patches.

Export exposure data for executive reporting
Include: exposure score trend, top exposed devices, remediation progress, internet-facing risks
Map findings to MITRE ATT&CK Initial Access techniques
Provide actionable recommendations with estimated risk reduction impact

// ============================================================
// Executive Dashboard: Attack Surface Summary
// ============================================================
// WHAT: Single-query executive summary showing total exposure,
//       remediation coverage, and internet-facing risk.
// WHY:  Provides a 30-second snapshot for CISO briefings.
DeviceTvmSoftwareVulnerabilities
| summarize
    TotalDevices        = dcount(DeviceId),
    TotalCVEs           = dcount(CveId),
    CriticalCVEs        = dcountif(CveId, VulnerabilitySeverityLevel == "Critical"),
    ExploitableCVEs     = dcountif(CveId, IsExploitAvailable == true),
    InternetFacingDevs  = dcountif(DeviceId, IsInternetFacing == true),
    CritInternetFacing  = dcountif(CveId,
        VulnerabilitySeverityLevel == "Critical" and
        IsExploitAvailable == true and
        IsInternetFacing == true)
| extend RiskLevel = case(
    CritInternetFacing > 10, "🔴 CRITICAL - Internet-facing exploitable CVEs exceed threshold",
    CritInternetFacing > 0,  "🟠 HIGH - Some internet-facing exploitable CVEs remain",
    ExploitableCVEs > 50,    "🟡 MEDIUM - Internal exploitable CVEs need attention",
    "🟢 LOW - Exposure well managed")
| project TotalDevices, TotalCVEs, CriticalCVEs,
          ExploitableCVEs, InternetFacingDevs,
          CritInternetFacing, RiskLevel

💡 Pro Tip: Map your top exposed CVEs to MITRE ATT&CK T1190 (Exploit Public-Facing Application) and T1133 (External Remote Services) in your report. This connects vulnerability data to real-world attack techniques and helps non-technical stakeholders understand why specific patches are urgent.

Step 10 · Build a Continuous Attack Surface Management Program

Attack surface management is not a project with an end date - it is an ongoing programme. This final step establishes the operational cadence, roles, and metrics that turn one-time assessments into a sustainable, continuous process that keeps your organisation's exposure under control.

Weekly: Review new recommendations and exposure changes
Monthly: Report exposure score trends, remediation progress
Quarterly: Comprehensive attack surface review with penetration test correlation
Annually: Update attack surface reduction strategy based on threat landscape changes

💡 Pro Tip: Tie your attack surface KPIs to executive performance metrics. When the CISO's quarterly objectives include "reduce exposure score by 15%" and "eliminate all P0 internet-facing vulnerabilities within 72 hours", the entire organisation prioritises attack surface reduction.

Resource	Description
Exposure score overview	Understand how DVM calculates your organisation's exposure score
DeviceTvmSoftwareVulnerabilities	Advanced Hunting schema for software vulnerability data
DeviceNetworkInfo	Network configuration and connectivity data per device
Browser extensions inventory	Discover and assess browser extension risks across your fleet
Remediation activities	Create and track vulnerability remediation tasks
MITRE ATT&CK T1190	Initial Access via Exploit Public-Facing Application