QRadar EDR (formerly ReaQta): Detection and configuration

For incident triaging, ReaQta recommends the following “3 by 4” methodology as a “guideline".

• Identify the subject (s) (processes, which trigger the incident), its parent, and child processes that are the “3” of the “3 by 4”
• For the parent, subject, and child process check the 4 areas are legit:
  
  ⦁ Authenticity: If it is a trusted application that is, signed by a trusted certificate, known installed application and so on.
  ⦁ Parameters: whether the command-line parameter, which is run together with the application looks legit and harmless.
  ⦁ Behaviors: whether the behavior is acceptable to the organization.
  ⦁ Connections: ensure the connections (if any) are legit.

• Terminate Process: lists all processes associated with the malicious behavior.
  ⦁ Kill - stops the running process. 
  ⦁ Remove - removes the file corresponding to the process entry.
  ⦁ PID - system ID of the running process.
  ⦁ PPID - system ID of the parent process that creates the process.
  ⦁ Affected Endpoints - Endpoint affected by the Alert.
  ⦁ Cloud Analysis - Metadata-based cloud analysis to expedite triaging and automatically identify potential threats. Results can be: Infected, Suspicious, Safe.
  ⦁ Process Information - detailed information about the process including Process name, Path, User, and the relevant Key Events generated by the process.
• Remove dropped executable files: Removes the selected executable files created by the malicious process. 
  ⦁ Remove - mark to be removed.
  ⦁ Prevalence - The number of times an artifact is seen in other endpoints.
  ⦁ Cloud Analysis - Metadata-based cloud analysis to expedite triaging and automatically identify potential threats. Results can be: Infected, Suspicious, Safe.
  ⦁ Dropped files - Path and SHA256 hash of dropped files to be removed 
• Remove file system Persistence: removes file system persistence created by the malicious processes 
  ⦁ Remove - mark to be removed.
  ⦁ Persistence - persistency settings to be removed.
• Remove Registry Persistence: removes registry entries created by the malicious processes 
  ⦁ Remove - mark to be removed.
  ⦁ Prevalence - the number of times an artifact is seen in other endpoints. 
  ⦁ Persistence - persistency settings to be removed including registry entry details: Name, Data, Object (registry entry) 
• Isolate Endpoints: Directly isolate the endpoint-preventing damage to other endpoints in the infrastructure and data exfiltration. Includes information about the status, name, IP address, Asset type, and domain membership. 
• Remediation Summary: Summary of the selected remediation actions including the number of processes and entries to be removed. 
• Remediation History - Additionally once remediation is completed you can review the results by using the drop-down menu of the Create Remediation Plan button and choose Remediation History.
  
  The status includes information about: 
  
  ⦁ Status - failed or succeed.
  ⦁ Date and time of the execution attempt.
  ⦁ Type of remediation.
  ⦁ Data column includes details pertaining to the selected remediation item such as the path, SHA256 hash, File name, process ID, and more. 

The Threat Hunt (Proactive Hunting) offers the possibility to search across all the events collected by the endpoints, which belong or not to an alert. The search is performed through the User Interface (UI), and the correlation of events is automatic. 

Next, a summary of the functionalities at high level:

• Query-collected events.
• Promote an event to Alert, by leveraging the correlation capabilities of Hive.
• Export the query results in JSON.
• Remediation strategies with single click to remotely kill in real time.
• Allow users to build their own Detection Strategy and Playbooks.

It works by elaborating a threat hunting query that is composed by multiple query parameters combined in OR, AND, and NOT logical operators, that return one or more events matching the specific criteria. We can combine the 3 of them to create a complex query.



In addition to the use of these logical operators we can search by using the date, event type, end points, and groups information parameters. This capability makes threat hunt more granular and efficient as those inputs are combined together by using the Logic to make queries stronger and powerful.

Some examples:

Example 1: Hunt for a DNS name by using the prefix search:
OR Field: eventdata.dns:"Google"
  Results: All the DNS event fields containing “Google”

Example 2: Hunt for PowerShell executed with the “Bypass” parameter - mix of exact match and prefix search:
AND Field: originalFilename:"powershell.exe"cmdline:"Bypass" 
 

Important: The events belonging to File Operations and Registry Operations are collected only if they belong to an Alert.
 

Limitations: 

• It is not possible to specify in the query parameters the wildcard operator *. It is whereby possible to leverage prefix search wherever specified in the built-in query help.
• It is not possible to create nested queries.

Threat Hunt Page details overview: 
 

• Query – defines the query to be applied. The following operators can be used:
  OR, AND and NOT: Three separate input boxes each one applies a given Boolean logic when multiple query parameters are specified in the same input box. The “+” button for each input box opens the query parameter list and search helper.
• Date - Possibility to search events that happened in a defined range of time.
• Presets - Automatically fill the Date range with: 24h 7d and30d ranges
• Events – events available for hunting. It’s possible to filter by one or more events, when multiple events are selected, they are combined in AND. 
• Endpoints - Specify one or more (applied in AND) endpoints to apply the query.
• Groups - Specify one or more (applied in AND) groups/clients to apply the query.