ADSec102 - Protocol Security
Outdated and vulnerable protocols pose a great security risk in environments. By default, a lot of commonly abused protocols are enabled on Windows and Active Directory. Abusing them may allow an attacker to elevate privileges leveraging various techniques.
In the following, I will go through common protocols used in AD and ways to mitigate the risk associated with them.
Authentication
Windows authentication protocols are often targeted by attackers due to their wide usage, allowing lateral movement or privilege escalation. Modern Windows operating systems authenticate using two authentication protocol families:
- NTLM
- Kerberos
NTLM is divided into two generation: NTLMv1 and NTLMv2. Both protocols are vulnerable and largely depricated. Latest Windows version have NTLMv1 removed by default, and enforce Kerberos usage for authentication.
Enforce NTLMv2
Since LM and NTLMv1 are deprecated and should therefore not be used, deactivating them in an AD environment is important to mitigate the risk associated with them.
NTLMv1 usage Audit
However, to avoid service disruption, an audit phase is recommended before enforcing the use of NTLMv2. The audit phase will allow us to see if the deactivation of LM and NTLMv1 causes issues.
The GPO to enable auditing is located at: Computer Configuration\Seucity Settings\Local Policies\Security Options
Network Security: Restrict NTLM: Audit NTLM authentication in this domain: Enabled
To review the generated logs:
- On the DC, open Event Viewer
- Go to Windows Logs/Security
- Filter the log for Event ID 4624 (An account was successfully logged on). NTLMv1 authentication appears in the form: • Authentication Package: NTLM • Logon Process: NtlmSsp • Package Name: NTLM V1 NTLMv2 authentication appears in the form: • Authentication Package: NTLM • Logon Process: NtlmSsp • Package Name: NTLM V2
Locate the origin of the NTLMv1 request if there is some.
NTLMv2
After a successful audit, we can enforce the use of NTLMv2.
The GPO to enforce NTLMv2 is located at: Computer Configuration\Security Settings\Local Policies\Security Options
Network security: Lan Manager authentication level:Send NTLMv2 response only. Refuse LM & NTLM
Enforce Kerberos
Even though using NTLMv2 considerably improves the security of the environment, it still comes with vulnerabilities. The best remediation that we can apply is completely turning off NTLM family protocols and only authenticate with Kerberos.
After the audit phase, as explained above, all the NTLM authentication attempts will appear. If there is no NTLM authentication that is required by a host, we can further proceed to the enforcement of Kerberos.
The GPO to enforce Kerberos and deny NTLM is located at:
- [DC ONLY]
Computer Configuration/Windows Settings/Security Settings/Local Policies/Security OptionsNetwork Security: Restrict NTLM: NTLM authentication in this domain:Deny All
Computer Configuration/Windows Settings/Security Settings/Local Policies/Security OptionsNetwork Security: Restrict NTLM: Incoming NTLM traffic:Deny AllNetwork Security: Restrict NTLM: Outgoing NTLM traffic to remote servers:Deny All
Protocols
RPC
RPC (Remote Procedure Call) defines methods that are accessible on a host via the network. Their goal is to be able to execution certain tasks outside of the computer. However, some of the functions can be abused, which can allow an attacker to gain access to a host even without being authenticated. Attacks, such as PetitPotam, highlight a real risk that some RPC interfaces create.
In general, attackers try to perform coercion attacks using vulnerable RPC interface to get other computer to authenticate to them, allowing them to gather information about the host, such as the NTLM hash. This could later be used to authenticate on any system, acting as the true originator.
An often used path to privilege escalation is using the captured NTLM hash to perform a relay attack against the AD CS service. The attacker can then issue a certificate, making him appear as the DC, therefore elevating its privilege.
PetitPotam
The PetitPotam attack against MS-EFSRPC (Microsoft Encrypted File System Remote Protocol) is one of the most famous coercion attack. It targets the methods: - EfsRpcOpenFileRaw, EfsRpcEncryptFileSrv, EfsRpcEncryptFileSrv, EfsRpcDecryptFileSrv, EfsRpcQueryUsersOnFile, EfsRpcQueryRecoveryAgents, EfsRpcRemoveUsersFromFile, EfsRpcAddUsersToFile, EfsRpcFileKeyInfo, EfsRpcDuplicateEncryptionInfoFile, EfsRpcAddUsersToFileEx.
The vulnerable methods allow an attacker to request the targeted system to authenticate to him, successfully sharing NTLM credentials. This can lead to local privilege escalation.
To remediate against the PetitPotam attack, the EFS service should be disabled. This can be done via registry:
Computer Configuration/Preferences/Windows Settings/Registry- New -> Registry Item
- Hive:
HKEY_LOCAL_MACHINE - Key Path:
SYSTEM\CurrentControlSet\Services\EFS - Value name:
Start - Value type:
REG_DWORD - Value data:
4
- Hive:
- New -> Registry Item
DFSCoerce
The ShadowCoerce attack targets Microsoft Distributed File System (DFS) Namespace Management Protocol. The two vulnerable functions are NetrDfsRemoveStdRoot and NetrDfsAddStdRoot. Similarly to other RPC-based attacks, the attacker manages to get NTLM hash of its victim by forcing it to authenticate to him.
To remediate against the DFSCoerce attack, the Dfs service should be disabled. This can be done via registry:
Computer Configuration/Preferences/Windows Settings/Registry- New -> Registry Item
- Hive:
HKEY_LOCAL_MACHINE - Key Path:
SYSTEM\CurrentControlSet\Services\Dfs - Value name:
Start - Value type:
REG_DWORD - Value data:
4
- Hive:
- New -> Registry Item
PrinterBug:
PrinterBug targets Microsoft Print System Remote Protocol (MS-RPRN). This service is responsible for the handling of print jobs and print-related tasks. As the other explained attacks, PrinterBug allows an attacker to trigger an authentication to any target.
Other vulnerable RPC protocols
- ShadowCoerce: Targets
Microsoft File Server Remote VSS Protocol (MS-FSRVP) - CheeseOunce: Targets
Microsoft EventLog Remoting Protocol (MS-EVEN)
SMB
SMB, or Server Message Block, is a network file sharing protocol. Windows environments use the SMB protocol to share resources, such as files or printers.
The way SMB authenticate using NTLM is prone to attack, in particular relay attacks. By default, SMB does not sign the data it transmits, therefore an attacker can capture the connection request and send it to another machine, acting as the originator of the request. Therefore, the server receiving the request cannot distinguish between the original packet or the replayed one, because of the absence of validation mechanisms.
SMB Signing
The quickest remediation to SMB relay attack is SMB Signing. Signing provides a way to ensure that the message received is, in fact, sent by the one who pretends to send it.
To enforce SMB Signing, navigate to:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options- (For clients) Microsoft network client: Digitally sign communications (always)
- (For DC & Servers): Microsoft network server: Digitally sign communications (always)
Not that settings the parameter for if server/client agrees serves no purpose and act as if the SMB signing was disabled.
Activating SMB signing should not cause any major issue, as SMBv1 is largely deprecated and therefore should absolutely not be used. SMBv3 is the current standard, and SMBv2 can remain active if legacy systems require it.
LDAP
LDAP, or Lightweight Directory Access Protocol, is used in Active Directory environment to access information on the DC, such as identities.
LDAP Signing Audit
Before, audit is required to ensure that no client require LDAP to not be signed. To
enable the auditing:
• Open Registry Editor on a domain controller.
• Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostic s
• Set the value for 16 LDAP Interface Events to 2 (Basic logging)
Still on the DC, configure LDAP GPO:
- On the DC, open Group Policy Management Console (GPMC).
- Create a GPO for the DC
- Go to: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options
- Configure: Domain controller: LDAP server signing requirements → None.
Setting it to None will allow logs related to insecure connection to be generated.
Monitor upcoming events in Event Viewer → Applications and Services Logs → Directory Service: • Event ID 2887: Daily summary of unsigned/simple binds (counts). • Event ID 2889: Detailed info about which client IP is making the insecure bind.
Once the EventID 2887 is no longer generated, it means that we can safely require the use of signing, without it breaking certain connections.
LDAP Signing
To activate LDAP signing and protecting LDAP communication from being abused, navigate to the following:
- On the DC, open Group Policy Management Console (GPMC).
- Create a GPO for the DC
- Go to: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options
- Configure: Domain controller: LDAP server signing requirements → Require signing.
- Create a GPO for Computers
- Go to: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options
- Configure: Network Security: LDAP client signing requirements → Require signing.
Microsoft Caution Note: “If you set the server to Require Signature, you must also set the client. Not setting the client results in loss of connection with the server.”
Conclusion
Thank you for reading, hoping it helped secure Windows protocol usage. This article is prone to future modifications to improve its quality/precision/completeness.