Keep analyzer reports when merging a case

[francoisihry]

Request Type

Bug

Work Environment

| OS version (server) | Debian | TheHive4py version | 3.0.9

Problem Description

When I merge a case containing observables and analyzer reports with another case : The new merged case is created with the observables but I have to run the analyzers again. That's a problem because if there are a lot of cases that need to be consecutively merged with the same case, all the analyzers have to be relaunched at each merge instead of keeping the analysis reports of the first case.

[nadouani]

The only thing to decide here is: if both case share the same observable and that observable has two different mini reports in each case, which mini report should be kept on the resulting observable

[francoisihry]

Correct me if I am wrong, I think the current merging process works like above: I created a case A with its own observables and analysis reports. I created a case B with its own observables. From the case B, I choose to merge with the case A -> It creates a case C containing A observables (without the analysis reports), and close the case A and B. From the case C, we can see in the description that it has been merged from cases A and B.

My scenario is a phishing context : I decide to merge phishing alerts when they share the same fields except the receiver mail address (field To). That means all the custom fields and observables are identical except the "To" custom field. You can easily understand that when a phishing attack concerns 100 different targets, I want the analyzers to be launched for the first alert, and the 99 other alerts be merged with the first one but keep the analyzes reports.

[nadouani]

Do you convert all the phishing alerts to a case in your workflow or, just merge the new alerts into the existing case? (which will copy the new observables from the alert into the case, and ignore the existing observables)?

[francoisihry]

Sorry I said phishing alerts but that's actually phishing cases. Through the API I create phishing cases according to a phishing template.

[francoisihry]

my python script check if there is a case that shares the same fields except the "To" custom field. And if so, it merges the new case with that one.

[nadouani]

Why you don't just add the observables from the new case without creating it? Do you need to know how many Phishing alerts did you get?

I think that the way you do it will result in a huge number of useless cases (it's just an opinion). You could use a metric that your script could increment, every time a new identical phishing alert arrives.

But anyways, we will take a look to the observable reports after case merge and let you know if something is not working as expected.

[francoisihry]

You are right, that would be more relevant.

Now, let's say, the attacker is a bit smart and generates a lot of phishing mail but with varying some observables (like the name of the receiver in the body message).

I would have a lot of cases and in that context the merging function might be interesting ? The merging process should save the shared data only one time ? And let the user know the fields which are different ?

Basically a merge is used when two cases shared a lot of identical fields or observables right ?

[saadkadhi]

A merge is usually warranted when analysts realize that two cases (i.e. two investigations) or more are in fact related to the same attack/campaign.

It’s up to you and your expertise to decide, using different criteria that ongoing investigations should be blended into one, hence saving time and other resources. TheHive aids by displaying Related Cases and the relationship is basic as it is based solely on the values of observables. This is somehow reflected as well in the Alert preview page where cases carrying observable similarities with the alert attributes are shown. As I wrote, the functionality is currently basic and there is a plan to improve it in future versions.

Getting back to your scenario, if you receive an alert related to phishing/malspam campaign that you make a case out of then few seconds or minutes later, new alerts come up that relate to the same phishing/malspam campaign, previewing those will show you similarities with the case you’ve just created even though the attacker used subject variations as the remote MTA and/or the sender’s FQDN and/or other SMTP artifacts would stay the same.

That being said, if the phishing/malspam campaign generates a hundred of alerts/user notifications, the analyst would still end up having to preview them in TheHive and merging one by one in the existing case. That’s definitely tedious and you may want to catch those alerts before they reach TheHive, programmatically cluster them and feed them in groups of N to TheHive to ease up the analyst’s work.

[francoisihry]

I automatize as far as possible the analysis. So when an email is reported as phishing, a python script will automatically look for similar cases in theHive. Based upon some observables of the email the script will automatically merge with a similar case, or create a new case instance. I want to test that with hundreds of phishing mails so that the CSIRT analyst doesn't have to do it manually when it happens. The analyst should see in the UI the number of cases that have been merged as a metric that can be taken into account in the scoring criticality of the case.