search

Yamato-Security / hayabusa

Hayabusa (隼) is a sigma-based threat hunting and fast forensics timeline generator for Windows event logs.
GNU Affero General Public License v3.0
2.28k stars 202 forks source link

[bug] Defender is getting triggered when unpacking rules #1356

Closed scudette closed 4 months ago

scudette commented 5 months ago

Describe the bug

Using the Velociraptor artifact I noticed that defender is getting triggered on the rules that are unpacked to the disk.

image

Step to Reproduce Steps to reproduce the behavior:

  1. Collect the artifact https://docs.velociraptor.app/exchange/artifacts/pages/windows.eventlogs.hayabusa/

Is it possible for you to package the rules into a static string as is common for Go binaries so there is no need to unpack them to disk?

fukusuket commented 5 months ago

Thank you for reporting this. I confirmed Defender detection of the same file on my Windows11. 

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
  <Provider Name="Microsoft-Windows-Windows Defender" Guid="{11cd958a-c507-4ef3-b3f2-5fd9dfbd2c78}" /> 
  <EventID>1116</EventID> 
  <Version>0</Version> 
  <Level>3</Level> 
  <Task>0</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-04-27T00:17:03.8249878Z" /> 
  <EventRecordID>5869</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="18952" ThreadID="15600" /> 
  <Channel>Microsoft-Windows-Windows Defender/Operational</Channel> 
  <Computer>mouse</Computer> 
  <Security UserID="S[-](https://github.com/Yamato-Security/hayabusa/issues/1356#)1-5-18" /> 
  </System>
 <EventData>
  <Data Name="Product Name">Microsoft Defender ウイルス対策</Data> 
  <Data Name="Product Version">4.18.24030.9</Data> 
  <Data Name="Detection ID">{A519CFB5-6267-4874-BDF5-5D95328595F3}</Data> 
  <Data Name="Detection Time">2024-04-27T00:17:00.734Z</Data> 
  <Data Name="Unused" /> 
  <Data Name="Unused2" /> 
  <Data Name="Threat ID">2147772966</Data> 
  <Data Name="Threat Name">Trojan:Script/Phonzy.A!ml</Data> 
  <Data Name="Severity ID">5</Data> 
  <Data Name="Severity Name">重大</Data> 
  <Data Name="Category ID">8</Data> 
  <Data Name="Category Name">トロイの木馬</Data> 
  <Data Name="FWLink">https://go.microsoft.com/fwlink/?linkid=37020&name=Trojan:Script/Phonzy.A!ml&threatid=2147772966&enterprise=0</Data> 
  <Data Name="Status Code">1</Data> 
  <Data Name="Status Description" /> 
  <Data Name="State">1</Data> 
  <Data Name="Source ID">3</Data> 
  <Data Name="Source Name">リアルタイム保護</Data> 
  <Data Name="Process Name">C:\tmp\velo\velociraptor-v0.72.0-windows-amd64.exe</Data> 
  <Data Name="Detection User">mouse\fukus</Data> 
  <Data Name="Unused3" /> 
  <Data Name="Path">file:_C:\Users\fukus\AppData\Local\Temp\gui_datastore\temp\tmp2897136193\rules\sigma\builtin\powershell\powershell_classic\posh_pc_tamper_windows_defender_set_mp.yml; file:_C:\Users\fukus\AppData\Local\Temp\gui_datastore\temp\tmp2897136193\rules\sigma\builtin\powershell\powershell_script\posh_ps_tamper_windows_defender_set_mp.yml</Data> 
  <Data Name="Origin ID">1</Data> 
  <Data Name="Origin Name">ローカル コンピューター</Data> 
  <Data Name="Execution ID">1</Data> 
  <Data Name="Execution Name">中断</Data> 
  <Data Name="Type ID">8</Data> 
  <Data Name="Type Name">高速パス</Data> 
  <Data Name="Pre Execution Status">0</Data> 
  <Data Name="Action ID">9</Data> 
  <Data Name="Action Name">該当なし</Data> 
  <Data Name="Unused4" /> 
  <Data Name="Error Code">0x00000000</Data> 
  <Data Name="Error Description">この操作を正しく終了しました。</Data> 
  <Data Name="Unused5" /> 
  <Data Name="Post Clean Status">0</Data> 
  <Data Name="Additional Actions ID">0</Data> 
  <Data Name="Additional Actions String">No additional actions required</Data> 
  <Data Name="Remediation User" /> 
  <Data Name="Unused6" /> 
  <Data Name="Security intelligence Version">AV: 1.409.525.0, AS: 1.409.525.0, NIS: 1.409.525.0</Data> 
  <Data Name="Engine Version">AM: 1.1.24040.1, NIS: 1.1.24040.1</Data> 
  </EventData>
  </Event>
fukusuket commented 5 months ago

@YamatoSecurity @hitenkoku I am not familiar with Defender detection ... 😅 If we include a Sigma rule string in the binary, Hayabusa itself could be stopped by Defender...? If so, it might be better to allow some of the rules to be missing, such as this issue. What do you think?

I noticed that there is already a note about this in the README.

scudette commented 5 months ago

My suggestion is to just embed the rules inside the binary rather than require them to be unpacked to disk

This detection is probably due to on access scanning when the file is written to disk

fukusuket commented 5 months ago

@scudette Thank you so much for your comment! Yes I understand what you are proposing. My one concern was that when the entire rules are included in the binary, the possibility of hayabusa.exe itself being stopped by Defender will increase? What do you think? (My concern may be lessened if we check that it is not detected by Defender at the time of release)

scudette commented 5 months ago

Usually we compress the string inside the binary so this is extremely unlikely.

This is clearly a false positive from defender triggering off a string in that rule. When the string is compressed it should avoid triggering this match.

Also usually on access scans only cover the first part of the file so if the string is embedded deeper into the file it might also not trigger.

We can always test to see how it works and worse case implement simple xor

fukusuket commented 5 months ago

@scudette I see, then it seems very unlikely that Defender will detect it!

There are both advantages and disadvantages to being a YAML text, so this needs to be considered, but thank you for the detailed information :) I would first like to check the feasibility with a prototype.

As I can think of it now,

Binary rule's advantages:

YAML rule's advantages:

There is also the option of creating both binaries (although this may be a bit more cost to maintain 😇).

scudette commented 5 months ago

Another advantage is that we don't need to unpack the zip on the endpoint creating thousands of temporary files then immediately deleting them. This impacts a lot of things like USN journal and other artifacts.

Having a single binary is just much easier to use. Of course your can always offer to parse plain yaml files with a command line switch and so the same binary can be used in both use cases. It would make no difference to the users, if they want to keep using the external rules they can unpack the zip file and do it just like they do now.

You can even change the way you ship the tools to a rules package and a binary (I noticed these are already separated into different repos).

hitenkoku commented 5 months ago

Thank you for your suggestion. We will consider whether to implement a new one, but we have a few concerns.

Is the method you suggest still not detected by Windows Defender's real-time detection when the zip is unzipped?

For example, can't you add a limited Windows Defender exception from Velociraptor?

scudette commented 5 months ago

No. If you embed the rules in the binary they are just strings in memory and can not be seen by real time scanner which is only applied to files.

We don't want to manipulate defender settings at runtime. That will trigger all kinds of edr alerts (and rightly so).

YamatoSecurity commented 5 months ago

@scudette Thank you for the suggestion. Do you have any recommendations for how to update rules though? We do releases about every month or so, so there is not a huge gap but would like to give users the ability to use the latest rules for their threat hunts. We will discuss internally how we might be able to implement this.

scudette commented 5 months ago

Sorry im not a Rust expert but a quick google shows some promising resources like

https://crates.io/crates/include_dir

https://www.reddit.com/r/rust/comments/kv8iev/what_is_the_idiomatic_way_of_embed_files_into/

Usually we do this in Go all the time - it just gets included at build time so it is always the latest version embedded inside the binary

YamatoSecurity commented 5 months ago

@scudette As a temporary measure, we have excluded the two rules that cause defender FPs and will send a PR to update the Hayabusa artifact so it won't trigger alerts. For a long term solution, we are probably going to try to embed config files into the binary and encrypt all the rules into a single file to reduce FPs with AVs as well as cut down the number of files needing to be placed on the system to reduce overwriting any evidence as you mentioned with USN journals, etc...

YamatoSecurity commented 4 months ago

@scudette As we exclude the offending rules, I will close this for now. We are going to create an option to encrypt rules in a zip which will prevent this in the future as well as minimize files put on the system.