Source: Securelist – Kaspersky
Headline: A journey into forgotten Null Session and MS-RPC interfaces, part 2
In the first part of our research, I demonstrated how we revived the concept of no authentication (null session) after many years. This involved enumerating domain information, such as users, without authentication. I walked you through the entire process, starting with the difference between no-auth in the MS-RPC interfaces and the well-known null session, and ending with the methodology used to achieve our goal.
Today, as promised, we’ll dive into part two. Here, we’ll explore why Windows behaves the way it does – allowing domain information to be enumerated without authentication. I’ll also explain why this activity is difficult to prevent and monitor.
First, we’ll examine why this activity is hard to stop by looking at how WMI works. We’ll also discuss the methods available for detecting and addressing this issue.
After that, we’ll cover some basics about MS-RPC security and how to secure your RPC server. Then we’ll analyze the security of the MS-NRPC interface using two approaches: theoretical insight and reverse engineering to gain a deeper understanding.
So, buckle up and let’s continue our journey!
The group policy that punches your domain in the face
When it comes to stopping certain activities in Windows, group policies are often the first line of defense, and our case is no exception. As we discussed in part one, the Restrict Unauthenticated RPC Clients policy can be used to block no-auth activity against interfaces. This policy comes with three settings: “None”, “Authenticated”, and “Authenticated without exceptions”.
While testing, we discovered that even with the policy set to “Authenticated”, it’s still possible to enumerate domain information using MS-NRPC and network interfaces using the IObjectExporter interface. Naturally, the next logical step would be to use the “Authenticated without exceptions” setting to completely block such activity.
At first, enabling “Authenticated without exceptions” seems to work perfectly – blocking all enumeration activity with no authentication. Over time, however, we would notice significant issues: many of the domain controller’s functions would stop working. This is not surprising, as Microsoft has explicitly warned that using this policy setting can severely disrupt domain controller functionality. In fact, it has been described as “the group policy that punches your domain in the face,” effectively rendering the domain controller inoperable.
To better understand this issue, let’s use WMI as an example and examine why setting this policy to “Authenticated without exceptions” causes domain functionality to fail.
Windows Management Instrumentation (WMI) is the infrastructure for managing data and operations on Windows-based operating systems. It’s widely used by system administrators for everyday tasks, including remote management of Windows machines.
To test the effect of setting the Restrict Unauthenticated RPC Clients policy to “Authenticated without exceptions”, let’s try to access WMI on a remote machine using the wmic command to list processes. In this case, we’ll use valid administrator credentials for the remote machine.
Listing remote processes using wmic
As shown in the screenshot above, the attempt to list remote processes fails with an “Access Denied” error, even with valid administrator credentials. But why does this happen?
Remote WMI access relies on the DCOM architecture. To interact with the WMI server, a DCOM object must first be created on the remote machine. As explained in part one, interfaces such as IObjectExporter ( IOXIDResolver) are responsible for locating and connecting to DCOM objects.
In simpler terms native Windows libraries typically use the IObjectExporter interface by default during the initial steps of creating a DCOM object, although it is technically optional. When binding the interface, the authentication level is set to “no authentication” (level 1). Next, the libraries use the ServerAlive2 function.
When the Restrict Unauthenticated RPC Clients policy is set to “Authenticated without exceptions”, it blocks these no-auth activities. This prevents the creation of DCOM objects, so the WMIC command that creates a DCOM object fails and returns an “Access Denied” error, even if the credentials are valid.
Furthermore, since DCOM object creation is integral to many domain controller functions, blocking these activities can disrupt most operations on the domain controller. In short, setting the policy to “Authenticated without exceptions” not only breaks remote WMI access, it also impacts broader domain functionality.
To better understand this behavior, let’s examine what happens under the hood when we set the Restrict Unauthenticated RPC Clients policy to “Authenticated” or “None”. Using Wireshark, we’ll capture the traffic while running the same PowerShell command as before.
Network traffic for remote WMI
In the captured traffic, we can see that before the DCOM object is created, the IOXIDResolver interface must be bound, and the ServerAlive2 function is called (packets 21-24).
If we inspect packet 21, which contains the bind request, we see that the native libraries bind the interface without authentication – because the authentication length is zero.
Binding without authentication
Next, let’s inspect the traffic when the Restrict Unauthenticated RPC Clients policy is set to “Authenticated without exceptions”.
From the captured traffic, we can see several “Access Denied” responses when attempting to call the ServerAlive2 function with valid credentials. This happens because the policy blocks the no-authentication behavior, effectively stopping the initial binding of the IOXIDResolver interface (which binds without authentication by default). The failure to bind the interface at the beginning of the process is what causes this error, proving that it does not come from WMI itself.
The event that never occurs
As we saw earlier, preventing enumeration of domain information seems impossible, but detecting it might be another story. The first place to look for detection is Windows audit policies. I found the audit policy under event ID 5712, which should generate an event like “Audit RPC Events 5712(S): A Remote Procedure Call (RPC) was attempted.”
However, Microsoft states that this event never occurs, and after enabling this audit policy, I indeed found no related events in the event viewer for any RPC attempts.
The event that never occurs seemed like a dead end for detecting RPC activity. However, after further research, I found two additional ways to detect RPC activity.
The first method is Event Tracing for Windows, which logs RPC-related events. However, it lacks useful details such as the IP address of the RPC client and generates many events, including local RPC activity, making it difficult to parse.
The second method is to use third-party open source software called RPC-Firewall. This tool audits all remote RPC calls, allowing you to track RPC UUIDs and opnums, block specific ones, and filter by source address. It integrates with the event viewer to display logs, as shown in the screenshot below of an RPC event generated by RPC-Firewall.
Prior to conducting this research, I had found these three ways to detect such activity that I mentioned earlier. However, due to the lack of native detection, the process remains challenging. You can rely on third-party tools or develop your own detection method. But even with these approaches, it’s difficult because you need to identify which machines in your domain are making RPC requests without authentication and track the frequency of this activity.
MS-RPC security
Now let’s explore why Windows behaves this way, why there are issues with policies, and what exceptions really mean. But before diving into all that, we need to discuss MS-RPC security – basically, how to secure your RPC server.
From this point on, I’ll be referring to a new term, the RPC server. The RPC server is where the logic of the interface is defined. A single server can have multiple interfaces.
Securing an RPC server is a complex process because of the variety of access methods, such as named pipes or TCP endpoints. In addition, security measures for RPC servers have evolved over time.
In this research, I will focus on the security methods relevant to our study, but there are several other methods, some of which are described in this post.
Registration flags
When registering an interface for an RPC server, specific flags can be set using the RpcServerRegisterIf2 function. Three flags are of particular relevance:
- RPC_IF_ALLOW_LOCAL_ONLY: Rejects calls from remote clients.
- RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH: Invokes a security callback for authentication checks.
- RPC_IF_ALLOW_SECURE_ONLY: Limits connections to clients with an authentication level higher than RPC_C_AUTHN_LEVEL_NONE.
The RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag registers a security callback (e.g., MySecurityCallback), as shown in the examples below, which takes over security checks from the RPC runtime.
RPCServerRegisterIf2 with security callback
If the callback returns RPC_S_OK (mapped to 0), the client passes; otherwise, the client fails the security check.
By default, the RPC runtime ( rpcrt4.dll library) handles client authentication using mechanisms such as NTLM or Kerberos. However, its behavior is influenced by two factors:
- The Restrict Unauthenticated RPC Clients policy:
- If set to “None”, unauthenticated clients are allowed.
- If set to “Authenticated”, only authenticated clients can connect.
The RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag:
This flag overrides the default policy, allowing the security callback to handle authentication even when clients are unauthenticated. The only exception is the “Authenticated without exceptions” policy value, which blocks all unauthenticated clients regardless of this flag.
This explains the exceptions we discussed earlier: they occur when interfaces inside RPC servers are registered with this flag, enabling unauthenticated connections even when the policy is set to “Authenticated”. The source and behavior of these exceptions should now be clear.
Securing the endpoint
As mentioned earlier, RPC servers can be accessed through various transport layers. For remote connections, TCP ports and named pipes are commonly used.
When registering an endpoint for an RPC server using the RpcServerUseProtseqEp function, you can include a security descriptor (SD) to control who can connect to the endpoint. It’s important to note that this SD only applies to named pipes, not TCP ports. Additionally, it can also be used for local connections using ALPC ports as endpoints.
Securing the interface
Microsoft has introduced a newer version of the RpcServerRegisterIf2 function, called RpcServerRegisterIf3, which allows you to add an optional SD when registering your interface. This enables you to control who can connect directly to the interface.
This security mechanism raises an important question: if an interface has registered an SD, and a client connects via TCP without authentication (authentication level = 1), how is the security check performed? Specifically, what security token is assigned to the client for the SD check?
To answer this, we need to do some reverse engineering magic against the RPC runtime library ( rpcrt4.dll).
The figure below shows the decompiled view from IDA for the function called when a client connects without authentication. As you can see, it uses the ImpersonateAnonymousToken function, which allows the thread to impersonate the system’s anonymous logon token. In other words, a client connecting via a TCP endpoint without authentication is represented as an anonymous user.
Called function for unauthenticated clients
After that, the access check is performed using the AccessCheck function:
Binding authentication
The final RPC security issue to discuss is binding authentication. As you recall, the authentication method is specified in the binding packet (the first packet in an RPC connection). But what does that mean?
An RPC server can register its preferred authentication method for clients using the RpcServerRegisterAuthInfo function. For instance, in the following example, NTLM authentication is registered as the chosen method.
After that, the client can connect using RPCBindSetAuthInfoEx and specify the correct authentication service and authentication level.
Now that we’ve covered RPC security, it’s time to answer questions about our interface (MS-NRPC): What security is applied on the server that defines this interface, and why were we able to access it without authentication?
To do this, I used two approaches:
- Surface analysis: I examined the internal security checks of the RPC server using a flowchart from a great RPC toolkit. This chart provides valuable insight for our research, allowing us to analyze the security applied by the RPC server in more detail. I’ll go through it step by step, following the path described in the chart to conduct the investigation.
- In-depth analysis: In this approach, I interacted directly with the RPC server using reverse engineering to gain further insight into the enabled security.
Surface analysis
I will now attempt to determine the security mechanism used by the RPC server that’s related to the MS-NRPC (Netlogon) interface. I will assume that we are the RPC client calling a function from (MS-NRPC) Netlogon to enumerate domain information without using any authentication.
Let’s start with transport protocols, as outlined in the flowchart:
In the chart above, the RPC client has two options for connecting to the RPC server: via TCP or SMB named pipes. In our research, we are using TCP, which is highlighted.
Next, we encounter the Restrict Unauthenticated RPC Client policy, which has two values: “None” or “Authenticated”. If set to “None”, we proceed to the next step. If set to “Authenticated”, a check is performed to see if the client has authenticated. If it has, the flow continues; however, if the client connects without authentication (as in our case), the RPC runtime checks for the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag and either accepts or denies the connection based on its presence.
Since the policy is set to “Authenticated” and our client does not perform authentication, we need the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag to be registered in order to proceed to the next step, thereby making an exception to the policy. The presence of this flag allows us to conclude that a security callback has also been registered.
Our path now looks like this:
Next, there is another check to see if the server has registered an authentication service. If the server hasn’t registered one and the client tries to authenticate, it will be denied with an “authentication service unknown” error. However, if the client doesn’t attempt authentication, the process continues.
If the server has registered an authentication service, the check against the endpoint (the SD registered via RpcServerUseProtseqEp) is performed. If the client passes this, another check is made against the interface SD (registered using RpcServerRegisterIf3). Failure to pass either of these checks will result in access being denied.
In our case, we know the server has already registered an authentication service because it’s a well-known Microsoft protocol. We don’t need to worry about the endpoint check either, as it’s intended for clients connecting via named pipes. As for the interface security descriptor, we either passed this check if the SD doesn’t exist at all, or the SD does exist and it allows anonymous users (representing clients without authentication).
Next, we check two flags: the first, RPC_IF_ALLOW_LOCAL_ONLY, determines if the interface can be accessed remotely, and the second checks for RPC_IF_ALLOW_SECURE_ONLY. If the latter is present, it ensures that we are using an authentication level higher than “None”, denying or allowing access based on the authentication level. Finally, we check for the presence of a security callback. If it doesn’t exist, we can access the server immediately. If it does exist, we must pass the custom checks within the security callback to access the server.
In our case, we know that RPC_IF_ALLOW_LOCAL_ONLY doesn’t exist because we can access the interface remotely. We also know that RPC_IF_ALLOW_SECURE_ONLY isn’t present because we’re using an authentication level of “None”. Finally, we conclude that a security callback is registered based on the previous use of RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH, and we successfully pass the security callback check to gain access to the server.
Our final path looks like this:
Surface analysis conclusion
At this stage, we can conclude that the RPC server has the following characteristics:
- Regarding registration flags:
- Has RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH (indicating a security callback).
- Doesn’t have RPC_IF_ALLOW_LOCAL_ONLY.
- Doesn’t have RPC_IF_ALLOW_SECURE_ONLY.
Regarding the interface:
- We’re unsure if it has a security descriptor (SD) or not.
Regarding registered binding authentication:
- The RPC server registers authentication.
As shown, the surface analysis couldn’t provide a complete security overview for the Netlogon (MS-NRPC) interface, so I decided to proceed with an in-depth analysis.
In-depth analysis
The goal of our in-depth analysis is to leverage reverse engineering techniques to assess the security of the RPC server under the MS-NRPC interface. As we saw before, the interface is accessible through the LSASS process, specifically via the Netlogon DLL. Here we have two approaches to analysis:
- Use automated tools to examine the security of the interface.
- Go directly to IDA and manually locate the interface and its associated security mechanisms.
Let’s begin with a tool called PE RPC Scraper. If we provide the Netlogon DLL as an argument, this tool reveals information about the RPC server, its interfaces, functions and security details.
The output of the tool shows that it successfully identified the Netlogon interface (UUID) and confirmed that it contains 59 functions. It also revealed the presence of a security callback and a set of flags with a value of 0x91. After decoding this value, we can see that the following flags have been registered:
- RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH
- RPC_IF_SEC_CACHE_PER_PROC
- RPC_IF_AUTOLISTEN
The output from PE RPC Scraper also indicates that the interface has no security descriptor.
The information obtained from both the surface analysis and the automated tool provides the answer to the security bypass issue and allows me to conclude the investigation at this point. However, I personally don’t trust automated tools, and I have a good reason for that. So, for further confirmation, let’s dive into IDA.
IDA like a superhero
At this point, I’ve loaded netlogon.dll into IDA and started my investigation.
A. Locate the interface
The first step is to determine where the interface is registered. As shown in the figure below, the UUID registered using RPCServerRegisterIf3 is related to the MS-NRPC interface.
MS-NRPC interface registration
B. Endpoint registration
At this stage, we’ll check the endpoint registration for the server. As you can see in the screenshot below, RpcServerUseProtseqEpW and RpcServerUseProtseqExW have been used to register three endpoints:
- SMB named pipe, lsass
- Local ALPC port, NETLOGON_LRPC
- High dynamic TCP ports
C. Interface registration
As I mentioned earlier, RpcServerRegisterIf3 is used to register the interface.
The function used the 0x91 value as a set of flags, which are: RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH | RPC_IF_SEC_CACHE_PER_PROC | RPC_IF_AUTOLISTEN. RpcServerRegisterIf3 also has a security callback ( sub_18002EF60), in addition to a security descriptor ( hMem). This finding contradicts what was previously confirmed by an automated tool – that’s why I don’t trust them for reverse engineering.
D. Security callback
Now let’s go inside the security callback and see how the security check is performed. From the screenshot below, we can see that RpcServerInqCallAttributesW is called first with the Flags field inside the RpcCallAttributes struct set to 96. After decoding this value, we can see that this function used two flags – RPC_QUERY_IS_CLIENT_LOCAL | RPC_QUERY_NO_AUTH_REQUIRED – to request the client information.
The security callback has a condition statement.
The security callback conditions
First, the callback verifies that the RpcServerInqCallAttributesW function was called successfully, then it checks if the opnum is less than 59. If both previous conditions are met and the client is local, access to the server is granted. If the client is remote, the callback uses an access array (a matrix) to determine if the opnum is allowed to be called by the remote client.
The access matrix is just hardcoded bytes in memory:
All of the previously mentioned functions in the MS-NRPC interface that can be accessed without authentication (as outlined in the table in the first part) pass the access matrix check.
Now, let’s analyze what happens when the conditions are met or not, using assembly language since the IDA decompiler tab lacks precise interpretations.
The security callback conditions in assembly
- For the security callback, as we mentioned earlier, returning 0 indicates a successful call.
- For the first condition (RpcServerInqCallAttributesW), failure results in an error value.
- For the second condition (operation number compared to 59), failure still returns 0. This only ensures that the matrix index doesn’t exceed its size and doesn’t validate implemented functions that are handled elsewhere.
- For the third condition, if both the access matrix and local client checks fail, the callback returns 5 (access denied). If either of them succeeds, execution continues.
If all of the above checks in the IF statement are passed, the security callback proceeds to check the Windows version with another IF statement that verifies the value of a DWORD in memory.
This DWORD is initialized using the code shown below. The value is set based on whether or not the machine is a domain controller (DC).
Checking the machine type
- If the machine is a DC, execution continues and returns 0, indicating that the security callback check was successfully passed.
- If it is not a DC, further checks are performed.
This sequence of checks shows that passing the security callback for the remote client on a DC requires only that the access matrix check be successfully passed.
E. Interface security descriptor
As we saw before, the security descriptor is assigned through the RpcServerRegisterIf3 function. It is set up by calling another function that contains many instructions. The security descriptor definition language (SDDL) for the security descriptor is shown below.
SDDL for security descriptor
From the SDDL, we can see that the following groups of users have read access: Anonymous Logon, Everyone, Restricted Code, Built-in Administrators, Application Package, and a specific security identifier (SID).
But I ran into a problem. The function where the security descriptor is set up contained numerous operations, and I wasn’t sure if any changes had been made to the SDDL representation of the security descriptor. That’s why I decided to find an alternative method to verify that the SDDL interpretation remained the same.
To achieve this goal, I considered two approaches:
- Memory search: I considered searching memory at runtime for the known value in the header of the relative security descriptor to intercept and extract the discretionary access control list (DACL) inside LSASS. However, since this involves interacting with the LSASS process, which is risky, I took a different approach.
- ALPC Port Security Descriptor: The ALPC port NETLOGON_LRPC, registered during endpoint setup, shares the same security descriptor as the interface:
Endpoint and interface registration
Using the ALPC port’s name, I used the NtObjectManager PowerShell module (you can use any programming alternative) to extract the security descriptor from the ALPC port.
Extracting the SD from the ALPC port in PowerShell
After that, I obtained the DACL from the security descriptor.
Security descriptor for ALPC port
The screenshot above shows that the DACL obtained from the ALPC port’s security descriptor matches the SDDL representation we obtained earlier. As we can see in the first line of the ACL entries, anonymous login is allowed on the interface, which explains why we can pass the security descriptor access check for the interface (if there is no client token, the Anonymous LOGON token is assigned).
In-depth analysis conclusion
From the in-depth analysis, we now have the whole scenario of the MS-NRPC security mechanism, which allowed us to understand how we could successfully pass the security checks of the MS-NRPC interface and call multiple functions without authentication, even if the RPC policy is set to “Authenticated”.
To summarize, here’s how we were able to bypass the security of MS-NRPC:
- Registration flags:
We found that the interface has the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag: for this reason, we were able to get past the RPC policy.
- Security callback:
We found that this flag has a security callback, which in our case is used to check if we pass the check against the access array, and all of our functions passed the check.
- Interface security descriptor:
The interface has a security descriptor that permits multiple user groups to connect, including anonymous users. Since we are using no authentication, the access check is performed against the anonymous user, allowing to access the interface’s functions.
Research conclusion
At the end of this part and my research, I hope I was able to provide all the details related to this research and the approaches that I used. I also hope that you are now able to understand why we have this kind of no-authentication enumeration. Furthermore, I hope you are now equipped to develop your own ways to detect this kind of activity.
Thank you for reading, and see you soon with more research projects.
