SMB, RPC, and Netlogon: Mapping communication paths in an AD environment

1. Core mechanism

Calls between a Domain member computer and domain controller are not a single protocol, but rather overlapping layers. At the bottom is the TCP transport layer; The fact that a port is accessible only means that there is a service listening there. Above it SMB (default TCP 445) establishes a session: SMB2/3 NEGOTIATE, then authentication with SESSION_SETUP (Kerberos or NTLM via Negotiate), then TREE_CONNECT and CREATE. RPC, on the other hand, can operate over two transports: over the SMB named pipe (ncacn_np) or directly over the TCP (ncacn_ip_tcp). Netlogon is not a separate port of this table, but a RPC interface; \PIPE\NETLOGON is accessed on the well-known named pipe SMB or via a dynamic port TCP with ncacn_ip_tcp.

Interfaces and specifications

• TCP transport: the fact that a port is reachable indicates that it is a listening-only service; It does not contain identity or authority.
• SMB (default TCP 445): The sequence NEGOTIATE → SESSION_SETUP (authentication) → TREE_CONNECT (IPC$ or a share) → CREATE (named pipe or file).
• RPC over named pipe (ncacn_np): \PIPE\<ad> over share IPC$; RPC bind and authentication follow the SMB session.
• RPC over TCP (ncacn_ip_tcp): Endpoint Mapper (TCP 135) resolves dynamic endpoint; dynamic port range 49152–65535 on modern Windows.
• Netlogon (MS-NRPC): UUID 12345678-1234-ABCD-EF00-01234567CFFB, RPC version 1.0; \PIPE\NETLOGON via named pipe or ncacn_ip_tcp, in the context of machine account secure channel.
• Evidence surface: 4624 network logon carrying LogonType 3 on the target Security channel; This indicates successful authentication at the application layer, which port reachability alone does not produce.

Separate three layers: transport, SMB session, RPC bind

When a client can handshake TCP to DC's port 445 or 135, it only learns that there is a service listening there. This does not mean that any identity has been verified.

On the named-pipe path, SMB SESSION_SETUP handles authentication. Direct TCP RPC does not traverse that SMB step; authentication can be configured on the RPC binding. An interface security callback and application access checks are separate mechanisms. Do not assume that every RPC method performs a mandatory, independent authorization check on every call.

ncacn_np: TCP 445 → SMB NEGOTIATE / SESSION_SETUP → IPC$ → named pipe → RPC binding
ncacn_ip_tcp: EPM TCP 135 → dynamic TCP endpoint → RPC binding
Authentication: depends on transport/binding configuration
Authorization: interface callback / application access check
Netlogon: method-specific MS-NRPC conditions, not a generic RPC requirement

Where Netlogon fits

Netlogon Remote Protocol (MS-NRPC) is an RPC interface used for machine and user authentication. It has no fixed, dedicated "Netlogon port"; clients reach it through the SMB named pipe \PIPE\NETLOGON or through a dynamic TCP port assigned by the Endpoint Mapper for ncacn_ip_tcp.

For Netlogon operations using a secure channel, the machine-account context and method-specific MS-NRPC requirements matter. Methods implementing client privilege checks apply their own rules. This Netlogon context does not imply that every RPC interface requires a secure channel.

Same interface, two different transports

The RPC protocol sequence identifies the transport: ncacn_np denotes an SMB named pipe, while ncacn_ip_tcp denotes TCP/IP. On the named-pipe path, the call traverses the SMB session (TCP 445) and IPC$; on the TCP path, the client first queries the Endpoint Mapper (TCP 135) and receives a dynamic port.

The two paths can reach the same logical RPC interface when that server exposes it on both transports. Port reachability establishes neither authentication nor permission to invoke a method.

What Artifact can and cannot say

The synthetic 4624 instance carries LogonType 3: a successful network logon session was created on the target, using an authentication package (here, Kerberos).

This record alone does not identify the share, named pipe, or RPC method that was accessed. A successful network logon does not prove that every subsequent transaction was authorized.

State and data flow

1. Select the RPC transport: SMB named pipe (ncacn_np) or direct TCP (ncacn_ip_tcp).
2. Named pipe: TCP 445 → SMB NEGOTIATE and SESSION_SETUP. Direct TCP: TCP 135 Endpoint Mapper → reported dynamic endpoint.
3. The named-pipe path opens IPC$ / the named pipe. Direct TCP has no such SMB steps.
4. Establish RPC binding. Binding authentication and interface security callback conditions depend on the service configuration.
5. A successful network logon with Audit Logon Success can produce target-side 4624 / Type 3; it does not prove a particular RPC method result.
6. Evaluate applicable application access checks and method conditions. Netlogon operations using a secure channel are a separate MS-NRPC scope.

2. Exploitation

Broken trust assumption

Broken assumption: "If the port is open (e.g. 445 or 135 accessible) the protocol is available and the call is authorized." Whereas reachability, authentication and authorization are separate layers. An open port exposes only the transport layer; SMB can also deny the session at the authentication level, and RPC can also reject it at the bind and method level.

Technical prerequisites

• Network path (transport reachability) from the client to the corresponding port of DC.
• SMB is an accepted credential for logging in; Anonymous access is greatly restricted.
• The context or authority required for the corresponding RPC interface and method (e.g. machine account secure channel for Netlogon).
• The target listens to the relevant transport and the network segmentation does not block this path.

Exploitation mechanism

Reachability, authentication and operation permission are separate evidence. A named pipe uses an SMB session; direct TCP RPC does not require SMB SESSION_SETUP. A service can constrain requests through binding authentication, an interface callback or applicable method access checks. Do not generalize Netlogon’s method-specific secure-channel conditions to all RPC. This teaching example makes no connection or call.

Reachability is not capability

An open port does not mean authenticated or authorized access to that service. Each layer makes its own rejection decision: transport may be accessible, but session SMB or bind RPC may be rejected.

Therefore, attack surface assessment cannot be achieved by port inventory alone; The question of which identity can verify what on which transport and which RPC method is authorized should also be asked.

Where does rejection occur?

The denial layer determines the evidence: at the transport level the connection is never established (filtered/closed), at the SMB level authentication fails, at the RPC level the bind or method returns access denied.

Mixing these layers produces the wrong conclusion: a failed logon does not mean that the port is closed, and an open port does not mean that access succeeded.

3. Defense & Detection

Telemetry scope

• Telemetry occurs on the target computer (DC or member server); The channel for authentication over the network is Security.
• Within the Audit Logon subcategory, Success supports 4624 network logons, while Failure supports 4625 failures.
• Port reachability appears in firewall or connection logs. Application-layer acceptance or rejection is evaluated from logon records in the Security channel. This artifact contains only one successful LogonType 3 instance.

Events and relevant fields

• 4624 / LogonType 3: a successful network logon session; reaching a port alone does not generate this event.
• 4624 / AuthenticationPackageName: the package used (Kerberos or NTLM); this field does not identify the transport or RPC method that was called.
• 4624 / IpAddress and IpPort: source network context used for correlation.
• 4624 / TargetUserSid and TargetDomainName: the identity and authority context of the session principal.
• 4625 (Failure) and Status/SubStatus: indicate why authentication was denied; a failure can appear here even when the transport is reachable.

Two different proofs: connection and acceptance

Firewall and connection logs show that a port is accessible and traffic is flowing; but it doesn't say that the identity has been verified. Application acceptance is read from the 4624/4625 records in the Security channel.

Separating these two pieces of evidence prevents erroneous inferences such as "the port was open, therefore it was accessed."

Read the reason for rejection from Status

Status and SubStatus in 4625 records indicate why authentication was denied; they document an application-layer rejection even when the transport is reachable.

RPC-level access denial is separate from the Security logon record; even when a logon succeeds, a specific RPC method may remain unauthorized.

Detection logic · XPath

*[System[(EventID=4624)] and EventData[Data[@Name='LogonType']='3']]

Query assumptions

• This is an unexecuted candidate filter for Windows Event Log XML fields; it is not a SIEM query or a port-scan detector.
• LogonType 3 indicates successful authentication at the application layer; port reachability events should be searched in different sources (firewall/connection logs).
• IpAddress, AuthenticationPackageName, and TargetUserSid should be assessed together; no single field is sufficient for classification.
• The fixture parser has not been run; no result on an actual Windows dataset is claimed.

False positives

• Network logons are extremely common: file sharing, printing, and management RPC calls normally generate 4624 LogonType 3 events.
• A port scan that finds an open port does not produce a 4624 unless authentication occurs; port activity must not be confused with logon success.
• Negative example: a single 4624 does not indicate which share/pipe/RPC method was accessed.

Hardening

• Make session manipulation difficult by requiring SMB signing; take inventory and phase in and verify impact on legacy clients.
• Keep signing structure requiring signing/sealing for Netlogon secure channel; Apply by testing the compatibility effect.
• RestrictRemoteClients limits unauthenticated RPC client behavior; it is not a client allow-list or interface ACL, and ncacn_np named-pipe clients are exempt from these restrictions. Microsoft documents broad compatibility effects and says this policy should never be applied to a domain controller. Do not use it as generic DC hardening guidance.
• With network segmentation, open access to 445/135 and dynamic RPC ports only to required resources; Verify that legitimate traffic is not corrupted after the change.
• Establish alarm and correlation by separating port activity from evidence of success (4624) and failure (4625); this distinction has not yet been validated in the lab.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4624</EventID><Version>2</Version><Channel>Security</Channel><Computer>DC01.outreason.example</Computer></System>
  <EventData><Data Name="SubjectUserSid">S-1-5-18</Data><Data Name="TargetUserSid">S-1-5-21-3623811015-3361044348-30300820-1108</Data><Data Name="TargetUserName">WS10$</Data><Data Name="TargetDomainName">OUTREASON</Data><Data Name="TargetLogonId">0x9f2c1</Data><Data Name="LogonType">3</Data><Data Name="LogonProcessName">Kerberos</Data><Data Name="AuthenticationPackageName">Kerberos</Data><Data Name="WorkstationName">WS10</Data><Data Name="IpAddress">192.0.2.50</Data><Data Name="IpPort">49762</Data><Data Name="LmPackageName">-</Data><Data Name="KeyLength">0</Data></EventData>
</Event>

Two reality checks

Assumption: If port 445 or 135 is open on a DC, the attacker has already accessed the domain.

In fact: An open port establishes only reachability. Named-pipe RPC uses SMB authentication; direct TCP RPC uses its binding configuration. Interface callbacks and application access checks are separate conditions. Do not assume a mandatory separate check for every method; port or logon evidence does not establish operation permission.

Assumption: Netlogon is its own separate port and service; It has nothing to do with SMB.

In fact: Netlogon is an interface of RPC (MS-NRPC). \PIPE\NETLOGON is accessed via SMB (default TCP 445) as named pipe or via dynamic port TCP provided by Endpoint Mapper with ncacn_ip_tcp. There is no fixed dedicated "Netlogon port".

Sources

• Microsoft Open Specifications · [MS-RPCE] 2.1 Transport
  Transport section and RPC protocol-sequence table: ncacn_np (SMB) and ncacn_ip_tcp (TCP/IP).
• Microsoft Open Specifications · [MS-NRPC] Netlogon Remote Protocol (Overview and Transport)
  Introduction (RPC interface definition) and Transport 2.1: \PIPE\NETLOGON named pipe, ncacn_ip_tcp dynamic endpoint, UUID 12345678-1234-ABCD-EF00-01234567CFFB, RPC 1.0.
• Microsoft Open Specifications · [MS-SMB2] Server Message Block (SMB) Protocol Versions 2 and 3
  Protocol Details: NEGOTIATE, SESSION_SETUP, TREE_CONNECT, and CREATE message sequence.
• Microsoft · Service overview and network port requirements for Windows (KB832017)
  Dynamic port range (49152–65535) and RPC/Endpoint Mapper assignment of dynamic TCP ports.
• Microsoft · 4624(S) An account was successfully logged on
  Event Description, Logon types table (Type 3 Network), and Field Descriptions.
• Microsoft · NTLM overview
  Introduction: NTLM/Negotiate network authentication context and Kerberos as the preferred protocol.
• Microsoft · 4625(F) An account failed to log on
  Event 4625 failure is logged on the computer where the logon was attempted; Event description, Status/SubStatus, Audit Account Lockout and Audit Logon subcategories.
• Microsoft · Audit Credential Validation
  Audit Credential Validation occurs on the system authoritative for the credentials (DC for domain, local computer for local credentials); event list includes 4776.