Time and again, new vulnerabilities are discovered and published, just as we saw when VMWare announced new vulnerabilities in vCenter Server and Cloud Foundation in September. You are probably using these servers right now, in your network or cloud environments. These critical vulnerability disclosures do not offer a quick and easy patch – so if you are using either vCenter Server or Cloud Foundation, you must declare an emergency and treat it like you have already been compromised.  

According to Bob Plankers, Technical Marketing Architect at VMware, "This vulnerability can be used by anyone who can reach vCenter Server over the network to gain access, regardless of the configuration settings of vCenter Server." Plankers went on to add: "In this era of ransomware it is safest to assume that an attacker is already inside your network somewhere, on a desktop and perhaps even in control of a user account, which is why we strongly recommend declaring an emergency change and patching as soon as possible.”

An attacker can compromise VMware vCenter Server using CVE-2021-22005 (a critical vulnerability with a CVSSv3 score of 9.8), which is “a file upload vulnerability that can be used to execute commands and software on the vCenter Server Appliance.” Regardless of the configuration settings, anyone who can access vCenter Server over the network can get access. This allows attackers to perform other malicious actions in your environments.

This VMWare security advisory also included 18 other vulnerabilities in vCenter Server 7.0, many of which had important severity ratings. These vulnerabilities also apply to Cloud Foundation 4.x (vServer Center). Fixed versions are available for all of them, and workarounds are available for some.  

Patches aren't enough

Working exploits became publicly available quickly, helping attackers to quickly target unpatched environments, which is why patching is a critical step. Fortunately, there are also detection methods and indicators of exploit available that can help defenders as they seek to determine whether their organization has been exploited by attackers. However - just patching is not sufficient, as VMWare indicated quite clearly in the VMWare vulnerabilities case.

When you are thinking about known vulnerabilities, particularly ones that are severe and announced with no patch available, or when there is a patch that requires considerable resources to implement (and therefore take time to put in place), there is another aspect to consider. It's important to determine whether a cybercriminal has already used the vulnerability against you in the past. Asking this question leads to compromise assessments and threat hunts in your environment. If you assume that bad guys have already used the vulnerability against you, indicators of compromise or artifacts can help you to either prove the thesis or determine that it has not been used against you and eliminate it as a potential problem in your environment.  

Hunting for evidence of attacks

When you are focusing on a specific vulnerability, you should be looking for evidence of it being used, or for evidence of the next steps of the attack. For example, the VM security advisory warned about vulnerabilities in vCenter Server and Cloud Foundation, which have the potential to lead to a large variety of attacks. But how far back should organizations look for evidence of exploitation?

Should you look for evidence in just the last 10 days? Do you need to look a bit further, perhaps in the last 30 days? Or do you need to do a more in-depth investigation, analyzing your data for the last three years? It may not be possible to conduct as thorough an investigation as you might like, because there is often a limit on forensic data retention, and an in-depth investigation is challenging if not impossible without forensic data.

That lack of forensic data is a problem because we know that attackers sometimes get access to an environment or network and stay for extended periods of time. In that period, how can you tell what they might have done without forensics to follow the trail? Even if they did not stay in the system, it may be that an attacker had access in the past and left, leaving behind more potential weaknesses. To take control when a critical vulnerability is disclosed, such as the vCenter Server and Cloud Foundation disclosures, patching quickly is step one. Analyzing your forensic data will give you a much better picture of what has happened and how to fix it, which means that you need to store forensic data for longer periods of time than is common, especially in cloud environments.  

Ongoing data collection improves IR

Collecting data on an ongoing basis for effective incident response is really a step you need to take prior to the four step incident response life cycle that NIST lays out. It is part of an overall readiness approach that improves an organization’s resilience, whether it is facing a data breach, a ransomware attack, a distributed denial of service attack, or something else. Proactively storing forensic data helps investigators examine a situation so your organization can make informed decisions quickly and bounce back faster after an attack. Attackers are always looking for easy entry points, and quickly exploiting zero- and one-day vulnerabilities is expected behavior from cybercriminals. Shifting your organization to a readiness mindset will help reduce the impact of these types of vulnerabilities and create more resilience in the case of future attacks.  

Protecting your enterprise against one of tday's most dangerous cyberthreats: ransomware

LAST UPDATED:

May 28, 2024

Don't miss these stories:

Frost & Sullivan’s Latest 2025 Frost Radar: The Need for Runtime Cloud Security in a Cloud-First World

Cloud breaches rose 35% year over year in 2024, and legacy security tools are failing to keep up. The rapid sprawl of multi-cloud and SaaS has shattered the assumptions baked into legacy, on-prem, and endpoint-focused security stacks, which can’t keep pace with today’s dynamic attack surfaces.

The Remote Worker Scam: Understanding the North Korean Insider Threat

Recent investigations have uncovered a sophisticated scheme by North Korean operatives to exploit remote work policies in the U.S. tech industry.

Who Touched My GCP Project? Understanding the Principal Part in Cloud Audit Logs – Part 2

This second part of the blog series continues the path to understanding principals and identities in Google Cloud Platform (GCP) Audit Logs. Part one introduced core concepts around GCP logging, the different identity types, service accounts, authentication methods, and impersonation.

Mitiga Security Advisory: Lack of Forensic Visibility with the Basic License in Google Drive

Mitiga's advisory highlights critical gaps in forensic visibility with Google Drive's Basic license, affecting security and incident investigations. Read on.

Cloud Detection vs Cloud Threat Hunting: Insights for Cyber Leaders

As cyber threats evolve, security teams need to detect and mitigate cloud attacks. Learn why cloud detection and threat hunting are key defense strategies.

Oops, I Leaked It Again — How Mitiga Found PII in Exposed Amazon RDS Snapshots

A recent Mitiga Research Team investigation found the well-regarded Amazon Relational Database Service is leaking PII via exposed RDS Snapshots.