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!!
Here's random stuff related to what I am working on or interested in during my work day or in my personal life. I'm a nerd. The content will be nerdy.
Wednesday, March 28, 2018
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!