ESET Online Help

Search
Select the category
Select the topic

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.

Example of an expression:

<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 this part is empty, the detection is triggered as soon as 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>

The following operation types are supported:

CodeInjection—a process was subject to some form of code injection

CreateNamedPipe—a named pipe was created

CreateProcess—a process was created

DeleteFile—a file was deleted

Detection—an event was triggered on client-side antivirus

DnsRequest—a DNS request was made ( usually IP > domain, domain > IP)

HttpRequest—an HTTP request was made

LoadDLL—a DLL was loaded

LoadDriver—a driver or kernel module was loaded

ModuleDrop—an executable was dropped

MultipleFilesChanged—process modified multiple files

OpenProcess—added a new rule attribute, which triggers when a process is opened. Only the open process to lsass.exe is monitored

ReadFile—triggered when a monitored file was read. Monitored files refer to those which contain either sensitive information or stored credentials, for example, stored browser passwords, stored FTP clients passwords, AD database and so on.

RegDeleteKey—a registry key was deleted

RegDeleteValue—the value of the registry was deleted

RegRenameKey—a registry key was renamed

RegSetValue—a registry key was altered

RenameFile—a file was renamed

Scripts—a script exposed by AMSI was executed

SetFileAttribute—a file attribute was set

SystemApiCall—a system function was called

TcpIpAccept—an incoming TCP/IP connection was accepted

TcpIpConnect—an outbound TCP/IP connection was made

TcpIpProtocolIdentified—on top of TCP/IP connection, describes the protocol used.

TruncateFile—a file was truncated, this operation is reported only on Posix systems

UnloadDriver—a driver or kernel was unloaded

UserActivate—the user was activated

UserAddToGroup—the user was added to the group

UserCreate—a new user was created

UserDisable—the user was disabled

UserLogin—the user logged in

UserLogout—the user logged out

UserRemove—the user was removed

UserRemoveFromGroup—the user was removed from the group

WmiExecution—WMI execution event was triggered

WmiPersistence—WMI persistence event was called

WmiQuery—WMI query was executed on a computer

WriteFile—a file was written to


important

Earlier versions of Windows do not produce WMI events. This functionality has been available since Windows 10 version 1803.

Some of the events provide only partial information:

File write events—only the first file change is recorded (This is per process. If two processes change the same file, both changes are recorded)

Registry related events—only the first registry key change is recorded (first time by a process)

DLLLoad—only DLLs that are not whitelisted by AV are recorded

TcpIp events—only the first connection is recorded (first time by a process)

Http events—only the first request is recorded (first time by a process)

ModuleDrop (a.k.a PEDrop)—it is reported only for the first drop of a given module (first time on a computer)

AmsiTriggerEvent—only the first execution is recorded (first time on a computer)

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".

The Severity of rules defines the way a rule is displayed in the Detections screen. 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. Action names are:

BlockModule—blocks DLL that is being loaded in the LoadDll event

BlockParentProcessExecutable—blocks a parent process hash (only if not trusted or LiveGrid® info is missing)

BlockProcessExecutable—blocks a process hash (ban hash via the rule, only if not trusted or LiveGrid® info is missing)

BlockProcessSuspiciousModules—blocks a module marked as suspicious by MarkModuleSuspicious action

CleanAndBlockModule—blocks dropped module in the ModuleDrop event

CleanAndBlockParentProcessExecutable—cleans and blocks a parent process hash (only if not trusted or LiveGrid® info is missing)

CleanAndBlockProcessExecutable—cleans and blocks a process hash (only if not trusted or LiveGrid® info is missing)

CleanAndBlockProcessSuspiciousModules—cleans and blocks a module marked as suspicious by MarkModuleSuspicious action

DropEvent—drops an event that triggered the rule

HideCommandLine—removes command line string from a process

IsolateFromNetwork—isolates the computer from the network

KillParentProcess—kills parent of the running process that triggered the detection (only if not trusted or LiveGrid® info is missing)

KillProcess—kills running process that triggered the detection (only if not trusted or LiveGrid® info is missing)

LogOutUser—logs out the user from the operating system

MarkAsCompromised—the process that triggered the rule will be marked as compromised. This status is visible in the process details view in ESET Inspect Web Console.

MarkAsResolved—marks the currently evaluated detection as resolved

MarkAsScript—marks an executable as a script

MarkModuleSuspicious—marks a module as suspicious

Reboot—reboots computer that triggered the detection

ReportIncident—creates incident when the detection is triggered. You can aggregate detections into one incident by time, computers or both using aggregateOn parameter. To specify time aggregation you can use aggregationParameter

Shutdown—shutdowns computer that triggered the detection

StoreEvent—stores events that triggered the detection from this rule

SubmitModuleToLiveGuard—submits module to ESET LiveGuard

SubmitParentToLiveGuard—submits parent of the executable that triggered the detection to ESET LiveGuard

SubmitToLiveGuard—submits executable that triggered the detection to ESET LiveGuard

TriggerDetection—if you do not specify actions in the actions tag field, this action is executed by default and the detection triggers in ESET Inspect. If other actions are specified, and you still want to trigger detection, you must add this action


important

Some of the actions are disabled for Linux and macOS:

IsolateFromNetwork

KillProcess

KillParentProcess

SubmitModuleToLiveGuard

SubmitParentToLiveGuard

SubmitToLiveGuard

You can put actions into a single action element:

<action name="BlockProcessExecutable"/>

Or stack multiple actions into actions element (as shown in the following example):

<actions>

<action name="BlockProcessExecutable"/>

</actions>

Multiple actions can be triggered from a single rule.