Last week, we have released Mellifera (TheHive 2.11.0), a major version of your favorite (or soon to be favorite) Security Incident Response Platform. Sadly, some annoying bugs have slipped past our QA (n’est-ce pas Thomas ?).
We are happy to announce the availability of Mellifera 1 (TheHive 2.11.1) which corrects those bugs and adds a few enhancements detailed below.
#204: update case templates created with previous versions of TheHive.
#206: apply case templates when an alert is converted into a case.
We also took the opportunity of this hotfix to add the following enhancements:
#180: merge duplicate tasks during a case merge operation. Starting from this release, if you have waiting tasks (i.e. not assigned) with the same name in cases you’d like to merge, the new merged case will have only one task instead of two.
#211: show the number of available analyzer reports for each observable. If an observable has not been analyzed yet, say so.
Please note that we have moved all the documentation of TheHive in a new repository. If you are not using TheHive4py 1.2.0 (or future versions), you can send alerts to Mellifera using the API as documented.
Download & Get Down to Work
If you have an existing TheHive installation, please follow the new migration guide.
If you are performing a fresh installation, read the installation guide corresponding to your needs and enjoy. Please note that you can install TheHive using an RPM or DEB package, deploy it using an Ansible script, use Docker, install it from a binary or build it from sources.
As this reporter informed you a few weeks ago, the fine cooks of TheHive Project were working hard on a new version of TheHive (TH) which most prominent feature is case merging. Put simply, starting from 2.9.1, TH lets you merge two cases together once you realize that they are similar to each other if not outright identical. This will save you from tearing your hair up and duplicating work on two separate investigations only to realize down the DFIR road that they should have been one right from the start.
When you perform a merge, the two original cases will be used to create a new one that is a union of all the observables of its parents. However, all the tasks of the parents will appear in the child, even if a task has the exact same name in the original cases. This might look as a shortcoming but pause a second and think about it. Tasks are basically worklogs and if we were to fuse a task, how would we collect the worklogs in each of them and put them back in an intelligible form? Got any effective ideas? Then what are you waiting for? Shoot them our way.
In the meantime, let’s see how this works in practice through an example. Earlier today*, Antoine, our intrepid security incident response lead of the StarGazer CSIRT imported a MISP event that looked interesting (to him at least):
While Antoine can import a MISP event as a TH case that has no associated tasks and create those by hand, he prefers automating as many things as possible. So he previously logged in as an administrator, then he created a case template for importing MISP events. The template contains the typical set of minimal tasks that need to be performed during the investigation of such events. He hasn’t supplied numerical metrics for the template at this time.
Meanwhile, Isabelle, his fellow analyst, was monitoring the CSIRT mailbox for user reports and notifications that may need to be acted upon. As it happens, Anthony Braco from the HR department forwarded a suspicious email which resembles a malspam:
She extracts the suspicious attachment, fires it up in the team’s sandbox and extracts a number of observables which she starts adding to the case:
Interestingly, the URL she has just added has the eye icon which means it has already been seen somewhere else. She clicks on the observable to get the details:
Under the Observable Links section, Isabelle observes that the URL was added to the case #10 that has been created a few minutes ago. She executes the URL Category analyzer that was kindly contributed by Eric Capuano and integrated to TH 2.9.1. The website is flagged as malicious:
Isabelles then clicks on the Case Summary tab and makes sure that her case shares the observable with the one that was created by Antoine:
sabelle then decides to perform a merge of her case with Antoine’s. This will let the team avoid duplicating efforts and leverage the attributes from the MISP event that Antoine converted speed up the investigation and cover more ground during the identification, containment and eradication phases of incident response. To do that, she clicks on the facing arrows icon:
The two cases are then merged and a new one created, containing all the observables, analyzer results, cases and tags of the originals:
Once the merge operation is completed, the original cases are closed:
Besides the case merge feature and the addition of the URL Category analyzer, 2.9.1 fixes a number of bugs and adds a few enhancements, many of which were brought to our attention by our user community. Please read the full changelog for additional details.
If you are a current 2.9.0 user, we highly recommend you update to 2.9.1.
* Please do not put too close an attention to the dates in some of the cases which are off by several weeks. We are intentionally using old data for the sake of demonstrating the feature.
The chefs behind TheHive authorized this reporter a sneak preview into their code kitchen as they were preparing a delicious recipe for an upcoming release: case merging.
Reading about someone else’s experience with food, wine, music or in this case code can be baffling but let us not shy away from a tedious task and call an example to the rescue.
Antoine is the security incident response lead of the StarGazer CSIRT which is using TheHive (TH) to handle incidents and keep the monsters at bay. Their TH instance is connected with their MISP server and Antoine has been keeping an eye on the top navigation bar of the application to spot new MISP event notifications that would need processing. Here comes one. Antoine clicks on the notification bubble and is taken as a result to the Import MISP events view.
Indeed, a new MISP event showed up from a partner’s instance that is synced with StarGazer’s. Antoine previews the event, decides it worths an investigation and creates a TH case out of it with a number of associated tasks by clicking on import event. StarGazer CSIRT has indeed taken advantage of TH case template engine to match handling MISP events to their processes.
Isabelle, a StarGazer security analyst, has just wrapped up a task from a previous case, looking for suspicious activities in proxy logs. She completed her analysis, updated the task in TH and closed it. Since the Flow was open on her screen, she saw Antoine creates the new case and the related tasks. As it happens, one of them consists of searching URLs copied over from the MISP event in the proxy logs.
Isabelle clicks on the new task, an action that automatically assigns it to her, and starts working on it. Antoine sees what Isabelle is up to thanks to the Flow and then moves on to deal with a different task.
A few minutes later, Antoine’s eyes are caught by a new MISP event notification. He can’t handle it right now so he reaches out to Sabine, the backup incident response lead, and asks her to take care of it. Sabine obliges and previews the new event which is from a different source than the first one. She decides that it deserves an investigation as well and there, she creates a new case. Time flies by and StarGazer analysts are buzzing along the two investigations only to realize that the two MISP events were in fact almost the same.
Here is what happened. The two events were published by two different sources who were subjected to a spear-phishing attack by the same threat actor. While the malicious attachments are unique for each recipient, they drop the same malware which beacons using HTTP to a small set of C2s that were successfully identified by both parties. The email addresses used by the attacker are different but not the MTA. Moreover, the email subjects have the same pattern.
In this situation, using the current TH version (2.9.0), the analysts’ hands are kind of tied. They may close the second case after manually copying the observables that were created out of the new MISP event to the case opened by Antoine for example. What a hassle. It kinds of defeat the productivity boost they were expecting by choosing TH.
In TH version 2.9.1, which will be released in a few days, the StarGazer team will be able to merge both cases very simply, creating a new one, without losing observables, tasks or their associated logs. So even if a new MISP event pops up hours or days later, they will be able to create a case out of it and merge the case right away with an existing one if similarities are found. And spotting similarities is quite easy with TH since when you create and update a case, the Web UI Case View will tell you if there are look-alike cases based on observables. You can also navigate to the observables tab of the new case, choose to display 100 at a time and see if most observables have an ‘eye’ icon associated with them (which means they have already been seen). Of course, this second method is not ideal and if you want be thorough you’d want to review if all the observables have an ‘eye’ icon.
Case merging will not be limited to cases created out of MISP events. You may use this feature for any case that you have created in TH.
But what happens if, after merging, the MISP event that was used to create one of the original cases is updated and new attributes have been added to it? As this reporter was pestering the chefs with questions, they asked him to leave the kitchen since they were putting the very last touches to the recipe so he complied.
Well, all we have to do is grab a nice table, put a napkin on our lap, and wait for the new version to be served. Maybe then our question will be answered.