This is a repository containing curated sigma rules that detect attacks in Windows event logs.
It is mainly used for Hayabusa detections rules and config files, as well as Velociraptor's built-in sigma detection.
The advantage of using this repository over the upstream sigma repository is that we include only rules that most sigma-native tools should be able to parse.
We also de-abstract the logsource
field by adding the necessary Channel
, EventID
, etc... fields to the rules to make it easier to understand what the rule is filtering on and more importantly to reduce false positives.
We also create new rules with converted field names and values for process_creation
rules and registry
based rules so that the sigma rules will not only detect on Sysmon logs, but will detect on built-in Windows logs as well.
Hayabusa detection rules are written in YAML format with a file extension of .yml
. (.yaml
files will be ignored.)
They are a subset of sigma rules but also contain some added features.
We are trying to make them as close to sigma rules as possible so that it is easy to convert Hayabusa rules back to sigma to give back to the community.
Hayabusa rules can express complex detection rules by combining not only simple string matching but also regular expressions, AND
, OR
, and other conditions.
In this section, we will explain how to write Hayabusa detection rules.
Example:
#Author section
author: Zach Mathis
date: 2022/03/22
modified: 2022/04/17
#Alert section
title: Possible Timestomping
details: 'Path: %TargetFilename% ¦ Process: %Image% ¦ User: %User% ¦ CreationTime: %CreationUtcTime% ¦ PreviousTime: %PreviousCreationUtcTime% ¦ PID: %PID% ¦ PGUID: %ProcessGuid%'
description: |
The Change File Creation Time Event is registered when a file creation time is explicitly modified by a process.
This event helps tracking the real creation time of a file.
Attackers may change the file creation time of a backdoor to make it look like it was installed with the operating system.
Note that many processes legitimately change the creation time of a file; it does not necessarily indicate malicious activity.
#Rule section
id: f03e34c4-6432-4a30-9ae2-76ae6329399a
level: low
status: stable
logsource:
product: windows
service: sysmon
definition: Sysmon needs to be installed and configured.
detection:
selection_basic:
Channel: Microsoft-Windows-Sysmon/Operational
EventID: 2
condition: selection_basic
falsepositives:
- unknown
tags:
- t1070.006
- attack.defense_evasion
references:
- https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
- https://attack.mitre.org/techniques/T1070/006/
ruletype: Hayabusa
#Sample XML Event
sample-message: |
File creation time changed:
RuleName: technique_id=T1099,technique_name=Timestomp
UtcTime: 2022-04-12 22:52:00.688
ProcessGuid: {43199d79-0290-6256-3704-000000001400}
ProcessId: 9752
Image: C:\TMP\mim.exe
TargetFilename: C:\Users\IEUser\AppData\Local\Temp\Quest Software\PowerGUI\51f5c69c-5d16-47e1-9864-038c8510d919\mk.ps1
CreationUtcTime: 2016-05-16 09:13:50.950
PreviousCreationUtcTime: 2022-04-12 22:52:00.563
User: ZACH-LOG-TEST\IEUser
sample-evtx: |
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385f-c22a-43e0-bf4c-06f5698ffbd9}" />
<EventID>2</EventID>
<Version>5</Version>
<Level>4</Level>
<Task>2</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2022-04-12T22:52:00.689654600Z" />
<EventRecordID>8946</EventRecordID>
<Correlation />
<Execution ProcessID="3408" ThreadID="4276" />
<Channel>Microsoft-Windows-Sysmon/Operational</Channel>
<Computer>Zach-log-test</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="RuleName">technique_id=T1099,technique_name=Timestomp</Data>
<Data Name="UtcTime">2022-04-12 22:52:00.688</Data>
<Data Name="ProcessGuid">{43199d79-0290-6256-3704-000000001400}</Data>
<Data Name="ProcessId">9752</Data>
<Data Name="Image">C:\TMP\mim.exe</Data>
<Data Name="TargetFilename">C:\Users\IEUser\AppData\Local\Temp\Quest Software\PowerGUI\51f5c69c-5d16-47e1-9864-038c8510d919\mk.ps1</Data>
<Data Name="CreationUtcTime">2016-05-16 09:13:50.950</Data>
<Data Name="PreviousCreationUtcTime">2022-04-12 22:52:00.563</Data>
<Data Name="User">ZACH-LOG-TEST\IEUser</Data>
</EventData>
</Event>
Author section
Alert section
" ¦ "
. Field placeholders are enclosed with a %
(Example: %MemberName%
) and need to be defined in rules/config/eventkey_alias.txt
. (Explained below.)Rule section
informational
,low
,medium
,high
,critical
deprecated
, experimental
, test
, stable
.system administrator
, normal user usage
, normal system usage
, legacy application
, security team
, none
. If it is unknown, please write unknown
.lolbas
tag. If the alert can be mapped to a technique in the MITRE ATT&CK framework, please add the tactic ID (Example: attack.t1098
) and any applicable tactics below:
attack.reconnaissance
-> Reconnaissance (Recon)attack.resource_development
-> Resource Development (ResDev)attack.initial_access
-> Initial Access (InitAccess)attack.execution
-> Execution (Exec)attack.persistence
-> Persistence (Persis)attack.privilege_escalation
-> Privilege Escalation (PrivEsc)attack.defense_evasion
-> Defense Evasion (Evas)attack.credential_access
-> Credential Access (CredAccess)attack.discovery
-> Discovery (Disc)attack.lateral_movement
-> Lateral Movement (LatMov)attack.collection
-> Collection (Collect)attack.command_and_control
-> Command and Control (C2)attack.exfiltration
-> Exfiltration (Exfil)attack.impact
-> Impact (Impact)Hayabusa
for hayabusa rules. Rules automatically converted from sigma Windows rules will be Sigma
.Sample XML Event
The following abbreviations are used in rules in order to make the output as concise as possible:
Acct
-> AccountAddr
-> AddressAuth
-> AuthenticationCli
-> ClientChan
-> ChannelCmd
-> CommandCnt
-> CountComp
-> ComputerConn
-> Connection/ConnectedCreds
-> CredentialsCrit
-> CriticalDisconn
-> Disconnection/DisconnectedDir
-> DirectoryDrv
-> DriverDst
-> DestinationEID
-> Event IDErr
-> ErrorExec
-> ExecutionFP
-> False PositiveFW
-> FirewallGrp
-> GroupImg
-> ImageInj
-> InjectionKrb
-> KerberosLID
-> Logon IDMed
-> MediumNet
-> NetworkObj
-> ObjectOp
-> Operational/OperationProto
-> ProtocolPW
-> PasswordReconn
-> ReconnectionReq
-> RequestRsp
-> ResponseSess
-> SessionSig
-> SignatureSusp
-> SuspiciousSrc
-> SourceSvc
-> ServiceSvr
-> ServerTemp
-> TemporaryTerm
-> Termination/TerminatedTkt
-> TicketTgt
-> TargetUnkwn
-> UnknownUsr
-> UserPerm
-> PermamentPkg
-> PackagePriv
-> PrivilegeProc
-> ProcessPID
-> Process IDPGUID
-> Process GUID (Global Unique ID)Ver
-> VersionFirst, the fundamentals of how to create a selection rule will be explained.
To write AND logic, we use nested dictionaries. The detection rule below defines that both conditions have to be true in order for the rule to match.
7040
.System
.detection:
selection:
Event.System.EventID: 7040
Event.System.Channel: System
condition: selection
To write OR logic, we use lists (Dictionaries that start with -
).
In the detection rule below, either one of the conditions will result in the rule being triggered.
7040
.System
.detection:
selection:
- Event.System.EventID: 7040
- Event.System.Channel: System
condition: selection
We can also combine AND
and OR
logic as shown below.
In this case, the rule matches when the following two conditions are both true.
7040
OR 7041
.System
.detection:
selection:
Event.System.EventID:
- 7040
- 7041
Event.System.Channel: System
condition: selection
The following is an excerpt of a Windows event log, formatted in the original XML.
The Event.System.Channel
field in the rule file example above refers to the original XML tag: <Event><System><Channel>System<Channel><System></Event>
Nested XML tags are replaced by tag names seperated by dots (.
).
In hayabusa rules, these field strings connected together with dots are refered to as eventkeys
.
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<EventID>7040</EventID>
<Channel>System</Channel>
</System>
<EventData>
<Data Name='param1'>Background Intelligent Transfer Service</Data>
<Data Name='param2'>auto start</Data>
</EventData>
</Event>
Long eventkeys with many .
seperations are common, so hayabusa will use aliases to make them easier to work with. Aliases are defined in the rules/config/eventkey_alias.txt
file. This file is a CSV file made up of alias
and event_key
mappings. You can rewrite the rule above as shown below with aliases making the rule easier to read.
detection:
selection:
Channel: System
EventID: 7040
condition: selection
Not all eventkey aliases are defined in rules/config/eventkey_alias.txt
. If you are not getting the correct data in the details
(Alert details
) message, and instead are getting n/a
(not available) or if the selection in your detection logic is not working properly, then you may need to update rules/config/eventkey_alias.txt
with a new alias.
XML elements may have attributes set by adding a space to the element. For example, Name
in Provider Name
below is an XML attribute of the Provider
element.
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-a5ba-3e3b0328c30d}'/>
<EventID>4672</EventID>
<EventRecordID>607469</EventRecordID>
<Channel>Security</Channel>
<Security />
</System>
</Event>
To specify XML attributes in an eventkey, use the format {eventkey}_attributes.{attribute_name}
. For example, to specify the Name
attribute of the Provider
element in a rule file, it would look like this:
detection:
selection:
Channel: Security
EventID: 4672
Event.System.Provider_attributes.Name: 'Microsoft-Windows-Security-Auditing'
condition: selection
Hayabusa can perform grep searches in Windows event log files by not specifying any eventkeys.
To do a grep search, specify the detection as shown below. In this case, if the strings mimikatz
or metasploit
are included in the Windows Event log, it will match. It is also possible to specify wildcards.
detection:
selection:
- mimikatz
- metasploit
Note: Hayabusa internally converts Windows event log data to JSON format before processing the data so it is not possible to match on XML tags.
Windows event logs are divided into two parts: the System
part where the fundamental data (Event ID, Timestamp, Record ID, Log name (Channel)) is written, and the EventData
or UserData
part where arbitrary data is written depending on the Event ID.
One problem that arises often is that the names of the fields nested in EventData
are all called Data
so the eventkeys described so far cannot distinguish between SubjectUserSid
and SubjectUserName
.
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<EventID>5379</EventID>
<TimeCreated SystemTime='2021-10-20T10:16:18.7782563Z' />
<EventRecordID>607469</EventRecordID>
<Channel>Security</Channel>
<Security />
</System>
<EventData>
<Data Name='SubjectUserSid'>S-1-1-11-1111111111-111111111-1111111111-1111</Data>
<Data Name='SubjectUserName'>hayabusa</Data>
<Data Name='SubjectDomainName'>DESKTOP-HAYABUSA</Data>
<Data Name='SubjectLogonId'>0x11111111</Data>
</EventData>
</Event>
To deal with this problem, you can specify the value assigned in Data Name
. For example, if you want to use SubjectUserName
and SubjectDomainName
in the EventData as a condition of a rule, you can describe it as follows:
detection:
selection:
Channel: System
EventID: 7040
Event.EventData.SubjectUserName: hayabusa
Event.EventData.SubjectDomainName: DESKTOP-HAYBUSA
condition: selection
Some of the tags nested in EventData
do not have a Name
attribute.
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<EventID>5379</EventID>
<Channel>Security</Channel>
<Security />
</System>
<EventData>
<Data>Available</Data>
<Data>None</Data>
<Data>NewEngineState=Available PreviousEngineState=None (...)</Data>
</EventData>
</Event>
To detect an event log like the one above, you can specify an eventkey named Data
.
In this case, the condition will match as long as any one of the nested Data
tags equals None
.
detection:
selection:
Channel: Security
EventID: 5379
Data: None
condition: selection
Some events will save their data to field names all called Data
like in the previous example.
If you specify %Data%
in details:
, all of the data will be outputted in an array.
For example:
["rundll32.exe","6.1.7600.16385","4a5bc637","KERNELBASE.dll","6.1.7601.23392","56eb2fb9","c0000005"]
If you want to print out just the first Data
field data, you can specify %Data[1]%
in your details:
alert string and only rundll32.exe
will be outputted.
A pipe character can be used with eventkeys as shown below for matching strings.
All of the conditions we have described so far use exact matches, but by using field modifiers, you can describe more flexible detection rules.
In the following example, if a value of Data
contains the string EngineVersion=2
, it will match the condition.
detection:
selection:
Channel: 'Windows PowerShell'
EventID: 400
Data|contains: 'EngineVersion=2'
condition: selection
String matches are case insensitive. However, they become case sensitive whenever |re
or |equalsfield
are used.
|base64offset|contains
: Data will be encoded to base64 in three different ways depending on its position in the encoded string. This modifier will encoded a string to all three variations and check if the string is encoded somewhere in the base64 string.|cidr
: Matches on a IPv4 or IPv6 CIDR notation (Ex: 192.0.2.0/24
)|contains
: Checks if a word is contained in the data|contains|all
: Checks if multiple words are contained in the data|contains|windash
: Will check the string as-is, as well as convert the first -
character to a /
character and check that variation as well.|contains|all|windash
: Same as |contains|windash
but all of the keywords need to be present.|startswith
: Checks the string from the beginning|endswith
: Checks the end of the string|re
: Use regular expressions. (We are using the regex crate so please out the documentation at https://docs.rs/regex/latest/regex/#syntax to learn how to write correct regular expressions.)
Caution: Regular expression syntax in sigma rules is still not defined so some sigma rules may not match correctly if they differ from the Rust regex syntax.
'|all':
: This field modifier is different from those above because it does not get applied to a certain field but to all fields.In this example, both strings Keyword-1
and Keyword-2
need to exist but can exist anywhere in any field:
detection:
keywords:
'|all':
- 'Keyword-1'
- 'Keyword-2'
condition: keywords
The following modifiers are not in the sigma specification but have been added for very specific use cases.
|equalsfield
: Check if two fields have the same value. You can use not
in the condition
if you want to check if two fields are different.|endswithfield
: Check if the field on the left ends with the string of the field on the right. You can use not
in the condition
if they are different.The following modifiers are currently not supported so we do not include any rules from the sigma repository that use them:
expand
gt
gte
lt
lte
utf16 / utf16le / utf16be / wide
Wildcards can be used in eventkeys. In the example below, if ProcessCommandLine
starts with the string "malware", the rule will match.
The specification is fundamentally the same as sigma rule wildcards so will be case insensitive.
detection:
selection:
Channel: Security
EventID: 4688
ProcessCommandLine: malware*
condition: selection
The following two wildcards can be used.
*
: Matches any string of zero or more characters. (Internally it is converted to the regular expression .*
)?
: Matches any single character. (Internally converted to the regular expression .
)About escaping wildcards:
*
and ?
) can be escaped by using a backslash: \*
, \?
.\\*
or \\?
.Eventkeys can be nested with specific keywords. In the example below, the rule will match if the following are true:
ServiceName
is called malicious-service
or contains a regular expression in ./rules/config/regex/detectlist_suspicous_services.txt
.ImagePath
has a minimum of 1000 characters.ImagePath
does not have any matches in the allowlist
.detection:
selection:
Channel: System
EventID: 7045
ServiceName:
- value: malicious-service
- regexes: ./rules/config/regex/detectlist_suspicous_services.txt
ImagePath:
min_length: 1000
allowlist: ./rules/config/regex/allowlist_legitimate_services.txt
condition: selection
Currently, the following keywords can be specified:
value
: matches by string (wildcards and pipes can also be specified).min_length
: matches when the number of characters is greater than or equal to the specified number.regexes
: matches if one of the regular expressions in the file that you specify in this field matches.allowlist
: rule will be skipped if there is any match found in the list of regular expressions in the file that you specify in this field.Hayabusa has two built-in regular expression files used for the ./rules/hayabusa/default/alerts/System/7045_CreateOrModiftySystemProcess-WindowsService_MaliciousServiceInstalled.yml
file:
./rules/config/regex/detectlist_suspicous_services.txt
: to detect suspicious service names./rules/config/regex/allowlist_legitimate_services.txt
: to allow legitimate servicesFiles defined in regexes
and allowlist
can be edited to change the behavior of all rules that reference them without having to change any rule file itself.
You can also use different detectlist and allowlist textfiles that you create.
Please refer to the built-in ./rules/config/regex/detectlist_suspicous_services.txt
and ./rules/config/regex/allowlist_legitimate_services.txt
when creating your own.
The null
keyword can be used to check if field does not exist.
detection:
selection:
EventID: 4688
ProcessCommandLine: null
condition: selection
Note: This is different from ProcessCommandLine: ''
which checks if the value of a field is empty.
With the notation we explained above, you can express AND
and OR
logic but it will be confusing if you are trying to define complex logic.
When you want to make more complex rules, you should use the condition
keyword as shown below.
detection:
SELECTION_1:
EventID: 3
SELECTION_2:
Initiated: 'true'
SELECTION_3:
DestinationPort:
- '4444'
- '666'
SELECTION_4:
Image: '*\Program Files*'
SELECTION_5:
DestinationIp:
- 10.*
- 192.168.*
- 172.16.*
- 127.*
SELECTION_6:
DestinationIsIpv6: 'false'
condition: (SELECTION_1 and (SELECTION_2 and SELECTION_3) and not ((SELECTION_4 or (SELECTION_5 and SELECTION_6))))
The following expressions can be used for condition
.
{expression1} and {expression2}
: Require both {expression1} AND {expression2}{expression1} or {expression2}
: Require either {expression1} OR {expression2}not {expression}
: Reverse the logic of {expression}( {expression} )
: Set precedance of {expression}. It follows the same precedance logic as in mathematics.In the above example, selection names such as SELECTION_1
, SELECTION_2
, etc... are used but they can be named anything as long as they only contain the following characters: a-z A-Z 0-9 _
However, please use the standard convention of
selection_1
,selection_2
,filter_1
,filter_2
, etc... to make things easy to read whenever possible.
Many rules will result in false positives so it is very common to have a selection for signatures to search for but also a filter selection to not alert on false positives. For example:
detection:
selection:
Channel: Security
EventID: 4673
filter:
- ProcessName: C:\Windows\System32\net.exe
- ProcessName: C:\Windows\System32\lsass.exe
- ProcessName: C:\Windows\System32\audiodg.exe
- ProcessName: C:\Windows\System32\svchost.exe
- ProcessName: C:\Windows\System32\mmc.exe
- ProcessName: C:\Windows\System32\net.exe
- ProcessName: C:\Windows\explorer.exe
- ProcessName: C:\Windows\System32\SettingSyncHost.exe
- ProcessName: C:\Windows\System32\sdiagnhost.exe
- ProcessName|startswith: C:\Program Files
- SubjectUserName: LOCAL SERVICE
condition: selection and not filter
The condition
keyword described above implements not only AND
and OR
logic, but is also able to count or "aggregate" events.
This function is called the "aggregation condition" and is specified by connecting a condition with a pipe.
In this password spray detection example below, a conditional expression is used to determine if there are 5 or more TargetUserName
values from one source IpAddress
within a timeframe of 5 minutes.
detection:
selection:
Channel: Security
EventID: 4648
condition: selection | count(TargetUserName) by IpAddress > 5
timeframe: 5m
Aggregation conditions can be defined in the following format:
count() {operator} {number}
: For log events that match the first condition before the pipe, the condition will match if the number of matched logs satisfies the condition expression specified by {operator}
and {number}
.{operator}
can be one of the following:
==
: If the value is equal to the specified value, it is treated as matching the condition.>=
: If the value is greater than or equal to the specified value, the condition is considered to have been met.>
: If the value is greater than the specified value, the condition is considered to have been met.<=
: If the value is less than or equal to the specified value, the condition is considered to have been met.<
: If the value is less than the specified value, it will be treated as if the condition is met.{number}
must be a number.
timeframe
can be defined in the following:
15s
: 15 seconds30m
: 30 minutes12h
: 12 hours7d
: 7 days3M
: 3 monthsby
keyword. Example: selection | count() > 10
If
selection
matches more than 10 times within the timeframe, the condition will match.
by
keyword. Example: selection | count() by IpAddress > 10
selection
will have to be true more than 10 times for the sameIpAddress
.
by
keyword. Example: selection | count(TargetUserName) > 10
If
selection
matches andTargetUserName
is different more than 10 times within the timeframe, the condition will match.
by
keyword. Example: selection | count(Users) by IpAddress > 10
For the same
IpAddress
, there will need to be more than 10 differentTargetUserName
in order for the condition to match.
This is the most basic pattern: count() {operator} {number}
. The rule below will match if selection
happens 3 or more times.
count() by {eventkey} {operator} {number}
: Log events that match the condition
before the pipe are grouped by the same {eventkey}
. If the number of matched events for each grouping satisfies the condition specified by {operator}
and {number}
, then the condition will match.
count({eventkey}) {operator} {number}
: Counts how many different values of {eventkey}
exist in the log event that match the condition before the condition pipe. If the number satisfies the conditional expression specified in {operator}
and {number}
, the condition is considered to have been met.
count({eventkey_1}) by {eventkey_2} {operator} {number}
: The logs that match the condition before the condition pipe are grouped by the same {eventkey_2}
, and the number of different values of {eventkey_1}
in each group is counted. If the values counted for each grouping satisfy the conditional expression specified by {operator}
and {number}
, the condition will match.
The details output for count rules is fixed and will print the original count condition in [condition]
followed by the recorded eventkeys in [result]
.
In the example below, a list of TargetUserName
usernames that were being bruteforced followed by the source IpAddress
:
[condition] count(TargetUserName) by IpAddress >= 5 in timeframe [result] count:41 TargetUserName:jorchilles/jlake/cspizor/lpesce/bgalbraith/jkulikowski/baker/eskoudis/dpendolino/sarmstrong/lschifano/drook/rbowes/ebooth/melliott/econrad/sanson/dmashburn/bking/mdouglas/cragoso/psmith/bhostetler/zmathis/thessman/kperryman/cmoody/cdavis/cfleener/gsalinas/wstrzelec/jwright/edygert/ssims/jleytevidal/celgee/Administrator/mtoussain/smisenar/tbennett/bgreenwood IpAddress:10.10.2.22 timeframe:5m
The timestamp of the alert will be the time from the first event detected.
When possible, always specify the Channel
or ProviderName
name and the EventID
number. By default, only the event IDs listed in ./rules/config/target_event_IDs.txt
will be scanned so you may need to add a new EventID
number to this file if the EID is not already in there.
Please do not use multiple selection
or filter
fields and excessive grouping when it is not needed. For example:
detection:
SELECTION_1:
Channnel: Security
SELECTION_2:
EventID: 4625
SELECTION_3:
LogonType: 3
FILTER_1:
SubStatus: "0xc0000064" #Non-existent user
FILTER_2:
SubStatus: "0xc000006a" #Wrong password
condition: SELECTION_1 and SELECTION_2 and SELECTION_3 and not (FILTER_1 or FILTER_2)
detection:
selection:
Channel: Security
EventID: 4625
LogonType: 3
filter:
- SubStatus: "0xc0000064" #Non-existent user
- SubStatus: "0xc000006a" #Wrong password
condition: selection and not filter
section_basic
section and other selections with meaningful names after section_
and filter_
. Also, please write comments to explain anything difficult to understand. For example:detection:
Takoyaki:
Channel: Security
EventID: 4648
Naruto:
TargetUserName|endswith: "$"
IpAddress: "-"
Sushi:
SubjectUserName|endswith: "$"
TargetUserName|endswith: "$"
TargetInfo|endswith: "$"
Godzilla:
SubjectUserName|endswith: "$"
Ninja:
TargetUserName|re: "(DWM|UMFD)-([0-9]|1[0-2])$"
IpAddress: "-"
Daisuki:
- ProcessName|endswith: "powershell.exe"
- ProcessName|endswith: "WMIC.exe"
condition: Takoyaki and Daisuki and not (Naruto and not Godzilla) and not Ninja and not Sushi
detection:
selection_basic:
Channel: Security
EventID: 4648
selection_TargetUserIsComputerAccount:
TargetUserName|endswith: "$"
IpAddress: "-"
filter_UsersAndTargetServerAreComputerAccounts: #Filter system noise
SubjectUserName|endswith: "$"
TargetUserName|endswith: "$"
TargetInfo|endswith: "$"
filter_SubjectUserIsComputerAccount:
SubjectUserName|endswith: "$"
filter_SystemAccounts:
TargetUserName|re: "(DWM|UMFD)-([0-9]|1[0-2])$" #Filter out default Desktop Windows Manager and User Mode Driver Framework accounts
IpAddress: "-" #Don't filter if the IP address is remote to catch attackers who created backdoor accounts that look like DWM-12, etc..
selection_SuspiciousProcess:
- ProcessName|endswith: "powershell.exe"
- ProcessName|endswith: "WMIC.exe"
condition: selection_basic and selection_SuspiciousProcess and not (selection_TargetUserIsComputerAccount
and not filter_SubjectUserIsComputerAccount) and not filter_SystemAccounts and not filter_UsersAndTargetServerAreComputerAccounts
We have created a backend for sigmac to convert rules from sigma to hayabusa format here.
The documentation for how to use it is here.
You can recieve the latest news about Hayabusa, rule updates, other Yamato Security tools, etc... by following us on Twitter at @SecurityYamato.