Introducing the Morado Analytics Engine

September 6, 2026

Written by

Morado Skunkworks

TAGS

analytics, threatintel

Alright, this was too cool to not write a blog post about, so we put this together over the weekend to talk about something cool we’ve been working on over here in the Morado Skunkworks department.

For the last year or so, we’ve been trying to come up with better ways to present information, or make that information more available to analysts to do what they want with it. We have a pretty robust API built out now that supports just general inquiries into the data, like what are my most recent alerts, or the latest IOC’s from a particular threat group. That’s all well and good, but we needed something better.

Since our backend is STIX-powered, meaning EVERYTHING is a STIX object (yes, we mean everything), and all those objects are connected via STIX relationships. This is where things get cool, because we’ve developed and are including an Analytics module in the platform that allows analysts to use that data in some pretty interesting ways we don’t typically see in other platforms. The even cooler thing about all this, is that this data spans Digital Risk, Dark Web, OSINT, CTEM, and you are able to interrogate it all under this module.

The language itself is a custom one developed that is like if Splunk and Storm had a baby. Storm-esque style lifts pull the data into the page, and then Splunk-style pipes and functions do the rest.

Before getting into much else, let’s start by taking a look at this capability and see what we are working with.

I want to start by saying as a former Analyst, I would have longed for a platform like this, along with a capability like this, so this is just making me super excited to be able to do stuff like this. So, back to the query - I want to reiterate that we are able to do some cool analytics over ALL of our data, which includes things like compromised credentials, ransomware breaches, TTP’s, dark web content, etc. so we can just start with something like, “Show me all incidents impacting Manufacturing”

That’s all well and good, we can pivot into the results here and get more context, push the content to a report, add to an investigation, analyze, whatever else. But we can keep going and find out some interesting things, like:

This is now introducing a “join”, which allows us to pull in any STIX relationships of a certain type (“attributed-to”), against a particular type of object (“threat-actor”), and then we join those threat groups against the Vulnerabilities they are targeting. Lastly, we only want the ones back that are known to CISA or other vendors as being a Known Exploited Vulnerability (KEV).

Boom. That’s a prioritized list of exploited vulnerabilities being seen in the Manufacturing industry. We could then take that, and do another join against where we have CTEM assets with those vulnerabilities identified on by joining against “my_assets”. Game changer in my eyes.

Another example:

Let’s say we are worried about ShinyHunters and think we are a likely target of theirs, let’s pull up their TTP’s and then view where we have no coverage (detection signatures or security tooling) for those particular TTP’s, so we can prioritize our detection gaps.

Get a whole bunch of relevant results and want to easily tag all of those nodes? “| tag ransomware” and it’ll tag the results with that tag for later analysis and processing.

Here’s another cool example for hunting:

Let’s look through our compromised credentials and identify the most common breaches where our credentials appeared. This isn’t necessarily a major vendor breach, but just the filenames that contained those credentials. Looking at these results, we can see some interesting dumps, and this can potentially help us narrow our focus for how these machines were compromised initially, or if there are other larger issues at play.

The language itself was cool as it was, and served a need, but then Jordan had a great idea - what if these served as the alerting mechanisms for generating alerts?

That was the lightbulb moment, since up until that point, we had a list of around 20 or so pre-canned alerts that were tied to particular events that warranted alerts like new compromised hosts, or new suspicious domains registered, which worked good as alerts, but didn’t allow for much flexibility beyond that.

That’s where the beauty of this language comes into play, because we can now create pretty complex analytic queries and have alerts generated from whatever results are returned from that query. So, instead of just one alert for a new compromised host, we can now filter that down a little bit to only show compromised credentials for a particular host, or only ones for owned assets. This provides the customization options for users to tune alerts as necessary, which unlocks so many new opportunities.

Being able to query across all aspects of threat intelligence in one platform using this type of language is pretty rad in my opinion. “Have any threat groups been linked to potentially impersonating domains of ours?” “What stealer malware family is most commonly seen as the stealer used on victim machines, and what are the CVE’s most commonly exploited by that malware family?”

Well, that’s easy now:

We are just scratching the surface of the capabilities of this feature in a platform like ours, and I’m excited for the next release when we can include this feature.