I have many audit failure with event ID 4625 and Logon type 3 in my event log.

Is this problem form my server(internal services or applications) ? Or this is brute force attack? Finally How can i find source of this logins and resolve problem?

This is detailed information in General tab:

An account failed to log on.

    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:       aaman
    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:   test2
    Source Network Address: -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:      NtLmSsp 
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

**And this is detailed information in Detail Tab:**

+ System 

  - Provider 

   [ Name]  Microsoft-Windows-Security-Auditing 
   [ Guid]  {54849625-5478-4994-A5BA-3E3B0328C30D} 

   EventID 4625 

   Version 0 

   Level 0 

   Task 12544 

   Opcode 0 

   Keywords 0x8010000000000000 

  - TimeCreated 

   [ SystemTime]  2015-05-09T06:57:00.043746400Z 

   EventRecordID 2366430 


  - Execution 

   [ ProcessID]  696 
   [ ThreadID]  716 

   Channel Security 

   Computer WIN-24E2M40BR7H 


- EventData 

  SubjectUserSid S-1-0-0 
  SubjectUserName - 
  SubjectDomainName - 
  SubjectLogonId 0x0 
  TargetUserSid S-1-0-0 
  TargetUserName aaman 
  Status 0xc000006d 
  FailureReason %%2313 
  SubStatus 0xc0000064 
  LogonType 3 
  LogonProcessName NtLmSsp  
  AuthenticationPackageName NTLM 
  WorkstationName test2 
  TransmittedServices - 
  LmPackageName - 
  KeyLength 0 
  ProcessId 0x0 
  ProcessName - 
  IpAddress - 
  IpPort - 

Working solution i found here: https://github.com/DigitalRuby/IPBan

For Windows Server 2008 or equivalent, you should disable NTLM logins and only allow NTLM2 logins. On Windows Server 2008, there is no way to get the ip address of NTLM logins. Use secpol -> local policies -> security options -> network security restrict ntlm incoming ntlm traffic -> deny all accounts.

In RU version: Локальная политика безопасности -> Локальные политики -> Параметры безопасности -> Сетевая безопасность: ограничения NTLM: входящий трафик NTLM -> Запретить все учетные записи

| improve this answer | |
  • Blocked all NTLM attacks with your solution! Thank you even you brought it from that GitHub page. It's so charming you answered so! – JoeCool Feb 28 at 23:34

I had the same type of events on a server. There were hundreds of login attempts with different user names but no process ID or IP address visible.

I'm pretty sure it was coming from RDP connections over the internet without network level authentication.

| improve this answer | |
  • I wouldn't be so calm if I were you. These are the hack attempts. – Interface Unknown Jul 7 '17 at 11:14

These are the hack attacks. Attackers' goal is to brute force your server's accounts/passwords.

I would suggest to install a simple Intrusion Detection System (IDS). You may want to consider RDPGuard (commercial), IPBan, evlWatcher. Myself I use Cyberarms IDDS. This one is simple, has an friendly interface (requires .NET Framework 4.0 though).

The idea is simple: IDS monitors your server's security log for the suspicious logon failure events. Then it soft-locks the IP address(es), the attempt came from. You can also configure a hard lock when the attempts from the soft-locked IPs continue.

| improve this answer | |

Did there happen to be a Domain Controller being shut down when this happened? This looks remarkably similar to the scenario described in this article:


When Windows enters the shutdown state, it should tell new clients attempting to authenticate against the DC that they need to contact a different DC. In some cases, though, the DC will reply to the client that the user does not exist. This will cause repeated authentication failures until the domain controller eventually finishes shutting down and the client is forced to switch DCs.

The solution proposed in this article is to stop the netlogon service on the Domain Controller before shutting the server down. This makes it unavailable for authentications before it enters the shutdown state and forces the client to find a new DC.

| improve this answer | |

This Event is usually caused by a stale hidden credential. Try this from the system giving the error:

From a command prompt run: psexec -i -s -d cmd.exe
From the new cmd window run: rundll32 keymgr.dll,KRShowKeyMgr

Remove any items that appear in the list of Stored User Names and Passwords. Restart the computer.

| improve this answer | |
  • care to explain what those commands do? – jj_ Jun 1 '18 at 23:21

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.