On our WS2012 R2, I see multiple 4625 logon audit failures. Anything between once every 5 minutes to 5 times a minute. The usernames that fail the logon attempt change frequently. But seem to be from a list of commonly used usernames (Administrator, User, Test, Sales, Bob, Intern, Admin2, BOARDROOM, BARBARA, ALAN, COPIER, BACKUP, XEROX, USER1, RECEPTION etc. ). These failed attempts also seem to continue 24/7.

Since we are a pretty small company, I am quite sure that these are not legit attempts and are automated.

Below is an example log from Windows logs security.

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:       BOARDROOM
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:        -
Detailed Authentication Information:
Logon Process:      NtLmSsp 
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only):   -
Key Length:     0

Am I right to worry that we are hacked? How would I find out from where these failed logon attempts are coming from and stop them?

  • Is it a sample of the log you received ? Did you obfuscate some data here ? Process and Network informations are where you should look to understand from where it comes I think. And to me it looks like a brute force attack, trying to guess some usernames/password couples. Is the logon type always 3 ? – Kaël Nov 27 '17 at 13:40
  • This is one of hundreds of similar logs, only the username is changing. I have not edited the log, there is not much info in it. Yes, always type 3. – ftzortz Nov 27 '17 at 13:44
  • 1
    Based on the information you've provided it doesn't appear as though you've been compromised, but rather someone is attempting brute force attacks on your network. What services do you have exposed to the internet that would allow someone to authenticate to that server (Outlook Web App / Exchange / Remote Desktop, etc)? – DKNUCKLES Nov 27 '17 at 14:08
  • We have a web application on IIS. No Outlook/Exchange or RDP. – ftzortz Nov 27 '17 at 14:45
  • @ftzortz does the web application have authentication against your Active Directory? Also is the domain controller exposed to the internet? – DKNUCKLES Nov 27 '17 at 15:15

So according to some small search on the internet, you're most likely under some sort of attack. If it is not, then someone must have done a huge mistake while configuring a connection script.

What we learn from your log :

  • Someone is trying to access your server from outside (logon type 3), through RDP.
  • The attempts are for now, all failures (event id 4625)
  • It is most likely a script, according to the frequency of the failed logons
  • You don't have any information about the source machine trying to access your server.

Why do you have no information ? Most likely due to the RDP, which prevents your server from logging such informations.

What you should do then ?

Try to restrict access to your server through whitelisting. Allowing only trusted workstation in your network to access the server.

Also, if you don't have one, some IDS/IPS can prevent such try.

If you can't afford either of these solutions, since the attack looks random and most likely based on a list of "most commonly used username and password", changing some critical usernames with unconventionnal ones might delay or even negate the attack.

Also in case one of your accounts match a tested username, a common practice is to lock an account after X failed authentication trials, or generate a new password for it. On the one hand you limit the risk that script finds the good username/password couple and exploit it, on the other hand, you're exposing your system to administration outages, by having some of your important accounts locked.

Be aware this is only a workaround, this is not meant to be a durable solution. Restricting access to your server would probably be best.

  • Thank you Kael. RDP is not exposed to the internet. Only thing exposed to the public internet is IIS. Could these be RDP connections be coming from an infected machine from within the network? Also this server is our DC, could these logs be showing attempts to authenticate/logon to a client and not directly to the server via RDP? – ftzortz Nov 27 '17 at 14:41
  • @ftzortz At the very beginning of your windows log, you should have the name of machine which was accessed. After the date, you'll find the name of the machine generating the log, and then after another date field you should find the accessed machine. Is it your DC ? – Kaël Nov 27 '17 at 15:19
  • @ftzortz And if RDP is disabled then I guess you should look at your IIS server. Anyway, the fact you don't have informations on the machine sending the request, probably comes from some protocol. According to that website : cyberarms.net/security-insights/security-lab/… with TLS/SSL, most request will not give you network information, without monitoring directly network packets – Kaël Nov 27 '17 at 15:24
  • Nevermind, RDP was enabled. Blocked it and now no more failed authentications. – ftzortz Nov 27 '17 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.