In this article, we walk through common scenarios that attribution-based attack surface management tools miss and demonstrate how you can use runZero’s new Inside-Out Attack Surface Management (IOASM) capabilities to close these gaps. IOASM helps you defend against opportunistic attacks by leveraging precise device fingerprinting to uncover exposures that are impossible to find through attribution alone.

The attribution challenge

Attackers are continuously scanning and prodding internet-facing systems, looking for easy wins. Although many campaigns start by knocking on your front door — testing assets clearly associated with your domain and IP space — attackers are just as likely to stumble upon an exposed system, compromise it, and only later realize it belongs to you. Opportunistic attacks drive an entire sub-category of the cyber-crime economy: initial access brokers. These criminal groups gain a foothold into your organization and then sell that access to other groups that steal data and attempt to extort money.

External attack surface management (EASM) tools (including runZero!) can reduce your risk by quickly flagging exposures before they can be exploited. You provide these tools with a list of domain names, IP addresses, autonomous system numbers (ASNs), and other identifiers, and the EASM attribution process will iterate on these “seeds” to identify internet-exposed assets. This process works great for well-known organizational resources, but often misses exposures where attribution is impossible using IP addresses and domain names alone.

Flipping the script with Inside-Out Attack Surface Management

This is where Inside-Out Attack Surface Management (IOASM) changes the game. While attribution-based EASM tools often struggle to identify exposures beyond their predefined “seeds,” IOASM flips the script by leveraging detailed knowledge of your internal assets to quickly and accurately identify external exposures, no matter where they are.

Instead of starting with known IPs or domains, the runZero Platform builds device fingerprints from attributes it gathers through external and internal active and passive discovery, as well as integrations with systems like cloud provider APIs and vulnerability scanners. This fingerprinting process captures details such as TLS certificates, SSH host keys, and SNMP metadata, in addition to other system-specific attributes, which tend to remain consistent even when a device changes IP addresses, network segments, or is redeployed from an image. By beginning with an internal baseline of these fingerprints, runZero can pinpoint each device’s unique identity deep within the environment, and then correlate those same devices against information collected externally.

If an asset that was once detected in an isolated subnet suddenly appears on the internet — or if a device spins up in a public cloud and shares the same cryptographic fingerprint as one on-prem — runZero recognizes that it’s the same underlying system. This is why inside-out discovery is so effective: rather than relying on traditional attribution methods like IP ranges or domain registries, runZero focuses on inherent device characteristics.

Once a device’s fingerprint is known, any reappearance gets flagged — be it behind corporate firewalls or exposed on a public IP. This allows security teams to see connections and gaps that external-only scans would miss. Through this inside-out lens, organizations can uncover at-risk assets faster and more accurately, significantly reducing blind spots that attackers often exploit.

To demonstrate, the scenarios outlined below highlight why attribution-based external attack surface management tools struggle with certain types of exposures and how IOASM can help you find the blind spots.

Common scenarios missed by attribution-based EASM

1. The Legacy VPN

A global manufacturer migrated from per-site VPN gateways to zero-trust network access (ZTNA) using endpoint agents. After the migration was complete, the per-site VPN gateways were decommissioned. Unfortunately, the VPN gateway at a small branch office was never turned off. Months later, this gateway was compromised through a zero-day vulnerability in the SSL VPN function, allowing attackers to gain access to the corporate network. Worse, cached credentials dumped from the compromised gateway enabled further ingress into the network.

Why was this missed?

After migrating to ZTNA, the DNS records for the VPN gateways were removed. For small offices, the VPN gateways were connected through business broadband connections, and those IPs were not recorded in the organization’s inventory or part of their EASM configuration.

How did runZero help?

A comprehensive internal discovery scan identified the legacy VPN gateway, leveraging runZero’s advanced device fingerprinting to ensure no assets were overlooked. The runZero Platform’s ability to perform regular, automated scans ensures that similar devices are identified promptly, even if they are misconfigured or hidden in unexpected network segments. Once the gateway was flagged, an alert was configured to notify the security team if any similar devices appeared on the network in the future.

2. The Mobile Broadband Leak

A large financial organization issued laptops to their senior staff, each equipped with built-in mobile broadband cards (cellular modems). The intent was to ensure their team could stay connected even during transit, without relying on public WiFi. These Windows laptops were continuously connected to the mobile network and roamed between cellular providers, even while simultaneously connected to the corporate network through WiFi and wired Ethernet. Depending on which cellular provider was in use, these laptops would sometimes receive public IPv4 and IPv6 addresses, yet the firewall was not configured to block inbound connections. As a result, some portion of the senior staff’s laptops were directly exposed to the internet on semi-random IP addresses. This, in turn, exposed the Remote Desktop and the SMB (CIFS) services to internet attacks. Fortunately, one of these systems was identified in the public Shodan search portal based on the organization’s unique Active Directory domain, and the issue was resolved by deploying a group policy for Windows Firewall that always treated the mobile broadband connection as a public network.

Why was this missed?

Mobile broadband connections can vary dramatically by provider and location. Some providers place customers into private IP space, while others assign public IPs. In some cases private IPv4 addresses are assigned in addition to public IPv6 addresses. Attribution-based exposure management tools struggle to find these connections.

How did runZero help?

An internal scan identified the public IP addresses of these Windows laptops using a combination of unauthenticated NetBIOS (UDP) and DCEPRC (Oxid2Resolver), leveraging runZero’s advanced asset fingerprinting capabilities to detect and categorize devices accurately. The runZero Platform’s ability to conduct both internal and external scans ensured that no public IP addresses associated with these devices were overlooked, even as they roamed between cellular providers. A direct scan of these public IPs confirmed that the mobile broadband connections were exposing these machines directly to the internet, including the Remote Desktop and SMB services.

Additionally, runZero’s automated inventory and exposure tracking ensured that any newly exposed IP addresses were promptly identified. An alert rule was configured to notify the security team whenever a Windows machine on the internal network was detected with a public IP address, enabling real-time monitoring of at-risk devices. This proactive visibility not only mitigated the immediate risk but also provided actionable insights for implementing policies to prevent future exposures, such as refining firewall rules and deploying group policies for Windows Firewall.

3. The “Smart” IP Camera

A national construction firm needed to install a camera in the lobby of their headquarters. They chose an IP camera made by Hikvision, one of the most prolific manufacturers and a type of device that is commonly sold under different brand names. This camera was “smart”; it could detect people and faces and send an alert when particular behavior was observed, such as someone loitering in the lobby after hours. Unfortunately, this camera was too smart; the default configuration caused it to open a hole in the firewall using the UPnP protocol and automatically port-forward several services from the internet to the camera. These services included the video service (RTSP), the web server used for device administration, and a few proprietary Hikvision services.

Shortly after installation, the camera was compromised using an off-the-shelf exploit that enabled remote, unauthenticated command execution through the web service. The attacker gained complete access to the camera and leveraged the Linux operating system shell to explore the company’s internal network. The UPnP-enabled network gateway was an issue on its own, but the automatic port forwarding behavior of the camera escalated the situation into a full-blown crisis.

Why was it missed?

This is an example where EASM can help, but only if the issue was identified and mitigated quickly. EASM tools can be noisy, and investigating the results of new exposures can often take days or weeks to track down the appropriate owner.

How did runZero help?

An internal network scan combined with IOASM capabilities immediately flagged this system as being externally exposed and accurately matched the internal asset to its corresponding external exposure. runZero’s advanced fingerprinting techniques ensured that the match was precise, even for devices with dynamic configurations or those hidden behind network complexities. By leveraging a combination of passive and active discovery, the platform provided comprehensive visibility into both internal and external networks.

Once the exposure was identified, an alert rule was created to notify the security team of similar vulnerabilities in the future. Additionally, runZero’s integration capabilities allowed the organization to correlate this exposure with existing threat intelligence feeds, enabling the team to assess whether the exposed device had been targeted or exploited. This integration also streamlined remediation efforts by generating actionable insights, such as misconfiguration details and recommended mitigation steps.

4. The Developer Tunnel

A global retailer was developing a new version of their online storefront. This work was being coordinated across multiple groups worldwide, including several external contractors. A standard test environment was configured in the cloud, but deployments were taking too long. As a result, the development team began using “tunnel” software, such as Cloudflare Tunnel and ngrok.io, to share their work-in-progress from their developer machines with the wider group.

An attacker stumbled over one of these tunnels and identified a development console in the application that exposed all environment variables. These environment variables contained a wide range of credentials, including access keys to the production cloud account. Fortunately, rather than backdooring the application or stealing data, the attacker instead launched mining bots for cryptocurrency. The organization noticed the resulting cost spike, traced the leaked credential to the developer workstation, and implemented a policy prohibiting the use of tunnels going forward.

Why was it missed?

The internet-side of the tunnel can pop out almost anywhere, including common providers like Cloudflare and ngrok, as well as on virtual machines hosted by cloud providers like Digital Ocean and Linode. These endpoints have no known relationship to the organization’s domain or registered IP ranges, making them difficult to detect with attribution-based tools.

How did runZero help?

This is another example of how IOASM was able to match the internal fingerprint of the web server to an externally exposed service on a tunnel provider. By leveraging advanced fingerprinting, runZero ensured the match was precise, even for services hosted in dynamic or ephemeral environments like those created by tunnel software. This capability provided visibility into hidden or misconfigured exposures that traditional attribution-based methods would likely miss.

After identifying the exposure, an alert rule was configured to notify the security team of any similar issues in the future. Additionally, runZero’s ability to integrate with SIEMs and other security tools allowed the team to automate follow-up actions, such as blocking traffic to unapproved tunnel providers or initiating incident response workflows. The runZero Platform’s continuous monitoring ensures that new tunnels or services appearing in the environment are flagged immediately, reducing detection and response times.

Minimal noise and no real false positives

An important point to note is that IOASM uses detailed fingerprints and a set of layered heuristics to determine if a match between an internal and external asset represents an exposure. This process isn’t perfect, but even in cases where a match doesn’t indicate a true exposure, it still highlights a risk. For example, if the same TLS certificate is found on an internal storage device and also observed on the internet, it could either mean this is the same device or that the device is using a hardcoded TLS key. runZero’s heuristics automatically report duplicated and widely shared keys.

In addition to reporting shared keys, runZero also assigns varying severity levels based on the confidence of the match. For instance, if an internal web server is using a TLS certificate observed on the internet, and that certificate is signed by a valid authority, this is likely either the internal side of an internet-facing web server cluster or a case where the public TLS certificate is also used on internal systems. runZero will report this as a low-risk exposure. Conversely, if the match involves a Remote Desktop service or a SSH host key that is not widely shared, this is almost certainly a critical issue requiring immediate action, and the exposure is reported as high risk.

From theoretical to operational

While it’s easy for us to describe how runZero can detect these threats, it’s even better to show you how to do it in your own instance. The good news is that Inside-Out exposure detection is enabled by default for all runZero customers.

To get started, navigate to the Inventory -> Vulnerabilities section and search for the word “Exposure”. Any internal assets that runZero was able to identify externally, regardless of IP address or location, will be flagged with a vulnerability record based on the type of exposure.

The three exposure detection methods available today are:

• TLS Certificate
• SSH Hostkey
• MAC Address

Here’s an example of an exposure that was identified by matching a TLS public key:

Clicking on the name of the vulnerability will open the details page. This page also provides a list of the public endpoints where this internal system was observed: