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:

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:

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

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:

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:

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

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):

Multiple actions can be triggered from a single rule.

˄˅