Rule syntax
A rule is a set of expressions defined using XML-based language.
ESET Inspect Web Console contains a pre-defined set of rules, but you can add and edit your own rules.
The general body structure of a rule is:
<rule> <definition> <ancestor></ancestor> <parentprocess></parentprocess> <process></process> <operations> <operation></operation> </operations> </definition> <description> <name></name> <category></category> <explanation></explanation> <os></os> <mitreattackid></mitreattackid> <maliciousCauses></maliciousCauses> <benignCauses></benignCauses> <recommendedActions></recommendedActions> </description> <maliciousTarget name=""/> <actions> <action name="action" /> </actions> </rule> |
Definition Tag
ancestor—can take an additional attribute:
•distance—specifies the actual distance from the current process of the ancestor being matched, i.e., 1 is the parent process, 2 grandparent, ... . If unspecified, the property is matched against all process ancestors
•unique—enables the ancestor tag to remove duplicate processes in the ancestor tree. For example, the malware creates multiple instances of the same process to avoid detection (explorer -> cmd -> cmd -> cmd -> malware), and this attribute will get rid of these duplications (explorer -> cmd -> malware)
Process and parentprocess
The process part lets security engineers restrict events to a specific process; therefore, you can write rules like "Outlook creates EXE file". If the process element is empty, parentprocess and operations are evaluated for all the processes.
The parentprocess part is similar to the process but allows security engineers to test parent process attributes. This enables rules like "PowerShell, started by Word, connects to the internet".
process, parentprocess, ancestor and operation use an expression element to describe a logical expression which is evaluated to check if a detection should be triggered. An expression consists of conditions and logical operators. A condition checks the value of some property, and logical operators group these conditions into logical expressions.
Expression example:
<operator type="and"> <condition component="FileItem" property="Path" condition="notstarts" value="%SYSTEM%" /> <operator type="or"> <condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="svchost" /> <condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="smss" /> <condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="lsass" /> <condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="csrss" /> <condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="wininit" /> <condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="services" /> <condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="winlogon" /> <condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="system" /> <condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="userinit" /> <condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="conhost" /> </operator> </operator> |
Operations
The operations part defines which operations executed by a process raise the detection. If empty, the detection is triggered when the process generates an event.
Operations are defined using an operation element with a type attribute and an expression element.
<operation type="WriteFile">Expression</operation>
For the complete list of supported operations, see the Operations topic.
Operator
Supported logical operators are: AND, OR, and NOT. Logical operators can be nested. Therefore, a logical operator can be an argument of another logical operator. Apart from logical operators, a condition element can be used as an argument for logical operators. You can use the operator tag as shown in this example:
<process> <operator type ="AND"> <condition component ="FileItem" property ="Path" condition ="starts" value ="% TEMP %"/> <condition component ="FileItem" property ="FileName" condition ="is" value ="svchost"/> </operator> </process> |
Condition elements consist of three parts:
•Property of operation's argument or process
•A value specified by the rule's author
•Relationship between the value and the property
Properties are hierarchically grouped into "components".
Detections There are three levels of severity: 1–39 > Info, 40–69 > Warning, and 70–100 > Threat.
Property types and their relations (condition attributes) are:
|
is(not)set |
is(not) |
is(not)empty |
(not)starts |
(not)contains |
(not)ends |
less, lessOrEqual, greater, greaterOrEqual |
---|---|---|---|---|---|---|---|
String |
✔ |
✔ |
✔ |
✔ |
✔ |
✔ |
|
Int |
✔ |
✔ |
|
|
✔ |
|
✔ |
Value |
✔ |
✔ |
✔ |
|
|
|
|
Bool |
✔ |
✔ |
|
|
|
|
|
Date |
✔ |
✔ |
|
|
|
|
✔ |
Set of Strings |
✔ |
|
✔ |
|
✔ |
|
|
IPv4 Address |
✔ |
✔ |
✔ |
|
|
|
|
IPv6 Address |
✔ |
✔ |
✔ |
|
|
|
|
Set of IPv4 Addresses |
✔ |
|
✔ |
|
✔ |
|
|
Set of IPv6 Addresses |
✔ |
|
✔ |
|
✔ |
|
|
Description Tag
Description is mandatory and must contain a name and category, but the rest is optional. It is helpful to define the fields listed below because they appear in the Detections details of ESET Inspect
name—unique name of the rule. It is shown in the list of rules.
category—allows you to categorize rules. You can specify your own categories.
explanation—explains the reason why the rule is triggered
os—this tag contains the operating system to which the rule applies. Possible values are: Windows, Linux, OSX, ANY
mitreattackid—contains the id of the MITRE ATT&CK®
maliciousCauses—describes the malicious causes of the event or the change that triggered the rule
benignCauses—describes the benign causes of the event or the change that triggered the rule
recommendedActions—describes the recommended actions to be taken by security engineers. A user can use the following markdown:
•[navigation:computer_details]—the default name shown to the user will be Computer Details
•[navigation:executable_details]—the default name shown to the user will be Executable Details
•[navigation:process_details]—the default name shown to the user will be Process Details
•[remediation:shutdown]—the default name shown to the user will be Shutdown Computer
•[remediation:reboot]—the default name shown to the user will be Reboot Computer
•[remediation:kill]—the default name shown to the user will be Kill Process
•[remediation:block]—the default name shown to the user will be Block Hash
•[misc:download]—the default name shown to the user will be Download file
Additionally, each command can display alternative text instead of the default one. To specify alternative text to display, follow the command with pipe sign and text. For example, [navigation:computer_details|GoToComDet] will display GoToComDet instead of default Computer Details. For other examples of use, search for the rule c0601 in the Detection rules tab in the Audit main window.
guid—used for internal rules. External rules have guid automatically generated. It is used to uniquely identify rules during export/import.
maliciousTarget Tag
You can use the maliciousTarget tag to specify the target that will be affected by user actions. For example, when you select block executable, the changes depend on the maliciousTarget. If you specify maliciousTarget as current or parent, the block executable user action will change to blockProcessExecutable or blockParentProcessExecutable, respectively. It does not change the behavior of the Actions Tag. Possible values are current, module, none and parent.
The maliciousProcess tag has been replaced by the maliciousTarget tag. It is still in legacy support but, we recommend using the maliciousTarget tag.
Actions Tag
Actions tag allows you to specify a set of actions that are executed when the rule is triggered. For the complete list of supported actions, see the Actions topic.
You can put actions into a single action element:
<action name="BlockProcessExecutable"/>
Or stack multiple action elements into single actions element (as shown in the following example):
<actions> <action name="BlockProcessExecutable"/> … </actions> |
Multiple actions can be triggered from a single rule.