The Stale SRV Record and the Silent DC
You are on a Linux assessment host in a client's IT VLAN with no domain credentials. Scope is 10.10.20.0/24 and a 90-minute window before a change freeze. A TCP SYN scan finds 61 live hosts: 3 domain controllers, 14 member servers, and 44 workstations. LDAP anonymous bind returns the naming context DC=corp,DC=local from 10.10.20.10 and 10.10.20.11. The third DC, 10.10.20.12, does not answer on 389 or 636, yet DNS SRV records still list all three DCs with equal priority and weight. SMB signing is not required on nine workstations and two member servers. 10.10.20.77 reports a clock skew of +7 minutes. LLMNR is enabled on the workstation VLAN. The client asks for a short, low-noise report and explicitly forbids exploitation that could cause an authentication outage. No credentials are available yet.
1. Which of the enumerated facts are confirmed findings, which are only evidence gaps, and what three checks would you run next? Justify the order.
Read the worked answer
Confirmed: LDAP is reachable on .10 and .11 and permits an anonymous rootDSE read; that is not the same as anonymous bind to the domain. SMB signing is disabled on 11 hosts according to the scan, which is a configuration fact but not proof of exploitability. Evidence gaps: .12 may be down, firewalled, or have LDAP blocked; SRV records prove DNS registration, not liveness. The +7 minute skew is a symptom, not yet a finding; it could be a VM snapshot, a bad time source, or a workstation-only issue. Order: first query DNS for the SRV/A records and test TCP 88/389/445 to .12 with a short timeout to decide whether it is a DC outage or filtering. Second, read rootDSE from .10/.11 for domain and forest functional level plus supported SASL mechanisms. Third, check the signing-disabled hosts for guest or anonymous SMB access and whether any hold privileged sessions, without relaying. Avoid LLMNR poisoning and relay because the client forbade authentication disruption and the window is short.
2. The client wants to know whether the SMB signing finding is a critical risk. How do you assess and communicate it without running a relay?
Read the worked answer
Signing-disabled SMB is a relay precondition, not a critical finding by itself. To call it critical you need an attacker-controlled authentication trigger, a path from the victim to the relay listener, NTLM accepted by a high-value service, and no LDAP signing or channel binding protections. With no credentials and a 90-minute window, I would not run a relay. I would check the hosts' SMB dialect and NTLM settings, whether they are file, print, or backup servers, and whether privileged accounts have sessions there. Then I would report: 'SMB signing is not required on 11 hosts; if an attacker can coerce NTLM authentication, relay to these hosts may be possible; this is a latent path to credential misuse, not a confirmed compromise.' Recommend requiring signing by GPO after the freeze, prioritizing servers over workstations. This communicates risk without overstating evidence.
3. What do you do with the +7 minute clock skew and LLMNR finding, given the no-outage constraint?
Read the worked answer
Treat both as hygiene and availability issues, not attack paths. A +7 minute skew will break Kerberos if it affects a DC or a host that authenticates to one; check the time source and whether the host is a VM restored from snapshot. Do not change time during the freeze without approval. LLMNR is enabled, which supports name-resolution poisoning, but poisoning can break production name resolution and is noisy. With no credentials and an explicit no-outage constraint, I would not run a responder. I would document LLMNR as a lateral-movement and credential-capture enabler and recommend disabling it via GPO. If the client permits passive collection only, a short, targeted LLMNR listener on the assessment host might be acceptable, but it should be scoped and time-boxed. The report should separate confirmed configuration from suspected impact.