Security

How do you check successful brute force logins?

xsstest
Communicator

Is there a better way to check sucessful brute force logins?

raw event (this is a microsoft exchange web access log):

The firs field is source IP, second field is login name, third field is date, fourth field is time......The eighth field is response length, ninth field is status code, tenth field is HTTP method, eleventh filed is access link.

If response length is greater than 1000 (Usually its value is 1989), it means successful login, if response length is less than 1000 ,(Usually its value is 613),it means failed login

1.1.1.1, annie, 12/26/2017, 11:15:44, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Baron, 12/26/2017, 11:15:44, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Bill, 12/26/2017, 11:15:44, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Christ, 12/26/2017, 11:15:44, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Bob, 12/26/2017, 11:15:43, W3SVC1, TestExchangeSvr, 10.10.20.10, 1989, 302, POST, /owa/auth.owa
1.1.1.1, Burke, 12/26/2017, 11:15:43, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Burton, 12/26/2017, 11:15:43, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Barton, 12/26/2017, 11:15:43, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Beacher, 12/26/2017, 11:15:43, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Beck, 12/26/2017, 11:15:43, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, annie, 12/26/2017, 11:15:43, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Benson, 12/26/2017, 11:15:43, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Curitis, 12/26/2017, 11:15:43, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa
1.1.1.1, Corey, 12/26/2017, 11:15:43, W3SVC1, TestExchangeSvr, 10.10.20.10, 613, 302, POST, /owa/auth.owa

I create an alert to monitor brute force, the search as follows:

index=exchange sourcetype=exchange_web_log "/owa/auth.owa"|stats count,values(_time) as _time,values(user) as user by sip|search count>=25|table sip _time user count

run once every two minutes , search span is -2m@m to @m, the search can working properly.

now, I want to check sucessfull brute force loggings, I create another alert , the search as follows :

index=exchange sourcetype=exchange_web_log "/owa/auth.owa" length>1000 [search index=exchange sourcetype=exchange_web_log "/owa/auth.owa" lengtch<1000|stats count as user by sip|search count>=25|table sip]|table _time sip user

run once every two minutes , search span is -2m@m to @m, But the search sometimes can detect successful brute force logins and sometimes misses successful brute force logins.

So, I think this search is a failure.

Is there a better way to check successful brute force logins? Can these two searches be merged? I hope a search can tell me that a brute-force attack has taken place and also can tell me which account was successfully logged in via brute force attack. If not, then I hope to get an answer to tell me successful brute force loggings.

0 Karma

nikita_p
Contributor

Hi @xsstest,
Can you try below query?
index=exchange sourcetype=exchange_web_log "/owa/auth.owa"| eval "Length Status"=if(length>1000, "Successful", length<1000, "Failed"|stats count as user by sip,"Length Status"|search count>=25|table _time sip user "Length Status"

0 Karma

kunalmao
Communicator

Please extract the 8th field if not automatically extracted. Assuming it is extracted then you can use

| where clause to streamline the query. If you can provide me with the list of fields available to you then perhaps i can give a shot at writing the query.

0 Karma

xsstest
Communicator

may you share your search ?

0 Karma

kunalmao
Communicator

index=exchange sourcetype=exchange_web_log "/owa/auth.owa" | eval attempts= if(length>1000,""successful","failed") | stats count as user_count by sip, attempts | where user_count >25 | table user user_count attempts

you can try this, it is similar to the one listed above by @nikita_p with some very minor changes. Please let me know if this works.

0 Karma

xsstest
Communicator

lack user
index=exchange sourcetype=exchange_web_log "/owa/auth.owa" | eval attempts= if(length>1000,""successful","failed") | stats values(user) as user,count as user_count by sip, attempts | where user_count >25 | table user user_count attempts

If more than 25 users login successful normally in two minutes ( because a company has the same Internet IP,This means that all employees use the same IP to login the mailbox,and there are login successfully),It's not a brute force attack. It's a normal log on.But your search will still produce an alert.

So I'm going to make sure that this IP has a brute force attack first,then capture users who successfully logged in using this IP

0 Karma

kunalmao
Communicator

Alternatively i would suggest you have a dynamic lookup with valid user list and refer that in your search to verify if the users attempting login are geniune

0 Karma

nikita_p
Contributor

So you can increase user_count to whatever you think can be a brute force attack also you can dedup sip.

xsstest
Communicator

firs field extract the name is sip, second field is user, the fourth and third field are actually _time, The eighth extract the name is length, ninth field is statsu_code, tenth field ismethod, eleventh filed is uri

0 Karma
Get Updates on the Splunk Community!

Optimize Cloud Monitoring

  TECH TALKS Optimize Cloud Monitoring Tuesday, August 13, 2024  |  11:00AM–12:00PM PST   Register to ...

What's New in Splunk Cloud Platform 9.2.2403?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.2.2403! Analysts can ...

Stay Connected: Your Guide to July and August Tech Talks, Office Hours, and Webinars!

Dive into our sizzling summer lineup for July and August Community Office Hours and Tech Talks. Scroll down to ...