1 Microsoft Penetration Tester Interview Questions & Answers

I would prefer Kerberos and reduce NTLM, then make remaining NTLM authentication non-relayable. I would require SMB signing, enforce LDAP signing and channel binding where applicable, enable Extended Protection for Authentication on supported web services, restrict unnecessary network paths, and audit legacy NTLM dependencies before enforcement.

NTLM relay happens when an attacker forwards a captured NTLM authentication exchange to another service that accepts it. The practical defense is therefore to remove NTLM where possible and make services reject authentication that is not sufficiently protected or bound to the intended connection or service. In an authorized review, I would verify the Windows client-to-service authentication path, the network boundary, and the services that still accept NTLM. I would then validate SMB signing, LDAP protections, Extended Protection for Authentication, segmentation, and the organization's plan for safely reducing legacy NTLM use.

1. Which Windows services and network segments are in scope for the review?
2. Are SMB, LDAP, and Windows-authenticated web applications included?
3. Is NTLM still required by any known legacy applications or devices?
4. Are we expected only to review configuration, or also to perform a safely bounded validation of denied authentication paths?
5. Is there an existing NTLM audit or migration program that I should use as evidence?

I would start with the main decision: prevent captured NTLM authentication from being successfully forwarded to another service.

The client is the source of the authentication. In the preferred path shown in the diagram, I would use Kerberos where feasible because it reduces reliance on NTLM and provides stronger service authentication properties. Where NTLM must remain, the receiving services need controls that make a relayed authentication unusable.

For SMB file servers, I would require SMB signing on the relevant connection. SMB signing protects message integrity and helps defend against relay and spoofing attacks. When the receiving SMB server requires signing, an attacker who merely relays NTLM authentication cannot continue with arbitrary SMB operations unless valid signed SMB messages can be produced for that authenticated session.

For Active Directory LDAP, I would enforce LDAP signing for applicable LDAP authentication and configure LDAP channel binding appropriately for TLS-protected LDAP connections. LDAP signing protects the integrity and authenticity of LDAP messages. Channel Binding Tokens, or CBTs, bind application-layer authentication to the underlying TLS session. When CBT is required and the token is missing or does not match the current TLS session, authentication is rejected.

For IIS or other supported Windows web applications using Windows authentication, I would enable Extended Protection for Authentication, or EPA. EPA uses channel-binding information for SSL/TLS connections and service-binding information where applicable. This helps prevent captured Windows authentication from being successfully relayed to a different connection or service.

I would also reduce the number of reachable targets. Firewall rules and segmentation should prevent ordinary or untrusted client networks from reaching sensitive services unless the path is required. This is a supporting control: it reduces relay opportunities, but it does not replace SMB signing, LDAP protections, EPA, or reducing NTLM itself.

Finally, I would audit NTLM use before restricting it. The goal is to identify legacy systems that still depend on NTLM, migrate them to Kerberos or another supported authentication path where possible, and then progressively restrict or block NTLM. NTLM auditing provides evidence of dependency; it is not itself a preventive control.

For evidence, I would review effective service and Group Policy configuration, relevant authentication and NTLM audit logs, and permitted versus denied network paths from authorized vantage points. I would prefer non-destructive configuration and policy validation over actually relaying credentials unless the rules of engagement explicitly authorize a tightly controlled relay test.

A safe failure state is that SMB traffic that does not meet a required signing policy, LDAP authentication that does not satisfy required signing or channel-binding checks, or Windows authentication that fails required EPA checks is rejected rather than silently accepted. Unnecessary network paths should also be denied at the segmentation boundary.

The main limitation is compatibility. Older applications or devices may require NTLM or may not support the strongest signing, channel-binding, or EPA settings. That is why auditing and staged enforcement matter. Residual risk remains wherever NTLM is still accepted by a reachable service without an effective relay-resistant control.

1. Confirm the written authorization, in-scope Windows clients, services, and network boundaries.
2. Map where NTLM is still used and distinguish it from Kerberos authentication.
3. Identify relay-relevant receiving services, especially SMB, LDAP, and Windows-authenticated HTTP services.
4. Verify that relevant SMB servers require signing rather than merely supporting it.
5. Verify that Active Directory LDAP signing is enforced for applicable authentication and that LDAP channel binding is configured appropriately for TLS-protected LDAP connections.
6. Verify Extended Protection for Authentication on supported IIS or Windows web applications that use Windows authentication.
7. Review firewall and segmentation rules so ordinary or untrusted client segments cannot reach unnecessary authentication targets.
8. Audit legacy NTLM dependencies before tightening NTLM restrictions, then migrate or remediate those dependencies.
9. Validate allowed and denied paths using non-destructive checks, effective configuration, and log evidence. Perform an actual relay only if it is explicitly authorized and safely constrained.
10. Retest after remediation and document any systems where NTLM or weaker compatibility settings must remain.

The main cost is compatibility and operational work, not computation. Requiring SMB signing, LDAP signing, channel binding, or EPA can expose old clients and applications that rely on weaker behavior. Restricting NTLM may require application changes, service-account review, testing, and staged rollout. Segmentation adds firewall-policy and maintenance work. Auditing and monitoring also create log-review overhead. The benefit is a strong reduction in relay opportunities, but organizations should audit first and enforce gradually so security improvements do not unexpectedly interrupt required business services.

A common mistake is saying that disabling NTLM is the only answer without considering legacy dependencies or staged migration. Another is relying only on segmentation; firewalls reduce reachable targets but do not make an exposed service relay-resistant. Candidates also confuse encryption with relay protection: TLS by itself does not necessarily stop NTLM relay unless authentication is correctly bound to the TLS channel or intended service. Other mistakes include enabling SMB signing without requiring it where protection is needed, discussing LDAP signing without distinguishing it from LDAP channel binding, treating NTLM auditing or monitoring as prevention, or attempting a live relay during a review without explicit authorization.

Lead with the principle: make captured NTLM authentication unusable at another service. Then name the service-specific controls in order: prefer Kerberos and reduce NTLM, require SMB signing, enforce LDAP signing and appropriate channel binding, use EPA for supported web services, limit reachable targets, and audit legacy dependencies before enforcement. Clearly state that segmentation and monitoring support the defense but do not replace protocol-level protections.