See What Attackers Can Reach in Your Cloud

Jul 21, 2025
5 minutes
... views

Stop Guessing. Start Validating.

Costing organizations an average of $5.17 million per incident, cloud-based data breaches are the most costly security risk organizations face. Attackers armed with automated tools and bots continuously scan the internet, seeking publicly exposed resources to exploit as entry points to your critical assets.

But not all risks carry the same weight. To respond effectively, security teams need context around each issue to properly prioritize and respond. Consider two applications with the same critical vulnerability: One is exposed to the internet and connected to a business-critical database, and the other resides in an internal network with the same level of access to sensitive data. Both require remediation, but application exposed to the internet presents an immediate threat that demands attention.

Introducing External Probe Validation

When it comes to cloud exposure, knowing what’s vulnerable isn’t enough. You also need to know what’s actually reachable from the internet. That’s why Cortex Cloud is introducing External Probe Validation: A new capability that verifies which cloud assets are externally exposed.

External Probe Validation combines detailed network path analysis from Cloud Network Analyzer (CNA) with outside-in visibility from Cortex Cloud Attack Surface Management (Cloud ASM). It confirms exposure and shows exactly what’s visible to attackers, including protocols, ports, services and metadata.

Security teams can now validate exposure, understand how it happens, and act fast to prevent attackers from exploiting internet-exposed assets.

Identify and Validate Externally Exposed Resources

Let’s walk through a real-world scenario: Identifying an internet-exposed virtual machine with known risk factors.

We start by searching for internet-facing VMs associated with critical or high-severity vulnerabilities. We can quickly identify assets that meet the criteria and visualize their context, which helps teams to understand the scope of exposure and prioritize remediation.

Uncover vulnerabilities exposed to the internet.
Figure 1: Uncover vulnerabilities exposed to the internet.

From the results, we’ve identified two virtual machines that meet our criteria. Let’s drill into one of them to explore the associated risks and exposure details.

Asset Highlights displaying important asset security risks
Figure 2: Asset Highlights displaying important asset security risks

In the asset highlights, we see that this VM is linked to 14 high-severity cases, 44 high-severity issues, and is internet exposed.

Continuing our investigation, we review the internet exposure details to understand what’s visible externally and how the exposure is occurring.

Internet exposure issue details
Figure 3: Internet exposure issue details

As seen in figure 3, we’ve uncovered some critical information:

  • The asset is exposed through two different ports (HTTP and SSH).
  • The SSH on port 22 responds with a ‘not available’ response code.
  • The HTTP service on port 8081 responds with a 200 OK HTTP response code.

To understand how this exposure is happening, we examine the full network path. Cloud Network Analyzer traces the route across gateways, route tables, load balancers, security groups and subnets. Visibility of this level helps security teams pinpoint the configuration enabling the external access.

In our sample case, the VM has public IPs and is not behind a load balancer. As a result, it’s directly reachable from the internet.

Lastly, we attempt to connect to the HTTP service to see what content is being served on the exposed port.

HTTP service accepting connections
Figure 4: HTTP service accepting connections

After connecting to the HTTP service, we see that the asset is running a Jenkins server, and its login page is publicly accessible.

Combined with the known critical and exploitable vulnerabilities on this VM, this presents a high-risk scenario that demands immediate action.

Next, we check whether any of the vulnerabilities are directly tied to Jenkins.

Asset vulnerabilities view
Figure 5: Asset vulnerabilities view

As shown in figure 5, the vulnerabilities view, this host has several exploitable issues linked to Jenkins, confirming that the asset presents an immediate risk.

We open the vulnerability details view to review the specific CVE affecting the Jenkins server.
Figure 6: We open the vulnerability details view to review the specific CVE affecting the Jenkins server.

Remediate the Risk

To reduce the risk of the internet-exposed asset, users have various risk remediation control options to choose from:

  1. Fix the internet exposure: Remove the security group rule that allows unnecessary access to the Jenkins login page or other vulnerable services. This limits external access and reduces the risk of exploitation.
  2. Fix the vulnerability: Upgrade Jenkins to the latest recommended version. Follow the vendor’s guidance to patch known issues and ensure updates are applied regularly to stay protected.
  3. Apply runtime security policy: Use the Cortex XDR® agent with Web Application and API Security to block attacks targeting vulnerable applications in real-time.

Cortex Cloud gives security teams clear visibility into internet-exposed assets, along with the context needed to validate exposure and prioritize the most urgent risks.

It’s also the first CNAPP to include attack surface management capabilities, helping organizations discover and understand their cloud’s internet attack surface.

Learn More

Want to see Cortex Cloud in action? Take a self-paced product tour to explore key capabilities or go deeper by requesting a personalized demo with one of our experts.

 


Subscribe to Cloud Security Blogs!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.