Why should a DC contact clients in the domain?

Why should a DC contact clients in the domain?

  • Comments 1
  • Likes

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 http://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

 

Comments
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment