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 |
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.