Add DataStreams Field to MFT Rules and Add Part 1 Rules for Suspicious Script and Executable Locations #212
Conversation
…s Script and Executable Locations Add DataStreams Field to MFT Rules and Add Part 1 Rules for Suspicious Script and Executable Locations Reduce False Positives with Recycle Bin and ADAMNTDS.DIT and NTDS.DIT Exclude Intel and Temp from root_nonstand_fold as other rules cover this Add MFT Rules to Cover Root of Program Files and Windows Folders Add MFT rule for RTLO and add .lnk to most sup_script_exec rules
There was a problem hiding this comment.
@reece394 - Massive thank you for raising this PR, lots of great additions here! :)
I've left a few comments, mainly about the detection severity of each rule. If you can make those changes I can merge!
| @@ -0,0 +1,122 @@ | |||
| --- | |||
There was a problem hiding this comment.
@reece394 - I'm not sure about this rule in its current format. I ran it over a test MFT and it generated 41175 detections.
I'm not sure if it's what you intended, but the rule logic is triggering on almost every file?
There was a problem hiding this comment.
Hmm when I tested it it hasn't generated that many files to me. I thought I mitigated against false positives for this one by excluding anything with a \ which should mean no subfolders should detect. In your test mft is everything in the root of the drive?
There was a problem hiding this comment.
@reece394 - you can grab the MFT I'm using to test here: https://github.com/AndrewRathbun/DFIRArtifactMuseum/tree/main/Windows/NTFSArtifacts/MFT/Win10/APTSimulatorVM
Looks like it's triggering on random paths like: "FullPath": "Users/TestUser/Desktop/kape.exe",. I assume because you've excluded directories with 'i*\*' but not /?
|
Resolved most of the comments in regards to levels. The ones with comments once we get those confirmed I will change those over as well and resolve and then it will be ready to merge |
|
Since my review comments are pending I am going to chuck my findings in here as well just in case they get missed. It seems the issue with \ and /s are platform specific. I was doing my rule creation and testing on Windows hence never coming across it. When running Chainsaw on Windows it outputs the MFT paths as \ but when running it on Linux and macOS it outputs the paths as /. The two options we have is I account for this in the rules or fixing the code to output the same regardless of platform. Doing further research into this it is a known issue with the mft library being used. Seems like this would solve the issue. I recommend forking the library and adding that modification in once it has been validated as a good solution as it doesn't look like there has been activity on the library for a while. I would check this first to see if there are any differences between that and the GitHub master. |
|
The MFT Library has been forked. As a result on Windows the slashes are now the same as macOS and Linux and I will now rewrite the rules with this in mind. Do not merge these until the MFT library fork work is done and merged as the rules are in a varying state of broken due to earlier assumptions |
As mentioned I have added the DataStreams field to all MFT rules as it might be handy for Zone.Identifiers since #210 has been merged now.
Additionally I have worked on the first batch of rules which aim to automate finding dodgy files in commonly abused Threat Actor locations. This work is based on observations on real incident response cases as well as the excellent SANS FOR508 course. The Suspicious Locations are purposely split out to allow analysts to choose the rules they wish to use. There will be false positives in these (I noted that antiviruses in ProgramData can be particularly noisy as an example) but this should help cut through the noise and generate quick findings for analysts to pivot off rather than having to read the MFT like a book.
This commit also fixes an issue where ADAMNTDS.DIT and NTDS.DIT rules were flagging with an update file that was exactly 55 bytes in size being a very annoying false positive and tightens the Recycle Bin rules to have $I act the same as $R.
Additionally this adds rules for Program Files, Program Files (x86) and Windows to look in the root of the folders for suspicious files. This uses regex to gate the rules to look at just the root of the folders to help cut down on false positives.