Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Service Mappings to Sigma Event Logs #130

Merged

Conversation

reece394
Copy link
Contributor

@reece394 reece394 commented May 28, 2023

Based on my comment at #122 I decided to try implementing more service mappings and providers. I used thor.yml for inspiration and based on my tests so far it seems promising as a solution to #122. Let me know what you think.

I did leave out some including System, Application and PowerShell due to not being sure what the Provider Name is for System and Application.I presume they are both the same name as their title?
For PowerShell I was unsure how to represent multiple Providers so I chose to leave that one for now. I did attempt multiple providers with a problematic rule at the bottom of the commit but I am unsure if it is correct

Edit: Service: System and Service: Application appears to specify multiple providers in their rules already so won't need to add System or Application to this PR

This Adds Mappings to Events Based on their Service Name. It maps Service Name to a Log Provider Cutting Down on False Positives Dramatically.
@alexkornitzer
Copy link
Collaborator

Hi @reece394,

Thanks for this, I can't totally comment on what providers to use as I am not in IR, but i'll rope some people in.

You are correct in how you did multiple providers its is as simple as using an array, if you are curious here are the Tau docs, if they are lacking or could be clearer please do let me know https://docs.rs/tau-engine/latest/tau_engine/struct.Rule.html

Lets track the work here, then once this PR is in I think its fair to close out the issue.

Thank you for taking it on yourself to help with #122, this is a sufficient work around until Sigma rules are improved.

@reece394
Copy link
Contributor Author

No problem! I have been a fan of Chainsaw for a while and use it regularly so when I realised this could fix the problem I have been having with Sigma rules I wanted to make sure others benefited as well.

Before merge I would like to clarify the todo statement inside commit ccdc354. I just want to check and make sure with the commits I made there won't be any events dropped by mistake with the way I wrote the preconditions. Otherwise I believe the commit is ready for review as System and Application Events have different providers attached to their rules already.

Providers just need double checked to make sure I haven't made any errors but I took the majority of them from either my own Chainsaw sigma dumps or EVTX-ETW-Resources.

@alexkornitzer
Copy link
Collaborator

Right took me a while to work out what I meant by that FIXME comment, I should have been more verbose! Basically at the moment a rule can only have one precondition tied to it. This should not affect your PR as you do not have duplicate for blocks defined anywhere.

I have pinged some IR peeps, so once they double check the providers I will get this merged in :)

@alexkornitzer alexkornitzer merged commit e7be350 into WithSecureLabs:master May 31, 2023
@reece394 reece394 deleted the reece394-Service-Mapping branch May 31, 2023 18:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants