Karasu Spreads Its Wings — From Blog to MISP

Ever read a Threat Intelligence blog post and thought to yourself "Hmm this is useful information, I should probably ingest this into MISP" only to shift to a different task and never actually get around to it? Karasu aims to support security professionals by leveraging AI to perform the initial heavy lifting in order to transform blog posts or whitepapers into easily structured MISP events.

Design and complexity of the application are intentionally kept lightweight. After authenticating, a simple dashboard is ready to start lifting those Threat Intelligence weights.

Simply paste a URL in the text box and press the Submit button.

In the background Karasu will fetch the content, after which navigation bars, ads, sidebars and the like are stripped. Another round of clipping and condensing is done by removing HTML tags, excessive new lines or multi spaces. What remains is a readability-stripped, tag-stripped, white-space-normalized text which is stored in the database.

Now that we have this letter soup, it is automatically fed to an LLM in order to start extracting relevant data points. Once this process completes, the status will be updated accordingly.

Step one has been completed; step two is where the human review starts. By clicking on one of the extracted URLs, different tabs appear. These are all pre-populated by the LLM.

In the first tab Metadata is displayed along with a short summary of the parsed content.

If there are indications referencing specific sectors or countries, or if attribution to certain actors is done, this data will also be displayed. There is (should be) no inference from the LLM itself regarding targets or Threat Actors. This data needs to be explicitly mentioned in the parsed content itself.

It will come as no surprise that in the IOCs tab the different Indicators of Compromise are listed. The To IDS flag concept from MISP is also incorporated. This way relevant information can still be shared inside the event without blowing up detection engines with incorrect alerts. Next to the actual IOC value there's a small description in order to provide some contextual information. If a human analyst at any point disagrees, simply uncheck the To IDS flag or remove the IOC entirely.

The Detection Rules tab extracts any rules which are mentioned in the content. It was surprisingly difficult to minimize the hallucinations or inference regarding this topic.

The TTPs tab is populated with MITRE ATT&CK based IDs & Technique names. There can (and will) be some inference from the LLM in this section; there's no clear requirement that the TTPs need to be specifically named in the extracted content (as opposed to Detection Rules & Targets). This allows for some interpretation and flexibility but also introduces the chance for hallucinations. Based on testing, the trade-off has been deemed beneficial.

Lastly the Threat Hunting tab provides, if applicable, hypotheses to perform threat hunts. This is one of the aspects where either the prompt is not yet fully fleshed out or the LLMs are struggling a bit. Getting a proper hypothesis & approach with the right level of extraction while not reverting to "look for malicious X or suspicious Y" remains a bit of a trial.

With that step two is completed and the only thing remaining is sending the data to MISP.

Before we can actually send data to MISP, a MISP API token needs to be configured for the logged on account. Simply click the username and paste the token in the relevant location.

Once this is done, navigate back to the extraction details and simply push the button.

Step three completed; your flight has been cleared for landing.

An important aspect is of course to have a brief look at how & in what format the event arrives in MISP. This post will assume some prior knowledge of the MISP interface.

The data is sent utilizing the API key which is configured for the user who clicked the push button. Based on this user certain attributes, such as Creator org & Owner org will be automatically assigned.

The first thing that draws the attention is the MITRE galaxy tags. These have been added based on the techniques listed in the TTPs tab. A second less colorful but important property to notice is the Date; this is set to when the event was first observed. If this data is missing the date of extraction will be used.

Scrolling down reveals a number of Event Reports.

These reports contain the Threat Hunting hypotheses and also receive the equivalent tag.

The information stored in the "Metadata" & "IOC" tabs is added as attributes with the configured To IDS flag (note, metadata information is never set To IDS).

A number of "attack-pattern" objects are also included in the event. These are basically the MITRE ID & Technique names as seen in the "TTPs" tab, but they also maintain the extra contextual information.

One might wonder why the double documentation of TTPs in both the Galaxy & Attack Pattern object? The Galaxy approach doesn't allow for that extra contextual information which, from my perspective, adds the necessary value.

That being said, this also ends the initial flight, stay tuned for more updates.

Karasu is open source and available at https://github.com/Sorakurai/karasu. Deployment requires Docker Compose, a MISP instance, and credentials for the supported LLM providers.