Skip to content

Alerting Guide


1.1 Alerting Mode

CyberQuest’s alerting feature is a completely adaptable feature that can be set up and edited by the end-user:

• The event that triggers the alert can be user-defined to respond to the most specific events need, ensuring great accuracy and reducing false alerting to a minimum. This can be done via the Settings menu item Alt text selecting the “Real Time alerts management” tab.

Alt text

Pic.2.11.1: Navigating to alerts tab

In this tab, users can add, edit and delete alerts:

  • To add an alert, click the “New Alert” button in the Actions menu.

Alt text

Pic.2.11.2: Creating a new alert

Alt text

Pic.2.11.3: Scheduled alert

  • Each alert name description and added date is shown in the alerts management tab and individual alerts can be edited by pressing the “edit” Alt text button or deleted, by pressing the “delete” Alt text button .
  • When pressing the “Edit” button, an “Edit Alert” window will be opened where the alert can either be edited as a standalone alert or composed with one or more alerts to apply more filters depending on the user necessity. This is one of two ways that an alert can be set up.

Alt text

Pic.2.11.4: Editing alerts

• The second way that users can add alerts is from a report: Select the desired report from the Reports tab and click the “Add as alert” button.

Alt text

Pic.2.11.5: Adding alerts

1.1.1 Configuring custom reports

If one of the standard definitions for reports or alerts doesn’t quite fit the user needs, the alert can be customized for increased accuracy, by clicking the “compose” Alt text button :

Alt text

Pic. Customizing alerts

First the user needs to set the “Time span” in which the composed alerts can occur, filter data for each alert to increase/decrease the number of events that will be correlated with the composed alert, the next report definition (the events that will answer to this report will be correlated and filtered to match the first alert’s events), “join rules” the explicit data from the previous events that the user needs to use for the next alert definition.

1.1.2 Configuring real time alerts examples

1.1.3 Alert Templates

Logon alert example

This scenario presumes setting up an alert for a specific user for two failed logons during a 60 seconds time interval.

Step 1. Access reporting mode by pressing the “Reports” icon:

Alt text

Pic. Reports icon

Step 2. Selecting the report definition. In the current scenario, the report definition is “Windows failed logons”: - The user must browse to the desired report from the report tree on the left side of the page. In this case, select the “Windows Failed Logons” report then click “Add as Alert”.

Alt text

Pic. Selecting desired report

  • In the “Filter data” filed, type the username of the person who’s failed logons we want to be alerted on: UserName:"usertest", in the ‘time span’ form, type the time interval that the alert will be active for (in this case if the user fails a logon and doesn’t fail again for at least 60 seconds, the first event will be deleted, thus avoiding sending false alerts), in the “Join Rules” type “UserName=E1.UserName” to provide the composed alert the information that it needs to look for, and finally in the description a short description of what this alert does. Finally, after checking the information click “Submit”. A short message will prompt the user that the alert has been registered.

Alt text

Pic. Added alert message

Alt text

Pic. Add New Alert – Windows Failed Logons

Step 3.

The alert can be set up to send an email or an SMS when it occurs, but alternatively the alerts are shown in the alerts tab from the top menu:

Alt text

Pic. Alerts tab

The alerts are displayed like regular events. In this example, the alert was set up to trigger when the “usertest” user will fail to login twice. Because that is a result of combining the same type of response action, two alerts will be triggered: The first one is triggered when a failed logon occurs for the “usertest” user (the first alert that we composed) and the second alert (the one we wanted to configure) will trigger when a second logon event occurs and the username is “usertest” (This was previously set up in the “join rules” part of composing alerts) The results are the following:

Alt text

Pic. Alerts Configuring summary alerts examples

Logon alert example

The alerting scenario will be: notify the security office if a user accesses Facebook more than 50 times a day.

Step 1. Creating the report with the alert definition (basically a report that shows all the events with the necessary filters, in this case, Facebook website). This custom report once executed till find all events that contain the word “Facebook” in them also with the relevant information (IP address, date, time etc.). To do this the necessary actions are as follows:

  • Click “Reports” Alt text button and common practice would be to make a new folder for this and any following custom reports so click “New Folder” Alt text from the reports tree on top left. A popup will appear prompting for the new folder name. In this case the name is “Custom” click “Save”.

Alt text

Pic. Create a New Folder in Reports Tab

Select this new folder and create a new report by clicking the “New Report” button.

Alt text

Pic. New Folder in Reports Tab

1.1.4 Alert Templates

To create a new alert template navigate to any alert management (summary or real time) from the settings menu

Alt text

Click “New alert template” Alt text. This will open an alert template form window.

Real-time alert templates: Alt text Keywords enable extracting useful information from the events that trigger the alert.

Alt text

Real-time alert templates can extract any of the event fields being encapsulated by % signs (Ex: Computer, Username, LocalTime, S fields etc.)

For example :

The %E1.UserName% has logged on to %E1.Computer% etc.

The Event dropdown list is used for multi-step alert (that involves more than one event) to select what event we are referring to, in the case of a single event E1.

Summary alert templates:

Alt text

The possible keywords are:

Setting Description
%AlertGeneratedTime% the creation time of the alert
%SummaryOnLevelX% the field which was selected for summary on level X
%SummaryOnLevelXMatch% the value of the field matched on level X (if summary type is avg or sum, last level doesn't have a match, use SummaryValue instead)
SummaryType summary type of the alert
SummaryValue the summary value (for avg and sum types)
Threshold The alerts’ defined threshold
TimeIntervalBack time interval
NumberOfEvents events included in the alert
EventAnalysisSection count of events per time intervals
First100EventsSection list of events (first 100 events list, including the fields selected from below)
AlertActionsSection section with actions for alert (view, acknowledge, false positive, delete)

Alt text

1.1.5 DTS Objects

Data Transformation Service Objects are JavaScript objects that are compiled at runtime. They are used for log enhancement, enrichment, decision making, alerting and other functionality.

A CyberQuest event has the following format:

  "EventID": "1-2000000000",    
  "LocalTime": "yyy-mm-dd hh:mm:ss.fff",
  "GMT": " yyy-mm-dd hh:mm:ss.fff",",
  "UserName": "blacklisted.user1",
  "UserDomain": "Demo",
  "SrcIP": "",
  "DestIP": "",
  "VersionMajor": "6",
  "VersionMinor": "2",
  "Computer": "A-PC.Demo.local",
  "Source": "Microsoft-Windows-Security-Auditing",
  "EventLog": "Security",
  "Category": "Logon",
  "EventType": "8",
  "Description": "An account was successfully logged on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-0-0\r\n\tAccount Name:\t\t-\r\n\tAccount Domain:\t\t-\r\n\tLogon ID:\t\t0x0\r\n\r\nLogon Type:\t\t\t3\r\n\r\nImpersonation Level:\t\tImpersonation\r\n\r\nNew Logon:\r\n\tSecurity ID:\t\tS-1-5-21-1009658894-4016096118-1013530418-1275\r\n\tAccount Name:\t\tblacklisted.user1\r\n\tAccount Domain:\t\tDemo\r\n\tLogon ID:\t\t0xC2C9FA762\r\n\tLogon GUID:\t\t{00000000-0000-0000-0000-000000000000}\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x0\r\n\tProcess Name:\t\t-\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\tRemoteWorkstation\r\n\tSource Network Address:\t10.10.10.10\r\n\tSource Port:\t\t44214\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tNtLmSsp \r\n\tAuthentication Package:\tNTLM\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\tNTLM V1\r\n\tKey Length:\t\t128\r\n\r\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\r\n\r\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\r\n\r\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.",
  "S1": "S-1-0-0",
  "S2": "-",
  "S3": "-",
  "S4": "0x0",
  "S5": "S-1-5-21-1009658894-4016096118-1013530418-1275",
  "S6": "blacklisted.user1",
  "S7": "Demo",
  "S8": "0xc2c9fa762",
  "S9": "3",
  "S10": "NtLmSsp ",
  "S11": "NTLM",
  "S12": "RemoteWorkstation",
  "S13": "{00000000-0000-0000-0000-000000000000}",
  "S14": "-",
  "S15": "NTLM V1",
  "S16": "128",
  "S17": "0x0",
  "S18": "-",
  "S19": "",
  "S20": "44214",
  "S21": "%%1833",
  "S22": "",
  "S23": "",
  "S24": "",
  "S25": "",
  "S26": "",
  "S27": "",
  "S28": "",
  "S29": "",
  "S30": "",
  "S31": "",
  "S32": "",
  "S33": "",
  "S34": "",
  "S35": "",
  "S36": "",
  "S37": "",
  "S38": "",
  "S39": "",
  "S40": "",
  "S41": "",
  "S42": "",
  "S43": "",
  "S44": "",
  "S45": "",
  "S46": "",
  "S47": "",
  "S48": "",
  "S49": "",
  "S50": "",
  "S150": ""

S1-150 are extra string fields and are generally used to store extracted useful information from the event. The purpose of this is to correlate that use full information in dashboards and set alert triggers.

EXAMPLE: We can use a DTS object to check a dynamic or static list for blacklisted or unknown users. We use the getter function to check if the current user is part of a blacklist or a whitelist.

Case 1: the user is part of a blacklist : we can raise an alert that a blacklisted user has logged on to a computer with the RaiseAsAlert function

Case 2: the user is part of a whitelist : we do nothing(from an alerting point of view) just parse useful data if needed

Case 3: the user is not in either of the lists and we want to add unknown users to a blacklist by default . That can be achieved by using the setter function.

In order for a DTS object to receive an event as parameter (for an event to be parsed) the following 3 preconditions need to be followed:

  1. Create a DTS object Alt text Alt text A new DTS object can be created from the setting menu by navigating to: “Settings”->”DTS Objects”->”New DTS Object”

  2. Create a Filter rule
    Alt text

A new Filter rule can be created from the setting menu by navigating to: “Settings”->”Filter Rules”->”New Filterrule”

The filter rule is a set of conditions that received events have to meet in order to be passed through one or more DTS Objects (parsed).

  1. Create a DA rule (data acquisition rule) Alt text

A new DA rule can be created from the setting menu by navigating to: “Settings”->”DA Rules”->”New DA Rule”

The DA rule is a decision making mechanism that sends Events (data) that meet criteria set by Filter rules through DTS objects and to Data Storage service and/or Data Analyzer service. DTS Objects Built-in methods

DTS objects have custom built-in functions created with the purpose of interacting with Redis lists or with the alerting module. The functions are:


Inserts values in Redis lists Parameters: [list_name],[list_key],[list_value][TTL]

Example: setter(‘UserLists’,this.inputEvent.UserName,this.inputEvent.SrcIP,360);

In this example the DTS object looks in ‘UserLists’ for the event’s UserName field and


If it already exists it changes its value ( SrcIP field) and resets the list entry duration to 360 seconds,


If it does not exist, it creates a new entry with UserName key and SrcIP value that has a 360 second expiration date.


Gets values from Redis lists. Parameters: [list_name],[list_key]

Example: getter ('IPLists',this.inputEvent.SrcIP); In this example the DTS object looks in 'IPLists' list for the current event’s SrcIP field and gets associated value.

RaiseAsAlert Generates an alert event with the desired settings. Parameters: event_list,[alert_name],[email_address(es)],[security_score],[security_level], [alert template]

Example: RaiseAsAlert(JSON.stringify(EventList),"MultipleLogins(10)","","7","7","Multiple Logins(10)");

In this example the DTS object alerts "” an when the "Multiple Logins (10)" alert is triggered and gives it a security score of 7 and a security level of 7.

Example: backEvents (‘SearchString’), NumberOfDays); Default NumberOfDays (if not specified) is 100. Searches for ‘SearchString’ and returns all the events that match the search in JSON format (array)

Example: backCount (‘SearchString’), NumberOfDays); Searches for ‘SearchString’ and returns count of all the events that match the search.

Example: ConsoleLog (String); Logs desired String in in /var/log/data-acquisition.log