And the environment which is purely Windows Server 2016 (No domain) with LmCompatibilityLevel set to 5, does this hold true when using the currently available PyWinRM version when used with Windows Targets?
“Regardless of the transport protocol used (HTTP or HTTPS), PowerShell Remoting always encrypts all communication after initial authentication with a per-session AES-256 symmetric key.”
Since it will be quite a while before Kerberos and certificates will be available in the environment, is this basically the best that can be done for now? The password length is well above 8 characters, in addition.
I am also not sure how to classify the NTLMv2 Session Security as described here
The first article is a bit dated, but is Session Security used with NTLMv2 with an environment that has LmCompatibilityLevel set to 5? And if yes, how does the 128-bit encryption fit in? Is this baked in?
And since as per Windows 10 10.0.14393 or v1607 the NT Hashes have changed to AES-128, does this in any way influence the NTLMv2 Response?
The note around AES 256 session security is not entirely accurate, there are various forms of encryption that can go on when using winrm;
TLS based encryption
This is used when you are using a https endpoint and trumps auth based encryption (below)
Encrypts the entire http payload whereas auth based encryption just encrypts the WinRM message data
This is dependent on the Schannel configuration and is the same type of security that is used when you visit websites over https
Typically Windows does have pretty sane and secure defaults but older Windows hosts might have older hosts might have some settings that aren’t as secure
https://www.nartac.com/Products/IISCrypto/ is a great tool to help see what cipher suites and protocols are enabled as well as order them to what you want- CredSSP based message encryption
Same as TLS based encryption but only on the WinRM data- Kerberos based message encryption
Typically it is AES encryption but there are other encryption types that could be used [1]
In a secure environment you would be using AES 256 but an environment that is set up improperly could be using outdated ciphers like RC4 or DES
Because it is Kerberos, it requires a domain to be set up
NTLM based message encryption
RC4 encryption that can be based on a 40, 56, or 128 bit key
RC4 has quite a few vulnerabilities and while I don’t know of any practical way to decrypt it off the top of my head I’m sure there is something out there- No encryption
Basic auth doesn’t support encryption over http and the username password are just base64 encoded
Do not use basic auth unless you are running it over https, see TLS based auth above
So from your perspective, NTLM is better than basic auth as the token is a hash not base64 encoded info but the encryption is not that strong. Setting up a self signed certificate is not the hardest thing to do and it might be a better option for your setup right now. You won’t get the full security offered by certs but you will at least have a solid encryption setup in place whereas with NTLM you don’t even have this. Once you have a certificate authority or domain setup then you can just swap it over to Kerberos or use a CA issued cert.
I am also not sure how to classify the NTLMv2 Session Security as described here
NTLMv2 session security is a special mode implemented inside the NTLM protocol. During the authentication phase, the client will send a flag saying it supports the extended session security mode and the server responds back saying it either does or does not. This mode does a few extra things to make the authentication a bit more secure but NTLM is still not the best. You are definitely better off with it and having an LmCompatibiltiyLevel of 5 on your server end is the best way to do that.
And since as per Windows 10 10.0.14393 or v1607 the NT Hashes have changed to AES-128, does this in any way influence the NTLMv2 Response?
That article you linked to talks about how the LM and NT hashes are stored at rest on a Windows host or domain controller. The NTLM wire protocol is still the same as older Windows versions and NTLM only supports RC4 encryption.
TLDR: NTLM is not really secure but is better than basic auth. If you cannot use Kerberos then using a self signed certificate is highly recommended.