CISA released a warning to federal agencies on May 18 that APT actors are actively exploiting recent vulnerabilities found in VMware, including CVE-2022-22954. Your first thought may have been to want new signatures, indicators, and/or behavioral techniques to detect attempted and successful exploits. If you’re a Zeek user or Corelight customer, you’ll find that sometimes you’re already getting what you need. In the event that the malicious payload is sent over cleartext HTTP, you’ll have the evidence you need sitting in your http.log. In this post, we share simple ways to detect evidence of this attack in the logs, which can be adapted to other data stores (e.g., a SIEM). Then, we show how a simple Zeek package can be used to provide better context when responding to an incident.
It is worth noting that a general issue with attacks like this is that they exploit the dynamic nature of the underlying software, so it’s unlikely that the search strings presented below represent the only ways to detect these vulnerabilities. As security researchers learn more about the root cause of these vulnerabilities, expect ways to hunt for exploitation to change. There won’t be a comprehensive “silver bullet,” but don’t fret because the evidence exists in your logs.
CVE-2022-22954 works when an attacker sends a well-crafted HTTP GET request to force remote code execution. One PoC relies on some fixed paths and templating keywords, however, given that this vector is from an issue reported six years ago, it is unlikely to be the only way to exploit this. That said, the PoC gives us three sample strings to search for:
${"freemarker.template.utility.Execute"?%24%7b%22%66%72%65%65%6d%61%72%6b%65%72%2e%74%65%6d%70%6c%61%74%65%2e%75%74%69%6c%69%74%79%2e%45%78%65%63%75%74%65%22/catalog-portal/ui/oauth/verify?The first is the templating feature used to launch commands on the remote machine. The second is just a URL encoded version of the first. The third is a vulnerable path on the VMware appliance. Simply searching for these in HTTP logs should find any attempted exploits sent in the clear. When doing so, pay close attention to the HTTP status_code, as a value of 400 could indicate a successful exploit.
To aid in further hunting for this attack, we’ve open sourced a Zeek package that identifies attempted/successful exploits based on these search strings and generates a notice, which includes the first 4KB of the response that was sent to the attacker. In the event the attacker used this for reconnaissance, for example by executing cat /etc/hosts, cat /etc/passwd, or whoami, the log will contain this information so you will know precisely what data was leaked. In the event the injected code isn’t to exfiltrate data, you will see whatever the injected code outputs, which may be helpful in determining the scope while responding to the incident. We did not see any successful exploits on our Polaris sites, but we did see reconnaissance checks like the commands above and at least one instance of an attempt to wget a shell script from a remote server and execute it.
Given the right historical evidence, a new vulnerability does not need to induce panic. With Zeek logs and the right visibility, you likely have everything you need to determine if a compromise occurred. And given Zeek’s extensibility as a platform, it’s easy to add functionality as we have shown to provide additional context when things go wrong.
By Corelight Labs team