The Importance of SMB and Understanding SMB Relay Attacks

In today's interconnected environments, the Server Message Block (SMB) protocol plays a vital role in facilitating file and resource sharing between systems. However, with great power comes security risks. One of the most prominent attacks involving SMB is the SMB Relay Attack, where attackers exploit the absence of SMB signing to hijack authentication processes and gain unauthorized access to systems.

In this blog, we dive deep into both the fundamentals of the SMB protocol and how the SMB relay attack operates, especially on systems where SMB signing is not enabled. We also explain how attackers can successfully execute SMB relay attacks even when SMB signing is enforced, detailing the added complexity and the methods required to manipulate and sign packets in such scenarios.

To make it easier for readers to understand:

• We begin by explaining how authentiation both as domain user and local users works.

• Next, we explore how SMB works in a typical access scenario, where a user attempts to connect to a shared folder.

• From there, we describe two distinct SMB relay attack scenarios: one with incorrect shared folder names and one with valid folder names, demonstrating how attacks evolve in each case.

• Finally we give a short summary of key different between 2 explained scenarios and sum up.

By the end of this blog, you'll have a comprehensive understanding of how SMB operates, how SMB relay attacks unfold, and how forced SMB signing can be bypassed.

User Credentials and Authentication Understanding the Foundation for SMB Relay Attacks

Before diving into how an SMB relay attack works, it’s essential to grasp how user credentials are stored and authenticated, both on local systems and domain environments. This foundational knowledge will make it easier to understand why SMB relay attacks are so effective, and it will help you appreciate the critical role authentication plays in network security. So, let’s break it down:

Local System Authentication

When a user is created locally on a Windows system, a unique Security Identifier (SID) is generated, which is crucial because it uniquely identifies the user within that system. The user’s password is stored in the Security Account Manager (SAM) file located at C:\Windows\System32\Config\SAM. The password may be stored using an LM (LAN Manager) hash or, more commonly, an NTLM hash due to the outdated and less secure nature of LM hashing.

Here’s an example of what a SAM entry might look like:

• Username: Jone
• RID: 1001 (the last component of the SID, identifying Jone as the 1001st user created on the system).
• LM Hash: Disabled in modern systems, often represented as aad3b435b51404ee.
• NTLM Hash: c39f2beb3d2ec06a62cb887fb391dee0.

Whenever a user logs in locally, the system verifies the password by checking it against the hash stored in the SAM.

Domain Authentication

For domain users, authentication happens differently. The user’s password is stored in the NTDS.dit file on the Domain Controller (DC), located at C:\Windows\NTDS\NTDS.dit. When a domain user logs in, the DC checks the user’s NTLM hash against this file. Upon successful verification, the user is issued a session key and a Ticket Granting Ticket (TGT), by Kerberos Protocol, allowing them to access network resources. So in other words, after successful verification of the Ntlmv2 hash , the KDC (Key Distribution Center) which is a part of Kerberos Protocol, will issue TGT to the user allowing them to access network resources.

Connecting the Dots How SMB Relay Attacks Exploit Authentication

Here’s where this knowledge becomes crucial:

In an SMB relay attack, the attacker captures the NTLM hash from a domain user login attempt (e.g., User A). After capturing this hash, the attacker sends it to another system (System B). If User A has local administrative privileges on System B, and the password for the local account matches the domain password, System B grants access. This allows the attacker to dump the SAM hashes from System B, gaining unauthorized access to sensitive credentials.

Now that you understand how authentication works in a domain, you're ready to explore how the SMB (Server Message Block) protocol enables systems to access shared resources, like folders, within the domain. This knowledge is crucial for fully grasping how SMB relay attacks exploit these connections. By understanding both authentication and SMB, you'll see how attackers take advantage of vulnerabilities when systems communicate across the network.

Normal Access Scenario to a Shared Folder

When a user from System A wants to access a shared folder on System B, the process involves following steps :

1. Authentication of User A while loging to Domain:

   • -User A authenticates with its NTLM hash to the Domain Controller (DC).
   • -The DC verifies the NTLM hash against its NTDS.dit database. Upon successful authentication, the DC provides User A with a first session key and a Ticket Granting Ticket (TGT).
   • (A TGT is a secure token that contains user credentials, allowing the user to access various services in the domain without needing to re-enter their NTLMv2 hash.)

2. Accessing SMB Service on System B:

   • -When User A wants access to the SMB service on System B ,(THE SHARED FOLDER), it sends the TGT along with the request to the DC.
   • -The DC decrypts the TGT using its unique decryption key to verify its integrity. If valid, the DC generates a second session key specifically for the communication between User A and System B.

3. Key Distribution:

   • -User A uses the first session key to decrypt the second session key and sends the relevant part of this key to System B. in addition it sends it NTLMv2 hash to B , in order to be authenticated and be eligible to get access to the shared folder.
   • -System B, upon receiving the second session key, uses its own key to decrypt it. Now, both User A and System B have a shared session key for encrypting and signing their SMB packets. B then after checking the NTLMv2 hash allows A to get access to the shared folder.

In this normal access scenario, the secure exchange of session keys and the verification of User A's NTLMv2 hash ensures that only authorized users can access shared resources like folders. However, when SMB signing is not enforced, this process can be exploited by attackers in an SMB relay attack. Now that you understand how access works under normal conditions, let's explore how this vulnerability is used to gain unauthorized access in an SMB relay attack when signing is disabled.

Scenario 1 SMB Relay Attack When the Share Folder Name is Typed Incorrectly

In this scenario, User A (the client) tries to connect to a non-existent shared folder on System B by typing the name of the shared folder with typo. This triggers a series of events that leads to a successful SMB relay attack.

1. User A Mistakenly Types a Wrong Shared Folder Name:

   • -User A sends a request to DC , saying that it wants access to a shared folder on system B. It also sends its TGT.
   • -The Domain Controller (DC), which handles authentication, checks the TGT sent by A, and authenticate system A , after authentication it realizes that no such folder exists.
   • -Since the folder doesn’t exist, the DC does not issue a second session key to User A, as there is no valid target for the session to continue.

2. LLMNR Request for the Unknown Address:

   • -User A, after receiving the DC's response, sends a Link-Local Multicast Name Resolution (LLMNR) query to find other systems that may know the location of this shared folder.
   • -Here, the attacker’s Responder tool comes into play,getting the query packet of A and replying to User A, claiming that it is the correct system (even though it isn’t) with that shared folder.

3. NTLM Challenge-Response:

   • -User A, thinking it's communicating with the an eligible system that has the shared folder , proceeds with the NTLM challenge-response authentication process.
   • -Responder captures User A’s NTLM hash and username during this process.

4. Sending NTLM Hash to System B:

   • -Responder relays User A’s NTLM hash and username to the real System B using the tool ntlmrelayx.py.
   • -No second session key is involved because the DC never issued it to User A in this case.
   • -Since SMB signing is disabled on System B, System B accepts the NTLM hash and authenticates the attacker as User A.

5. Access Without Encryption:

   • -In this scenario, because no session key was issued, the communication between the attacker (using ntlmrelayx.py) and System B is not encrypted. However, because SMB signing is disabled, System B does not raise any suspicions regarding the lack of encryption.
   • -The attacker can proceed to exploit the authenticated session, often dumping SAM hashes from System B.

6. Quick Note on Encryption in This Scenario:

   • In this case, because no second session key is issued, the packets are not encrypted, and System B does not flag this as suspicious since SMB signing is disabled. System B is only concerned with authenticating the NTLM hash, which the attacker successfully relays.

While this scenario shows how an SMB relay attack can succeed when SMB signing is disabled, many believe that forcing SMB signing completely prevents these attacks—but that’s not true.** We have discovered new techniques that can bypass this defense. In the next section, we’ll explore how SMB relay attacks can still be executed even when SMB signing is enforced. Don’t miss this critical update—understanding these advanced methods is essential to staying ahead of evolving threats and protecting your network.

Scenario 2 SMB Relay Attack When the SMB signing is ENFORCED and Correct Shared Folder Name is Used

In this scenario, User A tries to connect to a valid shared folder on System B, but an SMB relay attack still occurs.

1. User A Requests Access to a Valid Shared Folder:
   • User A correctly types the name of a shared folder on System B and sends its request along with its TGT to DC.
   • The DC verifies User A's credentials and provides A with a second session key which is used for encrypting the communication between User A and System B.
2. Responder Intercepts the Connection:
   • As User A attempts to communicate with System B, Responder impersonates System B and claims to be the target system.
   • User A, unaware of the impersonation, sends the second session key and the NTLM hash to Responder during the challenge-response exchange.
3. Simultaneous Capture of NTLM Hash and Second Session Key:
   • Responder successfully captures both the NTLM hash and the second session key.
   • With these in hand, Responder can now decrypt the communication from User A (using the session key) and relay the NTLM hash to System B.
4. Sending Encrypted Packets to System B:
   • The attacker, using ntlmrelayx.py, encrypts and signs the packets (including any malicious commands) using the second session key and relays them to System B.
   • Since the session key matches, System B decrypts the packets, verifies the NTLM hash, and authenticates the attacker as User A.
   • The attacker can now perform malicious actions on System B, such as dumping SAM hashes, all while maintaining an encrypted communication channel using the second session key.

Summary of Key Differences Between the Two Scenarios

• Scenario 1 (Incorrect Share Name):
  • No second session key is issued by the DC.
  • The attacker captures the NTLM hash via Responder and relays it to System B without encryption and without any signiture.
  • The attack works because SMB signing is disabled, so System B doesn’t detect the unencrypted communication.
• Scenario 2 (Correct Share Name):
  • The DC issues a second session key, which is captured by the attacker.
  • The attacker uses this key to both decrypt packets from User A and encrypt packets sent to System B.Moreover the attacker uses that second session key to sign the smb packets appropriately.
  • If in this scenario the smb Signing is forced , that can cause complexitiy to the penetration process due to this reason that the attacker must also calculate the signiture of the manipulated packets which can make this attack difficult to perform.

Conclusion

In summary, understanding the intricacies of SMB and the mechanisms behind SMB relay attacks is crucial for maintaining network security. We explored two distinct scenarios illustrating how these attacks can occur—one when SMB signing is disabled and another even when it is enforced. Despite the belief that enforced SMB signing can completely thwart these attacks, we demonstrated that attackers can still find ways to exploit vulnerabilities, underscoring the need for comprehensive security measures. By staying informed about these tactics and implementing robust defenses, organizations can better protect their systems from evolving threats in the landscape of cybersecurity.