Duplication of Alerts when using the "Mimikatz Use" Community Play

[SimonCampbell85]

Duplication of Alerts when using the Mimikatz Use Community Play

I encountered this problem while attempting to demonstrate Security Onion and the Playbook app. In particular:

• I used Wazuh agent to forward Sysmon events from a Windows machine to Security Onion.
• I then enabled the first Play in the community Playbook "Mimikatz Use"
• Ran Mimikatz on the Windows machine using the command line and passed some parameters:
  C:\Users\User1\Desktop\mimikatz\x64\mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" exit >> C:\Users\User1\Desktop\MimikatzOutput.txt
• Checked the Alerts in Security Onion

So this does work, I enable the play, perform the activity that will trigger it, then I can see a new alert appears. The problem is that Alerts continue to be produced long after the activity is performed.

In the below image, Mimikatz alerts continue to be produced, in this instance.

Mimikatz was first run at: 2022-12-19 11:13:29.000 +00:00
However I can still see alerts being generated at: 2022-12-19 11:35:00.000 +00:00

When I look at the details of the alert, things get weird with the field names...

Its almost like there's some sort of weird recursion or duplication that's happening.

My colleague suggested to me that it's like the Alerts are triggering more Alerts and that got me thinking. I checked out the logic of the Mimikatz play and can see that the Sigma rule looks for a few keywords anywhere in the log entry.

detection:
  keywords:
  - dpapi::masterkey
  - eo.oe.kiwi
  - event::clear
  - event::drop
  - gentilkiwi.com
  - kerberos::golden
  - kerberos::ptc
  - kerberos::ptt
  - kerberos::tgt
  - Kiwi Legit Printer
  - 'lsadump::'
  - mimidrv.sys
  - \mimilib.dll
  - misc::printnightmare
  - misc::shadowcopies
  - misc::skeleton
  - privilege::backup
  - privilege::debug
  - privilege::driver
  - 'sekurlsa::'

I thought that this detection logic was a bit broad so I edited the rule to only look for these patterns in the Command Line field

detection:
detection:
  command_selection:
    CommandLine|contains:
     - dpapi::masterkey
     - eo.oe.kiwi
     ...
     - 'sekurlsa::'
  condition: command_selection

These changes resolved the above problem, the Alert only fired once for everytime Mimikatz was run, and there were no alerts with weird fields.

So whats causing this?

My Theory

I suspect that when an Alert is generated, this creates an event that is stored in a similar way to the other events received by Security Onion, an Alert is just another event. The details of the original event are present in the Alert, which means that the Alert itself will match the detection logic (Keyword will match the text anywhere in the log). This creates a bit of a loop and new alerts that are created, continue to trigger more alerts.

Are Alerts stored similar to rest of the events received by Security Onion?
Does detection logic get run against Alerts?

I may not be 100% correct on this, but I believe that you should be able to repeat this using the steps I have outlined below.

How can we correct this?

Potentialy this could be resolved by just amending the detection logic Mimikatz Use on the Sigma repository. However I think this would be messy and not really address the root cause of the problem.

I think the main thing that needs to be addressed here, is that detection logic should only be run against actual events ingested from other sources and not run against alerts that have been generated on Security Onion.

Please reach out if you have any questions and I will be happy to assist!

[defensivedepth]

Thanks for the detailed writeup! I am digging into this a bit to see what's going on.

[defensivedepth]

@SimonCampbell85 I have communicated about this situation with the Sigma devs. We agree that this rule is broken. What's happening is that because it is not specifying a Logsource to map to a particular field, the Elastalert rule is searching for the strings in all the fields. This creates some problems - what you are seeing as well as performance issues etc.

I would suggest disabling this rule for now. It is in the process of being fixed.

[SimonCampbell85]

@defensivedepth Thanks for getting back to me about this, is there any way I can keep up to date with the progress of this? Would you be able to let me know when the fix has been applied and what version that will be in?

[defensivedepth]

@SimonCampbell85 You can track the status of it here: SigmaHQ/sigma#3871