Why should a DC contact clients in the domain?

Article
08/04/2010

Hi there,

In today’s blog post, I’m going to show you how I found out why a Domain controller was contacting random clients in the domain. This issue was reported by the customer due to security concerns. They suspected that a suspicious process might be running on the DC and the case was raised as a result of security concerns. In general we don’t expect Domain controllers to contact the clients running in the domain so our customer wanted to understand the reason behind that.

We first verified that the DC was really contacting some clients by collecting a network trace on the DC. You can see one of those clients (client1) contacted by the DC (DC1):

Note: DC and client IP addresses are replaced for data privacy.

...

11415 14:21:12 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=3912, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=70128947, Ack=0, Win=65535 ( ) = 65535 {TCP:515, IPv4:46}

11443 14:21:12 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=3913, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=3133793441, Ack=0, Win=65535 ( ) = 65535 {TCP:518, IPv4:46}

30922 14:33:17 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=4118, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2414564040, Ack=0, Win=65535 ( ) = 65535 {TCP:1270, IPv4:46}

30950 14:33:17 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=4120, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=1797119693, Ack=0, Win=65535 ( ) = 65535 {TCP:1273, IPv4:46}

51472 14:45:22 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=4314, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=1834145861, Ack=0, Win=65535 ( ) = 65535 {TCP:1403, IPv4:46}

51500 14:45:22 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=4315, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=4278939251, Ack=0, Win=65535 ( ) = 65535 {TCP:1406, IPv4:46}

67096 14:57:26 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=4514, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=1707963693, Ack=0, Win=65535 ( ) = 65535 {TCP:1945, IPv4:46}

67126 14:57:26 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=4515, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=3807245641, Ack=0, Win=65535 ( ) = 65535 {TCP:1948, IPv4:46}

74691 15:09:30 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=4740, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=1036190517, Ack=0, Win=65535 ( ) = 65535 {TCP:1983, IPv4:46}

74721 15:09:31 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=4741, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2281072822, Ack=0, Win=65535 ( ) = 65535 {TCP:1986, IPv4:46}

84937 15:21:35 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=4930, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=3190224054, Ack=0, Win=65535 ( ) = 65535 {TCP:2104, IPv4:46}

84965 15:21:35 05.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=4931, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2774224583, Ack=0, Win=65535 ( ) = 65535 {TCP:2107, IPv4:46}

...

At first look, it drew my attention that the connection attempt was repeated every 12 minutes or so. Then this should have been something running periodically on the DC. Normally Network Monitor should show you the process that is initiating those TCP sessions but under heavy load Network monitor stops to do so in favor of performance as it’s a costly operation. There’re some other methods to find out a process sending a certain packet but I decided to let the DC do whatever it would do against the client to see the whole activity.

So the customer removed firewall filters and allowed the DC to connect to Client1. After doing so we collected a new network trace to see the latest situation. We got the expected results by examining the new network trace:

a) The first interesting finding was that the client was sending a “Master Browser” announcement to the DC (DC1) shortly before one of these connection attempts from the DC side:

47140 07:30:31 08.07.2010 CLIENT1 DC1 BROWSER BROWSER:Master Announcement {SMB:351, UDP:350, IPv4:3}

b) After that browser announcement, the DC contacted the client at TCP port 139 to establish an SMB session:

47595 07:30:33 08.07.2010 DC1 CLIENT1 TCP TCP:Flags=......S., SrcPort=3787, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2594372577, Ack=0, Win=65535 ( ) = 65535 {TCP:373, IPv4:3}

47596 07:30:33 08.07.2010 CLIENT1 DC1 TCP TCP:Flags=...A..S., SrcPort=NETBIOS Session Service(139), DstPort=3787, PayloadLen=0, Seq=2981880191, Ack=2594372578, Win=8192 ( Scale factor not supported ) = 8192 {TCP:373, IPv4:3}

47597 07:30:33 08.07.2010 DC1 CLIENT1 TCP TCP:Flags=...A...., SrcPort=3787, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2594372578, Ack=2981880192, Win=65535 (scale factor 0x0) = 65535 {TCP:373, IPv4:3}

c) Then it initiated a NetBT session to the client:

47598 07:30:33 08.07.2010 DC1 CLIENT1 NbtSS NbtSS:SESSION REQUEST, Length =68 {NbtSS:374, TCP:373, IPv4:3}

47599 07:30:33 08.07.2010 CLIENT1 DC1 NbtSS NbtSS:POSITIVE SESSION RESPONSE, Length =0 {NbtSS:374, TCP:373, IPv4:3}

d) Then it established an SMB connection:

47600 07:30:33 08.07.2010 DC1 CLIENT1 SMB SMB:C; Negotiate, Dialect = PC NETWORK PROGRAM 1.0, LANMAN1.0, Windows for Workgroups 3.1a, LM1.2X002, LANMAN2.1, NT LM 0.12 {NbtSS:374, TCP:373, IPv4:3}

47602 07:30:33 08.07.2010 CLIENT1 DC1 SMB SMB:R; Negotiate, Dialect is NT LM 0.12 (#5), SpnegoToken (1.3.6.1.5.5.2) {NbtSS:374, TCP:373, IPv4:3}

47614 07:30:34 08.07.2010 DC1 CLIENT1 SMB SMB:C; Session Setup Andx, NTLM NEGOTIATE MESSAGE {NbtSS:374, TCP:373, IPv4:3}

47615 07:30:34 08.07.2010 CLIENT1 DC1 SMB SMB:R; Session Setup Andx, NTLM CHALLENGE MESSAGE - NT Status: System - Error, Code = (22) STATUS_MORE_PROCESSING_REQUIRED {NbtSS:374, TCP:373, IPv4:3}

47616 07:30:34 08.07.2010 DC1 CLIENT1 SMB SMB:C; Session Setup Andx, NTLM AUTHENTICATE MESSAGE, Workstation: DC1 {NbtSS:374, TCP:373, IPv4:3}

47621 07:30:34 08.07.2010 CLIENT1 DC1 SMB SMB:R; Session Setup Andx {NbtSS:374, TCP:373, IPv4:3}

e) Then it connected to the interprocess communication share (IPC$):

47625 07:30:34 08.07.2010 DC1 CLIENT1 SMB SMB:C; Tree Connect Andx, Path = \\CLIENT1\IPC$, Service = ????? {NbtSS:374, TCP:373, IPv4:3}

47626 07:30:34 08.07.2010 CLIENT1 DC1 SMB SMB:R; Tree Connect Andx, Service = IPC {NbtSS:374, TCP:373, IPv4:3}

f) Then it called RAP (Remote Administration Protocol) APIs like NetServerEnum2 etc:

47630 07:30:34 08.07.2010 DC1 CLIENT1 RAP RAP:NetServerEnum2 Request, InfoLevel = 1, LocalList in {SMB:379, NbtSS:374, TCP:373, IPv4:3}

47631 07:30:34 08.07.2010 CLIENT1 DC1 RAP RAP:NetServerEnum2 Response, Count = 1 {SMB:379, NbtSS:374, TCP:373, IPv4:3}

g) Once it got the requested info, it logged off and disconnected the TCP session:

47642 07:30:34 08.07.2010 DC1 CLIENT1 SMB SMB:C; Logoff Andx {NbtSS:374, TCP:373, IPv4:3}

47643 07:30:34 08.07.2010 CLIENT1 DC1 SMB SMB:R; Logoff Andx {NbtSS:374, TCP:373, IPv4:3}

47650 07:30:34 08.07.2010 DC1 CLIENT1 SMB SMB:C; Tree Disconnect {NbtSS:374, TCP:373, IPv4:3}

47651 07:30:34 08.07.2010 CLIENT1 DC1 SMB SMB:R; Tree Disconnect {NbtSS:374, TCP:373, IPv4:3}

47657 07:30:34 08.07.2010 DC1 CLIENT1 TCP TCP:Flags=...A...F, SrcPort=3787, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2594373651, Ack=2981881320, Win=64407 (scale factor 0x0) = 64407 {TCP:373, IPv4:3}

47658 07:30:34 08.07.2010 CLIENT1 DC1 TCP TCP:Flags=...A...F, SrcPort=NETBIOS Session Service(139), DstPort=3787, PayloadLen=0, Seq=2981881320, Ack=2594373652, Win=15559 (scale factor 0x0) = 15559 {TCP:373, IPv4:3}

47662 07:30:34 08.07.2010 DC1 CLIENT1 TCP TCP:Flags=...A...., SrcPort=3787, DstPort=NETBIOS Session Service(139), PayloadLen=0, Seq=2594373652, Ack=2981881321, Win=64407 (scale factor 0x0) = 64407 {TCP:373, IPv4:3}

h) That similar activity was seen every 12 minutes in the network trace.

RESULTS:

========

1) After analyzing the second network trace, the reason behind DC’s connection to clients was clear now:

Every 12 minutes or so master browser in a network segment informs the domain master browser (which is the DC) that it’s a master browser. And then the DC connects to master browser in turn to retrieve the browse list from that master browser. You can find more details below:

Taken from https://technet.microsoft.com/en-us/library/cc737661(WS.10).aspx How Computer Browser Service Works:

When a domain spans multiple subnets, the master browse servers for each subnet use a unicast Master Announcement message to announce themselves to the domain master browse server. This message notifies the domain master browse server that the sending computer is a master browse server in the same domain. When the domain master browse server receives a Master Browse Server Announcement message, it returns to the “announcing” master browse server a request for a list of the server’s in that master browse server’s subnet. When that list is received, the domain master browse server merges it with its own server list.

This process, repeated every 12 minutes, guarantees that the domain master browse server has a complete browse list of all the servers in the domain. Thus, when a client sends a browse request to a backup browse server, the backup browse server can return a list of all the servers in the domain, regardless of the subnet on which those servers are located.

...

Hope this helps

Thanks,

Murat

Why should a DC contact clients in the domain?

Additional resources