You cannot control when the next critical vulnerability will occur. You can control how much of your environment is exposed when it is published. The problem is that most teams are exposed to the internet more than they realize. Intruder’s head of security takes a deep dive into why this happens and how teams can intentionally manage it.
Time to exploitation is reduced
The larger the attack surface and the less controlled it is, the more opportunities for exploitation. And the window to address them is rapidly shrinking. The most severe vulnerabilities can take 24 to 48 hours to be exploited after being disclosed. Zero Day Clock predicts that by 2028, exploits will take just minutes.
This is not a very long time when you consider what is required before deploying a patch: running a scan, waiting for results, raising a ticket, agreeing on priorities, implementing, validating the fix, etc. It will take even longer if the disclosure is made after hours.
In many cases, vulnerable systems do not even need to be connected to the Internet in the first place. Visibility into the attack surface allows teams to proactively reduce unnecessary exposure and completely avoid disruption when new vulnerabilities emerge.
If Saturday is zero day
ToolShell was an unauthenticated remote code execution vulnerability in Microsoft SharePoint. If an attacker gains access, this could lead to code execution on the server. Additionally, because SharePoint is connected to Active Directory, attacks begin from a highly sensitive part of the environment.
This is a zero-day, meaning it was exploited by attackers before a patch was available. Microsoft revealed on Saturday that Chinese state-backed groups had been exploiting it for up to two weeks before that. By the time most teams knew about it, opportunistic attackers had scanned the exposed instances and exploited them at scale.
Intruder’s research found that thousands of SharePoint instances were publicly accessible at the time of publication, even though SharePoint does not require an Internet connection. All of these exposures were unnecessary, and any unpatched server was an open door.
Why are exposures missed?
So why do security teams often miss breaches?
A typical external scan will have hundreds of informational findings under critical, high, moderate, and low. However, that information may include detections that represent actual exposure risk, such as:
A public SharePoint server A database exposed to the internet (such as MySQL or Postgres) Other protocols (usually should be reserved for internal networks) (such as RDP or SNMP)
A working example is:
In vulnerability scanning terminology, it may make sense to classify these as informational. If the scanner is on the same private subnet as the target, exposed services may be truly low risk. But when those same services are exposed to the Internet, they carry real risks, even if they don’t have any known vulnerabilities attached to them. still.
The danger is that traditional scan reports treat both cases the same, allowing real risk to slip through the cracks.
What does proactive attack surface reduction actually involve?
There are three key elements to making attack surface reduction really work.
1. Asset Discovery: Define the attack surface
Before you can reduce your attack surface, you need to have a clear understanding of what you own and what is externally accessible. It starts with identifying shadow IT (systems your organization owns or operates but isn’t currently scanning or monitoring).
It’s important to bridge this gap, and there are three key elements we recommend getting in place.
Integrate with cloud and DNS providers to automatically retrieve and scan new infrastructure as it is created. This is one area where defenders have a real advantage. Users can integrate directly with their own environments, but attackers cannot. Use subdomain enumeration to uncover externally reachable hosts that are not in your inventory. This is especially important after an acquisition where you may inherit infrastructure that you don’t yet have visibility into. Identify infrastructure hosted by small, unknown cloud providers. You may have a security policy that requires your development team to use only the primary cloud provider, but you must ensure that this practice is followed.
Learn more about these techniques.
. Treat exposure as a risk
The next step is to treat attack surface exposure as its own risk category.
This requires detection capabilities that identify which informational findings represent an exposure and assign an appropriate severity level. For example, a published SharePoint instance might reasonably be treated as a medium-risk issue.
It also means making space for this work by how you set your priorities. When strategic initiatives like attack surface reduction always compete with urgent patching, you always lose. That might mean setting aside time every quarter to review and mitigate risks, or assigning clear ownership so that someone is accountable on a regular basis, not just when a crisis occurs.
3. Continuous monitoring
Reducing your attack surface is not a one-time effort. Exposures change constantly as firewall rules are edited, new services are deployed, subdomains are forgotten, and teams need to detect those changes quickly.
Vulnerability scans take time to complete, and it is usually not possible to run a full scan every day. A daily port scan is better. This means it’s lightweight, fast, and can discover newly published services as they appear. If someone edits a firewall rule and accidentally publishes a remote desktop, you’ll know about it the same day it happens, rather than at your next scheduled scan (which could be up to a month later).
Fewer services exposed, fewer surprises
If unnecessary services are not exposed in the first place, they are much less likely to become embroiled in large-scale exploitation following a significant exposure. This means fewer surprises when new vulnerabilities emerge, less urgent scrambling, and more time to respond thoughtfully.
Intruder automates this process, from discovering shadow IT and monitoring for new exposures to alerting teams the moment something changes, so security teams can always be proactive rather than reacting to exposures.
If you want to see what’s exposed in your environment, schedule an Intruder demo.
Source link
