Brute force attack with no IP to trace

Question

I am getting constant event 4625 messages saying that accounts are failing to log in with non-existent usernames. Names such as: SALES, USER, TEST, HELPDESK, SUPPORT, PROGRAMMER are not users of ours, but we are getting 20 or so messages every minute saying accounts such as these are trying to log in. I can only conclude that this must be a brute force attack. I have already made sure that RDP is NOT publicly accessible. I can tell that these are coming from outside of the domain because NTLM is stopping it, however I cannot blacklist IPs because Network information is blank in the event messages. What should I do in this situation?

An account failed to log on.

Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed: Security ID: NULL SID Account Name: POSTERMINAL1 Account Domain:

Failure Information: Failure Reason: Unknown user name or bad password. Status: 0xC000006D Sub Status: 0xC0000064

Process Information: Caller Process ID: 0x0 Caller Process Name: -

Network Information: Workstation Name:
Source Network Address: - Source Port: -

Solution

This information will be obfuscated so long as you have RDP set to negotiate security with TLS/SSL & NLA. If you reduce your security level down to just RDP encryption, you will fetch more info in those log entries. Obviously not an ideal approach, as that weakens your security posture.

Try looking in this log: Application and Service Logs > Microsoft > Windows> > RemoteDesktopServices-RdpCoreTS > Operational

See if there are any 140 events (generated when a fake name is used), or 131 events (failed but legit name). These should have a source IP in the description.

PureRDS had a good write-up about this earlier in the year: http://purerds.org/remote-desktop-security/auditing-remote-desktop-services-logon-failures-1/

Comments

[Admin]

I have also seen 4625's with no associated network address. Not sure why this would be missing, but you can try enabling NTLM audit logging to collect additional details on the activity: support.symantec.com/en_US/article.HOWTO79508.html

[tkam]

Thank you I found this information to be very useful! I didn't know you could find the ip in events 140 and 131.