When a vendor releases a security update, the official advisories often provide minimal technical detail. This is intentional: detailed explanations can help attackers develop exploits before systems are patched.
Binary diffing flips this problem around. Instead of relying on documentation, we compare the actual compiled code between two versions of a binary.
This approach immediately reveals:
Because modern software systems are enormous, finding the relevant changes manually would be extremely time consuming. However, binary diffing tools such as BinDiff and Diaphora can automatically match functions between versions and highlight the differences.
In practice, this reduces the problem of understanding a large patch to analyzing only a few modified functions.
For this analysis we compare two versions of the Windows SMB server driver:
| Version | Build |
| srv2.sys | 10.0.26100.7920 |
| srv2.sys | 10.0.26100.8036 |
Running a diff between the two binaries produces an immediate insight:
This means the update is extremely targeted. Instead of modifying large parts of the SMB stack, Microsoft introduced a very small number of security checks.
The modified functions appear in a very specific part of the SMB connection pipeline:
Smb2RefreshRegistryValue
Smb2ExecuteNegotiateReal
Smb2ValidateLoopbackAddress
Smb2InitializeConnectionPassive
These functions are responsible for:
This immediately suggests that the patch affects authentication or connection policy logic.
Binary diffing quickly narrows the analysis from thousands of functions to just a handful.
Another interesting discovery from the diff is the presence of a new feature flag and helper functions that check whether the feature is enabled as can be seen in the following code:
This mechanism uses Windows Implementation Library (WIL) feature management, which allows Microsoft to enable or disable features dynamically.
Security changes are often deployed behind feature flags because they can affect compatibility. SMB is a critical protocol used by millions of systems, and sudden policy changes could disrupt legacy environments.
Feature flags allow Microsoft to:
This approach reduces the risk of breaking existing deployments while still delivering security improvements.
The patch also introduces a new registry-based configuration option that defines a security policy specifically for SMB loopback connections. The new value appears under the SMB server configuration path:
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
The newly introduced key is:
RequireSecuritySignatureForLoopback
This setting is loaded by the SMB server during configuration initialization inside the function Smb2RefreshRegistryValue. When the driver starts or refreshes its configuration, it reads this registry value and updates an internal variable named Smb2SigningRequiredForLoopback, which determines whether SMB signing must be enforced for connections originating from the local host.
Conceptually, the logic works as follows:
This registry policy becomes meaningful when examining where the value is actually enforced. The enforcement occurs during the SMB negotiation phase in the function Smb2ExecuteNegotiateReal, which processes the initial SMB NEGOTIATE request sent by a client when establishing a new session. During this stage, the server determines protocol capabilities and security requirements such as encryption and signing.
Prior to this patch, signing enforcement depended solely on the global SMB configuration. After the update, the negotiation logic introduces an additional check for loopback connections. If the new feature flag is enabled and global signing is not already required, the driver verifies whether the connection originates locally. When the registry policy is enabled and the connection is identified as loopback, SMB signing is enforced specifically for that connection.
In simplified terms, the updated logic behaves like this:
if feature enabled:
if signing not required globally:
if RequireSecuritySignatureForLoopback enabled:
if connection is loopback:
require SMB signing
This effectively introduces a separate signing policy for localhost SMB sessions. Administrators can now require cryptographic signing only for loopback SMB traffic while leaving the behavior of remote SMB connections unchanged.
This distinction is important because many environments disable SMB signing globally for performance reasons. However, loopback SMB connections are frequently abused in authentication relay scenarios where an attacker forces a privileged service to authenticate to another service on the same host. By enforcing signing only for loopback connections, Windows can mitigate these attacks without introducing the performance overhead of requiring signing for all SMB traffic.
One of the most revealing insights from the binary diff is the introduction of explicit loopback connection awareness in the SMB server stack. Two new functions appear in the updated driver:
Both functions are imported from SRVNET.SYS, the lower-level networking component used by the Windows SMB server. Their presence immediately suggests that the patch introduces special handling for SMB connections originating from the local machine.
Loopback connections refer to SMB sessions that originate from the same host, typically using addresses such as:
Historically, Windows relied primarily on address-based checks to determine whether a connection was loopback. For example, the SMB driver previously used the function SrvNetIsAddressLoopback which simply inspected the client’s IP address.
However, modern Windows networking environments are significantly more complex. Systems frequently use technologies such as:
In these scenarios, relying purely on IP address inspection can produce unreliable results, since a connection might originate locally even if its address does not strictly match a traditional loopback range.
The updated driver replaces the previous approach with a more robust mechanism based on connection-level validation. Instead of examining only the IP address, the new function SrvNetIsConnectionLoopback evaluates the actual network connection context, allowing Windows to determine whether the SMB session originates from the same host regardless of the transport or networking abstraction used.
In addition, the function SrvNetCheckLoopbackConnection is now invoked during connection initialization. This allows the SMB stack to identify and mark loopback connections early in the connection lifecycle, enabling later components such as negotiation and authentication logic to apply loopback-specific security policies.
Together, these changes indicate that Microsoft intentionally introduced stronger and more reliable loopback detection within the SMB stack. By moving from simple address checks to connection-aware validation, the updated driver ensures that localhost SMB sessions can be accurately identified and handled differently from remote network traffic.
Although the patch itself does not explicitly name a vulnerability, the changes strongly align with mitigations for NTLM reflection and authentication relay attacks.
A typical attack chain that many exploits (like the potatoes family) trigger looks like this:
1. Attacker triggers NTLM authentication from a privileged service
2. Authentication is relayed to SMB on localhost
3. SMB accepts the authentication
4. Attacker gains elevated access
Requiring SMB signing breaks this attack because the attacker cannot forge the required message signatures.
By enforcing signing on loopback connections, Windows effectively prevents localhost authentication relay attacks and treat loopback SMB as a security boundary.
Binary diffing identifies the code changes, but understanding them still requires careful reasoning. Traditionally, reverse engineers would manually analyze each modified function, reconstruct the logic, and attempt to infer the security implications.
This is where AI dramatically changes the workflow.
Instead of manually parsing hundreds of lines of decompiled code, an analyst can provide the diff output to an AI model and ask questions such as:
AI can quickly:
This does not replace the reverse engineer; rather, it amplifies their productivity, allowing researchers to move from raw diff output to a security hypothesis much faster. With the right tools, security researchers can quickly extract meaningful insights from vendor patches.
Together, these technologies allow researchers to analyze operating system patches faster and more effectively than ever before.
By diffing two versions of the Windows SMB driver and analyzing the changes with AI assistance, we discovered that this patch introduces loopback-specific SMB security hardening.
The update adds:
Although the patch modifies only a few functions, the impact is significant: it closes a potential attack path involving authentication relay to localhost SMB services.
More importantly, this case study illustrates the power of combining binary diffing and AI-driven analysis. What once required days of manual reverse engineering can now be accomplished in a fraction of the time, enabling security researchers to keep pace with modern software complexity by working in large scales of data (which is also multiplied with AI).
