1

I've recently implemented a SIEM solution, and am now able to see a large amount of failed login attempts from legitimate users. In fact, it's such high volume that my SIEM is correlating them to be Brute Force attacks. However they come from a variety of accounts and computers, and are just simple auth attempts against the Domain Controller. I am confident they are not malicious.

What is the best way to track down a failed authentication event on a Domain Controller down to what application in the environment causes the authentication? They are similar to generic events found through Event Viewer on the Domain Controller, and I can see the hostname and username of where the auth came from.

Here is an example of the flood of logs I'm dealing with:

AV - Alert - "1566830804" --> RID: "18130"; RL: "5"; RG: "windows,win_authentication_failed,"; RC: "Logon Failure - Unknown user or bad
password."; USER: "(no user)"; SRCIP: "192.168.1.59"; HOSTNAME: "(DomainCntrl) 192.168.1.2->WinEvtLog"; LOCATION: "(DomainCntrl)
192.168.1.2->WinEvtLog"; EVENT: "[INIT]2019 Aug 26 08:46:42 WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: (no
user): no domain: DomainCntrl.MyDomain.com: An account failed to log on. Subject:  Security ID:  S-1-0-0  Account Name:  -  Account Domain: 
-  Logon ID:  0x0  Logon Type:   3  Account For Which Logon Failed:  Security ID:  S-1-0-0  Account Name:  MyUsername  Account Domain:  MyDomain 
Failure Information:  Failure Reason:  %%2313  Status:   0xc000006d  Sub Status:  0xc0000064  Process Information:  Caller Process ID: 0x0 
Caller Process Name: -  Network Information:  Workstation Name: Win10-Wrk  Source Network Address: 192.168.1.59  Source Port:  57648  Detailed
Authentication Information:  Logon Process:  NtLmSsp   Authentication Package: NTLM  Transited Services: -  Package Name (NTLM only): -  Key
Length:  0  This event is generated when a logon request fails. It is generated on the computer where access was attempted.[END]"; 
2
  • "coming from a variety of accounts and computers" could easily describe password spraying: doubleoctopus.com/security-wiki/threats-and-tools/… Aug 26 '19 at 20:01
  • Sorry what I mean is that there are 4 or 5 domain accounts attributing to the excessive invalid login attempts. Ultimately, I'd just like information on the best method to correlate these logs to what application produces them. Such as taking the time of the invalid attempt on the Domain Controller, and matching it with the corresponding event log on the workstation producing the auth attempt.
    – Jake Y
    Aug 26 '19 at 20:24
1

Dealing with Windows failed events can be a very hard task. Firstly, you have consider 2 types of failed events in Windows:

  • Kerberos logins (not in your scope): ID 4768, 4769, 4771
  • Windows logins: ID 4625, ID 4776

Considering now your event, the most meaning full events are the following:

  • Logon Type: 3 > network event
  • Workstation Name: Win10-Wrk > source host, but sometimes can be wrong, so better trust the IP
  • Source Network Address: 192.168.1.59
  • Sub Status: 0xc0000064 > MOST IMPORTANT, the error code

In this situation, the error code 0xc0000064 means that the account does not exist. This can report a tentative of account enumeration, but it can also be created because of wrong configuration on domain, servers or even sometimes Exchange mail servers.

What I would suggest now it to verify the Kerberos events on the concerned DC and also enable the failed login auditing on the source machine. This will provide additional information for you analysis.

In case you would like to move one step forward, you can implement the following rule/use case logic in your SIEM for the brutforce rules:

enter image description here

-1

Every SIEM solution produces noise when newly deployed. You need to finetune the rules that you have written to reduce false positives.

@Michel de Crevoisier has shared you list of rule names to detect malicious activity. you may start working on fine tunening these rules

Your SIEM rule must consider the logs with event id 4625, and for example a threshold of 10 login failures within 5 minutes from a single source . you may exclude the expired password substatus codes from this rule, since this doesn't tell that user is bruteforcing or guessing the passwords

The threshold needs to finetuned based on logon type as well , rdp,interactive, network type etc.

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.