SMB2 - NTLM GSSAPI messages continued

Hi all,

As you read a while back I'm trying to make the GSSAPI NTLM parsing generic enough for reuse, as it is now intertwined with the SMB parsing code. I have made some progress but before I continue, I would like some feedback from the community what is 'the bro way' on how to proceed.

What I did so far is create a separate gssapi.pac file with all the type definitions for GSSAPI*TOKEN* messages. I removed all the smb_header parameters to its parsing functions so that GSSAPI and SMB are decoupled. Yet, I get confused over what information belongs to which protocol. I display my thoughts here hoping that you can either concur my line of reasoning or correct me, before I type something that is completely 'un-brolike' :slight_smile:

As far as I know, the correct protocol chain is SMB[v1/2] -> GSSAPI -> NTLM. In my opinion, all message descriptions in the pac files from type SMB_NTLM_* should be renamed to NTLM_* as NTLM is not part of SMB. This would result in a separate NTLM.pac for NTLM parsing only.

I am next wondering where and how to generate SMB-NTLM-authenticate BIFevents after the decoupling. As I understand it, the parsing of the types defined in the pac files is done recursively. So originally, the parsing would go something like:

type SMB1_session_setup_andx_request_ntlm_extended_security(header: SMB_Header)
-> security_blob: SMB_NTLM_SSP(header)
--> gssapi: GSSAP_NEG_TOKEN(header)
---> gssapi: GSSAP_NEG_TOKEN_INIT(header)
(.......) some more layers (...)
---------> SMB_NTLM_Authenticate: bool = $context.connection.proc_smb_ntlm_authenticate(header, this);
-----------> proc_smb_ntlm_authenticate function generates the BifEvent including the SMB header detaIls given down to it as a parameter of each function.

In the new situation the header does not get given down to each function, therefor, when reaching the end-of-the-line at 'proc_smb_ntlm_authenticate', it cannot generate a proper BifEvent with the SMB header as it is not available to that function.

My guess what is needed is: the ability to raise the BifEvent at the 'top layer', after the whole parsing has been done, and not at the tail of the parsing of the message. If I am not mistaken, if I add a function to the SMB1_session_setup_andx_request then this will gets executed after the complete message has been parsed. I would then be able to reach down the message to get the user/domain/workstation variables in the NTLM message. But this would give me variables like security_blob.gssapi.gssapi_token(...)...domain_name, etc which doesnt make a lot of sense and is actually an eyesore.

It is a bit long mail, but basically my two questions are

1) do we all agree that the SMB_NTLM* functions should be renamed to NTLM* or am I missing something?

2) What is the best way to generate a BifEvent with SMB header and all the parsed user/domain/workstation values that were parsed deeper inside the protocol layer?

Any help on this is much appreciated; especially if you think I am overlooking a hidden can of worms somewhere :wink:

Regards

-Martin

1) do we all agree that the SMB_NTLM* functions should be renamed to NTLM* or am I missing something?

Agreed.

2) What is the best way to generate a BifEvent with SMB header and all the parsed user/domain/workstation values that were parsed deeper inside the protocol layer?

Just generate them with the connection record as an argument and we can tie together the various protocols at the script layer. That gives you the possibility to keep the clean abstraction in the core and all of the messy cross-structure stuff can happen in scripts.

Any help on this is much appreciated; especially if you think I am overlooking a hidden can of worms somewhere :wink:

From what you've described here and in our off-list emails, I think you're on the right track.

  .Seth