Cross Forest Authentication NTLM

So we’ve seen how a trust is setup, and how we can manipulate the domain controllers involved, can we do the same for authentication traffic? The answer would be yes, but why is it a yes, and how is the main question.

While many believe WINS or LMHOSTS can help us on external (non-forest) trusts, we dive into a packet capture that has captured the opening of a fileshare on a remote forest.

For this demo, I have installed a resource server in the forestroot domain, and a RIVER client on the OCEANFLOOR domain.

The first packet that interests us is the call for the DNS record of the Resource server

Source: OCEANDC01

Destination: 172.16.6.31

Protocol: DNS

Description: DNS:QueryId = 0x82D9, QUERY (Standard query), Query  for resource.forestroot.local of type Host Addr on class Internet

That packet is offcourse answered with the IP address of the Resource server (172.16.6.103)

Source: 172.16.6.31

Destination: OCEANDC01

Protocol: DNS

Description: DNS:QueryId = 0xFF7F, QUERY (Standard query), Response – Success, 172.16.6.103

Then we see the outgoing connection from the RIVER client towards the RESOURCE server on SMB level:

Source: RIVER
Destination: RESOURCE

Protocol: SMB
Description: SMB:C; Negotiate, Dialect = PC NETWORK PROGRAM 1.0, LANMAN1.0, Windows for Workgroups 3.1a, LM1.2X002, LANMAN2.1, NT LM 0.12, SMB 2.002, SMB 2.???

The RESOURCE server responds with a Negotiate packet and then the line seems quiet for some time, so we need to look at what is happening on the forestroot side.

On the resource server, we also had a capture running, and there we see that the resource server is actually connecting with RPC to its domain controller.

Source: RESOURCE
Destination: 172.16.6.33 (FDC03 – domain controller)

Protocol: MSRPC

Description: MSRPC:c/o Bind:  UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT(EPMP)  Call=0x1  Assoc Grp=0x0  Xmit=0x16D0  Recv=0x16D0

After connecting to the server, it sends a logon package, indicating the remote logon:

Source: RESOURCE

Destination: 172.16.6.33

Protocol: MSRPC  (Netlogonr)

Description: NetLogonr:NetrLogonSamLogonEx Request, NLRNetrLogonSamLogonEx, Encrypted Data

The domain controller performs a DNS lookup (based on the site again!)

Source: 172.16.6.33
Destination: DNS SERVER

Protocol: LDAP

Description: DNS:QueryId = 0xB3DE, QUERY (Standard query), Query  for _ldap._tcp.South-Africa._sites.dc._msdcs.OCEANFLOOR.local of type SRV on class Internet

Now in this case, I (sneaky me) created the site in advance (on the OCEANFLOOR domain). The response therefore is the two (auto site coverage…) domain controller..

Now we see the same as with the trust creation, an LDAP lookup is fired to both domain controllers that were retrieved:

Source: 172.16.6.33
Destination: OCEANDC01

Protocol: LDAP

Description: LDAP:(CLDAP)Search Request, MessageID: 58, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases

Source: 172.16.6.33
Destination: MICHDC01

Protocol: LDAP

Description: LDAP:(CLDAP)Search Request, MessageID: 58, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases

Again, the first one to respond is the winner, however while the domain controller of the OCEANFLOOR do not respond that quickly (relatively speaking) the domain controller also fires a DNS lookup for the general domain, just in case: DNS:QueryId = 0x6B93, QUERY (Standard query), Query  for _ldap._tcp.dc._msdcs.OCEANFLOOR.local of type SRV on class Internet

And here is where it get’s interesting, while the LDAP is performed, the server actually also tries to locate the domain controllers of the OCEANFLOOR on Netbios!. This could be due to the fact that the OCEANFLOOR LDAP lookup takes some time, or that it does this always (something for next time). The better question then if off course, will the dc use the LDAP responses, or does it prefer the WINS lookup (need to setup a larger test lab 🙂 )

In my case WINS does not answer, the OCEANDC01 wins the run for the LDAP lookup..

Source: OCEANDC01

Destination: 172.16.5.33

Protocol: LDAP (Netlogon)

Description: NetLogon:LogonSAMLogonResponseEX (SAM Response to SAM logon request): 23 (0x17)

Then three packets follow that trigger our interest:

Source: 172.16.6.33
Destination: OCEANDC01

Protocol: MSRPC  (Netlogonr)

Description: NetLogonr:NetrLogonSamLogonWithFlags Request, LogonServer:NULL  ComputerName:

Source: OCEANDC01

Destination: 172.16.5.33

Protocol: MSRPC  (Netlogonr)

Description: NetLogonr:NetrLogonSamLogonWithFlags Response,

Source: 172.16.6.33
Destination: OCEANDC01

Protocol: MSRPC  (Netlogonr)

Description: NetLogonr:NetrLogonSamLogonEx Response,

And after that, the RESOURCE server seems to be granted access.