Wednesday, March 28, 2018

If I Can't Reach Active Directory, it's Down

Unless it's not.

I recently had a customer tell me that my AD servers were broken. They were unable to set SPNs via Setspn.

They were able to run AD queries and were able to do other "AD Stuff". As always, I demanded a packet capture.

In very short order, the issue was clear. Setspn, for reasons I cannot guess, uses RPCs to the domain controller to set SPNs. I have not clue why it doesn't just use LDAP. LDAP is better, it only requires one port, that we know will be open.

RPCs are a pain, they require TCP 135, the end point mapper, then some random high port, named at the time of connection.

Below, we see that the customer hit the EPM in Frame 873 and was assigned a new connection on port 1028. We the SYN to 1028 in 874, then retries in 966 and 1146.

Firewalls and windows RPCs don't mix. Click here for larger.


RPC OPEN ALL THE PORTS!!

Living off the land with Kerberos and netsh interface portproxy

Have you ever been in the situation where you need to do some remote PowerShell on a machine, but you can’t find a layer 3 path to the server?

Did you find out that you could get remote PowerShell on the machine next to it, but you don’t want to pass your credentials to that machine, to double hop?  You know, ‘cause you aren’t insane

Did you ever say, why can’t I use that machine and protect my credentials?

Well, for only $9.99, admin access on the relay machine, and the write access to the target machine’s computer object in AD, you too can do the needful.

Recently, I needed to shutdown two hosts that I had admin rights on, but I only had layer 3 access to one. That one had access to the other.


I want to Enter-PSSession on MAGICHOST01, but can only get to MAGICHOST02.




PS C:\Windows\system32> ping MAGICHOST01.domain.net   

Pinging MAGICHOST01.domain.net [192.168.72.152] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.72.152:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
PS C:\Windows\system32>

PS C:\Windows\system32> ping MAGICHOST02.domain.net 

Pinging MAGICHOST02.domain.net [192.168.72.149] with 32 bytes of data:
Reply from 192.168.72.149: bytes=32 time=107ms TTL=48
Reply from 192.168.72.149: bytes=32 time=107ms TTL=48

Ping statistics for 192.168.72.149:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 107ms, Maximum = 107ms, Average = 107ms
Control-C

Port proxying is time honored method for connecting through a host to another, and now can be done with no 3rd party tools!

Enter-PSSession MAGICHOST02.domain.net
[MAGICHOST02.domain.net]: PS C:\Users\adm_magamach\Documents> netsh interface portproxy add v4tov4 listenaddress=192.168.72.149 listenport=44444 connectaddress=192.168.72.152 co
nnectport=5985

[MAGICHOST02.domain.net]: PS C:\Users\adm_magamach\Documents> netstat -ano | Select-String -Pattern 44444
  TCP    192.168.72.149:44444     0.0.0.0:0              LISTENING       248
[MAGICHOST02.domain.net]: PS C:\Users\adm_magamach\Documents>

The port is proxied, now let’s connect!

PS C:\Windows\system32> Enter-PSSession MAGICHOST02.domain.net -port 44444
Enter-PSSession : Connecting to remote server MAGICHOST02.domain.net failed with the following error message : WinRM cannot process the request. The following error with
Error code 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred.
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic
At line:1 char:1
+ Enter-PSSession MAGICHOST02.domain.net -port 44444
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (MAGICHOST02.domain.net:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

Oh NO! Lots of kerberos fail words.  Oh yeah, I am probably using the ticket meant for MAGICHOST02. Let’s force NTLM using IP.

PS C:\Windows\system32> Enter-PSSession 192.168.72.149 -port 44444
Enter-PSSession : Connecting to remote server 192.168.72.149 failed with the following error message : The WinRM client cannot process the request. Default authentication
may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are
provided. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more information on how to set
TrustedHosts run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ Enter-PSSession 192.168.72.149 -port 44444
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (192.168.72.149:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

This is scary, I don’ think I want to over trust.  What are the implications?  I have no idea? Let’s look at how Kerberos works…

PS C:\Windows\system32> klist | Select-String -Pattern MAGIC

    Server: HTTP/MAGICHOST02.domain.net @ DOMAIN.NET

Sure enough, we have a ticket for 02 and thus we are sending it when called by name. Let’s call it by a new, unique name.  A principal, in this case, computer, can have many Kerberos names (SPNs).  We simply add the new name to the real computer object of MAGICHOST01 . MAGICHOST33 is free.

PS C:\Windows\system32> setspn -s HTTP/MAGICHOST33.domain.net MAGICHOST01
Checking domain DC=domain,DC=net

Registering ServicePrincipalNames for CN=MAGICHOST01,OU=PRODUCTION,DC=domain,DC=net
        HTTP/MAGICHOST33.domain.net

Now we just need to direct traffic bound for MAGICHOST33.domain.net to MAGICHOST02, via the hosts file.  
192.168.72.149  MAGICHOST33.domain.net

Now we connect via the alternate port and alternate name. PowerShell lies about the name, in yellow, but the host knows who it is, in green!

PS C:\Windows\system32> Enter-PSSession MAGICHOST33.domain.net -port 44444
[MAGICHOST33.domain.net]: PS C:\Users\adm_magamach\Documents> ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : MAGICHOST01
   Primary Dns Suffix  . . . . . . . : DOMAIN.NET
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : DOMAIN.NET

Ethernet adapter Admin:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : HP NC362i Integrated DP Gigabit Server Adapter
   Physical Address. . . . . . . . . : B4-B5-2F-68-FE-A8
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.72.152(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.240
   Default Gateway . . . . . . . . . : 192.168.72.148



Enjoy!
Inputting falsified referrals to this site violates the terms of service of this site and is considered unauthorized access (hacking).