Wow thanks so much Risto....I love the way you actually explain what's
going on...really appreciate it!
James
On 2019-03-16 05:36, Risto Vaarandi wrote:
hi James,
for addressing this problem, you could try the following EventGroup
rule:
type=EventGroup
ptype=RegExp
pattern=^\S+\s+\S+\s+((?:\d{1,3}\.){3}\d{1,3})\s+\d+\s+(?:\d{1,3}\.){3}\d{1,3}\s+88\s+AS\s+(\S+)\s+(\S+)\s+F\s+KDC_ERR_PREAUTH_FAILED
context=!WORKSTATION_$1_LOGIN_FAILURE_$2 && !ALERT_ISSUED_FOR_$1
count=create WORKSTATION_$1_LOGIN_FAILURE_$2 60
desc=Workstation IP $1 has failed to login with three different user
accounts
action=write - %s; create ALERT_ISSUED_FOR_$1 3600
window=60
thresh=3
The regular expression of this EventGroup rule will set $1 match
variable to IP address of the workstation and $2 to user account. I
have assumed that the user account is provided by "user/domain" field
in your example event. The EventGroup rule matches login failure
events and starts event counting operations for these events, so that
there is a separate operation for each workstation IP address (because
'desc' field of the rule contains $1 variable).
After the regular expression has matched a login failure event, the
'context' field of the rule makes sure that the context
WORKSTATION_<ip>_LOGIN_FAILURE_<useraccount> does not exist. Note that
the presence of this context indicates that the login failure event
for the given user account and workstation IP has already been counted
during the last 60 seconds. If this context does not exist, event
matches the rule and will be counted by the operation that runs for
the given workstation IP address. After the event has been counted,
the context WORKSTATION_<ip>_LOGIN_FAILURE_<useraccount> will be
created for 60 seconds (see the 'count' field of the rule) which
prevents login failure event for the same workstation and user account
counted twice in the window of 60 seconds. Due to the use of these
context, a counting operation which runs for some workstation IP
address can only observe 3 events within 60 seconds if three user
accounts for these events are *all* different.
Finally, after a counting operation has issued an alarm (see the
'action' field), the rule also sets up a context ALERT_ISSUED_FOR_<ip>
for 1 hour. The purpose of this context is to suppress repeated alarms
if the workstation continues to probe user accounts after initial
alarm. Without this context, you might get a new alarm about the same
workstation after each 60 seconds, while ALERT_ISSUED_FOR_<ip> context
suppresses such repeated alarms for 1 hour.
In order to illustrate how the EventGroup rule works, suppose the
following five events appear for workstations 10.1.1.1 and 10.1.1.2
[1]:
2019-03-15T10:50:30-0600 CAnW7i1DW5gZp7c6Vd 10.1.1.1
62469 192.168.1.1 88 AS bob/mydomain
krbtgt/domain F KDC_ERR_PREAUTH_FAILED -
2037-09-12T20:48:05-0600 - T T -
2019-03-15T10:50:31-0600 CAnW7i1DW5gZp7c6Vd 10.1.1.1
62471 192.168.1.1 88 AS alice/mydomain
krbtgt/domain F KDC_ERR_PREAUTH_FAILED -
2037-09-12T20:48:05-0600 - T T -
2019-03-15T10:50:32-0600 CAnW7i1DW5gZp7c6Vd 10.1.1.1
62472 192.168.1.1 88 AS alice/mydomain
krbtgt/domain F KDC_ERR_PREAUTH_FAILED -
2037-09-12T20:48:05-0600 - T T -
2019-03-15T10:50:34-0600 CAnW7i1DW5gZp7c6Vd 10.1.1.2
41916 192.168.1.1 88 AS bob/mydomain
krbtgt/domain F KDC_ERR_PREAUTH_FAILED -
2037-09-12T20:48:05-0600 - T T -
2019-03-15T10:50:38-0600 CAnW7i1DW5gZp7c6Vd 10.1.1.1
62473 192.168.1.1 88 AS donald/mydomain
krbtgt/domain F KDC_ERR_PREAUTH_FAILED -
2037-09-12T20:48:05-0600 - T T -
After seeing these events, the EventGroup rule would start two
counting operations for workstations 10.1.1.1 and 10.1.1.2 (operation
for 10.1.1.1 is started at 10:50:30 and operation for 10.1.1.2 at
10:50:34). Also, the operation which runs for 10.1.1.1 would fire an
alarm when the fifth event appears (at 10:50:38), since at that point
the operation has see login failure events for three distinct user
accounts bob/mydomain, alice/mydomain and donald/mydomain. Note that
the operation would not count the third event, since alice/mydomain
has already been observed during the last 60 seconds (see the second
event). Also, the fourth event is irrelevant for the counting
operation which runs for 10.1.1.1, since the workstation IP address is
different from 10.1.1.1 in this event.
I hope this example is helpful.
kind regards,
risto
Kontakt James Lay (<j...@slave-tothe-box.net>) kirjutas kuupäeval R,
15. märts 2019 kell 22:13:
So I have a log file that logs user login attempts made to a domain
controller like so (bro/zeek):
2019-03-15T10:50:30-0600 CAnW7i1DW5gZp7c6Vd cx.x.x.x
62469 sx.x.x.x 88 AS user/domain
krbtgt/domain
F KDC_ERR_PREAUTH_FAILED - 2037-09-12T20:48:05-0600
- T T -
In looking at the man page at:
http://simple-evcorr.github.io/man.html
I'm looking at:
type=SingleWithThreshold
ptype=RegExp
pattern=sshd\[\d+\]: Failed .+ for (\S+) from [\d.]+ port \d+ ssh2
desc=Three SSH login failures within 1m for user $1
action=pipe '%s' /bin/mail -s 'SSH login alert' root@localhost
window=60
thresh=3
My plan is to match on the cx.x.x.x IP address and username. From
the
above I know I can do this, but I do NOT want to match on the same
user...the idea is catch a single IP address (workstation) that
fails to
login to a Windows Domain Controller using more than one username
(domain user brute force). I don't want to match just one username
(in
this case at least) as, say if a user password expires over the
weekend,
then multiple failed attempts would happen for the same user. Any
advice on how to, in layman's terms, "match on a single ip with 3
failed
attempts from three different user names in 60 seconds".
Thank you.
James
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
Links:
------
[1] http://10.1.1.2
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
