Not working, if victim connects with hostname (TLS alert internal error)

Hello friends,

i used Seth to test our corporate network for this RDP-flaw.
It's strange, because it worked fine, when i used Seth from my homeoffice (different network as my corporate network, but VPN connection)
The command: sudo ./seth.sh eth0 IP_ATTACKER IP_VICTIM IP_GATEWAY worked well, espacially when the victim connects to an RDP-server using the hostname at the Windows 10 RDP-window.

Today I'm sitting in the office, connected to the corporate LAN. I'm using the same equipment and no changes were made (attacker is a fresh Kali Linux VM. No changes were made).
The command: sudo ./seth.sh eth0 IP_ATTACKER IP_VICTIM IP_RDP-SERVER isn't working well. When I connect to the RDP-server from the victim machine using the hostname, I get the error 'TLS alert internal error received, make sure to use RC4-SHA.' When I'm using the IP address to connect to the RDP-server, the attack works well. But this is not good for demonstration because (in my opinion) no user uses the IP address to connect to a server in real life....

I would be grateful for some advice

[AdrianVollmer]

I suspect that certificate validation is done via CredSSP (read: Kerberos) in the latter case. Windows clients seem to behave differently lately.

Is the victim machine the same one in both of your tests?

Thanks for the fast reply :)

We are using CredSSP with NLA without the option to downgrade the connection. Seth worked fine with the fake-server-mode.

Yes, the victim is the host, the attacker is a VM, running on this host. No changes were made, only the IP addresses are different, because of an other DHCP-server. But attacker (VM) and victim (host) are on the same subnet, the RDP-servers too. nmap, pings and traceroutes work well

Edit: I found out something strange. Seth is not running in the following cases. When I'm connecting via hostname to a RDP-server within the LAN, my systems executes the connection WITHOUT certificate-warning. And I know, the certificate is self-signed, because the Subject of the certificate is the same as the Issuer. When I'm connecting via the IP-address, I get a certificate-warning, telling me the CA is not trustworthy.
I'm not an admin, but is there a setting in the Windows-environment which says something like "Don't show a warning, if the name in the connection is the same as the name of the subject of the certificate AND if the connection is made from the same subnet" ?

[AdrianVollmer]

I'm not an admin, but is there a setting in the Windows-environment which says something like "Don't show a warning, if the name in the connection is the same as the name of the subject of the certificate AND if the connection is made from the same subnet" ?

I suspect if you are using the full hostname and at the same time the firewall profile is "domain", Kerberos is used to validate the certificate, which may be self-signed.

If you use an IP address, the client can't know if the host is part of the domain and thus doesn't use Kerberos. If the firewall profile is "public" or "private", Windows assumes it cannot contact a domain controller and again refrains from using Kerberos.

Again, I'm just speculating, but it seems plausible. Sorry for taking some time to respond.