In 2021, four critical Microsoft Exchange vulnerabilities were made public that were almost immediately being exploited by the HAFNIUM (Vaporous Taurus) threat group. When internet emergencies such as this happen, it becomes critical to immediately:
- Identify all potentially vulnerable instances in your environment
- Evaluate identified instances to determine if they are vulnerable
- Continuously monitor progress until all potential risks are mitigated
Further, this needs to be a continuous process for the rest of your life, because the median monthly percentage of infrastructure change for Cortex Xpanse customers is 42%. In this blog, we’ll explore three major internet emergencies and how each of these issues has created a mandate for external attack surface management (EASM).
SolarStorm Highlighted a Gap in Attack Surface Visibility
When the SolarStorm attack happened, companies scrambled to determine if they were impacted. CISOs were unsure where or how many Orion servers had been deployed and who was responsible for remediating them. CEOs and board members alike were asking about their exposure to this emerging threat that had compromised one of the better-known security companies in the world. We at Palo Alto Networks had four Orion servers ourselves, with only one of them being used by the adversary in an attempt to install a Cobalt Strike back door (which Cortex XDR was able to block).
At the time, CISOs had to assume compromise of every Orion server and activate incident response plans to investigate every instance. Without an accurate understanding of what Orion servers were in use, you would have been unable to communicate potential exposure to the key stakeholders in your company or have any confidence that your company wasn’t compromised via an undiscovered Orion instance.
Critical Vulnerabilities in Microsoft Exchange Exposed Just How Sensitive Your Attack Surface Can Be
Many times, we think of the initial intrusion into an organization as being the first step in a chain of exploitation, adversaries following some meandering attack path through your infrastructure that eventually leads them to the sacred crown jewels. Naturally, what follows is a philosophy of stopping the adversary before they can act on their objectives, devaluing how consequential that initial compromise may be. While this certainly could be the case, depending on the adversaries' objectives, a SQL injection attack on an external web application could quickly lead to data exfiltration.
In 2021, critical vulnerabilities in Microsoft Exchange exposed the ability to do incredible harm without even the guesswork of finding a SQL injection attack, adversaries such as HAFNIUM just had to find vulnerable Exchange servers. Our Unit 42 team was involved in many related incident response engagements for customers experiencing tactics, techniques, and procedures including:
- Spearphishing internal and/or external targets using legitimate email addresses
- Replying mid-thread to deliver malware in the middle of a legitimate email chain
- Monitoring email communications for discovery and emailing themselves new credentials as soon as they were dumped from LSASS to maintain persistence
- Automated bulk exfiltration of sensitive company communications
Sometimes that initial compromise is the one you have to prevent, and the time you have to remediate is getting shorter. As noted in the 2022 Unit 42 Ransomware Threat Report, “[exploitation] can practically coincide with the reveal if the vulnerabilities themselves and the access that can be achieved by exploiting them are significant enough.”
The Long Tail of Log4j Highlights the Need for Continuous Management
Just because you’ve patched active instances of a vulnerability doesn’t mean it won’t rear its head again after being reintroduced into your environment. One issue with Log4j is that it’s such a widely used software component, you need to verify that you aren’t reintroducing the vulnerability to your environment every time software is redeployed. You may have patched everything in your environment, but that clean bill of health is only good until a vulnerable service is executed from a container registry or some third-party software gets deployed. You need to be prepared to continuously detect Log4j vulnerabilities in real-time as they are introduced into your environment for the rest of your career or at least until adversaries stop scanning for them.
You Need Real-Time Management of These Issues, Forever
At the end of the day, you can’t just shrug your shoulders at poor asset management anymore. Your team probably isn’t the only one deploying software for your organization. Even if you have wonderful controls around deployment, you still cannot ensure security checks on deployments you don’t know about. At least, that’s the case without an EASM solution such as Cortex Xpanse.
Your EASM solution should not stop at discovery though, many organizations find themselves struggling to identify asset owners and stakeholders who can deploy the critical mitigations to avoid compromise. With Active ASM, Cortex Xpanse can help you find those asset owners, as well as providing the ability to deactivate and repair exposures automatically, saving response time in your security operations center. Due diligence now mandates that you have in place continuous management of your attack surface to be able to immediately mitigate issues as they arise, and rise again. In the end, it will only make your life easier to continuously manage your security posture without depending on every other part of your organization to be doing what they are supposed to.