Wireshark-users: Re: [Wireshark-users] Decoding custom application traffic as NTLMSSP

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sat, 3 Nov 2012 17:04:30 -0700
On Nov 3, 2012, at 5:28 AM, mikethomson@xxxxxxxxxxx wrote:

> Hi all,
> 
> I captured the traffic of a custom windows application that is
> communicating via WCF TCP (not HTTP).
> The application uses Windows NTLMSSP authentication. This can quite easily
> spotted by the packets starting with the "NTLMSSP" string. For now I
> "decoded" the NTLMSSP handshake manually to extract challenge and response
> because I was not able to tell wireshark that it should decode that
> payload as ntlmssp, but that is not very convenient on the long run.
> 
> Is it possible to tell wireshark to decode certain traffic as ntlmssp?

What might make more sense here would be a way to get Wireshark to dissect a particular TCP connection using whatever protocols are used for the Windows Communication Foundation when a TCP transport is being used; this might allow it to, among other things, recognize NTLMSSP in the authentication traffic.

This document:

	http://msdn.microsoft.com/en-us/library/ms733128.aspx

says:

	Messaging

	The messaging layer is composed of channels. A channel is a component that processes a message in some way, for example, by authenticating a message. A set of channels is also known as a channel stack. Channels operate on messages and message headers. This is different from the service runtime layer, which is primarily concerned about processing the contents of message bodies.

	There are two types of channels: transport channels and protocol channels.

	Transport channels read and write messages from the network (or some other communication point with the outside world). Some transports use an encoder to convert messages (which are represented as XML Infosets) to and from the byte stream representation used by the network. Examples of transports are HTTP, named pipes, TCP, and MSMQ. Examples of encodings are XML and optimized binary.

	Protocol channels implement message processing protocols, often by reading or writing additional headers to the message. Examples of such protocols include WS-Security and WS-Reliability.

	The messaging layer illustrates the possible formats and exchange patterns of the data. WS-Security is an implementation of the WS-Security specification enabling security at the message layer. The WS-Reliable Messaging channel enables the guarantee of message delivery. The encoders present a variety of encodings that can be used to suit the needs of the message. The HTTP channel specifies that the HyperText Transport Protocol is used for message delivery. The TCP channel similarly specifies the TCP protocol. The Transaction Flow channel governs transacted message patterns. The Named Pipe channel enables interprocess communication. The MSMQ channel enables interoperation with MSMQ applications.

so Wireshark would probably need to know how to recognize the encapsulations used atop those transports (local "named pipes" wouldn't be dissected, unless somebody adds to WinPcap a way to tap a local named pipe, but if remote named pipes over SMB are used that might be worth dissecting; I don't know whether MSMQ runs over a network, but if it does, there might be protocols to dissect there).  It might also dissect encapsulations used at the messaging layer.