This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Domain controller sending SMB2 protocol over TCP445 congesting network

0

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

asked 19 Sep ‘14, 03:13

sykhoo's gravatar image

sykhoo
11112
accept rate: 0%

edited 19 Sep ‘14, 04:16

grahamb's gravatar image

grahamb ♦
19.8k330206


One Answer:

0

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

answered 19 Sep '14, 14:38

PaulOfford's gravatar image

PaulOfford
131283237
accept rate: 11%