7.5.8. Analyzing the Retrohunt alerts

7.5.8.1. Introduction

For information, see the following paragraphs:

7.5.8.1.1. Management of the Retrohunt engine

For engine informations, see the paragraph Viewing the engine status
For information on engine upgrade, see the paragraph CTI update
For information on engine configuration, see the paragraph Engine configuration

7.5.8.1.2. Events generated by the engine

Events generated by the Retrohunt engine are alerts.

These are displayed:

In the main interface named WebUI of the GCenter in the `Alerts` screen:

The main interface named WebUI is described in Overview of the WEB UI.

To view only these alerts, select the `Retrohunt` engine filter.

See the presentation of the WebUI `Alerts` screen.

Click on the selected alert.

The `Alert details` window is displayed

The detailed information of this alert is displayed in Example of a Retro hunt alert in the WebUI.

In the interface named Kibana UI:
- Click on the `Hunting` icon on the left side menu bar in the WebUI.
  
  The interface displayed is the interface named Kibana UI (described in Overview of the Kibana GUI).
- Select the `Retro hunt` category of the `Alerts` section in Kibana then the `Overview` or the `Messages` tab.
- Click on the `Messages` tab.
To consult information about a specific alert:
- Click on the toggle icon (1) on the left of the Alert.
  
  The expanded document (2) is displayed.
  
  The detailed information of this alert can be viewed in table or json format (see the Retro hunt logs data structure).
  
  The displayed counters are given in the Engine log data structure appendix.

7.5.8.1.3. Essential information to understand the context of the alert

7.5.8.1.3.1. What are the key fields of an alert and their meaning?

In order to undertake the investigation or qualification of the alert, it is necessary to search for the IoC on the OpenCTI platform of Gatewatcher CTI to obtain more information about the threat and understand the context.

To do this, you must first determine what the IoC is:

If the alert is raised on a DNS packet, the value of the IoC is in the ``dns.query.rrname`` field of the alert
If the alert is raised on an HTTP packet, the value of the IoC is in the ``http.hostname`` field of the alert

Note

These elements can be found in the `Alert details` window.

It is also possible to search for IoC on the OpenCTI platform.

To this end:

Search for the IoC value in the general search bar at the top right of the home page
then select the IoC from the IoC present after searching

On the IoC page, you can find:

Its description

The IoC description consists of:
- Its value
- The type of IoC
  
  In the case of an ActiveCTI alert, alerts are associated with domains or URLs, but generally the platform includes file hashes, file names and IPs.
If Detection or not, see the Alert handling procedure
Its labels, which may correspond to:
- The type of threat involved
  
  This field can take different values including phishing, trojan, hacktool depending on how the threat was categorized by Gatewatcher CTI.
- On behalf of the associated malware
  
  In the case of a file hash or a URL or domain that downloads a file, if that file is categorized as belonging to a malware family, then the name will appear in the labels.
  
  For example: mirai, qbot, redline stealer.
- On behalf of the associated threat actor
  
  In the same way as for malware, if the threat is associated with a threat actor, its name will appear in the labels.
  
  For example: ta505, lockbit, lazarus group.
Its external references

These are external articles or analyzes in which the IoC is present and which provide additional context.

In the information displayed in the Kibana alerts, the key elements include:

`type`

This is the type of IoC reported. This field can be SHA256, SHA1, MD5, Filename, URL, Host.
`value`

Corresponds to the value of the IoC, that is, the IoC itself.
`signature`

When available, the signature consists of the following fields:
- `type`: if it is a hash, an IP, a domain.
- `categories`: threat category corresponding to the IoC. For example: phishing, trojan, ransom, backdoor.
- `families`: malware family corresponding to IoC. For example: Cobalt Strike, Mirai, gh0st RAT.
- `threat_actor`: threat actor associated with IoC. For example: TA505, Medusa, SilverTerrier.
- `relations`: corresponds to other IoCs present in the platform associated with IoC.

7.5.8.2. Alert handling procedure

7.5.8.2.1. How do you verify the accuracy of an alert and determine if it represents a real threat?

To assess the accuracy of an alert and determine whether it represents a real threat, several steps can be taken.
Here is an overview of the actions frequently taken when analyzing a generated alert.
The first item to check is the usage_mode field of the alert in Kibana.
It can take two values: `detection` or `hunting`.

If the usage_mode of the IoC mode has the `hunting` value which may be the case for a domain or an IP address, it means that the resource has not been contacted anymore.

On a network, this can happen for example when a malicious resource tries to contact a domain that is no longer active.
On the other hand, if the usage_mode has the `detection` value, the IoC is still active and represents in this case a current threat.

7.5.8.2.2. How to categorize the threat based on the information collected?

To categorize the threat, explore several avenues:

Check the threat type:
- In the case of a URL or domain, the associated threats are most often phishing or downloading a malicious file.
  
  This information is present in the IoC labels.
  
  If the labels do not determine the type of threat, the IoC value can give the information.
  
  Phishing URLs usually contain keywords that betray an attempt to spoof a service or company, where downloading a malicious file is often done from an IP and whose file name can be specified in the path.
  
  In other cases, IoC may refer to a domain of Command and Control, characterized by a specific malware name.
Search for threat on external CTI platforms:
- For more information on the level of malicious activity or to download the threat in which of a file, turn to external Threat Intelligence platforms such as VirusTotal or MalwareBazaar.
Verify the original IP address of the alert in the GCenter:
- If the alert is linked to an external IP address, review the reputation level of that address.
  
  An IP address with a bad reputation is more likely to be associated with malicious activity.
- Note also that just because it is an internal IP address does not make it a false positive.
View the alert history:
- View the history of similar alerts generated by ActiveCTI.
  
  If similar alerts have been confirmed as real threats in the past, it increases the likelihood that the current alert is also a threat.
  
  Depending on the observations, the threat can be categorized as real or not.
- If necessary, use the File transactions functionality presented in the previous paragraph to obtain the majority of this information via a condensed view.

7.5.8.2.3. What answers are needed if the threat is confirmed?

Note

This procedure allows further investigation and evaluation of the extent of the incident after confirmation of a threat generated by the ActiveCTI engine.

In general, it is appropriate to:

Determine extent of infection: identify machines infected by the threat
Isolate the system: immediately isolate the contaminated system and ensure it cannot cause further damage
Notify: inform relevant parties of threat detection

Depending on the case, different approaches are taken:

if the threat is a domain or IP associated with the download of a malicious resource, in this case it is probably the transfer of a malicious tool to or within the infected environment:
- Remove file or malware from infected machine(s)
- Scan the machine from which the request was made to the malicious server, which would have been infected before the request
if the threat is associated with a Command and Control server, this implies that one or more infected machines communicate with the said server:
- Remove the malicious tag that originated communications to the infected machine(s) server
if the threat is associated with phishing:
- Identify the target of phishing
- Ask the employee or employees about the details of the attack to assess the extent of the information communicated to the attacker

In a second step, it is also necessary to look at the relations associated with the IoC via the relations field or via the external_links for:

Anticipate the actions of the attacker
Monitor / block IoC related items
If the threat is a hash corresponding to a file:
- Neutralize the threat by deleting the file, blocking the original IP address, etc.
- Dynamic analysis: if possible, run the file in a secure environment (sandbox) to observe its behavior (a GBox for example).
- Reverse engineering (if necessary): if the threat is particularly complex, reverse engineering can be considered in order to fully understand its internal functioning.
  
  This can help identify exploited vulnerabilities and propagation mechanisms.
- Analyze the logs: review system and network logs to trace threat spread.

In a second step, it is also necessary to look at the relations associated with the IoC via the relations field or via the external_links for:

Anticipate the actions of the attacker
Monitor / block IoC related items

7.5.8.2.3.1. What if an alert from this engine is identified as a false positive?

If an alert from this engine is identified as a recurring false positive, it is recommended to mute the alert signed. There is no whitelist for the Retro hunt engine.