Network logon failures without a source address

So this is a common phenomenon in corporate networks, and is a common sort of inquiry I get almost daily from clients. That is, to determine the source of a specific sort of logon failure event that is often poorly logged (regardless of what platform we're monitoring with), and thus highly confusing to admins and security analysts who've never seen this before.

With this being a very common type of situation that I'm at least once weekly asked about, I figured I'd write something to help clarify about what's going on in these situations, and perhaps some things that can be done to help remediate the situation.

The situation...

So, you're the admin or the security fella on the SOC and you see something like a boatload of 4625 (Windows logon fails) coming in hitting your DC. They're all logon type 3 (network), they all have a source IP that's a particular internal host (usually some edge device), and they have a logon process of either advapi, IAS, or w3wp. Maybe the usernames look all crazy, like it's someone knocking on your network with a wordlist of common names or something...

For all intents and purposes, it looks like someone's trying to bruteforce your DC! But it's coming from an internal device? Does this mean the device is compromised?

What's going on? In the words of all the admins who've asked me: "can you shed some light on this?"

What's actually happening

So, when we see this combination:

  • Large volume of 4625 events
  • To a DC
  • From an internal device
  • Logon type 3
  • Logon Process is IAS, advapi or w3wp

...what's happening is that some edge device has an exposed logon portal on it that uses RADIUS authentication to authenticate credentials against the domain. The internal device that is being cited is likely the edge device in question, and the DC demonstrating the logon failures is your organization's NPS server (i.e. MS's RADIUS server).

Each of these 3 logon processes can indicate something slightly different (for example, w3wp, the IIS worker process, indicates that the logons are coming from an IIS hosted website, e.g. like for something like basicauth), but in general, in this situation, it's likely that on the edge device, there's a logon failure for:

  • IIS basicauth
  • A VPN that uses domain credentials
  • RD Gateway
  • Third party MFA integration failure (Okta, Duo, etc)

So that's what's happening: some exposed edge device is being brute forced for some sort of service that uses RADIUS.

"Can you help me track this down?"

This activity can be tracked down in fine detail, however, NPS logging needs to be enabled on the DC, and this is not enabled by default. More on how to enable this can be learned from Microsoft's documentation found in this article on NPS in general, and in this one on Configuring NPS accounting. Be advised that this sort of logging is not usually enabled because it has the potential to fill up whole drives rather quickly, so adequate log rotation practices need to be considered.

Once NPS logging is setup, though, Windows event 6273 should be able to tell us more information about the client, including their actual IP address, which will be listed under a field called "Calling Station ID".

Without NPS logging, it may be possible to manually correlate logs from the source appliance with the logon failures. For example, in RDWeb and IIS, event 1301-1315 can be queried to potentially correlate with logon failures in those applications.

Remediations

So now that we know what's causing this and how we can gain a bit of visibility into this activity, what should we do to resolve the situation?

Well, there's several things, most of which are pretty boilerplate for securing any exposed logon panel:

  • If NPS logging is enabled, ban the offending IPs.
    • This should be viewed as a stop-gap measure; IPs are easily changed, and a dedicated threat actor will have no issue doing so, sending you on the "whack a mole" route.
  • If the service does not need to be public:
    • consider placing the logon panel behind a VPN
    • consider whitelisting public IPs that are permitted to access the logon panel
    • consider geofencing to ensure threat actors from outside of countries you regularly interact with are not permitted access
  • Consider monitoring UDP 1812 and 1645 for excessive radius logons from the same user.
    • Using an IDS, if excessive logon attempts are detected, this traffic can be dropped, preventing the logon requests from reaching the Domain Controller.
  • If NPS logging is enabled, host-based 3rd party solutions such as RDPGuard can be used to temporarily ban logon attempts from specific IP addresses after a certain logon threshhold
    • Custom configurations will need to be made for this in RDPGuard, as this tool is not usually used with RADIUS authentication, but rather RDP and other network protocols.