7.5.8. Analysing the Retro hunt alerts

7.5.8.1. Introduction

For information, see the following paragraphs:

7.5.8.1.1. Management of the Retro hunt engine

To view the Retro hunt status, see the Viewing the engine status paragraph.
To update the Retro hunt, see the CTI update paragraph.
To configure the Retro hunt, see the Engine configuration paragraph.

7.5.8.1.2. Events generated by the engine

Events generated by the Retro hunt engine are alerts.

These are displayed:

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

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

To view the alerts, select the `Retro hunt` engine filter.

See the presentation of the Web UI `Alerts`.

Click on the selected alert.

The `Alert details` window is displayed.

The detailed information of this alert is displayed.

In the Kibana UI interface
- In the main interface WEB UI, to view the alerts, select the `Retro hunt` category of the `Alerts` section in Kibana then the `Overview` or the `Messages` tab.
  
  The interface displayed is the interface named Kibana UI (described in Overview of the Kibana GUI).
- By clicking on an alert, select on the command `Flow details` then select the arrow to the left of the alert.
  
  The detailed information of this alert can be viewed in table or json format.

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?

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

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.

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.3. Alert handling procedure

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

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.

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

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

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

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

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

ca existe??

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