Windows Domain Authentication flow via Netlogon - ToddMaxey/Technical-Documentation GitHub Wiki

Executive Summary: NTLM Authentication Troubleshooting with MITRE ATT&CK Codes

This article elaborates on the NTLM authentication process within a domain environment, focusing on both the authentication sequence and the configuration of Netlogon logging for troubleshooting purposes, incorporating relevant MITRE ATT&CK techniques for clarity.

  1. Authentication Process:

    • For an SMB or RDP connection where credentials are provided without specifying a domain, the local machine first tries to authenticate the user. If unsuccessful, the request is sent to the local Domain Controller (DC), and if that fails, to the Primary Domain Controller Emulator (PDCe). This follows the pattern described by MITRE ATT&CK technique T1556.002 (NTLM Relay), where NTLM credentials are relayed to a domain controller.

    • If authentication fails at all levels, including the PDCe, the process concludes, potentially indicating an attack or misconfiguration as per MITRE ATT&CK technique T1110.002 (Brute Force: Password Cracking).

  2. Troubleshooting Failed Logins:

    • Standard logs do not show the origin of failed authentication attempts, often leading to numerous failed attempts logged at the PDCe, associated with MITRE ATT&CK technique T1078 (Valid Accounts), where valid credentials are misused.

    • To pinpoint the source of failed logins, enabling Netlogon logging on the PDCe is essential. Subsequent correlation of logs identifies the DC and machine from which the requests originate.

  3. Enabling Netlogon Logging Using Various Methods:

    • nltest: This command-line tool enables or disables Netlogon logging, pertinent for capturing events related to T1556.003 (NTLM Brute Force) and other NTLM authentication issues.

    • PowerShell and Registry Editor (regedit): Both methods allow setting the DBFlag to enable detailed logging, crucial for monitoring and diagnosing as per T1569.002 (System Services: Service Execution).

    • Group Policy Object (GPO): Configuring Netlogon logging via GPO is effective for wide-scale deployment across multiple computers, aligning with T1484.001 (Domain Policy Modification: Group Policy Modification) to ensure consistent logging settings.

  4. Operational Considerations:

    • The Netlogon logs are vital for thorough investigation of authentication problems and follow the guidance of T1078 (Valid Accounts), as they help in tracking potentially compromised or misused accounts.

    • The setup described ensures logs are manageable and do not exhaust system resources, adhering to best practices in maintaining system performance and security.

Conclusion:

This detailed guide emphasizes the importance of Netlogon logging in diagnosing and addressing NTLM authentication challenges within a Windows domain environment. By correlating detailed logging with MITRE ATT&CK frameworks, IT administrators can enhance their security posture and quickly resolve authentication issues.

The data described in the article regarding NTLM authentication processes and the enabling of Netlogon logging is a critical resource for forensic investigations within Windows domain environments. Specifically, the detailed authentication logging facilitated by Netlogon provides invaluable insights into the authentication pathways and potential security breaches.

  1. Traceability of Authentication Attempts: By enabling detailed Netlogon logging, investigators can trace each step of the authentication process. This includes identifying whether authentication attempts were initially processed locally or forwarded to a domain controller. Such detailed logs are crucial for pinpointing the source of failed logins, whether they emanate from within the network or from external sources.

  2. Forensic Clarity: The ability to activate logging on demand (using tools like nltest or PowerShell) and collect logs from specific domain controllers or machines enhances the granularity of forensic analysis. It allows investigators to reconstruct events by correlating timestamps, account names, and machine identifiers across multiple log sources.

  3. Detection of Anomalous Activities: The logs generated provide a baseline of normal activity, against which anomalous or malicious activities can be detected. For instance, repeated failed logon attempts from a single source might indicate a brute force attack, while unusual logon times or locations could suggest credential misuse.

  4. Contribution to Mitigation Strategies: Understanding the flow of authentication and the points of failure not only aids in forensic analysis but also contributes to the development of more robust security measures. By analyzing the methods and pathways used in an attack, security teams can better design their network architecture, authentication protocols, and response strategies to prevent future incidents.

  5. Compliance and Documentation: Maintaining comprehensive logs is often a requirement for compliance with various security standards and regulations. The ability to produce detailed and accurate logging information fulfills these requirements and provides a ready means of documentation in the event of a security audit or investigation.

Overall, the use of detailed NTLM and Netlogon logging data is fundamental to understanding the dynamics of authentication within a Windows environment, providing a clear path to both detecting and responding to potential security threats. This, in turn, enhances the overall security posture of the organization by allowing for quick identification, analysis, and remediation of attacks.

Below, I have annotated the article with relevant MITRE ATT&CK codes (in bold) and descriptions for each item that pertains to NTLM authentication and Netlogon logging processes. These enhancements should provide a clearer linkage to the MITRE ATT&CK framework, detailing associated techniques and tactics.

With regards to NTLM authentication...

In a machine that is part of a domain, the process of authentication, when the authority authenticating is not specified, unfolds as follows:

  1. T1557 (Adversary-in-the-Middle): For an SMB or RDP connection where a username and password are provided but no domain is specified, the local machine is the initial authority checked for a matching username and password. If this check fails, the machine forwards the authentication request via Netlogon to its local Domain Controller (DC) for its Active Directory (AD) site. If the credentials fail authentication at the local DC, the request is forwarded to the DC that holds the Primary Domain Controller Emulator (PDCe) Flexible Single Master Operation (FSMO) role. If the credentials fail authentication at the PDCe, the process concludes.

  2. The standard authentication logging for DCs and local machines does not encapsulate the origin of the authentication attempt. This typically manifests as numerous failed authentication attempts displayed on the PDCe.

  3. T1557 (Adversary-in-the-Middle): To troubleshoot the origin of the failed logons, you will need to enable Netlogon logging on the PDCe and wait for another logon attempt that fails.

  4. You can now note the account name, date, and time of the event in the Authentication logs of the PDCe and then correlate this with any entries for that same username/date/time in the Netlogon log. This will then show you the upstream DC that sent the request.

  5. On the upstream DC, enable Netlogon logging and follow the previous methodology for the account in question. The failed authentication entry on this DC should point to a domain member machine like a workstation or a member server.

  6. On the upstream member machine, again enable Netlogon logging and wait for the failed Authentication attempt again. The information in the Netlogon log in this instance should show you the Name or IP of where the request originated. If this is outside of your network, then you will need to secure your exposed machine, and if it is on the inside, investigate the next machine. If it is a Windows machine, review the logs and set up Netlogon logging to gather more detail if needed.

Enabling Netlogon Logging Using nltest

The nltest command-line tool can be used to enable or disable Netlogon logging directly. To enable Netlogon logging, you would use the following command in an elevated Command Prompt:


nltest /dbflag:0x2080ffff

This command sets the Netlogon debugging flag to log all events of interest. To turn off logging, you would reset the flag by running:


nltest /dbflag:0x0

After enabling logging with nltest, the Netlogon log file (netlogon.log) will be generated in the %windir%\debug directory. It's important to monitor the size of this log file, as extensive logging can generate large amounts of data.

Enabling Netlogon Logging Using PowerShell

PowerShell does not have a direct cmdlet to enable Netlogon logging. However, you can use PowerShell to set the corresponding registry key that controls Netlogon logging:


Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "DBFlag" -Value 0x2080ffff 

Restart-Service Netlogon -Force

This script modifies the DBFlag registry value to enable verbose logging and then restarts the Netlogon service to apply the change. To disable logging, you would reset the DBFlag value to 0x0 and restart the Netlogon service again.

Enabling Netlogon Logging Using Registry Editor (regedit)

To enable Netlogon logging through the Registry Editor:

  1. Open regedit by typing regedit in the Start menu or Run dialog (Win + R).

  2. Navigate to the following path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  3. Right-click on Parameters, select New > DWORD (32-bit) Value, and name it DBFlag.

  4. Double-click on DBFlag and set the value to 0x2080ffff to enable verbose logging.

  5. Restart the Netlogon service for the changes to take effect.

To disable logging, change the DBFlag value back to 0x0 and restart the service.

Enabling Netlogon Logging Using Group Policy Object (GPO)

To enable Netlogon logging via GPO, which is useful for applying the setting across multiple computers in a domain:

  1. Open the Group Policy Management Console (gpmc.msc).

  2. Create a new GPO or edit an existing one that is applied to the computers you want to configure.

  3. Navigate to Computer Configuration > Preferences > Windows Settings > Registry.

  4. Right-click on Registry, select New > Registry Item, and configure the following settings:

    • Action: Update

    • Hive: HKEY_LOCAL_MACHINE

    • Key Path: SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

    • Value name: DBFlag

    • Value type: REG_DWORD

    • Value data: 0x2080ffff (to enable logging) or 0x0 (to disable logging)

  5. Once configured, ensure the GPO is linked to the appropriate Organizational Unit (OU) containing the target computers.

  6. The Netlogon service needs to be restarted on the target machines for the change to take effect. This can be achieved through script or manually.

Logfile location

The logfile, netlogon.log that is generated can be located at the path %windir%\debug

Typically this would be C:\Windows\debug

Each of these methods provides a means to enable detailed Netlogon logging, which is invaluable for troubleshooting authentication issues in a Windows domain environment. The logs files are fixed in size and are circular so not to pose a danger of drive space exhaustion. The additional compute overhead is really minimal for this logging and to have it enabled on every machine that is deployed could easily save time when troubleshooting these types of authentication issues.