Logs that show evidence of DFSCoerce are the ones that record unexpected remote procedure call activity against domain controllers, especially from unusual hosts or accounts. Look for abnormal DFS-related authentication or connection attempts and correlate them with later coercion or relay behaviour. Because specific logging depends on configuration, defenders should combine host, network and directory logs rather than rely on one source.
What the logs need to reveal
DFSCoerce evidence is usually indirect. The most useful logs are the ones that show an unusual DFS or RPC request reaching a domain controller, especially when the source host, user, or timing does not fit normal administrative activity. That means you are looking for the attempt itself first, then for follow-on relay or coercion behaviour in adjacent telemetry.
Security teams should treat a single log source as incomplete. Host logs may show the request path, network logs may show the connection pattern, and directory or authentication logs may show the account and target relationship. The strongest evidence comes from correlating those sources around the same event window.
Because the activity is often low-noise until it is abused, the key question is not “did one log flag DFSCoerce?” but “do multiple logs line up around an unexpected remote call to a domain controller?” That correlation is what turns an isolated event into evidence.
Which log sources are most useful
Windows event logs on domain controllers are often the first place to look, but they are rarely sufficient on their own. You want logs that can show authentication attempts, remote procedure call activity, and the source system involved, then compare them with network telemetry that captures where the request originated and whether it was repeated.
Endpoint telemetry on the source host can add the missing context if the request was launched from a server, jump host, or workstation that should not normally talk to the target in that way. Directory-related logs help determine whether the account was expected to access that service, while network sensor data can expose the pattern even when the host logs are sparse.
For broader detection design, it helps to align the hunt with established attack mapping in the MITRE ATT&CK Enterprise Matrix, because the same telemetry that shows coercion often also supports lateral movement and credential abuse investigations.
How to separate benign DFS activity from coercion
Normal DFS traffic usually follows predictable administration, server, or client access paths. Suspicious activity is more likely when the source is unusual, the target controller is not part of the expected workflow, or the request appears shortly before relay, authentication abuse, or other coercion-related behaviour.
Context matters more than a single event ID or one protocol field. A legitimate management tool, backup task, or service account can generate DFS-related traffic, so analysts should compare the event against host role, account purpose, baseline network paths, and whether similar activity has occurred before from that asset.
If you are building a detection rule or triage workflow, the practical aim is to reduce false positives while keeping the pattern sensitive enough to catch abnormal RPC-to-controller activity. That usually means combining alert logic with allowlists for known management systems and then reviewing anything that falls outside the established baseline.
Risk and Threat Considerations
DFSCoerce is risky because it can turn ordinary trust relationships into a path for authentication coercion and relay. The main exposure is not the log entry itself, but the fact that the request may indicate an attacker trying to force a domain controller or related service into authenticating outward.
Failure mechanism: An attacker abuses DFS-related remote procedure calls or related connections to trigger unexpected authentication activity, then pairs that with relay or credential abuse if the environment does not restrict where those authentications can go.
Impact: Successful coercion can contribute to privilege escalation, unauthorized access, or broader domain compromise, especially when the surrounding authentication controls and network restrictions are weak.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1021 — Remote Services | DFSCoerce involves suspicious remote service/RPC activity against domain controllers. |
| T1557 — Adversary-in-the-Middle | DFSCoerce can support relay-style abuse after coerced authentication. | |
| T1040 — Network Sniffing | Network telemetry helps reveal the abnormal connection pattern around coercion attempts. | |
| Recommendation — Map abnormal RPC access paths to T1021 and investigate the source host and target relationship. Correlate coerced authentications with T1557-style relay indicators and block unsafe authentication paths. Use T1040-aligned monitoring to spot unusual controller-bound traffic patterns and repeated attempts. | ||
Practitioner Guidance
What to verify: Confirm the source host, account, and time window against normal administrative behaviour before treating the event as malicious. If the same pattern appears from multiple unusual hosts, or if it aligns with later authentication anomalies, treat it as higher confidence than a one-off connection attempt.
Decision rule: If the logs show unexpected RPC or DFS-related traffic to a domain controller from an untrusted or unfamiliar system, prioritize correlation across host, network, and directory logs over waiting for a single definitive alert. If the request is already followed by suspicious authentication behaviour, escalate as potential coercion and relay activity.
Practitioner takeaway: DFSCoerce is best detected as a pattern, not a single event, so the strongest investigations correlate abnormal RPC activity, source context, and downstream authentication behaviour before deciding whether the activity is benign.