Real cases an ASM would have prevented

Attack surface is the set of every point through which an adversary can try to get into an organization: domains, subdomains, IP addresses, open ports, applications, APIs, leaked credentials, and third-party services operating on its behalf. The surface changes every week, and it almost always grows without anyone recording the change.

Your company is like a castle. Unlike a medieval castle with one gate and a moat, though, the modern company has thousands of entry points. Every new cloud service, every remote employee's laptop, every API connected to a partner, and even that forgotten test server tucked away in the corner of a subnet is a potential door or window.

The problem? You cannot protect what you do not know exists.

This is where one of the most critical concepts in modern cybersecurity comes in: Attack Surface Management (ASM).

The formal definition is clear: Attack Surface Management (ASM) is the continuous process of discovering, analyzing, monitoring, and remediating an organization's attack vectors.

But what does that mean in practice? It means adopting an attacker's view to find and close your own gaps before they do.

Unpacking the Concepts: Attack Surface vs. ASM

Before managing it, we need to understand what the "attack surface" is.

Attack Surface: It is the sum of all potential entry points where an attacker can attempt to extract data or gain unauthorized access to a system.

This includes several types of assets that often go unnoticed by security teams. Known assets are those on IT's radar: your corporate websites, email servers, VPNs, and public-facing applications. These are relatively easy to monitor because they are part of the organization's official inventory.

However, the real danger often lies in unknown assets, also known as Shadow IT. Imagine that server the marketing team spun up on AWS for a temporary project and forgot to shut down after the campaign ended. Or the subdomain from an old test that is still online, running an outdated version of software with known vulnerabilities. These "ghost" assets are preferred targets for attackers because they frequently do not receive security patches or adequate monitoring.

Then there are the third-party assets your organization uses but does not control: partner code, external APIs, open-source libraries such as Log4j. Each one is a potential attack vector. When a critical vulnerability lands in one of those dependencies, the question that matters is where it runs in your infrastructure, and it has to be answered the same day.

Finally, there are data exposures that may not be traditional technical assets but represent significant risks. Credentials leaked on paste sites, misconfigured cloud storage buckets that anyone can access, databases open to the internet without authentication; all of these are entry points that attackers actively look for.

Management (ASM) is the active process of mapping, analyzing, and reducing this surface. It runs as a continuous cycle, in four stages.

The first stage is Discover. Here, automated tools continuously scan the internet the same way an attacker would to find all assets connected to your organization, whether known or not. This is not a point-in-time process, but a continuous sweep that identifies new assets as soon as they appear online. The ASM platform acts as an ethical hacker, looking for domains, subdomains, IP addresses, SSL certificates, and any other digital trace that leads back to your organization.

The second stage is Analyze and Prioritize. It is not enough to simply find assets; you need to understand the risk each one represents. A web server running a business-critical application with a known critical vulnerability (CVE) is infinitely more dangerous than an outdated static blog. ASM classifies the discovered assets, identifies vulnerabilities through automated scanners and CVE databases, and then prioritizes what needs to be fixed first based on multiple factors: vulnerability criticality, asset exposure, the value of the data it processes, and whether there are active exploits circulating.

The third stage is Monitor. The attack surface is not static; it changes daily, sometimes by the hour. New ports are opened for testing and forgotten open. Patches are applied to some servers but not others. New subdomains are created for temporary projects. SSL certificates expire. ASM monitors these changes in real time, alerting immediately when something changes in a way that could introduce risk. It is like having a 24/7 watchman observing every change in your digital presence.

The fourth and final stage is Remediate. This is the ultimate goal of the entire process. A good-looking report fixes nothing. The platforms that work integrate straight into ticketing (Jira, ServiceNow) and vulnerability management tools, so the highest-risk flaw leaves the list and lands in somebody's queue with a name and a due date. Remediation is tracked, measured, and reported, creating a cycle of continuous improvement.

Why Is ASM So Critical Now?

Digital transformation, the massive adoption of the cloud, and the abrupt shift to remote work have exploded the attack surface of modern organizations. In the past, security focused on the perimeter, the famous castle moat. There was a firewall at the network edge, an IDS watching inbound and outbound traffic, and everything inside counted as reasonably safe. That model is over. The perimeter no longer exists.

Employees access corporate systems from home, from cafes, from airports. Business-critical applications run in multiple public clouds (AWS, Azure, Google Cloud) that you do not physically control. Business partners have direct access to internal APIs and systems. IoT devices connect to the network without going through any formal IT approval process. Each of these points is an extension of your attack surface.

Gartner has been emphatic about the importance of ASM in recent years. In its security trend predictions, the research firm highlights that External Attack Surface Management (EASM) is one of the top strategic priorities for CISOs. Gartner predicts that, by 2026, organizations that prioritize their security investments based on a continuous ASM program will suffer two-thirds fewer breaches than those that do not. This is not a marginal improvement; it is a transformative difference.

Without ASM, the security team works in the dark. It fixes the flaws it knows about, patches the inventoried systems, buys a pentest for the documented application. Meanwhile the attacker exploits what automated reconnaissance turned up: the forgotten server, the misconfigured API, the vulnerable subdomain nobody knew existed. One side sees the whole field and the other sees a slice of it.

What ASM Makes Possible

Adopting an ASM platform changes what the team can see, and then what it can do about it.

Real Threat Anticipation

ASM completely changes the game from reactive to proactive. In the traditional model, the sequence is painfully familiar: you are attacked, detect the incident (quickly, if you are lucky), respond to the attack, contain the damage, and then finally fix the vulnerability that was exploited. It is a cycle of "we were attacked, now we need to fix it." With ASM, the narrative changes radically to "we found an exposed flaw that we know is being actively scanned by ransomware groups; let's fix it before any attack happens."

You come to see your infrastructure through the adversary's eyes. The ASM platform scans your external digital presence the same way an intruder would: open ports, exposed services, SSL certificates, subdomains, technologies in use. The difference is the clock. You get to the vulnerability first.

Bringing MTTR Down (Mean Time to Remediation)

MTTR, or Mean Time to Remediation, measures how long it takes from the identification of a vulnerability to its effective fix. The problem for many security teams is not a lack of willingness or capacity to fix vulnerabilities; it is the lack of effective prioritization in the face of an overwhelming volume of alerts.

A traditional vulnerability scanner run on the internal network can easily generate 50,000 alerts. Which one do you fix first? Many teams end up prioritizing by CVSS score (Common Vulnerability Scoring System), but that breaks at the root, because CVSS does not take your organization's specific context into account. A vulnerability with CVSS 9.8 on an internal development server without internet access is far less urgent than a CVSS 7.5 vulnerability on a public web server that processes financial transactions.

An ASM platform solves this prioritization problem elegantly. It will say: "Of these 50,000 identified vulnerabilities, these specific 15 are on internet-facing servers, have known public exploits available in Metasploit, are being actively scanned by known ransomware groups (based on threat intelligence), and affect systems that process critical customer data. Fix them now, in this order." The result is a dramatic reduction in MTTR for the vulnerabilities that truly matter.

Basic Cyber Hygiene (CIS Controls)

ASM is the fundamental foundation of "cyber hygiene," the basic security practices that every organization must have. The CIS Controls v8 (and the more recent v8.1) are a widely recognized set of cyber defense best practices, developed by security experts from around the world. These controls are organized into three Implementation Groups (IG1, IG2, IG3) based on the size and sophistication of the organization.

Implementation Group 1 (IG1) is what CIS calls basic cyber hygiene: the minimum any company, whatever its size or sector, should have in place. It is the cyber equivalent of washing your hands.

The first two CIS controls, which form the basis of the entire framework, are:

CIS Control 1: Inventory and Control of Enterprise Assets. You need to know which devices and systems exist on your network.

CIS Control 2: Inventory and Control of Software Assets. You need to know which applications and software are running on those systems.

ASM automates and validates those two controls for internet-facing assets. There is no IG1 without knowing which assets and software sit exposed out there. ASM finds those assets and keeps the inventory alive, updated on its own. By hand, in a modern organization, that does not survive a quarter.

The Cost of Missing Visibility: Lessons from 7 Real Incidents

The absence of a continuous attack surface monitoring platform can have significant consequences. The cases that follow illustrate situations where the lack of complete visibility into external assets resulted in high-impact incidents. All involved vulnerabilities in internet-facing applications, exactly the type of exposure that a complete ASM platform is designed to identify proactively.

International Incidents

Equifax (2017)

The Equifax data breach illustrates the challenges of maintaining complete asset visibility in large organizations.

The challenge: A critical vulnerability (CVE-2017-5638) existed in the Apache Struts web application framework, used in a public portal. Although the patch was available, the complexity of tracking all assets and their dependencies made timely identification and remediation difficult.

The damage: The breach exposed the sensitive personal data of more than 147 million people, including social security numbers, dates of birth, addresses, and, in some cases, driver's license numbers. The total cost to Equifax, including regulatory fines, legal settlements, remediation costs, and loss of market value, exceeded $1.4 billion. The CEO resigned, and the company's reputation was permanently tarnished.

How would ASM help? An ASM platform would have performed three critical functions: (1) Discovered the public portal and identified that it was part of Equifax's infrastructure, even if it was a "forgotten" or poorly documented asset. (2) Identified that the portal used Apache Struts and which specific version was running. (3) At the moment CVE-2017-5638 was publicly disclosed, the platform would have cross-referenced that information with the asset inventory and prioritized applying the patch as "critical" immediately, well before attackers exploited the vulnerability months later.

Capital One (2019)

The Capital One case highlights the complexity of managing security configurations in dynamic cloud environments.

The challenge: An inadequate configuration in a Web Application Firewall (WAF) on AWS cloud servers created a vulnerability. The configuration allowed specially formatted commands to be executed by the server, making it possible to gain unauthorized access to S3 buckets containing customer data.

The damage: The attacker was able to access and extract data from more than 100 million customers and credit card applicants. Capital One was fined $190 million by federal regulators, on top of heavy costs for recovery, customer notification, and credit monitoring.

How would ASM help? ASM platforms discover cloud assets and keep watching their configuration for known misconfigurations and drift away from best practice. ASM would have detected the insecure WAF configuration and the inadequate exposure of the S3 buckets as a high-priority risk, generating alerts for the security team with specific remediation recommendations, enabling the fix before any breach occurred.

Kronos (UKG) (2021)

The Kronos incident demonstrates the challenge of tracking software dependencies in complex applications.

The challenge: The Log4j vulnerability (CVE-2021-44228) affected a Java logging library present in thousands of applications globally. Known as "Log4Shell," this critical remote code execution flaw posed an unprecedented challenge for security teams that needed to quickly identify where the library was being used.

The damage: A ransomware attack that exploited the Log4j vulnerability completely paralyzed Kronos's cloud payroll services for weeks, affecting thousands of global customers, including massive companies such as Tesla and Pepsico. Employees could not log hours, and companies could not process payrolls. The parent company UKG reported direct losses of more than $30 million, not counting the damage to customers.

How would ASM help? The Log4j case was a defining moment for ASM. On "Day Zero" of the vulnerability's disclosure, when organizations around the world scrambled to figure out where they were using Log4j, ASM platforms were the most effective tools available. They quickly scanned the entire external attack surface for signs of the vulnerable library (through techniques such as HTTP response analysis, application fingerprinting, and behavior detection), enabling teams to identify and prioritize fixing critical systems in hours, not weeks.

Incidents in Brazil

Banco Inter (2018)

The Banco Inter case highlights the security challenges of APIs, especially in environments of rapid digital innovation.

The challenge: An API (Application Programming Interface) had an authorization vulnerability. A security researcher identified that it was possible to access other account holders' data by altering parameters in the API call. This flaw, known as Insecure Direct Object Reference (IDOR) or Broken Object Level Authorization (BOLA), is among the most common vulnerabilities in modern APIs, listed in the OWASP API Security Top 10. The API exposed sensitive data, including personally identifiable information (PII) and details of financial transactions.

The damage: The bank was fined R$ 1.5 million by the MPDFT (Public Prosecutor's Office of the Federal District and Territories) and faced significant reputational damage at a critical moment of growth. For a digital bank that positioned itself as technologically advanced, the incident was particularly damaging to the brand.

How would ASM help? ASM is specifically designed to discover all exposed assets, including "Shadow APIs," APIs that the central IT team may not know are online, frequently created by development teams for specific projects and later forgotten. An ASM platform would have: (1) Discovered the API endpoint, either by identifying related documentation (swagger/openapi) or through direct integration with the cloud (reading the routes of API gateways). (2) Analyzed its behavior through automated testing and identified the lack of adequate authorization controls. (3) Flagged this API as a critical risk, enabling the security team to fix the flaw before any malicious exploitation.

Atento (2020)

The Atento case illustrates the risks of inadequate asset visibility in complex infrastructures.

The challenge: An Elasticsearch database containing 14TB of data was accessible over the internet without adequate authentication. This database contained sensitive data from Atento's customers, including major Brazilian banks, telecommunications companies, and retailers, with personally identifiable information (PII), call center logs, and details of services provided.

The damage: Exposure of the data of millions of Brazilians and of Atento's corporate customers. The incident occurred shortly after the LGPD (General Data Protection Law) came into effect, resulting in regulatory investigations and incalculable reputational damage for a company whose core business is precisely the secure management of third-party data. The trust of corporate customers was severely shaken.

How would ASM help? This is a textbook case of failure in CIS Control 1 (Asset Inventory). An ASM tool would have continuously scanned Atento's IP ranges and cloud environments, instantly discovering: (1) A service (Elasticsearch) running on a public, internet-accessible port. (2) The critical misconfiguration, the complete absence of authentication or access controls. (3) The alert generated would have had top priority, since exposed databases are considered "low-hanging fruit" (extremely easy targets) for attackers and are scanned by automated bots 24 hours a day, 7 days a week. The fix could have been made in minutes, simply by closing public access or implementing authentication.

City of Rio de Janeiro and MOVEit (2023)

The MOVEit incident at the City of Rio demonstrates the challenge of responding quickly to zero-day vulnerabilities in third-party software.

The incident: In 2023, the City of Rio de Janeiro was affected by a global attack campaign that exploited a vulnerability in the MOVEit Transfer software. Sensitive taxpayer data, including IPTU (Urban Property and Land Tax) and ISS (Service Tax) information, was exposed. The incident was part of a massive campaign by the Cl0p ransomware group that affected hundreds of organizations globally.

The challenge: The vulnerability CVE-2023-34362 in MOVEit Transfer, a file transfer software widely used by government organizations and companies, allowed SQL injection. The window between public disclosure and active exploitation was extremely short, creating a significant challenge for identification and remediation.

The damage: Exposure of the sensitive data of Rio citizens and companies. The City was notified by the Cybersecurity Laboratory (LAB-DEF/MJSP) about the exploitation, but the damage was already done. Globally, this single CVE cost hundreds of companies (such as British Airways, BBC, Shell, Siemens) billions of dollars and exposed the personal data of more than 60 million people worldwide. The Cl0p group published lists of victims and demanded massive ransoms.

How would ASM help? This is a perfect example of how ASM works in a real crisis situation. Discovery: The ASM platform would have identified that the City used a MOVEit Transfer server exposed on the internet, cataloging it in the external asset inventory. Analysis: the ASM inventory holds assets, software, and versions. On the day Progress Software (the owner of MOVEit) and CISA (the U.S. Cybersecurity Agency) publicly announced CVE-2023-34362, the ASM platform would have automatically cross-referenced that information with the inventory. Prioritization: The system would generate a "Critical" or "Urgent" priority alert, indicating: "You have a software product (MOVEit Transfer) with a remote code execution (RCE) vulnerability that is being actively exploited right now by known ransomware groups. Disconnect the server from the internet or apply the emergency patch immediately." With that alert, the City would have had hours, not days, to act before the attack occurred.

Lojas Renner (2021)

The attack on Lojas Renner illustrates the challenges of protecting complex corporate environments against sophisticated ransomware groups that exploit multiple known vulnerabilities.

The incident: In August 2021, Lojas Renner, one of the largest retail chains in Brazil, suffered a ransomware attack that affected its digital operations and internal systems. The RansomEXX group (also known as Defray777) claimed responsibility, publishing evidence of compromise on dark web forums. Although the company stated that there was no leak of customer personal data, the episode highlighted the capacity of organized groups to exploit vulnerability chains and perform lateral movement in large Brazilian corporations.

The challenge: The RansomEXX group is known for using multiple known vulnerabilities in its campaigns, creating a complex defense challenge. Among the CVEs historically associated with the group and the PipeMagic loader are: CVE-2017-0144 (EternalBlue) for internal propagation in poorly segmented Windows networks; CVE-2024-23897 (Jenkins LFI) for initial access to exposed Jenkins servers; and CVE-2025-31324 (SAP NetWeaver) for remote code execution in corporate SAP environments. The diversity of attack vectors makes it particularly challenging to maintain visibility and patch readiness across the entire attack surface.

The damage: The temporary shutdown of digital channels and back-office systems caused significant financial and reputational impacts, affecting market confidence and demonstrating the destructive potential of targeted ransomware attacks against Brazilian retail.

How would ASM help? An ASM platform such as CSURFACE would have provided multiple layers of protection: (1) Discovery of vulnerable services: Identification of critical internet-exposed services, such as SMB, Jenkins, and SAP Web components, which are known targets of ransomware groups. (2) Detection of outdated versions: Continuous mapping of software versions and automatic correlation with known CVEs exploited by groups such as RansomEXX. (3) Threat Intelligence-Based Prioritization: Automatic correlation between asset exposure, system criticality, and real exploitation likelihood based on observed threat group activity (threat likelihood), enabling the security team to prioritize remediation on the assets that ransomware groups are actively targeting.

Conclusion: What ASM Saves

The absence of continuous attack surface visibility can result in significant financial consequences. The data from IBM Security's "Cost of a Data Breach 2024" report is revealing.

The average cost of a data breach reached a historic record of USD 4.88 million, representing a 10% jump over the previous year. What matters in that number is the pace: incident costs are growing faster than the security budgets of most organizations.

The report also details the factors that push that cost up and down, and that is where the arithmetic gets interesting. Organizations that implemented Attack Surface Management technologies saved an average of USD 186,000 per data breach incident compared to those that did not. The figure comes out of thousands of analyzed incidents, not out of a projection.

Even more striking, the report shows that organizations that combined ASM with security AI and automation saved an average of USD 2.22 million per incident, nearly half the total average cost of a breach. With that figure on the table, the ASM budget conversation stops being about cost and starts being about measured ROI.

To put this in perspective: if your organization suffers a single data breach in the next 5 years (and the statistics suggest the probability is high), the investment in an ASM platform pays for itself several times over through the reduced impact of that single incident alone. And that does not count the incidents that will be completely prevented because the vulnerabilities were discovered and fixed before any exploitation.