Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's English Pages


Engineering and troubleshooting by Directory Master!
MCM: Directory

Quick Launch

Ondrej Sevecek's English Pages > Posts > How SMB encryption as well as many other Windows communications derive their encryption keys
March 03
How SMB encryption as well as many other Windows communications derive their encryption keys

Today, I have received an interesting question for which I have a more general and longer answer, so I decided to put it here instead of answering just the email.

How can a session between two non domain joined computers be encrypted using only the password of the account accessing the resource? It seems that there is nothing more shared between the two hosts. Do you know how that works and why (if) it is allowed?

Non-domain means NTLM authentication as against Kerberos authentication which requiers domain accounts and Active Directory (AD) domain or forest trusts.

Both Kerberos and NTLM offer "session security" - it is they can derive session security encryption/signature keys form the authentication process. Such session keys are used in wide range of Windows communications, such as SMB signing, LDAP signing, DCOM signing (the DCOM authentication level called PktIntegrity) or DCOM encryption (the DCOM authentication level called PktPrivacy) or SQL server as well as the very essential Secure Channel sealing (encryption). The latest addition to this family is the SMB encryption which was introduced in Windows 2012 and Windows 8 with SMB version 3.

Note: if you look at the packets on wire, such as with Network Monitor, it is often called SASL signing or SASL encryption or sealing.

If I mention DCOM, many services are communicating over DCOM - WMI in the first place, Outlook when connecting to Information Store service (MSExchangeIS, store.exe) on an Exchange mailbox server. Many remote administration consoles, such as Event Viewer, Task Scheduler, Device Manager, DNS, DHCP, Cluster Manager, etc. use DCOM as their transport.

DCOM provides generic integrity (signing) or encryption (privacy or sealing) technology with the keys derived from either NTLM or Kerberos. You can also try it yourself from powershell. If you go for a remote WMI query such as the following one, you can use the -Authentication parameter to specify what level of privacy you want for the transport:

Get-WmiObject Win32_Process -Computer remote-srv -Authentication PacketIntegirty
Get-WmiObject Win32_Process -Computer remote-srv -Authentication PacketPrivacy

If you look at the communication with Network Monitor, you will see the difference - either you can see the contents in the binary data window, or you see just a random junk in case the communication is encrypted.

In case of Kerberos the session keys are generated randomly by DCs and transported to the client and server by means of TGS tickets. This is most secure method, because the transport encryption does not depend on weak user password. It may seem irelevant if the authentication itself depend on weak user password, but user passwords may require frequent changes. If anybody was able to capture the authenticated and encrypted traffic, although he/she may be able to brute-force the user password after some time, hopefully only after the password has been safely changed, may be after several years or longer. Then the password is invalid. And the transport encryption uses something random, thus unbreakably strong.

In case of NTLM (it comes in three versions LM, NTLMv1 and NTLMv2), there is no trusted third party which would generate the transport/session keys randomly, so the session key must be derived directly from the NTLM user password (hash actually) and other salt obtained from the authentication exchange.

The shared secret here is the LM hash or rather NT hash (the MD4 hash of user's password). User remembers his/her password while the remote server (or its local DC) that you connect to, remembers your NT hash.

The pure authentication exchange itself, in case of all three protocols does not provide mutual authentication between the client and the server. It is just you, as a user, verify your identity against any server that you connect to. Thus there would be a point for a MITM attack. In case, for example, you authenticate against a HTTP (non SSL) web server with NTLM, you do not know whether you really communicate with the real server or with any man-in-the-middle attacker. With HTTP or RDP, you solve the problem with TLS/SSL certificate authentication.

In case of SALS security for the mentioned Windows intranet communications, you solve the problem of mutual authentication with NTLMv2 session security. Although LM and NTLMv1 session security does not offer mutual authentication, it is part of the NTLMv2 session security derivation process. So it is also as much secure as it can be considering the use of user password for transport data encryption.

With LM/NTLMv1 session security, the transport keys are derived from user's MD4 NT hash and the random number (challenge) which is unique for every session established. With NTLMv2 session security, there is another random challenge generated by the client itself to verify the server knows the user's MD4 hash as well. So the NTLMv2 session keys depend on the user's MD4 NT hash and the two random challenges, one of which is generated by the server, while the other is generated by the client.

If the subsequent tranpsort uses the SALS signing or encryption, you have mutual authentication even in case of LM or NTLMv1 (not that you would like to employ LM or NTLMv1 at all, because they are weak anyway).

Wrapping it up, if you have SMB signing, SMB encryption, LDAP signing or DCOM packet integrity or packet privacy with NTLMv2 session security you have a mutually authenticated and signed or respective encrypted channel even in workgroup environment.

What is wrong yet with the NTLMv2 session security is the fact it derives the encryption keys directly from user's password hash. Not that an attacker would be able to use rainbow-tables to crack the password or the transported data, because the key is salted with the two random numbers (challenges). Yet the attacker can try brute forcing a weak user password. However long it takes to bruteforce the weak password, the whole communication gets decrypted at once even after the several years it may take.

Note that this is exactly the reason, why even the PPTP VPN with MS-CHAPv2 and its MPPE encryption is deemed insecure in the first place. Not that it uses RC4 or even worse DES. The primary problem here is that MS-CHAPv2 is just the same as NTLMv2 and MPPE is just the same as NTLMv2 session security. So anything you transport over PPTP depends directly on your password and solely the password quality defines the time some attacker can get to the whole VPN data transmission. Years might not be significant for a small business, but for banking, pharmaceutic or security organization, it may be important more.


There are no comments for this post.

Add Comment

Sorry comments are disable due to the constant load of spam *

This simple antispam field seems to work well. Just put here the number.


You do not need to provide any value this column. It will automatically fill with the name of the article itself.

Author *

Body *