What if security teams could combine knowledge of which systems are vulnerable with evidence of how an attacker is actually moving through the network?
The gap between exposure and exploitation
Security teams face two critical questions when investigating a suspected compromise:
- What systems could an attacker exploit?
- What is the attacker actually doing on the network?
Answering either question independently provides valuable information. Answering them together creates a more complete picture of the potential impact of an attack.
Exposure management platforms such as Tenable help organizations understand their attack surface by identifying vulnerabilities, affected assets, and potential attack paths. This intelligence helps defenders understand where an attacker might find opportunities to move through an environment.
But exposure alone doesn't tell the entire story.
A vulnerable system may never communicate with a compromised host. Conversely, a system with relatively few known vulnerabilities may be actively involved in suspicious network activity.
This is where network evidence becomes essential.
Corelight provides visibility into observed network communications and behavior, helping security teams investigate suspicious connections, identify lateral movement, and reconstruct attacker activity.
Tenable helps identify what could be exploited. Corelight helps reveal what is actually happening.
By combining these complementary perspectives through agentic AI, security teams can move from understanding theoretical exposure to investigating the potential blast radius of a compromise.
Introducing a new approach to AI-driven investigations
As part of our participation in Tenable OPEN for AI, Corelight is exploring a joint use case that combines Corelight’s MCP Server with Tenable's Hexa AI MCP Server.
Model Context Protocol (MCP) provides a standardized interface through which AI applications can interact with external tools and data sources.
Rather than relying on a tightly coupled integration between two security products, an AI agent can use both MCP servers to retrieve the information needed for an investigation.
Corelight provides the network evidence. Tenable provides the exposure intelligence. The AI agent connects the two.
The result is a proposed workflow that could help analysts answer a question that often requires considerable manual investigation:
"If this host has been compromised, which other systems could the attacker target next?"
Following the attack: Two investigations from a working lab
To test this workflow, we connected an AI agent to the Corelight MCP Server and the Tenable MCP Server in a live lab network.
Corelight sensors monitor the user, management, and DMZ network segments. A physical sensor, Lab-AP200, receives mirrored traffic from the network switches, and virtual sensors Lab-vSensor1 through Lab-vSensor6 monitor the hypervisors' virtual switches. Tenable Vulnerability Management scans the same assets daily.
The agent had no shell access to any host. Everything it concluded came from network evidence and exposure data.
Here are two of its investigations. The first starts from a real alert and ends with a decision to deprioritize it. The second asks the blast-radius question directly, and the answer is less reassuring.
Example 1: A critical alert with no blast radius (from live traffic)
Step 1: Identify suspicious network behavior
Two Corelight sensors, Lab-vSensor5 and Lab-vSensor6, raised the same critical-severity alert: an attempt to exploit Log4Shell (CVE-2021-44228)—a remote code execution flaw in a widely used open-source logging library that is listed in CISA's Known Exploited Vulnerabilities catalog.
The source was a syslog server. The target was the organization's SIEM log indexer.
On its face, this looks like lateral movement aimed at the SIEM.
The agent retrieved the full session from Corelight. The connection used the port the SIEM's log forwarders use to deliver data to the indexer.
The payload was not an exploit addressed to the SIEM. It was a batch of log records being forwarded. One line from the server's DNS log contained the Log4Shell string, along with the address of the host that had originally sent it. The string's callback domain ended in nessus.org.
Corelight also showed that this original sender had swept 54 hosts across thousands of ports during the same period.
Step 2: Identify vulnerable targets
The agent then asked Tenable two questions.
Who is the original sender? Tenable's scan records answered directly. That address was the scanner used for the credentialed scans of the management and DMZ networks, and those scans were running when the alert fired.
Which assets are vulnerable to CVE-2021-44228? Tenable reported no finding for the CVE on any asset.
It did inventory the logging library on ten hosts. On nine of them, the "install" was a string match inside unrelated operating system packages, with no version and none of the vulnerable lookup code. The tenth was the SIEM indexer, where Tenable's earlier findings for older versions of the library were now marked fixed.
Step 3: Correlate exposure with network evidence
Exposure data said no host should be exploitable. Network evidence confirmed that none were.
Typically, a successful Log4Shell exploit makes the victim look up and connect to the attacker's callback address. During the scan, Corelight recorded 1,672 callback hostnames. Every one was first queried by the scanner itself; internal DNS servers only forwarded those queries. Neither the syslog server nor the SIEM indexer made an outbound LDAP connection.
The network evidence also explained why the alert existed at all. Alerts on the scanner's own traffic had already stopped that afternoon. What remained were copies of its probes carried inside the logging pipeline, where the visible source was the log forwarder, not the scanner. An allowlist of scanner addresses cannot catch that.
Step 4: Assess the potential blast radius
The blast radius was zero.
The agent classified the event as authorized vulnerability scanning, relayed by the logging pipeline, and recommended closing it at low priority. It cited the session payload, the scan records, the absence of the vulnerability across the inventory, and the absence of any callback.
Example 2: When exposure and evidence line up
The second investigation asks the question from the start of this post: "If this host has been compromised, which other systems could the attacker target next?"
In that investigation, the host was the administrator's workstation. It was exactly the system an attacker would want, and the system that would compel an analyst to ask “which other systems could be next?” after receiving the endpoint alert.
Step 1: Identify suspicious network behavior
Corelight showed that in the previous seven days the workstation completed connections to 20 hosts on the management network. These included SSH to servers and hypervisors, HTTPS to the virtualization management server, and SNMP to a UPS network card and to a server's baseboard management controller (BMC).
Ordinary user devices showed no completed connections into that network.
Step 2: Identify vulnerable targets
Tenable returned current findings for those 20 hosts. Three stood out:
- The virtualization management server: a critical remote code execution vulnerability. The installed build predated the vendor's fix.
- Three server BMCs: IPMI 2.0 password hash disclosure (high), which lets unauthenticated users retrieve password hashes for valid accounts.
- The UPS network card: an SNMP agent that answered to the default community string "public" (high).
Step 3: Correlate exposure with network evidence
Each of these exposures were sitting on a device which the workstation was already talking to, and two were sitting on the exact service that they were using.
The workstation reached the virtualization management server over HTTPS, its management interface. It queried the UPS card over SNMP, the service that was accepting the default community string. It also reached one of the vulnerable BMCs, although over SNMP rather than IPMI.
For the attacker on that workstation, the path to those systems were observed, not just inferred. Vulnerable hosts that the workstation never contacted ranked lower.
The agent kept the limits explicit. Observed connections showed the paths that were used, not every path the firewall allowed. The evidence was also only as complete as the sensor coverage. In this lab, traffic between virtual machines on the same hypervisor stayed invisible until dedicated virtual sensors were added.
Step 4: Assess the potential blast radius
From the workstation, the attacker had a short path to control the virtualization layer through its management server, and out-of-band management of the physical servers through their BMCs.
The agent's assessment listed:
- The compromised host and its observed management-plane connections.
- Vulnerable systems on those connections, with the Tenable finding behind each.
- Systems with known vulnerabilities but no observed connection, ranked lower.
- Remediation priorities: patch the virtualization management server, restrict IPMI access, and replace the default SNMP community.
- Next investigative steps were to review the workstation's recent sessions to these systems for anything unusual.
Two investigations, opposite outcomes, same method. In the first, exposure data and network evidence together let the analyst close a critical-severity alert with confidence. In the second, they showed which vulnerable systems sit on the attacker's most likely path.
Neither tool reached those conclusions alone.
From isolated observations to a network-wide investigation
In enterprise environments, network visibility is rarely provided by a single sensor.
Organizations commonly deploy sensors across data centers, branch offices, cloud environments, and network boundaries.
A suspected compromise may therefore generate evidence across multiple monitoring locations.
One sensor might observe internal reconnaissance. Another might capture connections to a vulnerable application server. A third might identify unusual outbound communications.
By querying available Corelight telemetry across these monitoring points, an AI agent can help correlate observations into a broader investigation.
When combined with Tenable exposure information, this approach can help analysts understand both the vulnerable assets involved and the observed network activity connecting them.
The objective is not simply to identify additional alerts. It is to reconstruct the relationships that matter during an investigation.
Editorial note: Sensor coverage matters
Building this lab taught us a lesson worth sharing. At first, no sensor monitored the virtual-switch port groups on the management network. The only sensor that could have seen that traffic was the physical sensor, Lab-AP200, on a SPAN port between the gateway and the first switch. As a result, the administrator's daily SSH sessions from the workstation to two management virtual machines were almost entirely missing from the network evidence: one captured session in 30 days.
Adding Lab-vSensor5 and Lab-vSensor6 to those port groups closed the gap, and the investigations above ran with that coverage in place.
The point: An agent's blast-radius assessment is only as complete as the sensor coverage beneath it. "No observed traffic" can mean "not reachable" or "not monitored," and traffic between virtual machines on the same hypervisor is a common blind spot. A trustworthy agent must treat absence of evidence as a coverage question, not proof of safety.
Why MCP matters
Traditional security integrations often require purpose-built connectors, proprietary APIs, and ongoing maintenance to exchange information between platforms.
MCP offers a different approach.
With Corelight and Tenable exposing complementary capabilities through their respective MCP servers, a compatible AI agent can interact with both systems without requiring Corelight to embed Tenable-specific functionality into its own MCP server.
This architecture also gives organizations flexibility in selecting the AI tools and orchestration platforms that fit their environments.
The agent can be instructed to retrieve exposure information when investigating suspicious network behavior, correlate that information with network evidence, and return a structured assessment.
For a dependable workflow, tool access alone is not enough. The agent must have clear investigation instructions, appropriate permissions, reliable asset identification, and a requirement to distinguish observed evidence from inferred risk.
The lab investigations above validate this cross-platform workflow and show how an agent can actively retrieve and use Tenable exposure data alongside Corelight network evidence.
Better context. More actionable investigations.
Exposure intelligence and network evidence address different but closely related security challenges.
Exposure management identifies weaknesses that attackers may exploit.
Network detection and response helps defenders understand the activity occurring across their environments.
Agentic AI creates an opportunity to bring these perspectives together dynamically.
Instead of manually switching between platforms, matching asset information, and reconstructing communication patterns, analysts could use an AI agent to perform those investigative steps and present the supporting evidence in a unified view.
This approach could help security teams:
- Prioritize vulnerable assets based on relevant observed network activity.
- Identify potential lateral movement opportunities following a suspected compromise.
- Investigate relationships between compromised systems and vulnerable targets.
- Reduce manual correlation across network and exposure-management platforms.
- Make more informed decisions about investigation and remediation priorities.
The goal is not to replace analysts or allow AI to make unsupported conclusions about an attack. It is to equip security teams with better context and a clearer path from an initial detection to an evidence-backed understanding of potential impact.
Connecting what could happen with what is happening
Understanding an organization's exposure is essential. So is understanding the activity taking place across its network.
But the real opportunity comes from connecting the two.
Through our participation in Tenable OPEN for AI, Corelight is exploring how agentic workflows can combine Tenable's exposure intelligence with Corelight's high-fidelity network evidence to investigate suspected compromises and assess potential blast radius.
The question evolves from:
"Which of my systems are vulnerable?"
to:
"Which vulnerable systems could be targeted next, and what does the network evidence tell us about the threat?"
Tenable provides the exposure context. Corelight provides the network evidence. Agentic AI brings them together to help defenders understand the potential blast radius of a compromise and determine where to investigate next.
See what your network evidence can reveal
Learn more about Corelight’s Agent Builder Library.
Learn more about Tenable's Hexa AI MCP.