PowerShell Classic (Windows PowerShell.evtx) related rules fields

[fukusuket]

Hello, Thank you for maintaining Sigma :)

Our Hayabusa project using Sigma heavily, then we noticed Hayabusa can't detect PowerShell Classic related following rules currently.

/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

The reason was that the above rule referred to a field under the Data field which was not defined in the XML explicitly.
For example, the following rule references a HostApplication field that is not defined in the XML.

sigma/rules/windows/powershell/powershell_classic/posh_pc_abuse_nslookup_with_dns_records.yml

Lines 22 to 27 in 8dc32d6

	HostApplication|contains|all:
	- 'powershell'
	- 'nslookup'
	HostApplication|contains:
	- '-q=txt'
	- '-querytype=txt'

A sample event log for Windows PowerShell.evtx is below.
Fields such as HostVersion and HostApplication do not seem to be explicitly defined in the XML definition.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="PowerShell" /> 
    <EventID Qualifiers="0">400</EventID> 
    <Version>0</Version> 
    <Level>4</Level> 
    <Task>4</Task> 
    <Opcode>0</Opcode> 
    <Keywords>0x80000000000000</Keywords> 
    <TimeCreated SystemTime="2023-10-09T13:24:55.2952147Z" /> 
    <EventRecordID>1643</EventRecordID> 
    <Correlation /> 
    <Execution ProcessID="4684" ThreadID="0" /> 
    <Channel>Windows PowerShell</Channel> 
    <Computer>HOSTA</Computer> 
    <Security /> 
  </System>
  <EventData>
    <Data>Available</Data> 
    <Data>None</Data> 
    <Data>NewEngineState=Available PreviousEngineState=None SequenceNumber=13 HostName=ConsoleHost HostVersion=5.1.22621.963 HostId=e2a4b19b-92ef-407b-9fe0-b646489b66c5 HostApplication=C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command Get-WmiObject Win32_Process | Where-Object { $_.ExecutablePath -eq 'C:\Users\alice\AppData\Local\Programs\Microsoft VS Code\bin\code-tunnel.exe' } | Select @{Name='Id'; Expression={$_.ProcessId}} | Stop-Process -Force EngineVersion=5.1.22621.963 RunspaceId=e1518a29-e3b8-41d3-931a-ff4db039a628 PipelineId= CommandName= CommandType= ScriptName= CommandPath= CommandLine=</Data> 
  </EventData>
</Event>

Then my question is,
What is the best way to write Sigma Rule's detection fields in PowerShell Classic?
For example, I think there are two options:

1. Use specific fields under the Data field(e.g. HostApplication). and extract fields under the Data field on the application side
2. Not use specific fields(e.g. HostApplication) . Instead, use the only Data field and match with |re, |contains, etc. For example, the following rules

sigma/rules/windows/powershell/powershell_classic/posh_pc_remotefxvgpudisablement_abuse.yml

Lines 25 to 28 in 8dc32d6

	detection:
	selection:
	Data|contains: 'ModuleContents=function Get-VMRemoteFXPhysicalVideoAdapter {'
	condition: selection

I'm sorry if my understanding is insufficient. It would be helpful if you could comment.
Regards,

[nasbench]

Hi @fukusuket

The definition section in the logsource explicitly state that events have to be extracted. Example:

logsource:
    product: windows
    category: ps_classic_start
    definition: fields have to be extract from event

This means that its expected out of the back end (in this case Hayabussa) to parse the event and extract the fields. Or simply map everything that has a logsource powershell_classic to the Data field.

We've talked about the Data field issue before in some other discussion (that i can't seem to find now). But there are 18 rules using the Data field. Some are necessary as the actualy field contains only data while others such as the powershell_classic actually contains unparsed data.

Another example would be the scheduled task creation event 4698 for example. It has a Task Content field that actually has the XML of the task. Some backends actually ingest the log raw while other parse it into separate fields.

Anyway the point being that at the end of the day both way of writing are "technically" possible. Here are up and downsides

• If you use the data field as i did in

  sigma/rules/windows/powershell/powershell_classic/posh_pc_remotefxvgpudisablement_abuse.yml

  Line 4 in 1584787

  - id: a6fc3c46-23b8-4996-9ea2-573f4c4d88c5 # ProcCreation

  the disadvantage being its going to be hard to map this with backends who extract fields. They have to match it with the raw event. The benefit being that only a simple string match on the raw event would suffice.

• If you use explicit fields, you need to extract them but its less resource intensive as you're matching on specific fields instead of the raw.

Personally (my logical side) would opt for specific fields instead of using the data just because its future proof. But my lazy side would say who cares and use data 😛

Hope this rambling answer your question somehow. I would pass this on to other members to see their current opinion on this matter.

Please let me know if you have any further questions

[fukusuket]

@nasbench

Thank you so much for your kind support :)

    definition: fields have to be extract from event

Sorry, I had overlooked this point. It's already clearly stated.

I understand that there are pros and cons to both, and that there are products that support field extraction.
I tried checking the Beats source code, I found that the PowerShell fields were extracted as you said.
https://github.com/elastic/beats/blob/master/x-pack/winlogbeat/module/powershell/ingest/powershell.yml

then I have one more question.
Do you think it would be better if I created these rules with OR conditions? For example:

 detection: 
     selection_data: 
         Data|contains: 'ModuleContents=function Get-VMRemoteFXPhysicalVideoAdapter {' 
     selection_field: 
         ModuleContents|startswith: 'function Get-VMRemoteFXPhysicalVideoAdapter {' 
 condition: selection_data or selection_field

The advantage is that it can support more products, and the disadvantage is that detection requires more resources.
If the advantages outweigh the disadvantages, I would like to create a pull request with above OR conditions.
(But I think there are probably some rules that cannot be made into OR conditions...)

On the other hand, if the disadvantages seem to outweigh the advantages, I will leave the current rules as they are and consider ways to deal with them on Hayabusa's member.

[nasbench]

Writing a detection with the 2 possible option can create some issues as you noted. We did that before for rules using the base64 and wide modifier for example. Where we provided both an encoded version and a version using the modifier but those rules are going to get updated in the future.

In this case and in my opinion the future proof way of doing this is to write it using the fields and let the backends do the extractions. (even though I agree and even suggested sometime to use the data field instead because its some work)

Also even if you don't want to do extraction you can tinker with pysigma mapping to map all fields using the powershell_classic logsource to the Data field and add the fields as a prefix?

Anyway as I said I will pass on this discussion to other members of the team to get their opinion and we'll see what's the majority's opinion.

I will get back to you soon :)

[nasbench]

Alright, I think the general consensus is to keep using the original field. So we'll convert the rules to using the Data field. If you would like to provide a PR for that or I will do it in the coming days :)

Thanks for pointing this out and for the discussion.

I'll mark this as answered.

[fukusuket]

I see, It seems that the disadvantages of creating two options are greater. also, now I understand that we can do it with PySigma.
Thank you so much for handling this topic :)

[nasbench]

No worries :)
As a quick side note are you gonna provide the PR fix or should I?

[fukusuket]

Yes, I would love to create PR! Thank you.