Hi everyone,
Simple question: how does the legacy UBA rule “Local Event Log Deletion” actually work? What is the detection rule and the log set behind it?
The reason for my question is, I tried to analyze one of those alerts and tried to find the corresponding log entry in the log search. Due to it being a UBA rule, we basically have no insight about the inner working of the detection rule. Naturally, I tried to search for Windows event ID 1102 " The audit log was cleared" under the Endpoint Logs/Sysmon log set - with no success.
Can anyone give me some guidance on this?
Cheers,
Nik
Hi Nik,
I’m a member of the product team here at Rapid7 working on projects related to our IDR detection rules, and might be able to offer some background. Unfortunately you are correct that the logs behind the legacy “Local Event Log Deletion” rule are not currently available within Log Search. We are actively working on an initiative to migrate our legacy UBA rules over to the Detection Rule Library, which will give users visibility into the logic powering their detections, and more capabilities to track down the signal triggering them. By using the alert evidence peek panel for our Detection Rule Library based rules, users are able to view both the detection rule logic, and the log events that triggered them.
3 Likes
That´s nice to hear it, Is there any way to track the changes or migration process?
Thanks!
Hi Jordan,
Any movement on allowing us to have visibility of this log in log search? Or even when we might expect this rule (Local Event Log Deletion) to be migrated to the Detection Rule Library.
Kind regards,
Stephen
Hey Stephen,
Thanks for your patience here. We are working through the migration process, and unfortunately Local Event Log Deletion is not part of our next cohort, so don’t have a firm migration expectation on it. In the case of this specific rule, you are correct that it is utilizing event code 1102 combined with some internal attribution to identify it as a local privileged action. As we are currently thinking about how we move the context triggering these alerts into a more visible state the team is looking at how we can make log information available only at time of detection vs. what is necessary to be in Log Search consistently. In this case what are you looking to do with access to this log, is it something that you expect to be able to search independently in Log Search, or does it only become relevant as context when an alert fires?
Hi Jordan, apologies for the delay in response. Just jumped on here to check something else and saw that I had a reply!
I think it’s important for both aspects. Both for having confidence in the detection rule and also for analysts to understand what’s going on without blatantly trusting.
I opened a support ticket around this time and they also confirmed what you said about no roadmap, which wasn’t really reassuring. But hey ho! We can hope one day.