SMB relay attack

Exploiting the weak Windows authentication protocols is on the top of the list for any adversary, because it mostly relies on a design flaw in the protocol itself, moreover, it is easy and could allow the adversary to get access to remote systems with almost no alert from most systems such as an IPS, AV, etc.

In this series of articles, I would like to go through the details of some authentication attacks such as SMB relay attack, pass the hash, pass the token, LM/NTLM cracking and others. In this article, I will start with SMB relay attack, it is one of the most common and powerful technique to get access to a fully patched and secure system.

SMB Relay attack takes advantage of a weakness in the authentication protocol (NTLM) to perform a man in the middle between two systems, which allow the adversary to get administrative access to its target. To fully understand the details of SMB relay attack and other attacks in the coming articles, I would like to start with an introduction to some common terms and concepts, such as SMB protocol, hashes and different types of password hashes in Windows and finally Windows authentication protocols NT/NTLM

So, what is SMB?

The Server Message Block (SMB) Protocol is a network file sharing protocol, and as implemented in Microsoft Windows is known as Microsoft SMB Protocol. SMB lets you share files, disks, directories, printers, and others. Before Windows 2000, SMB used to run with NetBIOS over TCP/IP port 139. Therefore a NetBIOS session was required to establish SMB connection

Starting from Windows 2000 and higher, SMB can run over TCP/IP using port 445 without the need to run over NetBIOS sessions. Since SMB provides several features such as manipulating files, shares, messaging, IPC and more, it is one of the most attractive services for hackers during enumeration and exploitation phases.

Samba in the other hand, is the UNIX implementation of SMB. Samba is used to provide clients with the ability to access UNIX directories and files via the SMB protocol, the exact same way if they were talking to a Windows server. Samba now runs on multiple platforms and is an essential part of most Linux distributions.

What about Password Hash?!

Password Hash is an encrypted text string generated by a special 1-way encryption function using the clear text password string, for example, MD5, which is easy to perform, but very difficult to reverse. Most systems convert password into a hash format to protect and hide the original password

I will describe a general workflow for the most common use of password hashes which is account registration on a website or a system:

First-time user registration

1. The user creates an account by providing username, password, and other information
2. The password is hashed and stored in the database using SHA1 or other hashing algorithms.

User login

1. When the user tries to log in, the provided password is converted into a hash using the same hashing algorithms, and it is checked against the hash of the real password stored in the database.
2. If the hashes match, the user is granted access. Otherwise, access will be denied

You can try using different hashing algorithms using this online tool

https://www.tools4noobs.com/online_tools/hash/

LM, NTLM, and Kerberos in a nutshell

Before I go deeper into the difference between LM and NTLM. Let’s understand the history in a nutshell. The very first authentication protocol scheme was LM (LAN Manager) with LM hash, which turned out to be very simple and easy to crack. As a result, it was replaced by NTLMv1/ NTLMv2 with NT hash then and finally the famous Kerberos at the end

LM or LANMAN hash!

LM or LANMAN is the original way Windows stored passwords, it is the easiest hash in history to crack and here is how it is being generated:

• The password is converted to uppercase.
• The password must be exactly 14 characters, either by padding with NULL bytes (‘’).
• The password is divided into two 7-character (56-bit) passwords
• Each of those passwords is converted into a 64-bit DES key, by adding a parity bit to the end of each byte.
• Encrypt a constant string “KGS!@#$%” with each of the two keys, generating two 8-byte encrypted strings
• Concatenate those two strings to form a 16-byte LM hash string

Microsoft has replaced the LANMAN hash with NTLM, and then the Kerberos protocol. However, LANMAN is still available in newer systems to allow for backward compatibility with legacy systems.

NT or NTLM hash!

To overcome the security weaknesses in LM hash and LM authentication scheme, Microsoft introduced the NT hash and NTLM(v1 and v2) authentication protocol, NTLMv1 uses a hash generated by DES algorithm while NTLMv2 uses MD4, generating NT Hash is easier and less complicated than the LM hash because it is just an MD4 of the password (NTLMv2)

NT hash isn’t stored in a format that could be cracked easily. However, it does have a major flaw: Windows systems before Windows Vista/Windows Server 2008 uses LM hash by default for backward compatibility, so it is most of the time sent and stored along with the NT hash. Also, neither the NT hash nor the LM hash is salted. Salting is a process that combines the password with a random numeric value (the salt) before computing the one-way function.

Starting with Windows Vista and Windows Server 2008, Microsoft disabled the LM hash by default; which can be enabled for local or domain accounts using security policy. A good practice, especially for service accounts to prevent LM hash from being generated, is to use a password at least fifteen characters in length.

Authentication protocols

Authentication is a process for verifying the identity of an object, service or person. When you authenticate an object, the goal is to verify that the object is genuine. When you authenticate a service or person, the goal is to verify that the credentials presented are authentic.

Windows authentication protocol used between Windows clients and servers is NTLM. Although NTLM has been replaced by Kerberos, it is still widely used and supported in Windows environment. For instance, it is used when the client is authenticating to a server using an IP address or when the client is authenticating to a server that is not part of the same domain

What is NTLM

There are two versions of NTLM authentication protocols, NTLM version 1 and 2. The NTLM authentication protocols are based on a challenge/response technique which provide a guaranteeto a server that a user knows the password associated with the authenticating account. A server must take one of the following actions to verify the identity of a user when NTLM authentication is used:

• connect to a domain controller if the authenticating account is part of a domain.
• Search for the user’s account in the local SAM database, in case the account is a local account.

The NTLM protocol uses NT or NT/LM hashed password values, which are stored on the server or domain controller depending on the authenticating account (local or domain). Both hash values are 16 bytes each. The NTLM protocol uses two hashing algorithms, depending on the NTLM version. NTLM version 1 use the DES one-way hashing function, while NTLM version 2 uses the NT MD4 one-way hashing function

With NTLM, clear text passwords are not shared during the authentication process. instead, an encrypted challenge/response protocol is used for authenticatication. If you don’t fully understand the flow, the coming example will explain the process in details

NTLM authentication example

The following steps present an outline of NTLM authentication. The first step provides the user’s NTLM credentials and occurs only as part of the interactive authentication (login) process.

1. (Interactive authentication only) A user accesses a client computer and provides a domain name, username, and password. The client computes the hash of the password and discards the actual password.
2. The client sends the username to the server (in plaintext).
3. The server generates a 16-byte random number, called a challenge, and sends it to the client.
4. The client encrypts this challenge with the hash of the user’s password and returns the result to the server. This is called the response.
5. The server sends the following three items to the domain controller:

• Username
• Challenge sent to the client
• Response received from the client

1. The domain controller uses the user name to retrieve the hash of the user’s password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
2. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

SMB Relay Attack

Now is the right time to explain the attack, SMB Relay is considered as a man in the middle attack where the adversary grabs the privileged credential and use it to authenticate to the target system. Let’s recap how the LM/NTLN challenge/response protocol works before we go into the details of the attack.

1. The client sends the username in clear text format as a request for authentication
2. The server generates the challenge and sends it back to the client
3. The client encrypts the challenge with the hash of the user password and returns the results to the server
4. The server will encrypt the challenge using the stored password hash (in case of a local authentication), or it will pass it to the DC to do so (in case of a domain authentication)

SMB relay attack allows the attacker to re-use authentication attempts to gain access to a system in the network, the following steps will describe the attacks phases:

1. The attacker selects his victim and waits until someone/some system tries to authenticate to his machine (the attacker’s machine)
2. When the attacker receives authentication request to his machine, it sends authentication attempt to the selected victim
3. The victim creates the challenge and sends it back to the attacker
4. The attacker sends the challenge to the machine that initiated the connection
5. The machine encrypts the challenge with the password hash and sends it back to the attacker
6. The attacker sends the encrypted challenge to the victim and authenticates itself which grant the adversary a full access to the target system

You need to know that SMB relay is only useful if the user who is trying to authenticate on the target machine has administrative privileges on the target, and therefore, the attacker would get a remote shell to the target system

It is very common to find automated systems that scan or connect to all systems for many reasons such as, antivirus updates, compliance check, backups, software inventory, patch management, and many others. These systems usually login using accounts with administrative privileges to perform its management tasks. Using SMB Relay attack scenario, the attacker would be able to get the authentication attempts from these automated systems and use them to access other targets on the network.

Attack Simulation

Now let’s go through the technical steps to simulate the attack in a LAB environment, we are going to use a script called smbrelayx.py from Impacket collection.

To get a list of options available, type smbrelayx.py –help

Since we want to get full access to the target, the meterpreter payload would be a good option, so we need to follow the following sequence to generate the payload and listener using Metasploit:

1. Create a meterpreter exe payload using MSF venom that Impacket will execute on the target machine
2. Create a listener in the attacker machine to listen for incoming connections and establish a session with the target machine

• Create a meterpreter payload
• LHOST IP is the attacker IP

• Create a listener for incoming connections from the target machine to establish a meterpreter session
• Note that we should use the same IP and port used to generate the meterpreter payload

• listener created and waiting for connection

Now everything is set, let’s start using the smbrelayx script.

We set the target host IP using –h and the payload using –e. Now, the attacker waits for a connection from the network to his machine. Social engineering and phishing email could deceive users with privileges account to authenticate to attacker’s machine

• A privileged user establishing an SMB connection to the attacker’s machine

• SMB connection received by attacker’s machine and relayed to the target machine (192.168.0.13)

• Exploit succeeded, and a Meterpreter shell has been established between the attacker and target machine

• The attacker has totally owned the target machine, after migration to system process, a dump of all hashes was successfully executed using hash dump command

So, what is the solution?

There is no silver bullet solution for this attack because it relies on a flaw in the NTLM authentication protocol. However, there are some recommended measures to reduce the possibility of a successful attempt such as:

1. Try to move to a more secure authentication protocol such as ‘Kerberos.’
2. Disable LM/NTLMv1 using group policy, SMB Relay module in Metasploit works only with NTLMv1.

1. Enable NTLM audit in active directory using “Audit incoming NTLM traffic” and “Audit NTLM authentication in this domain,” you can use a SIEM rule to monitor any NTLM attempt from rough systems.

1. Another useful GPO setting “Add remote server exceptions for NTLM authentication” might be used for exceptions in case NTLMv1 is required for backward compatibility

1. Enable SMB signing using GPO “Digitally sign communications (always)” to prevent man-in-the-middle attacks, the SMB protocol supports the digital signing of SMB packets. This policy could be used to negotiate SMB packet signing initially before allowing SMB communication.

1. Perform network segregation across the organization (all segments / VLANs) to reduce the attack surface. Creating security domains is crucial. Different assets with different values should reside in different security domains physically or logically. The least possible trust relationships between domains would mitigate SMB attack that tries to gain access from lower-security domains to exploit high-value assets in higher-security domains. 


Credits

• https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx
• https://technet.microsoft.com/en-us/library/hh831571(v=ws.11).aspx
• https://technet.microsoft.com/en-us/library/cc731957(v=ws.11).aspx
• https://support.microsoft.com/en-us/help/887429/overview-of-server-message-block-signing
• https://technet.microsoft.com/en-us/library/2006.08.securitywatch.aspx