Zero-day vulnerabilities: Lessons learned from the Death Star

It was perhaps the most egregious security breach in Imperial history.  

Galen Walton Erso, leading galactic authority on crystallography and energy enrichment, was head of the kyber crystal research team, a key unit involved in developing the Empire’s premier defense platform, the DS-1 Death Star Mobile Battle Station, more commonly referred to simply as the Death Star. Erso had a personal grudge against his employer and used his position to implement a critical zero-day vulnerability in the Death Star plans. He covertly worked with his daughter, Jyn Erso, to leak the master plans for the Death Star, including information on the zero-day vulnerability he had introduced. Jyn was a member of a special strike force associated with the notorious advanced persistent threat (APT) known as the Rebel Alliance (RA). RA was then able to use this information and target the zero-day vulnerability in the Death Star, causing catastrophic failure. 

Happy Star Wars Day! (May the Fourth be with you.)  

Zero-day vulnerabilities are on the rise. In 2021 Google Project Zero tracked a record-breaking 58 zero-day vulnerabilities being exploited in the wild. These vulnerabilities are in software that you and your client use every day. But like the Empire, you may not know a vulnerability exists until everything goes boom. Let’s talk about the realities of zero-day vulnerabilities, what they are, and how to detect and defend against them.  

What are zero-day vulnerabilities? 

The Death Star provides an example of a specific type of zero-day vulnerability—a threat introduced by someone inside your organization. But in general, a zero-day vulnerability is essentially an unknown flaw in a product, either software or hardware. So, a zero-day attack exploits a zero-day vulnerability by a malicious actor.  

Some may quibble over the finer points of these definitions. However, everyone agrees that a zero-day vulnerability is actively being exploited in the wild, and there is not yet an official patch, workaround, or fix available.  

How are zero-day vulnerabilities discovered?  

By its definition, a zero-day vulnerability is something you cannot detect because no one is aware that the threat even exists. However, threat actors typically reuse tactics, techniques, and procedures (TTPs), even when targeting a zero-day.  

While defenders may miss the zero-day that leads to initial access, you can still detect malicious activity by focusing on detection capabilities targeting common TTPs. For example, consider the group of Microsoft Exchange zero-day vulnerabilities disclosed in March 2021, commonly known as Proxylogon. According to a Microsoft report, the APT known as HAFNIUM (G0125) exploited Proxylogon for months before information on the critical remote code execution (RCE) vulnerability in Exchange was publicly released. HAFNIUM was exploiting Proxylogon (T1203) and deploying web shells (T1505.003), most notably a web shell known as China Chopper (S0020), a small web shell first discovered in 2012.  

We know based on Microsoft’s report that HAFNIUM was using malicious PowerShell (T1059.001), creating new domain accounts (T1136.002), and using web shells (T1505.003), to export mailbox data (T1114.002). So, while the method used to exploit Exchange was unknown before Microsoft’s public notice, the other TTPs used by HAFNIUM were well-documented and understood, and many platforms already had existing detections in place.  

The ConnectWise Cyber Research Unit (CRU) specifically had signatures in place and observed malicious web shells (T1505.003), launching commands via Windows Command shell (T1059.003). The query we use in the Perch SIEM to detect this type of activity looks like the following: 

event_id:1 AND process.parent.executable:"w3wp.exe" AND process.executable:("powershell.exe" OR "cmd.exe")

The “event_id:1” looks for process creation logs generated by Sysmon, which are are created for each new process. Then this signature looks for a new process with a parent process named “w3wp.exe,” which is the working process for IIS, Microsoft’s web server that Exchange is built on. Finally, we’re looking for processes named “powershell.exe” or “cmd.exe,” which would indicate a command being run by PowerShell or Windows command line. This signature would trigger on any web shell that tried to run malicious PowerShell or execute commands via the Windows command line, both of which are common TTPs used by any web shell. So, by focusing on these common TTPs, we can create detection signatures that aren’t limited to specific known vulnerabilities. While we might not detect initial access via a zero-day, we can still detect a compromise by detecting known TTPs. 

How to defend against zero-day vulnerabilities and attacks 

The key to defending against zero-day vulnerabilities is taking a defense in depth approach, which means focusing on reducing the attack surface as much as possible. Consider once again Proxylogon. Proxylogon targeted public Exchange servers, so a simple defense method to prevent most exploitations is to put your Exchange server behind a VPN.  

If that isn’t viable for your organization, at least put it behind a web application firewall (WAF). Even if the WAF cannot detect a zero-day, it certainly can detect the threat actor accessing the web shell and block them. While a threat actor may be able to compromise the server and get initial access, a good WAF would prevent them from doing anything with that access.  

Better yet, you can place the Exchange server behind a WAF and a VPN. Include proper monitoring and detections related to the WAF and you will be notified as soon as the web shell is accessed. This will allow you to investigate and properly mitigate the incident before any real damage is done. 

Additionally, a good defense in depth methodology includes: 

• Preventing Exchange mailbox accounts from having domain admin privileges 
• Enabling multi-factor authentication (MFA) by default everywhere 

• Segmenting the network to prevent lateral movement from the public-facing Exchange server 
• Using geofencing (even though geofencing is easy to bypass, it still reduces the attack surface) 

Additional third-party security tools, such as an EDR, can help when deploying Microsoft Defender ASR rules and zero-trust tools that implement application whitelisting and ringfencing.  

Conclusion 

Ultimately, zero-day attacks will continue to rise. So now it the time to take a good look at your network and consider the impact for each type of user and device if they were controlled by a malicious actor and what you can do to block, detect, delay, isolate, or deceive them. With careful planning, most risks can be mitigated. 

Build a plan using proven frameworks and models: MITRE DEFEND® provides a good framework for planning your security countermeasures, and the Cyber Defense Matrix is a good model for identifying gaps in your current security defenses.