TheHive Reloaded: 4.1.0 is out

We are proud and excited to annonce the availability of TheHive v4.1.0. This release is the new beginning of TheHive’s future, because all the upcoming features and enhancements will be based on this version, without the brakes.

4.1.0 is out after a significant work done during the last 6 months, interrupted by multiple events like:

  • supporting ES 7 in TheHive 3 and Cortex
  • supporting ES 7.11 in TheHive 3 and Cortex
  • 5 patch releases of TheHive 4.0
  • recent OVH datacenter incident (but this one was quickly fixed)

Our community is waiting for it, as we announced it will fix the performance issues that many of you were facing. The reason is that TheHive 4.0.x doesn’t include a database indexation component resulting on poor data fetching performance.

We are glad about this release, it includes tons of new features and improvements, across all the application.

The first and maybe, the main one, is the database indexation (#1731) that will significantly improve performance of queries such as lists, filters and sorting. As a consequence, you should experience a smoother browsing and usage of the application.

Amongst all other news features, we introduced:

  • Support for MISP taxonomies, in addition to custom tags and tag colour support;
  • Support for Case TTPs specified by MITRE ATT&CK framework;
  • Better and improved Case merging and deleting capabilities;
  • A customisable date and time format
  • A refined Case Templates management UI
  • Enhanced Case list UI with bulk actions
  • Enhanced Task list UI with bulk actions
  • A platform status page to get an overview of the platform health
  • Support for migration from TheHive 3.5.1 to 4.1
  • Support for authentication on Webhook endpoints

For those of you who want to know the full details, here is the change log

A word about the documentation

As you might know, TheHive has a documentation repository that includes content for TheHive 3 and TheHive 4, but the structure needs to be redefined. For that reason, we introduced a new documentation website that aims to be the single starting point of all the docs we produce for TheHive Projects’ products.

In the upcoming days, we will mark the old docs repositories as ARCHIVED and we will maintain the new docs repository.

To visit the new documentation website, go to
https://docs.thehive-project.org

More about the new features

Database indexation

Until now, we knew TheHive suffered from a performance issue with the database.

Technically, TheHive uses basic index mechanism embedded in JanusGraph. This indexes are simple to use and manage but they contain limitations. They only support equality lookups and cannot be used for sort (for example, this is not possible to simply look for cases with severity > LOW) . However, within TheHive, almost all lists – lists of cases, lists of alerts, tasks …- are sorted. So, getting a list means a scan of all the elements of the list, which have a heavy performance impact, particularly if the list is long.

In order to solve this issue, TheHive 4.1.0 comes with a new index engine, and indexes have to be stored outside the database. As a consequence you need to define and setup dedicated storage for these indexes.

  • If TheHive is used in a cluster mode, all servers must connect to a common index engine, which can be in a cluster mode or not. In this case, a new component must be installed for index management. Elasticsearch should be used, only as an index engine. For clusters, Elasticsearch is not used like it was with TheHive 3.x when it stored data.
  • If TheHive is used on a standalone server, Elasticsearch can be used, but a file based index engine – Lucene – can be preferred. The latter solution has less infrastructure impact – no component to install – and only requires configuration that indicate where index data is stored in the filesystem.

For more details about database indexing configuration, please refer to the documentation

MISP taxonomies support

TheHive 4 handles tags in a completely different way than TheHive 3, even if the APIs are still considering tags as simple strings. For example when you create a Case from TheHiv4py, you specify tags as a simple array of strings.

Behind the scene, TheHive transforms the tags into objects, with a namespace, a predicate and an empty value. For example if your create a case with a free tag src=mailbox, TheHive 4 creates a new Tag object as following:

{
    "namespace": "_freetag",
    "predicate": "src=mailbox",
    "value": null,
    "colour": "DEFAULT_COLOUR_FROM_THE_CONFIG"
}

This is where we introduced the support of MISP Taxonomies, allowing admin users with `manageTaxonomy` permission, to import tags defined in machinetag.json format, from the “Administration > Taxonomies page”

Taxonomies import dialog

Note: importing the full MISP taxonomies library can take some time (1 minute)

Once imported, you need to enable the taxonomies you need for use cases. All the taxonomies are disables by default. Enabling a taxonomy, make its tags available to all the organisations on the platform, so analysts can use the to tag Cases, Alerts, Observables.

Tags selector

Taxonomy tags can also bee used from any tag filter in Case, Alert and Observable lists:

Tag filter

Custom tags support

Custom tags or free tags, is the way we call free text tags associated with TheHive objects. Internally, custom tags are included into organisation related spécial taxonomy called `freetags`.

Custom tags are not shared across organisations, so existing users defining sensitive data in tags won’t suffer any data leakage issue.

In general, custom tags in TheHive are not supposed to user data and information. It’s not a best practice to use email adresses as tags. Custom fields are the right place for this type of data.

This topic needs a dedicated blog post, to share the best practices of using tags.

So, how do an org admin manage the custom tags? Well, TheHive 4.1 comes with a new UI section, under the organisation management page, allowing:

  • Listing all the custom tags
  • Filtering and sorting
  • Updating custom tag values and colours
  • Deleting custom tags
  • Displaying custom tag usage (# of cases, # of alerts, # of observables and # of case templates)
Custom tags management

For users migrating from TheHive 3, all the existing tags are imported as custom tags

Tactics, Techniques & Procedures, with MITRE ATT&CK

Supporting MITRE ATT&CK framework is one of the feature that has been postponed many time from TheHive. It’s a no brainer feature that any blue team oriented product must include.

In TheHive 4.1, we allow:

  • Importing the official MITRE ATT&CK attack patterns collection as defined in https://github.com/mitre/cti. In this version support the entreprise catalog, but the future goal is to allow managing multiple catalogs in a misp-galaxy-like manner.
  • Defining TTPs associated with TheHive Cases

Attack Pattern management

From the administration page, any user with managePattern permission is able to have access to a page where patterns can be imported, filtered, viewed.

Import attack patterns
Attck Pattern management page

Case TTPs

In addition to Tasks and Observables, in TheHive 4.1, you can associated TTPs to your Cases. TTPs objects are defined by:

  • A tactic
  • A technique or sub-technique
  • An occur date
  • An optional procedure description
Add a TTP to a Case

The Case TTPs are displayed in a dedicated tab on the Case details page, the same way as Tasks and Observables, with filtering and sorting capabilities.

List of TTPs published in the report SANDWORM INTRUSION SET
CAMPAIGN TARGETING
CENTREON SYSTEMS
” by CERT-FR

This screenshot, showcases the tactic colours we use, thanks to Paul Tol’s blogpost

Case list TTP related improvements

One more feature: Case list now show the number of TTPs associated with each Case, with a link to the TTPs list page.

Case overview

Customise date and time

Since the very beginning, TheHive displays dates with the Month-Day-Year format. After 5 years, you can now customise the way you want date and time be displayed in all views of the UI.

This can be configured at the Organisation level, by defining the preferred format in the UI Configuration view. This required a user with org-admin profile or any profile with manageConfig permission.

UI Configuration view

Improved Case templates management

Case template management UI has been rewritten to allow more capabilities, required when you start having a growing number of templates:

  • Filtering
  • Sorting
  • Display dates
  • Display number of tasks and custom fields
Case template management UI
Case template editing UI

Case merging

This is a feature that has been removed from TheHive 4.0 as it required a design update to take into account the multi-tenancy support.

In TheHive 4.1, case merging has the same UI:

  • Go to a case details page
  • Click merge
  • Select the case to merge data into
  • Validate

The difference in TheHive 4.1 is that, merging two cases, removes the originating cases, and create a new one with all the merged data.

Platform status page

This feature aims to help understand the issues related to TheHive health status. It contains details about:

  • database schema version
  • status of database indexes
  • status of database integrity checks

It also allows:

  • exporting a JSON report of the health status including more details then what is displayed on the UI
  • reindexing the database
  • triggering the database integrity checks

This page is available to super admin users and contains cross organisations data

Platform status

Webhook authentication options

In TheHive 4.1, you can define authentication configuration for your Webhooks. For more details, please refer to the documentation website

KNOWN ISSUE: the auth property in Webhook definitions, in application.conf file is REQUIRED, so if your webhook doesn’t need authentication, then just add

auth: {type: "none"}

for each Webhook definition

Updating from TheHive 4.0

Due to the new database indexation feature, updating from 4.0.x requires some attention. Depending on your type of installation – standalone server or cluster – your setup will need to be upgraded accordingly.

  • On standalone servers, you will have to define a new local folder to store indexes;
  • For a cluster, you will need to locate an Elasticsearch instance to use it as index.

Finally, update the /etc/thehive/application.conf configuration file, install the new version of the application and restart the service.

more detailed information regarding this update can be found here:

https://docs.thehive-project.org/thehive/operations/update/

Indexes related to existing data will be created at the first start after the update to TheHive 4.1.0. Depending on the size of your database, this process can take a long time.

Upgrading from TheHive 3.x

If you are still using TheHive 3.x and want to migrate to TheHive 4.1, then you need to take a look to the following supported paths:

Target versionRequired source version
TheHive 4.1.xTheHive 3.5.1
TheHive 4.0.x3.4.x < TheHive < 3.5.1
Supported migration paths

For more details, please refer to the documentation website

How to install

If you starts using TheHive with this version, we recommend having a look at our documentation site, and particularly to the installation and configuration section which is up to date and contains all instructions to install & configure TheHive 4.1.0.

Docker

If you use TheHive as a docker container, you can refer to the Docker-Templates repository that has a TheHive 4 up-to-date docker-compose configurations.

How to report issues

Please open an issue on GitHub with the dedicated template for TheHive 4. We will monitor them closely and respond accordingly. 

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. We will be more than happy to help!

Elasticsearch 7.11.x is now supported !

After the first feedback received from the community on Discord and Github, we have put the coming 4.1.0 release of TheHive on hold to focus on what can potentially break Cortex v3.1.0 and TheHive v3.5.0 with the upgrade to Elasticsearch v7.11.x.
Several questions appeared on our side:

  • How to fix the installation process ?
  • How to fix the upgrade process ?
  • As the update of an existing Elasticsearch database to 7.11.x makes the downgrade impossible after that, will our fix repair it ?

Good news: this is fixed with TheHive v3.5.1 and Cortex 3.1.1, and these versions will repair databases that have already been updated to ES 7.11.x.

The update to these new versions introduces new indexes, for Cortex (cortex_6), as well as for TheHive (the_hive_17).

  • If you plan to run a new installation for Cortex, just follow the installation guide;
  • If you want to update your setup, we recommend to follow this process:
    • Stop TheHive or Cortex
    • Stop Elasticsearch
    • Update Elasticsearch package
    • Restart Elasticsearch and ensure this is going well
    • Install TheHive 3.5.1 or Cortex 3.1.1 package
  • If you already updated Elasticsearch to version 7.11.x and faced potential breaks with Cortex or TheHive, follow the process described previously and you should regain access to your data.

Once updated, you should be invited to update the database:

Update Database after installing TheHive 3.5.1 or Cortex 3.1.1

Click on “Update Database” and you should then be invited to login. Everything should work fine after that.

As usual, we recommend making backups or a snapshot of the database before running the upgrade.

How to report issues

Please open an issue on GitHub for Cortex of the TheHive with the dedicated template for TheHive 3.x. We will monitor them closely and respond accordingly. 

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. We will be more than happy to help!

Compatibility issues with Elasticsearch update

Dear TheHive and Cortex users,

If you are running TheHive v3.5.0 and / or Cortex v3.1.0, the underlying database is Elasticsearch v7.x.

Elastic recently released two new versions: v7.11.0 and v7.11.1. After some initial feedback and investigations, we found that the new releases introduce changes that break the compatibility with our products – TheHive 3.5.0 and Cortex 3.1.0.

Therefore, please DO NOT upgrade your current database to Elasticsearch v7.11.x as no rollback is possible. Elasticsearch v7.11.x breaks the installation process as well as the update process.

If you are in the process of installing or updating to Cortex v3.1.0 or TheHive v3.5.0, you need to specify the exact working version of Elasticsearch to use:

  • For Debian packages: “apt install elasticsearch=7.10.2”
  • FOR RPM packages: “yum install elasticsearch-7.10.2-1”

We are currently running deeper investigations and are planning to release updated versions as soon as possible for Cortex v3.1.0 and for TheHive 3.5.0.

We will keep you informed, stay tuned!

It’s now time for TheHive 4 to get an update: TheHive 4.0.1 is out!

Back in July, we announced TheHive 4.0, the foundation for future releases of your favorite Open Source SIRP.

Today, we are pleased to deliver one of the biggest patch releases we’ve done so far, in terms of number of fixed issues: TheHive 4.0.1! Not only did we squash lots of bugs, we also included some cool improvements we didn’t want to hold until the next version.

As for TheHive 3 and Cortex unveiled few days ago, we fixed the vulnerabilities reported by Play framework in October as well.

A huge work has been accomplished to fix a backlog of bugs (thanks to the community) in several parts of the product:

  • Configuration;
  • API;
  • Dashboards;
  • Livestream;
  • Cases;
  • Alerts;
  • Observables;
  • Multi Factor authentication;
  • Active Directory authentication;
  • Export to MISP.

You can find details of the 80+ issues included in this milestone: Changelog file.

Wait, there is also new stuff:

  • Cases and Alerts similarity fine tuning;
  • Similar cases in Alert preview panel refined;
  • Filtering capabilities improvements;
  • New UI settings & options;
  • Custom fields in Case and Alert lists;
  • Statistics panel improvements;
  • API key in user settings page;
  • More migration tool options.

Cases and Alerts similarity fine tuning

In TheHive, correlation between Alerts and Cases, and between Cases themselves, is computed throughout their respective Observables:

  • A Case is considered similar to an Alert, if they have at least one common observable;
  • A Case is considered related to another Case, if they have at least one common observable.

In some situations, those relationships are undesirable when based on useless/meaningless observables.

Starting with TheHive 4.0.1, Observables are enriched with a new attribute called ignoreSimilarity, set to false by default. Now, when this attribute is set to true, an observable is simply not taken into account in the relationship between two cases, and is not involved in the similarity calculation, for Cases and Alerts.

This attribute is displayed alongside with the IOC and Sighted flags, in the Observables list – which has been tweaked for the occasion – as well as in the detailed view.

IgnoreSimilarity flag in the revamped Observables list

And you can also edit this for a set of selected observables.

Edit “Ignored for similarity”

Long story short, if you want to break a correlation, you just need to set the linking Observable‘s ignoreSimilarity flag to true.

Alerts and similar Cases

The attribute mentioned earlier is taken into account when correlating Alerts with existing Cases : the Similar Cases view in the Alert preview dialog.

Observables with ignoreSimilarity set to true will be ignored when fetching cases similar to the current Alert, whether it is in the Alert or the Case side.

A forthcoming update of thehive4py library will allow to set this attribute in Alerts, along with many other new things.

The Similar Cases view has been thoroughly enhanced to provide more highlights facilitating alert triage and the merging of alerts into existing cases. First, a column named “Matched” has been added. It contains the list of observable dataTypes and the number of occurrences matching the Alert : this should be very useful to identify quickly what type of data has matched the alert content. A filter on this column has also been added.

And there are more refining capabilities in this view:

  • Sorting and Filtering on Title of Similar Cases;
  • Specifying a minimum observables rate that matches the Alert;
  • Specifying a minimum IOCs rate that matches the Alert.
Refining the Similar Cases view during Alerts triage

… And, above all, columns can now be sorted. With all these new capabilities, triage and merge Alerts in Cases should be easier.

Filtering capabilities improvement

In TheHive 4, filter forms have the same structure all over the product. Any improvement in the area, benefits to all the listing pages.

For example, in the alert similar cases tab, a new filter form has been included. You can quickly select the type of Cases you want to display, but also use the advanced rules and search criterias.

In this release, the filter component has new capabilities:

  • Date filter: now allows setting dynamic ranges instead of setting from and to fixed date values. Possible values are:
    • Today;
    • Last 7 days;
    • Last 30 days;
    • Last 3 months;
    • Last 6 months;
    • Last year;
    • Custom: allowing the old-fashioned way of setting date ranges.
  • Tag filter: Autocomplete is now enabled.
Advanced filtering for Similar Cases during Alert triage
Autocompleted tags when adding a filter

In TheHive 4.0.1, there is one more place that welcomed a filter form: the list of Alert observables in the preview dialog.

New Org level UI settings

UI configuration page is the place where TheHive adds new options to customise the behavior of the UI, for a given organisation. This is an area that will be expanded over time.

For this milestone, two new options have been introduced:

  • Allow merging Alerts in resolved cases;
  • Default filter of Alert similar cases.
Default filter for Similar Cases in Alerts preview

The first one is self-explanatory and will hide the `Merge into case` button in the Alert similar cases section

The second one allows an administrator define, for an organisation, the default filter to apply to Alert similar cases view. For example: “show only potential similar cases created in the last 7 days and are still open”.

If during the triage, the filter has been updated by an analyst, the default filter cas be retrieved through Default filter option of the Quick Filters.

Retrieve default filter in alert similar cases

Custom fields in Case and Alert lists

“Damn, why I’m not able to see my custom fields in my cases list”, “It’s a shame I cannot filter my alerts with my custom defined properties”… We are pretty sure you said it, at least once.

Well, you dreamt of it, and here we go, we did it for Cases and Alerts

  • You will be able to see all the custom fields you defined in your Case Templates and propagated to your Cases;
  • Custom fields with undefined values are not displayed;
  • Custom fields are shown with respect of the order you define;
  • Clicking on a custom field, filters your lists using the selected value;
  • You can enable displaying the custom fields using the toggle button on the toolbar located on top of the filter form;
  • All those capabilities are available in Cases and Alerts views.
Custom Fields in Alerts list

New statistics view in Cases and Observables lists

The Stats view has been revamped to represent the statistics using both tables and shiny colourful donuts (not only for managers).

This improvement has been made in Cases, Observables and Alerts views.

New “Stats view” in Cases list

User settings

This feature has been initially introduced in Cortex and was missing in TheHive. All users can now access their API key, copy or update it, as long as an administrator created it first. No more API keys sent over emails or chat applications.

User settings with API key enabled

Migration

The migration assistant program has been updated with a few bug fixes and new filtering options. When migrating, you can now specify:

  • If you want to include or exclude Alerts generated from specific Sources or by their Type;
  • If you want to include Audit trails regarding specific objectType (case, case_task, case_observable …);
  • If you want to filter out Audit trails with specific actions (Update, Creation, Delete).
/opt/thehive/bin/migrate --help

[..]  
  --include-alert-types ,...
                           migrate only alerts with this types
  --exclude-alert-types ,...
                           don't migrate alerts with this types
  --include-alert-sources ,...
                           migrate only alerts with this sources
  --exclude-alert-sources ,...
                           don't migrate alerts with this sources
[..]   
  --include-audit-actions 
                           migration only audits with this action (Update, Creation, Delete)
  --exclude-audit-actions 
                           don't migration audits with this action (Update, Creation, Delete)
  --include-audit-objectTypes 
                           migration only audits with this objectType (case, case_artifact, case_task, ...)
  --exclude-audit-objectTypes 
                           don't migration audits with this objectType (case, case_artifact, case_task, ...)

So, you can migrate your data directly to TheHive 4.0.1.

However, please note that the migration tool does not support data from TheHive 3.5.0 yet. In short, you can only consider migrating you data from TheHive 3.4.0, 3.4.1, 3.4.2 or 3.4.4 to TheHive 4.0 or TheHive 4.0.1 for the time being.

How to install/update ?

Our installation guides are up-to-date.

Important note

If you are updating an existing instance of TheHive 4.0.0, ensure to read the installation guide. Since our recent release of TheHive 3.5.0, we updated our repositories. The codename of repositories containing all new released packages is now named release, instead of stable. So update your apt or yum repository file.

Have you got a minute to let us know how you use TheHive ?

We would love to hear from you (10 questions < 1minute) : https://t.co/l5osjvQ1k7

Many thanks for taking the time 🙏

How to report issues

Please open an issue on GitHub with the dedicated template for TheHive 4. We will monitor them closely and respond accordingly. 

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. We will be more than happy to help!

New releases for TheHive and Cortex: Elasticsearch 7 support and security fixes.

TheHive and Cortex with ES7 support

We are happy to announce the immediate availability of TheHive 3.5.0 and Cortex 3.1.0 that supports Elasticsearch 7. We are also releasing TheHive 3.4.4 to include security upgrades. All of them are including fixes for vulnerabilities reported on Play Framework this month. We encourage you to upgrade.

As promised, despite the release of TheHive 4.0 in July, we are still support version 3. Today we are releasing two versions of TheHive 3, but why ?

As mentioned previously, the EOL of Elasticsearch version 6 is the reason why we decided to upgrade TheHive and Cortex to exclusively support Elasticsearch version 7.

If you want to be up-to-date with TheHive and Cortex, you must use Elasticsearch 7 and the new released versions of our products: TheHive 3.5.0 and Cortex 3.1.0.

With that being said, we won’t let down the users who cannot migrate their Elasticsearch immediately to version 7, so we decided to fix an embarrassing bug related to alerts with large amount of observables, Thanks to TheHive 3.4.4.

What’s new in TheHive 3.5.0 and Cortex 3.1.0

In addition to support for Elasticsearch 7.x, following fixes has been added in TheHive 3.5.0:

  • Fix a bug with the admin page of Analyzers report templates (#1591)
  • Responder list is ordered alphabetically (#1564)
  • Keep date filters when pivoting from Dashboards to search page (#1581)
  • UI Configuration option to choose to filter TAG1 AND TAG2 or TAG1 OR TAG2 in Alerts view (#1171)
  • Fix issue when clicking on Analyzers short reports (#1350)

In addition to support for Elasticsearch 7.x, following fixes has been added in Cortex 3.1.0:

  • Take into account defaultValue in Neurons flavor file (#309)

Oauth2

Use OAuth2 with TheHive 3.5.0 and Cortex 3.1.0

Both versions have been updated to improve OAuth2 authentication support. They are now working the same way than TheHive 4.0.0, with a quite similar configuration.

We invite you to refer to the documentation for each application to configure it: TheHive and Cortex

Our support on TheHive and Cortex

However, starting from now, we will no longer support TheHive and Cortex version that use Elasticsearch < 7: i.e. TheHive < 3.5.0 and Cortex < 3.1.0. So please make sure to update your instances and rely on up-to-date and supported components.

Be aware that:

  • Any issue reported in TheHive version 3.4.4 and lower, will be fixed on top of TheHive 3.5;
  • Any issue reported in Cortex version 3.0.1 and lower, will be fixed on top of Cortex 3.1.0.

This situation made us also add strong changes regarding our repositories for DEB and RPM packages. Read carefully what follows and find your situation to learn how to upgrade.

You are still using or plan to continue with Elasticsearch 6 ?

Upgrade to TheHive 3.4.4

  • apt update && apt install thehive if you are using debian subsystems;
  • yum install thehive if you are using RedHat, Fedora or CentOS.

If you are using docker image you need to specify the version. Get it by running the following command line:

  • docker pull thehiveproject/thehive:3.4.4-1

This version introduces a bug fix regarding the import of alerts having significant amount of observables.

Keep Cortex 3.0.1

3.0.1 is the last version of Cortex supporting Elasticsearch 6.x. So keep this version until you move to Elasticsearch 7.x.

You are using or plan to move to Elasticsearch 7.x ?

⚠️ DO NOT run an upgrade command on your system until your data has been migrated in Elasticsearch 7.x and Elasticsearch is running.

Upgrading an existing installation ?

Elasticsearch 7.x introduced changes that break our way of representing the data, so some updates need to be applied on the database configuration and on the index first.

We highly recommend reading carefully our dedicated migration guides before starting the upgrade process:

Obviously, we recommend testing this process on a testing environment before running it in production.

Running a fresh installation ?

To publish packages supporting Elasticsearch 7 and avoid anyone break his servers, we decided to create dedicated packages repository. To install TheHive 3.5.0, according to your Operating System, run the following processes.

Deb packages

After installing Elasticsearch 7.x, ensure your /etc/apt/source.list.d/thehive-project.list looks like this:

deb https://deb.thehive-project.org release main

Then, run following commands to install TheHive 3.5.0:

apt update
apt install thehive # or apt install thehive=3.5.0-1

and following commands to install Cortex 3.1.0:

apt update
apt install cortex # or apt install cortex=3.1.0-1
RPM packages

After installing and running Elasticsearch 7.x, ensure your /etc/yum.repo.d/thehive-project.repo looks like this:

[thehive-project]
enabled=1
priority=1
name=TheHive-Project RPM repository
baseurl=https://rpm.thehive-project.org/release/main
gpgcheck=1

Them, run following commands to install TheHive 3.5.0:

yum update
yum install thehive # or yum install thehive-3.5.0-1

And following commands to install Cortex 3.1.0:

yum update
yum install cortex # or yum install cortex-3.1.0-1
Docker image
  • TheHive 3.5.0:
    • docker pull thehiveproject/thehive:3.5.0-1
  • Cortex 3.1.0:
    • docker pull thehiveproject/cortex:3.1.0-1
Ressources

Again, we strongly invite you to read detailed installation instructions:

Docker image of Cortex 3.1.0

Important modifications have been introduced in the docker image of Cortex 3.1.0. This image does not come anymore with programs of Analyzers and Responders and their dependencies.

Cortex is able to run those programs with Docker when images exist. The default configuration included in the official docker image of Cortex uses our catalogs of images of Analyzers and Responders.

Running Analyzers and Responders directly in Cortex container (using “process” method) is still supported. You can include them in container thanks to the Docker volumes when you start the container. If they need dependencies, you can create your own Docker image from our official Cortex image. Below an example of Dockerfile that retrieves Analyzers and Responders like previous Cortex Docker image:

FROM thehiveproject/cortex:3.1.0-1
RUN apt-get update
RUN apt-get install -y --no-install-recommends                        \
        python-pip python2.7-dev python3-pip python3-dev              \
        ssdeep libfuzzy-dev libfuzzy2 libimage-exiftool-perl          \
        libmagic1 build-essential git libssl-dev dnsutils iptables
RUN pip2 install -U pip setuptools
RUN pip3 install -U pip setuptools
RUN git clone https://github.com/TheHive-Project/Cortex-Analyzers.git \
        /opt/Cortex-Analyzers
RUN for I in $(find /opt/Cortex-Analyzers -name 'requirements.txt')   \
    do                                                                \
        pip2 install -r $I || true                                    \
        pip3 install -r $I || true                                    \
    done

How to report issues

Please open an issue on GitHub if you’d like to report a bug for TheHive or Cortex. We will monitor those closely and respond accordingly. 

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Discord, or send us an email at support@thehive-project.org. We will be more than happy to help!

TheHive 3.5.0-RC1 and Cortex 3.1.0-RC1 are here!

Elasticsearch 7.0 can read indices created in version 6.0 or above. An Elasticsearch 7.0 node will not start in the presence of indices created in a version of Elasticsearch before 6.0.

https://www.elastic.co/guide/en/elasticsearch/reference/7.x/breaking-changes-7.0.html#_indices_created_before_7_0

Who could imagine what’s hiding behind this sentence ? 

To be honest, we managed to support Elasticsearch 7.x pretty quickly ! But only for new and recent installations and instances — read, initially installed with Elasticsearch 6.x. 

The harder part was ensure older instances, with indexes created  with Elasticsearch 5.x, can migrate smoothly like for previous migrations: «stop the application, update the database software, update application and restart everything ». You might have to put your hands on the keyboard.

Source: Google Images

⚠️  TheHive 3.5.0-RC1 and Cortex 3.1.0-RC1 are not recommended for production use. These versions are intended for test only ; please, read carefully the full blog post and the associated documentation. Feel free to try it, try your migration and send us your feedbacks. 

New and recent installations

If your instance has been initiated with Elasticsearch 6.x, you can follow the following process : 

  • Stop TheHive version 3.4.2
  • Stop Elasticsearch version 6.x
  • Update Elasticsearch configuration file
  • Update Elasticsearch to version 7.x and restart the service
  • Update TheHive and restart the service
  • Update Cortex and restart the service 

Instructions to install TheHive 3.5.0-RC1 or Cortex 3.1.0-RC1 can be found in this guide.

At this stage, connect TheHive and Cortex with your browser and you should be invited to update the database : 

Older indexes

This is the tricky part. If you are using an instance initiated with Elasticsearch older that version 6.0, it is highly probable that you have to follow an heavier process to upgrade. In few words, you will have to :  

  • Stop TheHive and Cortex applications
  • Create new indexes in Elasticsearch 6.x with part of the settings of your current indexes
  • Do specific reindexing operations to this new indexes
  • Delete old indexes.

How to identify if your index is ready for Elasticsearch 7

You can easily identify if indexes are ready for Elasticsearch 7. On the index named the_hive_15 run the following command:

curl -s http://127.0.0.1:9200/the_hive_15?human | jq '.the_hive_15.settings.index.version.created_string'

If the version is 6.x.x then the index will be read by Elasticsearch 7.8.x. Otherwise (version is 5.x.x of below), reindexing the index is required.

Migration guide

You are not left alone there. A dedicated documentation is available. It should help you run this specific actions on your Elasticsearch database, and also install or update application whether you are using DEB, RPM or binary packages, and even docker images : 

https://github.com/TheHive-Project/TheHiveDocs/blob/master/admin/upgrade_to_thehive_3_5_and_es_7_x.md

How to report issues

Please open an issue on GitHub using the template made for TheHive 3.x if you’d like to report a bug on this version. We will monitor those closely and respond accordingly. 

ElasticSearch, TheHive and Cortex

For a few weeks, many questions have been arising regarding the End of Life of ElasticSearch 6.8, and its impact on TheHive and Cortex applications.

We were about to release TheHive 4.0-RC3 when Thomas, akwardly calmly announced to us, having found some time (where?) to review new features and most important, breaking changes introduced by ES7. We have now a good idea of what should be updated or added in the code, as well as the amont of work it represents to get the application working perfectly.

What about current version ?

Few months ago, we announced our intention to maintain current stable versions until ES6 End of Life. At that time, we didn’t expect it to be sooner.

Discontinuing TheHive 3.x with the release of TheHive 4.0 has never been in our plans. With the time, more and more organisations adopted them, and it is important for us to give everyone enough space to schedule and make the move to the TheHive 4.0. This is why TheHive 3 and Cortex 3 will support ES7.

The good news is our ability to announce that the changes introduced by ES7 have no major impacts on us, We are scheduling a first RC1 for TheHive 3.5.0 and Cortex 3.1.0 in the last week of July. Not only will they include support for ES7, but also a few interesting improvements that will be introduced in the coming blog posts.

What’s next ?

Needless to say, the chiefs are sparing no effort in focusing on TheHive 4.0, which requires a huge amount of attention. The application stack has completely changed – the most important adjustment is pushing aside ElasticSearch in favour of Cassandra to manage TheHive’s data storage – and thanks to the community, lots of bugs have already been fixed allowing it to be stronger with time.

Once we consider TheHive 4.0 reliable enough to be used in production, we will publish it as a stable version, and that would be in the coming days. After all, our plans are to make the applications use the same technology stack, which will directly benefit to the next major version of Cortex.

Besides, Cortex is scheduled to be upgraded and based upon Scalligraph, Cassandra and Hadoop. We hope to publish a first RC in few months.

Stay tuned sounds like TheHive Project’s Twitter account will be on fire 🔥 in the coming days!

TheHive 4.0-RC2, Fresh out of the Oven

Shortly after the release of TheHive 4.0 RC-1 in February 2020, many members of our community tested it and provided great feedback, spotting issues here and there. We would like to wholeheartedly thank all of those who, like us, want to make TheHive 4.0 a great, rock-solid release!

We are now happy to unveil the 2nd release candidate. It fixes many bugs and introduce – or reintroduce – some new (and old) features :-). In this blog post, we will concentrate on the following features:

  • 2FA
  • Age of cases
  • Reintroduction of webhooks

Please read the changelog for a more comprehensive view, including bugfixes.

And since the COVID-19 crisis is here to stay for quite some time, we don’t want you to rediscover boredom, a dreadful feeling long forgotten thanks to the continued stream of notifications, solicitations and attention-grabbing, 280 chars ‘thoughts’. So instead of getting bored, we invite you to test TheHive 4.0-RC2 to the best extent possible and, should you encounter any issue, please let us know. We want to issue the final release during the summer so that everyone can have it just in time for their forthcoming vacations at home!

2FA

Two factor authentication was initially scheduled for the final release. We changed our minds and decided to offer you the possibility to test this feature right away to gather your feedback and improvement ideas before we finish up baking the final recipe.

Users can enable 2FA from their account. To enable it, first go to your account Settings and check Enable Multi-Factor Authentication.

Once done, you are invited to use your preferred TOTP application (Google Authenticator, Authy, Microsoft Authenticator etc.) to scan the QR code or the code underneath it. Your 2FA will generate A TOTP that you should supply in the MFA Code area. If it is valid, 2FA will be activated.

Important notes:

  1. If a user loses access to their TOTP application, only an administrator can restore access to their account.
  2. If an org administrator loses access to their TOTP application and they are the only administrator for that org, only a super admin can restore access to their account.
  3. If a super admin loses access to their TOTP application and they are the only super admin of the instance, they should pack up their things and look for another job. That or use a magic DB command to restore access to their account. We’ll update the documentation accordingly.
  4. The current implementation of 2FA does not support backup codes or alternate authentication methods should a user loses access to their TOTP application. However, we are considering adding backup codes to the final release.
  5. 2FA cannot be enforced by default for all users at this stage. It is thus of rather marginal value. However, an org admin can see from the UI who did not activate it and pester them until they do. In the same way, a super admin can do the same for org admins, other super admins and mere users. We are updating the documentation to add an API query that will allow you to list all users who did not activate 2FA.
  6. We will consider making 2FA mandatory in TheHive 4.1.
2FA configuration view

Next time you log in, you will need to supply the TOTP verification code in addition to your login and password.

TOTP verification code required at login

Age of Cases

A new information regarding case duration has been added in the list of cases and in case view, so you can easily keep an eye on how old your cases are and activate your escalation procedures etc. if necessary.

Age of Cases in list view
Age of a Case in Case view

Webhooks are back!

TheHive 4.0-RC1 was released without webhooks. They have been reintroduced in this version. You can now configure TheHive 4.0 to use them, but also filter data sent to the remote server by Organisation.

How to report issues

Please open an issue on GitHub using the template made for TheHive4 if you’d like to report a bug on this version. We will monitor those closely and respond accordingly.

TheHive 4 is Here, Finally!


We have been speaking about it for almost two years.

We have been making it for more than twelve months.

And the day finally came for TheHive 4, our latest and greatest version, to be unleashed! The Chefs behind TheHive Project’s Code Kitchen are very happy to announce the immediate availability of TheHive 4.0, Release Candidate 1 (or 4.0-RC1 or the cool geeks call it).

Source: Berserk, écranlarge

Please note that a release candidate is not considered stable and must not be used in production. And since we almost rewrote TheHive from the ground up to accommodate all the nifty features outlined in a previous blog post, not to mention a few others we will cover in the upcoming weeks, we strongly recommend to take it for a spin on a test environment and help us uncover and fix bugs so we can release a stable version by April or May 2020.

Hmmm… I’d Rather Wait for a Stable Version

That’s your right but please don’t complain that, once released, the stable version is so buggy that it crashed your entire SOC operation and drove down the valuation of cryptocurrencies.

OK, OK… You Convinced Me. Where Should I Start?

Good! Well first things first. At this time, we produced documentation in kind of a rush while minding bazillion other things at the same time. We still need to proof-read it and enhance it.

If you are a seasoned TheHive user/contributor and you know what you are doing, please start with the installation guides for Debian or RedHat like operating systems. Then read the Quick start guide.

Noob warning: if you are completely new to TheHive, please use the latest stable version (3.4). TheHive 4.0-RC1 adds non-negligible complexity to accommodate advanced features such as RBAC and multi-tenancy and we will be very busy taking feedback from the intermediate/advanced users of our platform to make sure the stable version is rock-solid before we can recommend it to beginners.

You can find all the documentation we manage to write (more is coming) in the dedicated TheHive4 area of TheHiveDocs repository:

I’ve Just Tried it and Webhooks are Missing!

Nice catch Eagle Eye! Indeed webhooks have not been integrated in RC1. They will make a reappearance in a future RC, before the stable release. We have integrated them into a new notification system that is almost finished but still needs some elbow grease.

But Are you Going to Maintain TheHive 3.4.x when 4.0 will be Released?

You should know that bees will never let you down unless you gas them with pesticides (i.e. non-constructive feedback) and exigences (don’t forget that this is FOSS and we try to do the best we can, right?). So TheHive 3.4.x is scheduled to be maintained around two years after the release of 4.0 as a stable version, unless Elasticsearch 6.x is EOL’ed before that. In which case, we will have no choice but phase out 3.4.x (moving to ES 7+ will require a lot of work that we can put elsewhere).

Help!!! TheHive 4.0-RC1 Does not Work!

Please open an issue on GitHub using the template made for TheHive4 if you’d like to report a bug on this version. We will monitor those closely and respond accordingly.

Correction: March 3, 2020 
A new section regarding webhooks was added. In addition, a few typos were corrected.

Cortex-Analyzers 2.5.0: 142 Analyzers, 16 Responders

Shortly after the release of Cortex-Analyzers 2.4.0, TheHive Project’s code Chefs are happy to announce Cortex-Analyzers 2.5.0, a new Cortex analyzer & responder release which brings the total to 142 analyzers and 16 responders, up from 138 and 10 respectively!

We’d like to thank all the contributors for their precious work which will certainly provide more options to fellow cyber defenders and cyber threat intelligence analysts for improving their efficiency and focus on what really matters.

Source: https://dilbert.com/strip/2007-08-03

What’s New?

New Analyzers

New Responders

Analyzers

Clamav

Clamav is a powerful and open source antivirus engine that allows writing custom signatures using Yara and sigtool. @Hestat contributed with this analyzer that permits to TheHive to communicate with a local clamav-daemon.

A detailed configuration guide is available on Hetstat’s website.

Clamav short report for safe and malicious samples

IPVoid

Contributed by @jdsnape, this analyzer leverages the IP reputation check of apivoid.com, the API of www.ipvoid.com. As you can probably guess by its name, this analyzer can be used to enrich ip observables.

In order to use this analyzer, an account and a valid subscription to apivoid.com are required. An API key needs then to be provided.

TheHive displays the analyzer results as follows:

IPVoid analyzer short report
IPVoid analyzer long report

ThreatResponse

This analyzer lets you leverage the Cisco Threat Response service. Query Threat Response for verdicts and sightings for observables of type domain, filename, fqdn, hash (MD5, SHA1, SHA256), ip and url.

The analyser report lets you pivot into a Threat Response investigation of an observable.

Combining it with AMP for Endpoints Responder

It will extract the connector GUIDs as new observables to enable seamless use of the AMP for Endpoints Responder if a target is returned from the AMP for Endpoints module. It requires the AMP for Endpoints module to be configured in Threat Response.

A valid Cisco ThreatResponse subscription is required, and you have to provide your client ID and password information to use this analyzer.

TheHive displays the analyzer results as follows:

ThreatResponse analyzer short report
ThreatResponser analyzer long report

ThreatGrid

This analyzer queries Cisco Threat Grid for file, url, or hash and deliver analysis report. It also lets you pivot into the Threat Grid report to access more information related to Behavioral indicators or TCP/IP stream.

A valid Cisco Threat Grid subscription is required, and you have to provide hostname and api key to use this analyzer.

TheHive displays the analyzer results as follows:

ThreatGrid analyzer short report
ThreatGrid analyzer long report

Responders

AMPForEndpoints

This responders performs several actions on Cisco AMP for Endpoints. It comes in 5 flavors:

  • AMPforEndpoints_IsolationStart: Start Host Isolation.
  • AMPforEndpoints_IsolationStop: Stop Host Isolation.
  • AMPforEndpoints_MoveGUID: Move Connector GUID to a new group.
  • AMPforEndpoints_SCDAdd: Add SHA256 to a Simple Custom Detection List. TheHive’s case ID and description are appended to the description
  • AMPforEndpoints_SCDRemove: Remove SHA256 from a Simple Custom Detetion List.

A valid Cisco AMP for Endpoints subscription is required, and you have to provide the client id, api key and several context information to use this responder.

Redmine

Redmine is a free and open source, web-based project management and issue tracking tool. It allows users to manage multiple projects and associated subprojects. 

This responder, contribuited by srilumpa, can be used to create an issue in the Redmine ticketing system from a case. It will use the case title as the issue subject and the case description as the issue body.

To set it up in Cortex, you will need:

  • To define a user to allow Cortex to connect to Redmine and with access to the various projects in which issues should be created
  • Define three custom fields in TheHive that will be used to select the project, the tracker and, optionally, the assignee of the issue. These fields can be free form or can be custom fields with preset values.
Custom fields in TheHive for Redmine integration

At the moment the responder has few capabilities. If you need any other integration feel free to discuss on the pull issue.

Cortex responder output and corresponding issue in Redmine

Fixes

  • Umbrella Investigate [#698]

Get It While Supply Lasts!

If you are still using the old-style way of installing analyzers and responders, run the following commands:

cd path/to/Cortex-Analyzers
git pull
for I in analyzers/*/requirements.txt; do sudo -H pip3 install -U -r $I || true; done
for I in responders/*/requirements.txt; do sudo -H pip3 install -U -r $I || true; done

Once done, ensure to refresh your analyzers and responders in the Cortex WebUI. Connect as an orgadmin and go to the Organization menu. Click on the Analyzers tab and click on the Refresh analyzers button. Do the same for the Responders tab: click on the Refresh responders button. Refer to the online Cortex documentation for further details.

Update TheHive Report Templates

If you are using TheHive, you must import the new report templates in your instance as follows:

  • download the updated package
  • log in TheHive using an administrator account
  • go to Admin > Report templates` menu
  • click on Import templates button and select the downloaded package

Running Into Trouble?

Shall you encounter any difficulty, please join our user forum, contact us on Gitter, or send us an email at support@thehive-project.org. We will be more than happy to help!