WithSecureLabs / chainsaw

Rapidly Search and Hunt through Windows Forensic Artefacts
GNU General Public License v3.0
2.7k stars 242 forks source link

Sophos Antivirus Rule Not Parsing Data Events With Same Key Name #132

Closed reece394 closed 1 year ago

reece394 commented 1 year ago

When parsing this event using the Sophos Antivirus Rule sophos.yml after adding Sophos System Protection as a provider it is not parsing the Data key fields to the antivirus.csv file. The fields Threat Name, Threat Type and Threat Path all do not resolve even though the data fields they map to seem to be present.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
  <Provider Name="Sophos System Protection" /> 
  <EventID Qualifiers="37">42</EventID> 
  <Level>3</Level> 
  <Task>9</Task> 
  <Keywords>0x80000000000000</Keywords> 
  <TimeCreated SystemTime="2023-06-01T06:11:11.0000000Z" /> 
  <EventRecordID>321309</EventRecordID> 
  <Channel>Application</Channel> 
  <Computer>ABCDEFG</Computer> 
  <Security /> 
 </System>
 <EventData>
  <Data>File</Data> 
  <Data>C:/Users/ABCD/Downloads/PSTools.zip/PsExec64.exe</Data> 
  <Data>PsExec</Data> 
  <Data>ABC_123</Data> 
  <Data>{"certificates":[{"CertificateAlgorithm":"SHA256","CertificateSignatureLocation":"Embedded","CertificateSigner":"Microsoft Corporation","CertificateThumbprint":"key","CertificateValid":true}],"fileMetadata":{"CompanyName":"Sysinternals","FileDescription":"PsExec","FileVersion":"x.xx","InternalName":"PsExecHost","LegalCopyright":"Copyright ©","LegalTrademarks":"","OriginalFilename":"psexesvc.exe","ProductName":"Sysinternals PsExec","ProductVersion":"x.xx"},"filePath":"C:/Users/ABCD/Downloads/PSTools.zip/PsExec64.exe","fileSize":345,"globalReputation":44,"localReputation":11,"localReputationConfigVersion":"key","localReputationSampleRate":5,"mlScoreMain":4,"mlScorePua":5,"mlSuppressed":false,"remote":false,"reputationSource":"SOPHOS_HASH","scanEvalReason":"ON_DEMAND","sha1FileHash":"Hash","sha256FileHash":"Hash","sting20Enabled":true}</Data> 
 </EventData>
</Event> 

When I create a new field called Test in the sophos.yml rule using Event.EventData.Data it does parse separating each data key with a new line and - like the following - File - C:/Users/ABCD/Downloads/PSTools.zip/PsExec64.exe - PsExec

Event.EventData.Data[0], Event.EventData.Data[1] and Event.EventData.Data[2] doesn't work in this case for some reason. Any guidance on this would be appreciated as I would like to add Sophos System Protection to the providers once this issue is resolved.

Slightly off topic but what is your opinion on adding EDR solutions to Chainsaw rules? I have a SentinelOne rule I would like to commit as well however I had to add new fields to the .csv file and it seems to add these fields to antivirus.csv regardless of if SentinelOne is present. It might be good not to include a column if there is 0 entries for it?

Thanks!

alexkornitzer commented 1 year ago

Okay, so I could be incorrect, but is it not just failing because the providers do not match (https://github.com/WithSecureLabs/chainsaw/blob/master/rules/antivirus/sophos.yml#L31)?

Happy for as many rules to be added as you like, I think for the CSV the way around that would be to define it as a new group EDR instead of Antivirus?

reece394 commented 1 year ago

I definitely checked this and if the provider didn't match the events it wouldn’t show up at all in the antivirus.csv.

I modified this file when I was testing to add the provider so to be 100% clear currently sophos.yml doesn’t contain the provider Sophos System Protection but I added it in my version of sophos.yml which I am testing locally ATM.

The way I am interpreting the Data keys being the same Event.EventData.Data[0] and Event.EventData.Data[1] should work if Event.EventData.Data does unless I am misunderstanding the parsing syntax?

Different EDR solutions have different fields so this would still be an issue with EDR.csv regarding the last question.

alexkornitzer commented 1 year ago

Are you running it on the xml above or on an evtx file?

So I would say this is where we would then normalise the fields, or are there just no common patterns? You need to think about your usecase though are you wanting to view all EDRs in one csv, hence we need normalisation. Or are you just wanting them in individual files for further processing later, etc?

With in reason we can add whatever to Chainsaw, it just needs to match the use cases or its a lot of maintaince overhead for nothing.

reece394 commented 1 year ago

I am running the above as an evtx file but I displayed it in XML to show you the issue with the data fields.

In terms of patterns I would have to get back to you on that one. But ideally I want to have any results in the same file if there is a match.

It may end up being the case that the rules I am creating for those won’t be upstream-able which is fine but I want to upstream as much as I can

alexkornitzer commented 1 year ago

Okay, I think I have managed to replicate it, so will get that fixed.

Yeah so if you want all EDR in the same group then you will need to normalise or accept there will be column bloat, this is one of the caveats of using CSV for analysis. No hurt in submitting a PR and we can see how it plays.

I should eventually break the rules and mappings out of this repo.