Vulnerabilities Without CVEs: Governing the Dark Matter of Internal and Unknown Software

Vulnerabilities Without CVEs: Governing the Dark Matter of Internal and Unknown Software

Speakers: Josh Skorich, Spektion

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=dMejnDGQHYo

Overview

In the realm of cybersecurity, traditional vulnerability management (VM) programs often operate under a critical blind spot: the vast expanse of software that exists without a publicly recognized identifier like a Common Vulnerabilities and Exposures (CVE) ID. Josh Skorich's talk, "Vulnerabilities Without CVEs: Governing the Dark Matter of Internal and Unknown Software," delivered at VulnCon, meticulously dissects this pervasive issue. Skorich, drawing from a decade of offensive security experience, argues that the very systems designed to protect organizations are structurally incapable of identifying the vulnerabilities most commonly exploited in real-world compromises.

The core premise of the talk is that while current VM practices excel at tracking and remediating known vulnerabilities in commercially published software (often referred to as "World 1" software), they entirely miss a significant portion of an organization's attack surface. This "dark matter" includes internal tools, legacy applications, temporary services that became permanent, and even AI-generated code—all operating with real privileges and network reach but without formal tracking or advisory ecosystems. Skorich's presentation challenges the industry to look beyond CVEs and shift its focus from external inference to internal host telemetry, proposing a pragmatic framework for identifying and managing these invisible, yet critical, risks.

This talk is crucial for security professionals because it exposes a fundamental flaw in how many organizations perceive and manage risk. By demonstrating that attackers predominantly exploit uncataloged software, Skorich compels a re-evaluation of vulnerability assessment methodologies. He not only highlights the problem but also provides actionable, technically detailed strategies for leveraging existing operating system primitives to uncover these hidden vulnerabilities, integrate them into current VM workflows, and implement effective remediation strategies, thereby enhancing an organization's true security posture.

Background

▶ Watch: Vulnerabilities without CVEs: The hidden security problem. (0:00)

The modern cybersecurity landscape is heavily reliant on the CVE ecosystem, a monumental and largely successful coordination effort within the industry. This system, along with vulnerability scanners and patch management programs, forms the backbone of most vulnerability management initiatives. Organizations invest heavily in tools that scan for known product versions, match them against CVE databases, and prioritize remediation based on severity scores like CVSS. On paper, this approach yields impressive results: dashboards show green, SLAs are met, and remediation rates trend positively. Yet, as Skorich points out, this sophisticated machinery often fails to prevent actual compromises.

Skorich's decade of experience in offensive security, including red teaming and adversary simulation, consistently revealed a stark disconnect. The paths to compromise almost never traversed the vulnerabilities tracked by a customer's VM program. Instead, attackers gravitated towards "weird stuff": abandoned services with no clear owner, internal tools hastily written by former employees, temporary migration services left running indefinitely, niche vendor applications without public advisory ecosystems, or even utilities baked into base images years ago that execute with root privileges. More recently, the proliferation of AI-generated code, spun up for quick solutions without proper vetting, adds another layer to this untracked software.

The fundamental issue, Skorich explains, lies in a structural blind spot within the CVE-centric model. For a vulnerability finding to be created, a scanner must first discover an asset, fingerprint its software, identify a product name and version, and then look up that information against a CVE database. Every step after initial asset discovery hinges on successful software identification. If the software cannot be identified—because it's custom, too old, from an obscure vendor, or simply never intended for formal tracking—it cannot be matched to a CVE. No CVE means no finding, no dashboard entry, and thus, no action. The risk, however, does not disappear; it merely becomes invisible. Skorich emphasizes this point with an analogy: if 20% of servers lacked antivirus or EDR, it would trigger an emergency; yet, a similar percentage of software often operates completely outside the vulnerability management system, with zero assessment coverage.

Skorich categorizes software into three "worlds" to illustrate this blind spot:

1. Known Universe: This is the domain of named products with recognized versions, scanner fingerprints, CVE coverage, and published patches. This is where traditional VM programs effectively operate.
2. Known but Uncovered Software: Here, the software can be named and is known to exist, but it lacks a formal advisory ecosystem. Examples include regional vendors, forked projects that diverged, or abandoned products whose vendors were acquired and shut down. Organizations know these exist but receive no alerts when problems arise.
3. Dark Matter: This represents software that runs, possesses privileges, and impacts production, yet "nobody really knows what it is." This includes mystery binaries, temporary services, old container images, and processes without clear owners.

While most vulnerability programs diligently measure and remediate risks in World 1, attackers, according to Skorich, are "perfectly happy living in Worlds 2 and 3," precisely because "nobody was watching." This invisible attack surface is where sophisticated offensive engagements often yield the most interesting and impactful results, chainable into significant compromises.

Key Findings

▶ Watch: Shift from external scanning to host telemetry. (10:05)

The central thesis of Skorich's talk is that the primary problem in vulnerability management is not the intricacies of severity scoring or SLA tuning, but rather identity. The inability to identify and name software components—especially those developed internally, inherited from acquisitions, or spun up for temporary use—renders them invisible to traditional CVE-driven vulnerability management programs. This "dark matter" software, despite often running with significant privileges and network reach, produces no findings when scanned, creating a false sense of security.

To counter this, Skorich proposes a paradigm shift: instead of inferring vulnerabilities from the outside using network scanners, security teams must "ask the host" by observing everything from the inside. The host operating system, unlike an external scanner, possesses definitive knowledge of what ran, who spawned it, with what privileges, and what resources it accessed. This internal telemetry provides the granular, actionable evidence needed to uncover vulnerabilities in uncataloged software.

The talk highlights specific categories of host telemetry as crucial for this approach:

• Process Execution: What ran, where it lived, who spawned it, with what arguments, and its privilege context (user ID, capabilities, service account status).
• Network Behavior: Any open sockets, inbound connections, egress addresses, and their associated process IDs.
• File and Disk Activity: What files were read or written, temporary file usage, access to configurations or environment variables, and changes to executables.

A critical finding is the importance of process lineage. An identical system call, such as a shell invocation, can be benign (e.g., spawned by cron for a backup script) or highly malicious (e.g., spawned by a web-facing process in response to interpolated input). Host telemetry, when properly captured, provides this parentage information for free, allowing for accurate context-dependent analysis.

Skorich introduces the concept of "Synthetic CVEs" as a practical framework for integrating these findings into existing vulnerability management programs. Instead of inventing new queues or dashboards, synthetic CVEs leverage the same established workflows (finding format, severity scale, SLAs, owner assignment, leadership dashboards) but derive their identification from host evidence and observed behavior (e.g., location, binary name) rather than a product+version match against a public advisory. Remediation for synthetic CVEs focuses on restricting, isolating, replacing, or removing the problematic software, as traditional patching may not be an option.

The talk identifies three core classes of observable risks that are prevalent in "dark matter" software and can be detected using host telemetry:

1. Memory and Permission Boundaries: Processes operating with excessive privileges or attempting to read/write to sensitive memory regions (e.g., LSASS) or protected kernel areas without legitimate cause.
2. Network Posture: Undocumented or unauthenticated listeners on production ports, and critically, TLS clients explicitly disabling certificate validation (expiration, revocation, hostname mismatch) at the point of socket creation.
3. Execution Path Integrity: Vulnerabilities like unquoted service paths on Windows, ambiguous binary references, or DLL search order hijacks, where services resolve through world-writable directories, allowing attackers to inject malicious executables. Skorich notes he has found 40 such examples in "well-known software" alone.

These findings collectively underscore that a comprehensive vulnerability management strategy must extend beyond public CVEs to actively discover and address the "dark matter" of unknown and internal software, using internal host telemetry as the primary investigative tool.

Technical Deep Dive

▶ Watch: Leveraging Event Tracing for Windows (ETW) telemetry. (26:10)

The cornerstone of Skorich's proposed solution is a pivot from external, inference-based scanning to internal, observation-based host telemetry. This approach leverages the operating system's inherent ability to see and record every action performed by software running on it. Skorich emphasizes that this doesn't require proprietary tools, but rather a deliberate subscription to and correlation of standard, low-level operating system primitives. He outlines five key technologies—"the seams"—across Windows, Linux, and macOS that enable this deep visibility.

Windows: Microsoft Detours

Microsoft Detours is presented as the oldest and most application-proximate technique. Dating back to the 1990s, Detours allows for API hooking by patching the prologue of a target Win32 API function to redirect its execution to a custom function. This typically involves DLL injection at process creation. Once hooked, the custom function can log the call, inspect arguments, and perform instrumentation before "trampolining" back to the original function. From the application's perspective, nothing has changed, but the security team gains a perfect, structured record of what the application requested.

For instance, by detouring CreateFile, one can observe every file path an application attempts to access, including system DLLs being loaded, configuration files read, or sensitive network shares accessed. Crucially, Detours sees the exact string passed by the program before the OS interprets it, revealing vulnerabilities like DLL search order hijacks (e.g., LoadLibrary with a bare DLL name) or unquoted service paths (e.g., CreateProcess with an unquoted service path containing spaces). While challenging to implement (per-process, user-mode only, potential friction with modern Windows security features like CFG/Code Integrity), Detours offers unparalleled application-layer fidelity for specific behavior classes.

Windows: Event Tracing for Windows (ETW)

For broader, scalable telemetry across an entire Windows environment, Skorich highlights Event Tracing for Windows (ETW). Introduced in Windows 2000, ETW is a kernel-grade eventing system known for its low overhead. Every modern Windows component—the kernel, network stack, registry, DNS, firewall—continuously emits structured events to ETW providers. The key is to subscribe to and consume these events. This process doesn't increase system load as the events are already being generated; it merely involves listening.

ETW provides rich, correlated data stream. For example, subscribing to the NT kernel session (or newer kernel loggers) yields:

• Process events: Process ID (PID), parent process ID, full image path, command line, user account.
• Network events: TCP connect sockets tied to PIDs, source/destination.
• Configuration changes: Registry modifications.

All this data is correlated by PID, offering kernel-grade fidelity in real-time. Skorich points out that the evidence described in the PDF converter case study—binary path, parent process, immediate outbound connection—can all be derived from ETW data, which is readily available on every Windows machine.

Linux: eBPF + LSM

On Linux, eBPF (extended Berkeley Packet Filter), combined with the Linux Security Module (LSM) framework, is described as one of the most exciting telemetry primitives in recent years. eBPF allows for writing small, verified programs that execute directly within the kernel in response to specific events (e.g., syscalls like execv). The kernel verifier ensures these programs cannot crash the kernel, loop indefinitely, or read arbitrary memory, providing the safety of user space with the visibility of kernel space, all without requiring a kernel module to be shipped.

By setting up trace points for execv syscalls, eBPF programs can capture the PID, parent PID, and command-line arguments of every executed process. Attaching to LSM hooks—the same framework powering SE Linux and AppArmor—allows not only observation but also potential intervention in security-relevant events. For instance, an eBPF program can detect when a "PDF converter" executes, opens /etc/password (anomalous), makes an outbound network call, and then spawns sh as a child process. Every anomalous event, correlated by PID and parent PID, helps reconstruct a full exploitation chain in real-time, all without a user-space agent.

macOS: Endpoint Security Framework (ESF) & Network Extension

Apple's approach to endpoint telemetry on macOS involves two distinct frameworks. The Endpoint Security Framework (ESF) is the successor to deprecated kernel extensions, providing a stable, sandboxed API for process, file, and code signing events via system extensions (available since Catalina). ESF allows subscribing to event types like exec and open.

For an exec event, ESF provides the target process, executable path, and crucial code signing metadata (signing identifier, team identifier, whether it's a platform binary, ad-hoc signed, or entirely unsigned). Skorich highlights that on a modern Mac, any unsigned binary executing in production is itself a finding, as the host explicitly reports missing provenance. This immediately flags anomalies like an unsigned PDF converter opening master.pass, spawning a legitimate sh binary (but parented under the unsigned converter), which then spawns curl to an external IP.

For network activity on macOS, the Network Extension framework is used. Apple separates this to ensure user opt-in for privacy concerns related to network traffic monitoring. The Network Extension provides full attribution for network communications (who is talking to whom) directly from the kernel, tied to the process ID, without resorting to polling. This allows detection of events like plaintext egress from a child process.

By combining these macOS primitives, security teams can build a defensible finding, detailing what ran, what it touched, who it communicated with, and with what privileges, without needing to guess about the software's identity. The overarching technical message is that these operating system primitives, though diverse, offer the necessary depth and correlation to uncover the "dark matter" vulnerabilities that traditional scanners miss.

Demo / Proof of Concept

▶ Watch: Utilizing eBPF and LSM for Linux telemetry. (29:00)

While the talk did not feature a live, interactive demonstration of tools, Josh Skorich effectively illustrated the concepts through several detailed "case studies" and "detection patterns" derived from real-world offensive engagements. These examples serve as proof of concept, showing how host telemetry can uncover vulnerabilities that traditional CVE-based scanners would completely miss.

Case Study 1: The Legacy PDF Converter

This scenario involved a web-facing host running an old PDF converter software. The vendor had been acquired six years prior, and the product was discontinued, leaving no support or advisory ecosystem. The customer barely remembered installing it. The converter was listening on port 8080, reachable from production traffic. When an HTTP request came in, the converter spawned a shell with interpolated input, immediately executed an arbitrary command, and made an outbound connection to an external IP.

• Why scanners failed: There was no CVE for this software because the vendor ceased to exist, and thus no CPE (Common Platform Enumeration) match could be made.
• Host telemetry evidence: An unknown binary (or one with no CPE), a web-parented process, spawning a shell execution with interpolated input (indicating CWE-78: Command Injection), followed by immediate egress to an external IP. All this was captured during the software's execution.

Case Study 2: The Service Nobody Deployed

This involved a service running on a production host that was reading from a customer database and writing bulk data to S3. Despite its critical function, it was not in any inventory system, CMDB, or SBOM (Software Bill of Materials), and had no known owner. Multiple other production services depended on it, yet it remained invisible to standard security assessments.

• Why scanners failed: No formal record meant no product identification, hence no CVEs or associated findings.
• Host telemetry evidence: An unknown binary, performing reads from a PostgreSQL database, executing bulk writes to S3, and demonstrating dependencies from other production services. The finding was defensible solely on this behavioral evidence.

Case Study 3: The Unknown Fetcher

A random binary was found listening on port 8080, accepting URLs as input. Critically, it repeatedly made requests to 169.254.x.x—the well-known address for cloud metadata endpoints in AWS and Azure. This workload also held projected credentials with broad permissions.

• Why scanners failed: Again, an unknown binary with no formal product identity.
• Host telemetry evidence: The binary listening on 8080, accepting URLs, making requests to the metadata endpoint, and holding broad projected credentials. This pattern indicated Server-Side Request Forgery (SSRF) as a direct path to cloud account compromise.

Skorich also elaborated on specific detection patterns for common vulnerability classes:

• Execution Path Integrity (Unquoted Service Paths): On Windows, a service or CreateProcess call with an unquoted path containing spaces (e.g., C:\Program Files\Common.exe) can lead to the OS attempting to execute C:\Program.exe first. If an attacker can drop a malicious program.exe in C:\ (or, more realistically, a world-writable directory like C:\Users\Public), they achieve execution, often with elevated privileges. Host telemetry, particularly from Detours, can capture the unquoted path string passed by the application, revealing this 20-year-old bug that is still widely exploited. Skorich claims to have found "probably 40 examples" of this in well-known software.

• Insecure TLS Clients: This pattern involves applications that go through the effort of creating a TLS socket but then explicitly disable critical certificate verifications (e.g., expiration, revocation, hostname matching) during session establishment.
• Why network monitoring fails: On-the-wire inspection would only see a legitimate TLS connection with a strong cipher.
• Host telemetry evidence: Endpoint telemetry (via Detours on Windows, ESF/Network Extension on Mac) can capture the exact arguments or flags used during socket creation, revealing the intentional choice to ignore certificate validation. This allows defenders to identify clients vulnerable to man-in-the-middle attacks.

• Memory and Permission Boundaries: This involves detecting processes reading from or writing to another process's memory without legitimate reason, or any process attempting to access protected kernel regions.
• Host telemetry evidence: Modern OSes emit memory operation events. Detection involves identifying cross-process memory access where source and target PIDs differ without justification, or access to sensitive regions like LSASS memory (where Windows stores cached credentials) by tools like a PDF converter (as opposed to legitimate identity management tools).

These examples powerfully demonstrate that detailed host telemetry provides the necessary context and evidence to transform invisible risks into actionable vulnerability findings, even in the absence of traditional CVEs.

Defensive Implications

▶ Watch: Q&A: Why not just fix internal apps? (48:30)

The central defensive implication of Skorich's talk is the urgent need to expand vulnerability management programs beyond the confines of CVE-tracked software. Organizations must recognize and actively address the "dark matter" that often serves as the true path to compromise. Crucially, Skorich advises against building entirely new, parallel security programs, which would likely face funding issues, create competing priorities, and lead to unclear ownership. Instead, he advocates for integrating the detection of "synthetic CVEs" into existing VM frameworks.

Here's how defenders can operationalize this:

1. Integrate "Synthetic CVEs" into Existing Workflows:

• Same Queue, Different Source: Leverage the established vulnerability queue, but populate it with findings identified via host telemetry rather than public advisories.
• Standardized Format and Severity: Ensure synthetic findings adhere to the organization's existing finding format and severity scales (e.g., CVSS-like scoring based on impact and exploitability observed via telemetry).
• Existing SLAs and Ownership: Assign remediation SLAs and ownership using current processes.
• Unified Dashboard: Report these findings in the same dashboards that leadership already reviews, providing a more accurate picture of the organization's true risk posture.

1. Shift in Identification and Remediation:

• Identification: Traditional CVEs are identified by product and version, sourced from public advisories, and fixed by patches or upgrades. Synthetic CVEs, conversely, are identified by host evidence and behavior (e.g., binary path, process name, observed network connections). They are sourced directly from endpoint telemetry.
• Remediation: Since "dark matter" software often lacks a vendor or maintainer, traditional patching is frequently impossible. Remediation for synthetic CVEs focuses on:
• Harden & Block: Implement application whitelisting (e.g., AppLocker on Windows, Mandatory Access Control with SELinux on Linux), and host-based firewalls to prevent dangerous behavior.
• Monitor & Detect: Feed the rich host telemetry into existing EDR and SIEM solutions, building detection logic around the identified patterns (e.g., web-to-shell, unauthenticated data access, metadata endpoint requests).
• Isolate & Restrict: Employ network segmentation or apply least privilege principles to contain the blast radius of vulnerable software. Strip unnecessary capabilities or permissions.
• Eliminate & Decommission: If software has no clear owner or known business function, the most effective remediation might be to remove it entirely. This often quickly reveals its actual dependencies or lack thereof.

1. Start Small and Be Defensible:

• Begin by implementing detection for a handful of high-impact patterns (e.g., web-parented processes spawning shells, unauthenticated data store access, insecure TLS configurations, unquoted service paths).
• Ensure findings are structured and defensible, backed by concrete host telemetry evidence.
• The requirements are modest: a method for gathering process execution telemetry, basic network visibility (as provided by the OS primitives discussed), and sufficient inventory context to differentiate between known and unknown software.

By adopting this approach, defenders can transition from only governing the "street light" (public CVEs) to governing the "street" itself, uncovering and mitigating the pervasive, yet often invisible, vulnerabilities that truly lead to compromise.

Key Takeaways

• The "Dark Matter" Problem: Traditional CVE-based vulnerability management is structurally blind to a significant portion of an organization's attack surface, including internal tools, legacy applications, temporary services, and AI-generated code, which often lack public identifiers and advisory ecosystems.
• Attackers Exploit the Invisible: Attackers consistently target these uncataloged "dark matter" vulnerabilities because they operate outside the scope of conventional security monitoring, leading to a false sense of security despite robust CVE management programs.
• "Ask the Host" for True Visibility: Shifting from external inference (scanners) to internal host telemetry (leveraging OS primitives like Microsoft Detours, ETW, eBPF, ESF, and Network Extensions) provides definitive, real-time evidence of process execution, network behavior, and file activity, including crucial process lineage.
• Synthetic CVEs Integrate with Existing VM: Organizations can generate "Synthetic CVEs" from host telemetry and feed them into existing vulnerability management programs, utilizing current queues, severity scales, SLAs, and dashboards, thereby avoiding the creation of parallel, disjointed security efforts.
• Focus on Observable Risk Patterns: Prioritize detection and mitigation of common "dark matter" vulnerability classes, such as execution path integrity issues (e.g., unquoted service paths), insecure network posture (e.g., TLS clients disabling certificate validation), and unauthorized memory/permission boundary crossings (e.g., processes accessing LSASS memory).
• Diverse Remediation Strategies: For software without traditional vendor support, remediation for synthetic CVEs emphasizes hardening, blocking, continuous monitoring, isolation, restriction of privileges, or outright elimination/decommissioning, rather than relying solely on patching.

About the Speaker(s)

Josh Skorich is an expert in offensive security, having spent approximately a decade engaged in red team operations and adversary simulation. In his role at Spektion, he focuses on understanding and addressing the critical gap between what traditional vulnerability management programs track and the actual paths attackers take to compromise systems. His experience breaking into environments and observing how vulnerabilities are truly exploited has informed his perspective on the limitations of CVE-centric security models and the necessity of looking at "dark matter" software.