Sigma repository's `PowerShell Classic(Windows PowerShell.evtx)` rules are undetectable with `Hayabusa`

[fukusuket]

Describe the bug The PowerShell Classic(Windows PowerShell.evtx) related Sigma rule below cannot be detected because it checks the field under the noname Data field.

/rules/windows/powershell/powershell_classic

• Nslookup PowerShell Download Cradle
• Alternate PowerShell Hosts
• Delete Volume Shadow Copies Via WMI With PowerShell
• PowerShell Downgrade Attack - PowerShell
• PowerShell Called from an Executable Version Mismatch
• Netcat The Powershell Version
• Remote PowerShell Session (PS Classic)
• Renamed Powershell Under Powershell Channel
• Suspicious PowerShell Download
• Use Get-NetTCPConnection
• Zip A Folder With PowerShell For Staging In Temp - PowerShell
• Tamper Windows Defender - PSClassic
• Suspicious Non PowerShell WSMAN COM Provider
• Suspicious XOR Encoded PowerShell Command Line - PowerShell

For example, following rule use HostApplication field, but this field is under Data field. https://github.com/Yamato-Security/hayabusa-rules/blob/7692e0b34c5ac58e09c9d202ea4a9aa309c6a633/sigma/builtin/powershell/powershell_classic/posh_pc_abuse_nslookup_with_dns_records.yml#L26-L31

Actual behavior These rules are not detectable.

Expected behavior These rules are detectable.

Additional context Windows PowerShell.evtx event data structure is as follows.

[fukusuket]

At first I thought all I had to do was modify logsource_mapping.py, but after thinking about it more complex transformations were needed... ><

[fukusuket]

I will create a PR and ask the Sigma repository if it is possible to handle this with rules using Data.

[YamatoSecurity]

Thanks for creating this issue. Indeed, since the sigma rules cannot be used as is, it is probably better to fix them upstream in the sigma rules themselves. Might be possible to do with regex but would slow down performance. If the sigma rules search everything in the Data field then more chances for false positives... Let's ask the sigma maintainers what they think.

What about treating the following aliases in Hayabusa specially and parse out the HostApplication=, etc... fields from the Data field:

ContextInfo
HostApplication
EngineVersion
HostName

Unfortunately ContextInfo needs to be used to map a different field for ps_module logs. The other fields do not seem to be used in other sigma rules but are defined in eventkey_alias.txt for some reason. (EngineVersion,Event.EventData.EngineVersion, etc...) So if we implemented it in Hayabusa, we would have to first prioritize checking if HostApplication=, etc.. was in the Data field and if not, fall back to checking the alias defined in eventkey_alias.txt.

[fukusuket]

@YamatoSecurity I see, it seems like using Data will increase FalsePositive... It might be a good idea to handle this on the Hayabusa side:)

I asked the Sigma project the following questions! https://github.com/SigmaHQ/sigma/discussions/4510 If you have additional information, it would be greatly appreciated if you could comment on the discussion above😊

[fukusuket]

The following PR has been changed to use Data, so close this issue. https://github.com/SigmaHQ/sigma/pull/4519