November 19, 2024
Critical vulnerability at Palo Alto Networks: Patches and CISA warnings The latest serious security vulnerability in Palo Alto Networks products has
The abbreviation NTLM stands for New Technology LAN Manager, which is an authentication method developed and provided by Microsoft based on a challenge-response mechanism.
The first NTLM version, which was first released in 1993, is now known as NTLMv1. This version should no longer be used. Just five years later, in 1998, Microsoft released the NTLMv2 version that is commonly used today.
NTLMv2 is still widely used in networks, especially since older services and protocols are not deactivated. This is why it is used. If the network infrastructure and the systems used allow it, this should be replaced by newer protocols such as Kerberos!
In the context of the topic of NTLM, there is always confusion in the distinction between terminology.
NT hash: The NT hash (Windows NT) can be found together with the LM hash (LAN Manager) in the SAM database (Security Accounts Manager). Attacks can be run against this to crack the hash or it can be used for pass-the-hash attacks.
NTLM: Authentication protocol provided by Microsoft. This has since been replaced by Kerberos. NTLM exists in two versions, the older NTLMv1 also known as Net-NTLMv1 and the version NTLMv2 or Net-NTLMv2. The newer version can no longer be viewed as state of the art and should be replaced where possible by successor solutions such as Kerberos.
NTLMv2 uses a challenge-response procedure to authenticate the requesting network participant. The following communication takes place between client and server:
It should be one If an attacker manages to obtain an NTLMv2 hash, he can try to crack it and obtain the password or “interpose” himself between the communication between client and server and intercept information about (changed) requests. We have explained how this is possible in the articles LLMNO, NetBIOS or IPv6 described.
To illustrate the attack options, a laboratory environment was set up containing:
To carry out the scenarios described below, the network must be configured so that IPv6 is active and there is no automatic filtering of packets (in virtual environments this may have to be set actively).
In addition, it was shown that in this laboratory environment the Active Directory certificate services must be installed and set up on the domain controller to recreate the relay on LDAPS.
In the first attack scenario, the NTLM authentication is relayed to SMB. To do this, we use the Windows behavior for name resolution. If the client is looking for a release that the known DNS cannot resolve, the query is made using alternative (predecessor) protocols, e.g. LLMNR.
This query can be intercepted by the attacker, who poses as a corresponding server and passes on the query in a modified form. Because an NTLM hash does not contain any information about the destination or sender. In our case, the security account management (SAM – Security Account Manager) is queried to output all password hashes of the existing users stored locally on the system:
Before starting the responder, the SMB and http options must be deactivated in the configuration. The responder listens on the interface eth0.
Ntlmrelayx should forward to the IP 192.168.5.5, in this case the local Windows 10 client. Dumping the SAM data is standard behavior of the tool for SMB.
The output shows the corresponding LM or NT password hashes of the users, including, for example, Administrator and myUser. These hashes can now be used for offline attacks on the passwords using brute force or used for authentication in Windows domains.
In the next example, forwarding takes place using IPv6 to LDAP. This means that an unauthorized user without permissions in AD can query domain information. The attack is carried out using mitm6 and ntlmrelayx.
It is then sufficient for a user to open the browser on the Windows 10 client. The standard behavior is that it first searches for provided proxy configurations, which the attacker intercepts using mitm6. The default behavior of ntlmrelayx when redirecting to ldap is to query domain information, which is stored in the local directory.
Finally, the request is forwarded using LDAPS. The experimental setup is the same as in the last scenario, but ntlmrelayx should now establish a connection to LDAPS and create a PC. We could then use this for further attacks.
The best approach to prevent the attacks mentioned is to configure the network or the components involved accordingly and securely. Some options that also protect against the attacks described have already been presented in our previous articles, including “IPv6—Man in the Middle"Or"LLMNR poisoning“. In addition, the following measures prevent the possibility of successfully executing the attacks shown above.
With package signing, every package sent is given a signature, which enables the client and server to determine that it has not been changed. However, it does not protect against packets being read. Signing should not be confused with encryption here.
With SMBv2, for example, a corresponding hash is calculated using HMAC-SHA256, taking the entire message into account.
For example: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/8b80e60b-7514-442b-baf4-eb785d0b0e2c
SMB signing serves as an authenticity and integrity feature for SMB packages used when accessing resources within the Active Directory. The client and server sign the SMB packets during communication, so that SMB packets can be prevented from being changed or forwarded. (Details at https://www.prosec-networks.com/blog/smb-server-message-block-protocol/)
Corresponding signing is only recommended from version SMBv2 onwards, as the packet size with SMBv1 is so small that performance problems can arise here. Furthermore, when configuring, it is important to ensure that signing is required and not just desired or enabled.
SMB signing can be configured through GPOs on servers and clients. As always, we advise you to check this in appropriate test settings before implementation!
Recommended settings:
Microsoft network (client): Digitally sign communication (always) Enabled
Microsoft network (client): Digitally sign communication (if server agrees) Disabled
Microsoft network (server): Digitally sign communications (always) Enabled
Microsoft network (server): Digitally sign communication (if client agrees) Disabled
Similar to signing using SMB, signing can also be set for LDAP. LDAP signing provides the LDAP connection with a digital signature.
The setting is also done using GPO on the domain controller for server and client:
LDAP Server Signature Request (GPO):
Desktop -> Guidelines -> Windows settings -> security settings -> local guidelines -> Security options -> Enable “Domain Controller: Server Signature Requirements for LDAP Servers”.
LDAP signature request for the client, using DC Group Policy (GPO):
Desktop -> Guidelines -> Windows settings -> security settings -> local guidelines -> Security options -> "Network Security: LDAP Client Signing Requirements -" Enable
A missing channel binding allows authentications to be forwarded to LDAPS.
With channel binding, a hash of the certificate (of the server) is created and appended to the normal packet. The server performs the same step and then checks the hash of its certificate against the hash value that was appended to the LDAPS packet.
In March 2020, Microsoft released updates to use channel binding.
Note: In the test environment mentioned above, the updates must be installed accordingly, otherwise channel binding is not available.
– Channel binding can be configured on domain controllers by enabling the “Domain controller: LDAP server channel binding token requirements” group policy. This is located in Group Policy Management under the path Computer > Policies > Windows Settings > Security Settings > Local Policies > Security Options
– The policy must be configured to the “Always” option and the policy must be enabled.
Note: Whether LDAP signing and channel binding are active can easily be checked using LdapRelayScan https://github.com/zyn3rgy/LdapRelayScan.git be checked. A valid domain user must be used to verify LDAP signing.
The direct attack is difficult to detect because the use of the protocols described is standard behavior in the network. One way of detection is to monitor the devices in the network for the protocols underlying the attack (e.g. LLMNR). Answers to these inquiries usually do not come from the systems available on the internet; details can be found at: https://www.prosec-networks.com/blog/llmnr-poisoning/
This detection can also be configured in the firewall. The responses that the attacker sends in the scenarios presented above should only come from known and authorized systems (LLMNR, wpad). If there is a response in the network from an IP that is not defined, the attacker can be identified.
If an attack is detected using the methods described in the last section, you should obtain as much information about it as possible. The device in question should then be blocked.
Additionally, all existing logs should be searched for activity from this IP. In addition to the logs from the firewalls and network devices, this also includes the event logs from the domain controllers.
IT-Grundschutz Compendium:
OPS.1.1.3: Patch and change management
NET.1.2: Network Management
ISO27001:
A.12.4.1 Event logging
A.13.1 Network security management
Critical vulnerability at Palo Alto Networks: Patches and CISA warnings The latest serious security vulnerability in Palo Alto Networks products has
Chinese hackers use T-Mobile and other US telecommunications systems for larger espionage campaign The giant US telecommunications company T-Mobile has confirmed that it is one of the
The challenge of permissions and non-human identities – Why managing credentials takes longer than you think With the
