hi James,
yes, you can employ the EventGroup rule for addressing this task, and
let me provide two slightly different solutions below. The first and
somewhat simpler solution looks like this:
type=EventGroup
ptype=RegExp
pattern=^\d+\.\d+ \S+ ([\d.]+) \d+ ([\d.]+) 445 \d+\.\d+
\\\\pipe\\\\lsass netlogon DsrEnumerateDomainTrusts
context=!ATTACKER_$1_DC_$2
count=alias ATTACKER_$1 ATTACKER_$1_DC_$2
init=create ATTACKER_$1
end=delete ATTACKER_$1
desc=Attacker $1 has enumerated domain trust against several domain controllers
action=write - %s
thresh=3
window=30
The regular expression pattern of the rule has been designed to match
events in the format you have described, except the expression assumes
that instead of SameIP and DifferentIP there are IPv4 addresses in the
event. For example:
1625677087.655857 CAY8g9D3jAKFwhD02 10.1.1.1 59143 192.168.1.1 445
0.017172 \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
Also, it is assumed that the first IP address (10.1.1.1 in the above
event) belongs to the attacker, while the second IP address
(192.168.1.1) belongs to the domain controller. The above EventGroup
rule runs event correlation operations that write alerts to standard
output if the same attacker accesses three different domain
controllers within 30 seconds. Since the 'desc' field of the rule has
a value with $1 variable (IP address of the attacker), the rule runs a
separate event correlation operation for each attacker, with each
operation having its own event counter.
In order to make sure that access to each domain controller from the
same attacker is counted just once by the corresponding operation, the
above rule employs context aliases which refer to the same context
data structure. The use of just one context with multiple alias names
for each attacker eases the garbage collection procedure when event
correlation operation for the attacker is complete. Each time the rule
observes an event for a new attacker, it creates a new event
correlation operation for this attacker, and the initialization action
'create ATTACKER_$1' provided with the 'init' field is executed. This
action will create the context ATTACKER_<attackerip> that all future
alias names for this attacker will refer to.
When an event for attacker <attackerip> and domain controller <dcip>
is observed, the rule will check if the context alias
ATTACKER_<attackerip>_DC_<dcip> exists (that check is implemented by
the 'context' field of the rule). If that alias is not present, the
event gets processed, and the event correlation operation that is
executing for attacker <attackerip> will create a new alias with that
name, with the alias pointing to context ATTACKER_<attackerip> (the
relevant action is defined in the 'count' field of the rule). For
example, when the event
1625677087.655857 CAY8g9D3jAKFwhD02 10.1.1.1 59143 192.168.1.1 445
0.017172 \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
is observed, the alias ATTACKER_10.1.1.1_DC_192.168.1.1 gets created
which points to context ATTACKER_10.1.1.1. When the event for the
attacker 10.1.1.1 and domain controller 192.168.1.1 appears again, the
boolean expression !ATTACKER_10.1.1.1_DC_192.168.1.1 provided with the
'context' field evaluates false, and the event is no longer matching
the rule. This ensures that when multiple events for the same domain
controller and attacker combination appear, only the first event is
counted. Therefore, if an event correlation operation is executing for
attacker 10.1.1.1 and its event counter reaches the value of 3, three
events have been observed for attacker 10.1.1.1 for different domain
controller IP addresses. When the event correlation operation for some
attacker IP terminates, the garbage collection action given with the
'end' field is executed, and 'delete ATTACKER_$1' action will remove
the context ATTACKER_<attackerip> and all its aliases.
In order to illustrate the work of this rule, consider the following
four events for attacker 10.1.1.1 and three different domain
controllers:
1625677087.655857 CAY8g9D3jAKFwhD02 10.1.1.1 59143 192.168.1.1 445
0.017172 \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
1625677087.655860 CAY8g9D3jAKFwhD02 10.1.1.1 59143 192.168.1.1 445
0.017172 \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
1625677087.744290 C6mmd42niEVcW1djY5 10.1.1.1 59144 192.168.1.2 445
0.003689 \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
1625677087.776183 CamRzj1Y20KA9cv9Mi 10.1.1.1 59145 192.168.1.3 445
0.003968 \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
Here is the debug log of SEC which illustrates the event correlation process:
1625677087.655857 CAY8g9D3jAKFwhD02 10.1.1.1 59143 192.168.1.1 445
0.017172 \\pipe\\lsass netlogon DsrEnumerateDomainTrusts <- first
input event
Creating context 'ATTACKER_10.1.1.1' <- an event correlation
operation starts for attacker 10.1.1.1 and context ATTACKER_10.1.1.1
is created
Creating alias 'ATTACKER_10.1.1.1_DC_192.168.1.1' for context
'ATTACKER_10.1.1.1' <- a context alias for attacker 10.1.1.1 and
DC 192.168.1.1 is created and event counter of the operation for
10.1.1.1 is incremented to 1
1625677087.655860 CAY8g9D3jAKFwhD02 10.1.1.1 59143 192.168.1.1 445
0.017172 \\pipe\\lsass netlogon DsrEnumerateDomainTrusts <- second
input event: since the alias ATTACKER_10.1.1.1_DC_192.168.1.1 already
exists, the input event is not processed
1625677087.744290 C6mmd42niEVcW1djY5 10.1.1.1 59144 192.168.1.2 445
0.003689 \\pipe\\lsass netlogon DsrEnumerateDomainTrusts <- third
input event
Creating alias 'ATTACKER_10.1.1.1_DC_192.168.1.2' for context
'ATTACKER_10.1.1.1' <- a context alias for attacker 10.1.1.1 and
DC 192.168.1.2 is created and event counter of the operation for
10.1.1.1 is incremented to 2
1625677087.776183 CamRzj1Y20KA9cv9Mi 10.1.1.1 59145 192.168.1.3 445
0.003968 \\pipe\\lsass netlogon DsrEnumerateDomainTrusts <- fourth
input event
Creating alias 'ATTACKER_10.1.1.1_DC_192.168.1.3' for context
'ATTACKER_10.1.1.1' <- a context alias for attacker 10.1.1.1 and
DC 192.168.1.3 is created and event counter of the operation for
10.1.1.1 is incremented to 3
Writing event 'Attacker 10.1.1.1 has enumerated domain trust against
several domain controllers' to file '-'
Attacker 10.1.1.1 has enumerated domain trust against several domain
controllers <- since the counter of the operation for 10.1.1.1 has
reached the value of 3, write an alert message to standard output
Deleting context 'ATTACKER_10.1.1.1' <- the event correlation
operation for attacker 10.1.1.1 is terminating and dropping the
context ATTACKER_10.1.1.1 and its aliases
Context 'ATTACKER_10.1.1.1' deleted
Context 'ATTACKER_10.1.1.1_DC_192.168.1.1' deleted
Context 'ATTACKER_10.1.1.1_DC_192.168.1.3' deleted
Context 'ATTACKER_10.1.1.1_DC_192.168.1.2' deleted
The above EventGroup rule has one drawback -- if the threshold of 3
events is not reached during 30 seconds for an event correlation
operation, the 30 second event correlation window of the operation
will start to slide, and the operation could potentially exist for a
longer period of time. However, since aliases do not have any fixed
lifetime, they will continue to suppress events for a given
combination of attacker and domain controller, even if the first event
for this combination is already outside of the 30 second event
correlation window. If this is an issue in your environment and you
want to address it, you could enhance the 'count' field of the above
rule as follows:
alias ATTACKER_$1 ATTACKER_$1_DC_$2; create ATTACKER_$1_DC_$2_LIFETIME
30 ( unalias ATTACKER_$1_DC_$2 )
Here is the full rule definition with the modified 'count' field:
type=EventGroup
ptype=RegExp
pattern=^\d+\.\d+ \S+ ([\d.]+) \d+ ([\d.]+) 445 \d+\.\d+
\\\\pipe\\\\lsass netlogon DsrEnumerateDomainTrusts
context=!ATTACKER_$1_DC_$2
count=alias ATTACKER_$1 ATTACKER_$1_DC_$2; \
create ATTACKER_$1_DC_$2_LIFETIME 30 ( unalias ATTACKER_$1_DC_$2 )
init=create ATTACKER_$1
end=delete ATTACKER_$1
desc=Attacker $1 has enumerated domain trust against several domain controllers
action=write - %s
thresh=3
window=30
With this change, a separate context
ATTACKER_<attackerip>_DC_<dcip>_LIFETIME will be set up for each alias
after the creation of the alias. The context will exist for 30 seconds
(the size of the event correlation window) and will drop the alias
with 'unalias' action when context lifetime expires. Therefore, each
alias will exist for 30 seconds only, and when the event that
triggered its creation moves outside the event correlation window, the
operation is able to count the event for the given attacker and domain
controller combination again. Note that although the *_LIFETIME
contexts are not removed when the operation terminates, they will time
out quite quickly, and executing 'unalias' action for a non-existing
alias name is no-op (you will only get a debug-level message into SEC
log that the alias does not exist).
One final note -- you can find a similar solution for this scenario in
a paper that is available from the SEC home page:
https://ristov.github.io/publications/cogsima15-sec-web.pdf
Hope this helps,
risto
Kontakt James Lay (<j...@slave-tothe-box.net>) kirjutas kuupäeval K,
7. juuli 2021 kell 22:23:
>
> Hey all.
>
> So....been looking at EventGroups thinking this might fit the bill, but I'm
> not sure so I'm coming to you folks. I have the below:
>
> 1625677087.655857 CAY8g9D3jAKFwhD02 SameIP 59143 DifferentIP 445 0.017172
> \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
> 1625677087.744290 C6mmd42niEVcW1djY5 SameIP 59144 DifferentIP 445 0.003689
> \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
> 1625677087.776183 CamRzj1Y20KA9cv9Mi SameIP 59145 DifferentIP 445 0.003968
> \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
> 1625677203.779593 CF4JvS21lo6Beh3jUb SameIP 59149 DifferentIP 445 0.001475
> \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
> 1625677203.892484 C6LZI2ooakJbNI6vj SameIP 59150 DifferentIP 445 0.023818
> \\pipe\\lsass netlogon DsrEnumerateDomainTrusts
>
> My goal is to flag on this type of behaviour (a single IP enumerating domain
> trust against several domain controllers in a small space of time). Anyone
> have any tips on how to implement something like this? Is EventGroup not
> what I need? Thank you.
>
> James
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
