In the past few months a number of my clients have been experiencing some pretty intense attacks on their networks. Notably using open RDP ports to connect to PC’s and launch username/password combo attacks.
Some of these attacks have been pretty basic and if I didn’t have security auditing enabled may not have even noticed them. But I do, and I get email notification when an account is locked, which prompts me to go see what’s happening.
Before you say, “Hey, RDP open to the public is just ASKING for trouble!” – I already know this. In fact, I’ve been documenting the experiences. However, when a lot of this was originally set up the Internet was a safer place and the tools to exploit and attack networks were far less sophisticated. I now encourage all of my clients to pay a bit more attention to security concerns and start closing some of these transitional gaps.
Anyway, one of the biggest frustrations I’ve experienced is the ridiculous way Microsoft records Security Audit information.
The computer attempted to validate the credentials for an account.
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: LIBRARY
Source Workstation:
Error Code: 0xC0000064
Note that Source Workstation is blank or NULL. It isn’t always. Sometimes it’s some other nonsensical entry (MSTSC, RACCESS, etc.) that cannot be resolved on the domain or network. The point is, the information provided is basically useless. I know someone is trying, I just don’t know where it’s coming from. If I can’t source it, I can’t stop it.
In this particular case it was a workstation with a Public RPD connection available. The user was actually sitting in front of the workstation for a change, but it was still being used to brute force attack a number of accounts.
While the Security Logs can’t tell me the source, NETLOGON can.
Here’s how to go about finding the source:
Open a CMD prompt (as Administrator) on the domain controller (PDC Emulator)
nltest /dbflag:0x2080ffff
This turns on debug logging for the Netlogon service on the DC
Now go review the log entries: Start –> Run –> “%windir%\debug\netlogon.log”
When you’re done, unless you don’t mind the netlogon.log file growing at an alarming rate, turn off the debug logging:
nltest /dbflag:0x0
Now, the netlogon.log will be completely stuffed with helpful information, but it’s information overload. This is what you’re looking for:
SamLogon: Transitive Network logon of
Paste that into your Find and you’ll start seeing responses like this:
05/29 15:36:42 [LOGON] [10684] <<DOMAIN>>: SamLogon: Transitive Network logon of (null)\MARK from (via <<WORKSTATION>>) Returns 0xC0000064
More sophisticated attacks don’t have a NULL domain, and we’ve been seeing a lot of very targeted attacks where the hacker network knows the custom RDP port, the domain, and the username. I haven’t yet determined how they know this, but it is pretty accurate. As I’ve documented though, brute force attacks against networks with progressive security policies such as account lockout policies and complex password compliance with regularly changed passwords makes this a very inefficient way to break in. Having said that, it only takes one…
