Domain controller sending SMB2 protocol over TCP445 congesting network

Question

We have a Windows 2008R2 domain controller sending excess traffic to another win2008R2 domain controller and has been persistent for 2 weeks. Wireshark captured SMB2 protocol over TCP445 to the other DC. But we are unable to identify what is replicating, or file transferring. Appreciate anyone who can dissect the information below.

No.     Time           Source                Destination           Protocol Length Info
      5 0.002933000    10.101.23.250         172.16.10.3           SMB2     4418   Read Response
Frame 5: 4418 bytes on wire (35344 bits), 4418 bytes captured (35344 bits) on interface 0
Ethernet II, Src: 00:1a:64:25:9b:9e (00:1a:64:25:9b:9e), Dst: b8:af:67:ee:51:45 (b8:af:67:ee:51:45)
Internet Protocol Version 4, Src: 10.101.23.250 (10.101.23.250), Dst: 172.16.10.3 (172.16.10.3)
Transmission Control Protocol, Src Port: 445 (445), Dst Port: 65495 (65495), Seq: 4397, Ack: 118, Len: 4364
NetBIOS Session Service
SMB2 (Server Message Block Protocol version 2)
No.     Time           Source                Destination           Protocol Length Info
6 0.003496000    10.101.23.250         172.16.10.2           DCERPC   4450   Response: call_id: 4825142, Fragment: 1st, Ctx: 0
Frame 6: 4450 bytes on wire (35600 bits), 4450 bytes captured (35600 bits) on interface 0
Ethernet II, Src: 00:1a:64:25:9b:9e (00:1a:64:25:9b:9e), Dst: b8:af:67:ee:51:45 (b8:af:67:ee:51:45)
Internet Protocol Version 4, Src: 10.101.23.250 (10.101.23.250), Dst: 172.16.10.2 (172.16.10.2)
Transmission Control Protocol, Src Port: 445 (445), Dst Port: 63940 (63940), Seq: 1, Ack: 1, Len: 4396
NetBIOS Session Service
SMB2 (Server Message Block Protocol version 2)
Distributed Computing Environment / Remote Procedure Call (DCE/RPC) Response, Fragment: 1st, FragLen: 4280, Call: 4825142, Ctx: 0
No.     Time           Source                Destination           Protocol Length Info
7 0.005050000    172.16.10.3           10.101.23.250         TCP      60     65495→445 [ACK] Seq=118 Ack=7317 Win=256 Len=0
Frame 7: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: 6c:41:6a:13:1d:b1 (6c:41:6a:13:1d:b1), Dst: 00:1a:64:25:9b:9e (00:1a:64:25:9b:9e)
Internet Protocol Version 4, Src: 172.16.10.3 (172.16.10.3), Dst: 10.101.23.250 (10.101.23.250)
Transmission Control Protocol, Src Port: 65495 (65495), Dst Port: 445 (445), Seq: 118, Ack: 7317, Len: 0
No.     Time           Source                Destination           Protocol Length Info
8 0.005789000    172.16.10.3           10.101.23.250         SMB2     171    Read Request Len:4280 Off:0
Frame 8: 171 bytes on wire (1368 bits), 171 bytes captured (1368 bits) on interface 0
Ethernet II, Src: 6c:41:6a:13:1d:b1 (6c:41:6a:13:1d:b1), Dst: 00:1a:64:25:9b:9e (00:1a:64:25:9b:9e)
Internet Protocol Version 4, Src: 172.16.10.3 (172.16.10.3), Dst: 10.101.23.250 (10.101.23.250)
Transmission Control Protocol, Src Port: 65495 (65495), Dst Port: 445 (445), Seq: 118, Ack: 8761, Len: 117
NetBIOS Session Service
SMB2 (Server Message Block Protocol version 2)
No.     Time           Source                Destination           Protocol Length Info
9 0.005790000    172.16.10.2           10.101.23.250         TCP      60     63940→445 [ACK] Seq=1 Ack=2921 Win=353 Len=0
Frame 9: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: 6c:41:6a:13:1d:b1 (6c:41:6a:13:1d:b1), Dst: 00:1a:64:25:9b:9e (00:1a:64:25:9b:9e)
Internet Protocol Version 4, Src: 172.16.10.2 (172.16.10.2), Dst: 10.101.23.250 (10.101.23.250)
Transmission Control Protocol, Src Port: 63940 (63940), Dst Port: 445 (445), Seq: 1, Ack: 2921, Len: 0

Answer 1

What you are seeing is DCE-RPC encapsulated in SMB2. You will see a Write Request and Response for every DCE-RPC call, and a Read Request and Response for every DCE-RPC Response. Very messy.

This is a bit of a long procedure, but this is how you can get more information.

You need to see the connections start, and so you will have to shut down one server during a maintenance window and restart it. It's important that you capture with Wireshark (or dumpcap) when the servers make the TCP connections.

Stop the trace and identify the first stream that has the continuous traffic. Filter to select just that stream.

Filter further by adding the expression dcerpc.pkt_type == 11 to show all DCE-RPC BIND Requests. Within the decode of the BIND Request you will see Context Items (Ctx Item). Within each of these you will see the UUID of the program interface that the BIND sender is trying to connect to. Wireshark decodes most UUIDs. If it doesn't, search for the UUID with Google.

Repeat the above for any other long running streams.

Reasearch what those program interfaces are used for.

Best regards...Paul