Packetlabs Top 10 Critical Security Patches

The OWASP foundation has long maintained the OWASP Top 10 and it has served as a crucial framework in the development of all web applications. Within infrastructure the list is much larger and we’ve done our best to boil down and outline our own top 10 critical security patches. Each vulnerability outlined, except for CVE-2020-1350, has public exploit code available meaning any attacker can copy, paste, and compromise exposed systems. The purpose of this list is to maintain and outline critical patches that must be applied above all others.

Before outlining each of the Top 10 Critical Security Patches, it is important to outline first the cost of a data breach, and the top causes of a data breach. Within North America, the average cost of a data breach is between $4M USD and $10M USD and these numbers are on the rise. According to a recent report, nearly 60% of data breaches in the past two years can be traced back to critical missing security patches within operating systems, or applications.

“It’s a scale issue and it’s a prioritization issue,” says Stephen Boyer, co-founder and CTO at BitSight. “Think about all the vulnerabilities coming at you. The key question is which vulnerabilities [to patch] and when.”

Stephen Boyer, co-founder and CTO at BitSight

Remote working, during the COVID-19 pandemic, has also increased the challenges surrounding remote patch deployment as well as the maintenance of corporate systems. We are falling behind on patching corporate systems which has created massive opportunities for attackers. This list does not include weak or default credentials, insecure configurations, and use of legacy network protocols which still proliferate organizations today.

Remote Code Execution (RCE): In computer security, remote code execution is the ability for an attacker that has internet connectivity to a target system, to take control and perform unauthorized operations. This often includes running their own malicious code.

PL-1 - Microsoft Active Directory Certificates Services (AD CS) Vulnerabilities

The Active Directory Certificates Services (AD CS) is Microsoft’s Public Key Infrastructure (PKI) implementation, and is vulnerable by default if enabled within an Active Directory environment. While AD CS is not installed by default, for environments where it is deployed, these default misconfigurations can lead to devastating impact to the organization. There are significant privilege escalation vectors that exist and can be exploited by abusing these misconfigurations, which allows for any low-privileged user within the network to compromise and take over the entire domain ultimately.

There are multiple individual exploits which fall under the general umbrella of AD CS misconfigurations and vulnerabilities, each of them relying on different settings within the Active Directory Certificates Services itself, the individual vulnerable Certificate Templates, and dangerous access controls. These domain escalation vectors were identified and illustrated within research papers written by Will Schroeder and Lee Christensen released in 2021.

Microsoft has released information related to mitigation steps to protect organizations against AD CS related exploitation. The recommendation is to harden the configurations within the Certificate Template Settings, which includes reviewing access controls and enforcing strict enrollment rights and permissions on the templates. It’s also suggested to harden the AD CS server and HTTP endpoints, disabling NTLM authentication (see PL-4 NTLM Relay Attacks), enforcing signing (EPA, SMB Signing, LDAP Signing), and restricting server permissions and enrollment agents.

Beyond this, detailed tactics are provided within the aforementioned whitepaper that aim to provide guidance for monitoring, detecting, and preventing AD CS exploitation. While this includes methods for auditing and hardening enterprise CAs and templates, it also mentions enabling verbose event logging for visibility and detection of abnormal activity. Enabling CA audit logs, monitoring certificate enrollment requests (Event ID 4886/4887), certificate authentication events (EID 4768), template modifications (EID 4899), and more are crucial for identifying potential AD CS exploitation within an organization. 

PL-2 - Microsoft Windows Print Spooler Remote Code Execution Vulnerability, AKA PrintNightmare (CVE-2021-34527 & CVE-2021-1675)

In July of 2021, Microsoft officially announced that a vulnerability exists within the Microsoft Windows Print Spooler service. This remote code execution vulnerability is due to the Print Spooler service improperly performing privileged operations, which allows an attacker to execute arbitrary code with elevated privileges. The Print Spooler service is enabled by default on Windows and manages print queues and jobs, as well as loading printer drivers. All Windows versions are impacted by this vulnerability. It can also impact Domain Controllers and be exploited remotely to escalate privileges and compromise critical servers.

Microsoft has released a security patch that addresses this vulnerability. Administrators are recommended to install these updates, however, there are additional steps to help mitigate and protect systems from the PrintNightmare exploit. This includes disabling the Print Spooler service or uninstalling print services, if feasible, as well as disabling inbound remote printing so that the vulnerability cannot be exploited remotely. In general, reducing the attack surface and implementing sufficient monitoring and logging will help to identify and mitigate the impacts of this vulnerability.

PL-3 - NTLMv1 Downgrade Attack

Downgrade attacks in which a malicious adversary can intercept the authentication process between a client and server can be performed to trick systems into using a less secure authentication protocol. The older NTLMv1 challenge/response authentication protocol is considered less secure than the newer NTLMv2 counterpart.

The challenge-response mechanism in the NTLMv1 protocol has become vulnerable as improvements in systems hardware allows the hash to undergo offline cracking using brute-forcing or dictionary attacks, exposing the password, and therefore, allowing an attacker to gain unauthorized access to network systems or resources by essentially forcing systems to use this protocol for the authentication. NTLMv2 on the other hand, is considerably more difficult, and therefore, less susceptible to cracking. It is common however, to see NTLMv1 still enabled within environments, especially on servers where this is the default configuration, such as Windows Server 2003.

To mitigate vulnerabilities related to NTLM version 1, NTLMv1 authentication should be disabled within the environment by setting a domain-wide Group Policy Object (GPO), and to enforce only NTLMv2 responses.

PL-4 - NTLM Relay Attacks

NTLM relay attacks are extremely common within Active Directory environments. These attacks exploit the NTLM challenge-response mechanism directly, by intercepting legitimate authentication requests and forwarding (relaying) them to servers that are not enforcing signing to obtain unauthorized access. Plaintext passwords do not need to be known to execute these attacks.

Rather, this attack relies on stealing NTLM password hashes, and using them to authenticate to systems within the network by establishing a position between the client and server, and intercepting authentication traffic. There are multiple types of NTLM relaying attacks and methods for executing them. 

SMB/LDAP Relay Attacks

These types of attacks leverage capturing NTLM hashes and relaying them to other machines on the network via the SMB (Server Message Block) protocol. On the other hand, NTLM hashes can be captured and used to impersonate users to the LDAP (Lightweight Directory Access Protocol) service on a Domain Controller within the environment, as well.

Both can result in administrative access over a critical server, or allow attackers to laterally move with ease across a network, compromising several machines.

Coercion Methods

There are also existing methods that “force” or “induce” systems within a network to authenticate with NTLM for a man-in-the-middle attack. Instead of positioning oneself suitably to listen for authentication processes, there are tools that exist which exploit and abuse methods to coerce authentication instead from a targeted server. Abusing the Print Spooler service (MS-RPRN) or the MS-EFSRPC API to force authentication from a server is possible with public proof-of-concept tools, known as “PrinterBug”/”SpoolSample” or “PetitPotam”, respectively. However, these are only two among many public coercion tools and methods available. 

PL-1 Microsoft Active Directory Certificate Services (AD CS) Vulnerabilities and PL-3 - NTLMv1 Downgrade Attack leverage authentication coercion methods for exploitation. These attacks are exceptionally impactful and can lead to devastating compromise within an organization.

Mitigation

Disabling NTLM authentication in general across the environment is often suggested, however, this is not realistic or possible for many organizations. There are other mitigation efforts, however, which should be considered. This includes enforcing SMB Signing, LDAP Signing and Channel Binding, and Extended Protection for Authentication (EPA). Though, even careful consideration should be given to enabling security measures such as Channel Binding as this requires the integration and use of a Certificate Authority, which may lead to the introduction of further vulnerabilities within the environment (see PL-1 Microsoft Active Directory Certificates Services (AD CS) Vulnerabilities). 

Due to the general lack of knowledge regarding the security implications of AD CS, it is very possible that even with the best intentions, organizations may be opening up their infrastructure to additional vulnerabilities and exploits by attempting to remediate another.

PL-5 LLMNR, NBT-NS, and DHCPv6 Poisoning Attacks

Legacy protocols exist within environments that also enable NTLM relay attacks to take place (see PL-4 NTLM Relay Attacks). Protocols such as LLMNR and NBT-NS are protocols Microsoft Windows systems leverage as a backup to DNS for domain resolution. While DHCPv6, on the other hand, is used to configure and allocate IPv6 addresses for internal hosts. 

These protocols are all enabled on Windows systems by default, and can be exploited to perform relay attacks within the environment. The list of protocols that can be exploited to perform poisoning and relay attacks, however, are not limited here. Other protocols include WPAD (Web Proxy Auto-Discovery), mDNS/DNS, ADIDNS, and regular DHCP.

Requests are broadcasted within the network using these protocols, which can be poisoned by attackers to provide responses indicating that further requests should be forwarded to an attacker-controlled or compromised machine by spoofing an authoritative source (for example, a DNS server). In doing this, authentication information will be sent to the attacker-controlled machine instead, which can be combined with relay attacks to obtain unauthorized access to systems, or undergo offline password cracking to reveal the plaintext password from the hashed credentials.

Support for these protocols ideally should be disabled within internal environments, however, this is not possible for some organizations. Additional mitigation strategies are recommended, including enforcing signing on SMB servers and clients, and preferring Kerberos authentication over NTLM where possible. Disabling the Proxy Auto Detection Service will also mitigate further exploitation via DHCPv6 poisoning. Enforce and configure strong passwords for all domain users and accounts within the Active Directory environment to mitigate successful attempts at password cracking.

PL-6 - Kerberoasting Attacks

Kerberos is a ticket-based authentication protocol implemented by Windows into Active Directory. Domain users can request what’s known as a “Kerberos ticket” for any SPN (servicePrincipalName), which is an attribute that associates a service to an account within the Active Directory environment. This ticket is encrypted with the password hash of that service account, which can undergo password cracking in an attempt to reveal the plaintext password. Once the plaintext password is retrieved, the attacker can impersonate that account and access any systems and resources that the service account has access to. This attack in particular is dangerous because it is difficult to detect, it requires only low-privileged domain user access to the environment, and can allow for trivial privilege escalation or lateral movement within a network.

Detection and monitoring is key to mitigating Kerberoasting attacks, therefore, it is recommended to log Kerberos service ticket requests and investigate this activity within the network. Additionally, to reduce the impact or further exploitation via Kerberoasting, strong and complex passwords should be configured for service accounts, and strong AES encryption algorithms should be supported and enabled. Review and assign minimal required privileges within the domain for these accounts to limit access in the event of account compromise. 

https://www.crowdstrike.com/cybersecurity-101/kerberoasting/

https://adsecurity.org/?p=3458

PL-7 Local Administrator Password Reuse

Across organizations, a vulnerability that’s often identified within internal environments is the recurring usage of local administrator credentials. Local administrators possess high privileges and rights to machines and systems within a network, and with these privileges, it is strongly recommended that passwords be securely managed and unique across accounts on each individual machine. Once local administrator access is obtained to any one host, the credentials can be sprayed across all other systems within the environment to identify if the password is being reused. If it is, this results in trivial lateral movement across the network and can lead to cascading compromise and unauthorized administrative access to multiple machines. It can also potentially lead to domain privilege escalation if a vulnerable server is found to cache privileged domain credentials (see PL-10 Cached Credentials).

Password reuse for local administrator and privileged accounts should be avoided to contain and reduce the impact of unauthorized access. To prevent an attacker from leveraging a single set of credentials to compromise multiple internal systems, it is recommended to implement a tool such as Microsoft Local Administrator Password Solution (LAPS) to automatically and consistently rotate passwords for local administrator accounts. However, there are also other stronger, alternative tools that exist for securely managing these types of credentials that do not store passwords in plaintext and are not as susceptible to compromise with a privileged domain user

PL-8 Active Directory sAMAccountName Spoofing (CVE-2021-42278 & CVE-2021-42287)

In November of 2021, a domain escalation attack vector was identified based on two vulnerabilities that when exploited together, would allow low-privileged users to spoof and obtain elevated privileges within the Active Directory domain. Through this attack, any standard domain user account can obtain a Kerberos Service Ticket for a Domain Controller machine account by creating a new machine account (a privilege that is allowed by default for domain users) with a “sAMAccountName” attribute that points to the name of a Domain Controller, but without the “$” symbol which signifies that it is a machine account. When a service ticket is requested for this account, the created machine account name can be changed, resulting in a ticket for the legitimate Domain Controller machine account to be retrieved. This effectively would allow for the impersonation of the Domain Controller, and takeover of the entire domain. 

It is highly recommended for organizations to apply the associated Microsoft patches (KB5008380, KB5008602). If patching isn’t possible, there are workarounds involving setting the MachineAccountQuota attribute to “0”, which would prevent domain users from creating machine accounts. Monitoring the creation of computer accounts and Kerberos service ticket requests should also be performed to identify this attack and behaviour within the environment.

PL-9 Insecure Data Storage

A vulnerability often identified within internal environments is the insecure storage of sensitive data or credential information. It is frequently found that standard domain users within organizations have access to sensitive data and that the principle of least privilege is not adhered to. It is not uncommon to find credential data being stored as cleartext within files for ease of access, or within scripts for IT and system administrators to run automated tasks or jobs. This may result in unauthorized access to various systems and services within the organization or the compromise of privileged accounts. Among this accessible data, it has been found that shares sometimes contain entire backup drives, which can be parsed to retrieve sensitive information. Exploiting a low-privileged domain user who has access to these sensitive files can lead to trivial compromise of multiple servers or in the more severe cases, domain compromise.

The principle of least privilege should be adhered to for all groups within the domain. If access to certain information is not required to perform daily functions, then access should be restricted. Sensitive information should not be stored in cleartext without sufficient protections or access control restrictions on the file. When using scripts that require credentials, consider prompting for credentials rather than having them stored directly in cleartext. Implementing and enforcing an organization-wide password manager also assists in preventing the insecure storage of credentials by end-users.

PL-10 Cached Credentials

It is not uncommon for malicious adversaries to attempt to obtain unauthorized access using cached credentials. Cached credentials are encrypted credentials that are used when an authentication authority cannot be reached, enabling the machine to still authenticate an account and validate the user’s information. 

However, this is only one type. There are various types of credential stores that contain sensitive authentication data and numerous means for extracting them. The Local Security Authority (LSA) is a protected system process with the primary purpose of authenticating users on a local system, and may contain account passwords for Windows applications and services configured on the system, passwords stored in credential managers, service account passwords, security questions, and more. The Local Security Authority Subsystem Service (LSASS) is also a part of the LSA framework and keeps track of security policies and accounts that are in use on the system, storing credentials in memory for users that are currently active on the host. From this process, cleartext credentials can be easily extracted using simple methods or tools such as Task Manager (a native Windows system program) or malicious software such as Mimikatz. 

Extracting cached credentials is trivial on a system once administrative access is obtained over that host, and can be used to move laterally within a network, or even obtain more privileged access within an Active Directory domain environment.

While the concept of cached credentials is not a vulnerability on its own and is often leveraged legitimately for availability, attackers can exploit misconfigurations, lack of host hardening, and bad credential hygiene to pivot further within a network. It is recommended to implement credential tiering within the infrastructure to mitigate attempts at privilege escalation. Specifically, ensuring that Domain Administrators are only allowed to log in and administer Domain Controllers. A separate account with lower privileges should be created to administer other servers, and similarly for workstations or day-to-day activities. This prevents caching of highly privileged credentials on multiple low-trust machines or systems or several active privileged sessions.

Additionally, Windows features such as Credential Guard exist for newer Windows operating systems, and registry keys can be modified to enable features such as Protected Mode (for LSASS). Ideally, network endpoint detection and response should be tuned to detect and block attempts at accessing credential stores and registry keys. However, all recommendations are highly suggested to mitigate exploitation with cached credentials.

Conclusion

At Packetlabs, we specialize in penetration testing and application security. If you have concerns about whether you may be impacted by any of the top 10 critical vulnerabilities outlined in this article, our team of experts are always happy to help.

The frequency of your vulnerability scans must be at least quarterly. In large organizations, we often recommend weekly scans given the size and complexity of the environment.

Reach out today to get started.