The "-" impact of Network Level Authentication on failed logon events - 4625

In this short post we will be highlighting some of the observed abnormal failed logon events (related to RDP brute force activity) and how you can detect them and also how you can leverage them to conduct a "stealthy" RDP brute-forcing attack.

For this, we will be using an open source RDP client xfreerdp (available on Kali Linux by default):

Xfreerdp allow us to control the following parameters:

• source client machine (that the target victim machine should see)
•  /sec:nla will force the use of NLA (Network Level Authentication) as the RDP protocol to use (recommended by Microsoft)
• /u /p and /v for the target username, password (wrong password) and hostname/IP

Once the logon is attempted, those are the events that will be seen on the target machine:

As you can see above: 

• the logon type is marked as 3 (network) instead of 10 (RDP)
• the source network address is equal to "-"
• the source machine is marked as "Kali" (although we've specified a different client-hostname in xfreerdp /client-hostname parameter), but this can be changed by the attacker (hostname)

To investigate further if there other traces of failed RDP logon attempts, we need to check the following event sources (under Applications and services logs\Microsoft):

• TerminalServices-RemoteConnectionManager\Operational
• TerminalServices-LocalSessionManager\Operational
• RemoteDesktopServices-RemoteDesktopSessionManager

As you can see below, no useful events are logged (for failed attemts, those event sources are useful for successful logons):

Even if you change the settings on the target machine to not require NLA authentication, same events are logged when xfreerdp is supplied with /sec:nla:

If we specify other RDP authentication protocol (other than NLA), we can see the source IP of the failed logon activity:

4625 will look like this:

Both of the sourceIP and the correct logon type are recorded, but what's abnormal is the source workstation name equal to the target machine name.

And for eventid 1149, it reports also the correct source IP and the type of logon (RDP), but it marks this logon as succefful logon or it was a failed attempt.

So, the question now is what are the main takeaways?

1. detection correlation rules based on occurences count (i.e. more than x of failed attempts from same source IP or hostname) can be broken if one uses similar technique (rdp client that support setting rdp authentication protocol as NLA). 
2. Look for 4625 events (usually those are the ones that are collected and forwarded to a SIEM) with source network address NULL or equal to "-"
3. Look for 4625 events where source workstation is equal to AccountName or AccountDomain.
4. As a redteamer, if you want to conduct brute-forcing (inside the network), use this technique and you will be fine.
5. Don't trust event logs blindly!

To verify if point 2 matches any false positive, we've run the following query on a real environment:

That's all!