by Robin Dost
Part 4 of 7 of building the Malwarebox Ecosystem
Website: https://iimql.malwarebox.eu
GitHub: https://github.com/MalwareboxEU/IIMQL

In the previous part, I introduced IIM, the Infrastructure Intelligence Model.

IOCs tell you what existed
ATT&CK tells you what adversaries do on endpoints
IIM describes how adversary infrastructure is composed

Entry points, redirectors, staging hosts, payload locations, C2 endpoints, relations between them, techniques attached to infrastructure roles, patterns abstracted from concrete observations

Basically the stuff that is usually buried inside analyst prose, screenshots, PDF diagrams and “we saw this kind of redirect chain again” comments

IIM gives that layer a structure

But once you have a structure, the next obvious question is:

How do you search it?

Because describing one chain is nice.
Describing ten chains is useful.
Describing a few thousand chains and then manually scrolling through JSON like a threat intelligence raccoon in a dumpster is not a workflow.

That is where IIMQL comes in.

IIMQL is the query language for the Infrastructure Intelligence Model.
It is built to search, filter and correlate IIM chains, roles, entities, relations and structural patterns in a way that actually fits the model.

IIMQL is for questions like:

• Show me every chain where a staging artifact drops a payload that connects to a C2.
• Show me every actor using dynamic DNS in the C2 role.
• Show me every chain where the entry point flows into a redirector before reaching a payload.
• Show me every payload that connects to infrastructure annotated with a specific IIM technique.
• Show me every infrastructure chain that looks like this shape, even if every domain, IP and hash changed.

That last part is the whole point.

IOC feeds let you ask: Is this domain bad?
IIMQL lets you ask: Have I seen this operational shape before?
That is a very different question.

And frankly, it is the question we should have been asking more often.

Why a query language?

IIMs whole pitch is that adversary infrastructure is structural.

• A campaign chain is not just a bag of domains, it is a directed graph.
• An entry point references or downloads a staging artifact.
• A staging artifact drops or executes a payload.
• The payload connects to a C2.
• A redirector may sit in between.
• A dead-drop resolver may point to the final endpoint.
• DNS may rotate.
• Hosting may rotate.
• The operator may burn the entire surface tomorrow and rebuild it with new artifacts.
  

The structure often survives.
And if the structure survives, you should be able to query it.
That sounds obvious, but in practice threat intelligence tooling often stops right before that point.

• We can store indicators.
• We can tag indicators.
• We can enrich indicators.
• We can export indicators.
• We can re-import the same indicators into another tool and pretend that interoperability happened.

But asking structural questions across infrastructure chains is still weirdly painful.

You either write custom Python, use a graph database directly, abuse a SIEM query language that was never designed for this, or convert the whole thing into a generic graph model and lose the IIM semantics on the way.

IIMQL avoids that.

• It is small on purpose.
• It speaks IIM directly.
• It does not try to become a general purpose graph query language.

IIMQL has one job:

Ask useful questions against IIM data.

The basic shape

Every IIMQL query follows a simple idea:

MATCH what you care about
WHERE the conditions are true
RETURN the fields you want back

For example:

MATCH chain

That returns chains.

MATCH chain WHERE actor_id = "MB-0001"

That returns chains attributed to a specific actor ID.

MATCH position WHERE role = "c2"

That returns positions where an entity plays the C2 role.

MATCH entity WHERE type = "domain" AND value =~ /duckdns/

That returns domain entities matching a regex.

MATCH relation WHERE type = "drops"

That returns relations where one artifact drops another.

Nothing exotic.
Nothing that requires a PhD in graph theory or three tabs of vendor documentation.

The interesting part starts when you query shapes.

Structural matching

IIM chains are directed graphs.

So IIMQL supports graph style matching for chain shapes.

Example:

MATCH (:entry)-->(:staging)-->(:payload)-->(:c2)

That asks for chains where an entry position flows into staging, then payload, then C2.

You can make it stricter by requiring relation types:

MATCH (:entry)-[:download]->(:staging)-[:drops]->(:payload)-[:connect]->(:c2)

Now the shape is not just role order.

It also requires a download relation, then a drops relation, then a connect relation.

That matters.

Because “entry to staging to payload to C2” is a useful broad shape.

But “entry downloads staging, staging drops payload, payload connects to C2” is much closer to an operational flow.

IIMQL lets you move between those levels without losing the model.

You can also use aliases:

MATCH (e:entry)-->(s:staging)
WHERE e.techniques HAS "IIM-T019"
RETURN chain.chain_id, s.entity.value

This asks for chains where an entry position with a specific IIM technique flows into staging, then returns the chain ID and the staging entity value.

That is the kind of query I wanted IIMQL to make boring.

Because this should be boring.

Analysts should not need to write custom scripts for every question that is structurally obvious once the data is modeled.

Targets: chain, position, entity, relation and graph shapes

IIMQL can query different levels of the model.

MATCH chain is for top-level chain metadata.

Useful for actor IDs, confidence, observed timestamps, review flags, imported sources and general filtering.

MATCH position is for role assignments.

This is where you ask things like:

• Which entities acted as C2?
• Which positions carry IIM-T008?
• Which staging roles are still tentative?
• Which payload positions appear in confirmed chains?

MATCH entity is for raw artifacts.

Domains, IPs, URLs, files, hashes, emails, certificates, ASNs.

This is the closest IIMQL gets to a classic IOC workflow, but with one important difference:
Entities can still be returned with chain and position context.

A domain is not just a domain.
It may be a redirector in one chain and C2 in another.
That distinction matters.

MATCH relation is for edges.

Download, redirect, drops, execute, connect, resolves-to, references, communicates-with.

This lets you ask questions about how infrastructure pieces interact, not just what they are.
And graph patterns are for the good stuff.
The operational shapes.
The part that survives rotation.

Field filtering

IIMQL supports the basic operators you would expect.

Equality:

role = "c2"

Inequality:

role != "entry"

Ordering:

sequence_order > 2

Regex:

value =~ /\.duckdns\.org$/

Array membership:

techniques HAS "IIM-T008"

Substring matching:

value CONTAINS ".example"

Set membership:

confidence IN ["confirmed", "likely"]

Boolean logic:

role = "c2" AND NOT needs_review = true

Again, boring by design.

My point is not to be clever, my point is to be precise 🙂

Example: finding fast-flux or DGA C2

Let’s say you have a corpus of IIM chains and want to find C2 positions that carry either Fast-Flux DNS or DGA technique annotations.

In IIMQL, that becomes:

MATCH position
WHERE role = "c2"
  AND (techniques HAS "IIM-T007" OR techniques HAS "IIM-T009")
RETURN chain.chain_id, chain.actor_id, entity.value, techniques

That is the difference between “I have data” and “I can ask operational questions against my data”.

The query is not looking for a known bad IP.
It is looking for a role in a chain with specific infrastructure behavior.

That is a completely different analytical layer.
And it maps directly to IIM’s purpose.

IIM technique IDs describe infrastructure behavior, not endpoint behavior.
So when you query for IIM-T007 or IIM-T009, you are not asking “which malware family is this”, you are asking “which infrastructure role carries this property”.

That makes the result usable for clustering, detection engineering, reporting and pattern abstraction.

Example: finding a known operational tail

Another simple query:

MATCH (s:staging)-->(p:payload)-->(c:c2)
RETURN chain.chain_id, p.entity.value, c.entity.value

This finds chains where staging flows into payload and payload flows into C2.’
That tail is common in real operations.
The concrete filenames, domains and IPs can all change.
The chain shape stays useful.

And if you want to be stricter:

MATCH (:staging)-->(:payload)-[:connect]->(:c2)

Now the payload must connect to the C2 through a connect relation.

This is where IIMQL becomes more than a filter language:
It lets you treat adversary infrastructure like a structured system.
Not a spreadsheet, not a blocklist, not a pile of JSON.
A system.

Why this matters for Malwarebox

IIMQL is part of the same larger idea as IIM, ACDP and Kraken.

• IIM gives adversary infrastructure a grammar.
• ACDP gives prioritization a methodology.
• Kraken is the working environment where actor infrastructure is tracked as a living graph.
• IIMQL is the thing that lets you ask questions across that graph without hardcoding the question into the platform.

You can publish patterns all day, but if another organization cannot match those patterns against their own chains, the value stays mostly theoretical.
IIMQL is the bridge between “we have a structural model” and “we can actually operationalize this”.

The long-term goal is a European CTI ecosystem that can track, model, query and share infrastructure intelligence without depending entirely on US vendor platforms, closed enrichment systems or PDF-based trust rituals from 2012.
But more about this in the next part of this series.

Federation needs queryability

In the IIM article I described the federation idea:

Org A observes a campaign.
Org A builds an IIM chain.
Org A abstracts it into a pattern.

Org B receives the pattern.
Org B matches it against their own observations.

The concrete domains, IPs and hashes may be completely different.
The structure still matches.

That is the whole “patterns instead of indicators” argument.
But for that to work at scale, you need queryability.

You need to be able to ask:

• Which of my chains match this shape?
• Which actor patterns overlap with my new observations?
• Which chains contain a redirector before payload delivery?
• Which C2 roles use the same infrastructure techniques across different campaigns?
• Which chains are confirmed and which are still tentative?
• Which entities are volatile artifacts and which structural roles keep reappearing?

Without a query layer, every participant in a federation has to reinvent the matching logic locally.

The query language is not just a convenience feature, it is part of making IIM usable as a shared analytical layer.

Local first, no runtime dependency circus

IIMQL is implemented in Python and currently has no runtime dependencies beyond the standard library.

That is intentional.

I do not want a query language for CTI data that needs half of PyPI, a Java service, an Elasticsearch cluster, a graph database and a deployment diagram that looks like a hostage situation.

You can install it locally:

git clone https://github.com/Mr128Bit/IIMQL
cd IIMQL
pip install -e .

Then run queries from the CLI:

iimql 'MATCH position WHERE role = "c2"' examples/chains/

You can query from a file:

iimql -f examples/05-fast-flux-c2.iimql examples/chains/

You can return JSON:

iimql --format json 'MATCH entity WHERE type = "domain"' examples/chains/

You can count matches:

iimql --count 'MATCH (:entry)-->(:payload)' examples/chains/

You can pipe chains in:

cat examples/chains/*.json | iimql 'MATCH chain WHERE actor_id = "MB-0001"'

And you can use it as a Python library:

from iimql import parse, execute, load_paths, query_chains

docs = load_paths(["examples/chains/"])

q = parse('MATCH position WHERE role = "c2" AND techniques HAS "IIM-T008"')

for row in execute(q, docs.chains):
    print(row["chain"]["chain_id"], row["entity"]["value"])

That makes it easy to drop into existing SOC tooling, research notebooks, enrichment scripts, internal CTI pipelines or whatever other questionable Python folder has been running in production since 2019.

No judgement ^^

What IIMQL is not

IIMQL is not a replacement for SQL.

If your data is relational, use SQL.

IIMQL is not a replacement for Cypher.

If you already have a graph database and want general graph traversal, Cypher is mature and extremely good at that.

IIMQL is not a replacement for STIX Patterning.

STIX Patterning is for matching cyber observable patterns in STIX data.

IIMQL is not a detection language like Sigma or YARA.

It does not match logs or files.

It matches IIM documents.

IIMQL is also not an extension of the IIM specification.

IIMQL consumes IIM data.

It does not define new roles.

It does not define new relation types.

It does not define new technique vocabularies.

The model stays the model & The query layer queries the model.

That separation matters because otherwise every tool starts quietly changing the standard it claims to implement.

And that is how “interoperability” becomes a PowerPoint word.

Current limitations

IIMQL is still early.

The current version is intentionally small and there are limits.
No variable-length paths yet.

So this:

MATCH (:entry)-->(:payload)

means a direct edge.

It does not magically skip everything in between.
That is deliberate for the first cut because structural matching should be predictable before it becomes flexible.
No aggregation yet.

So no GROUP BY, COUNT by field, DISTINCT style reporting or sorting in the first implementation.

• No joins across chains yet.
• No MATCH pattern yet.

Patterns and feeds can be loaded, but queries currently run against chains.

Technique confidence and role confidence are readable, but there is no nice syntax sugar yet for questions like “show me chains where any position has tentative confidence”.

That will come later.

I would rather ship a small query language that behaves correctly than a big one that lies confidently.

Threat intelligence already has enough of that.

The design principle

The design principle behind IIMQL is simple:

Make structural infrastructure questions cheap.

• If an analyst sees a pattern in one campaign, they should be able to ask for that pattern across the corpus without writing a new parser.
• If a defender wants to find C2 roles using a specific infrastructure technique, that should be one query.
• If a researcher wants to compare actor tradecraft across rotations, they should not have to manually diff IOC lists.
• If a European public-sector team wants to exchange patterns without exposing victim-specific artifacts, they should be able to match those patterns locally against their own observations.

IIMQL is small, but it sits directly in that problem space.
It gives IIM data a usable query surface.

That is necessary if IIM is supposed to be more than a schema.

Why this belongs in the Malwarebox ecosystem

Malwarebox is slowly becoming a stack.

The direction is clear

The public frameworks stay open because they need review, adoption and criticism.
The private lab stays private where sensitive actor tracking and unfinished research can mature before it becomes public methodology.

That split is intentional.

Open frameworks need a place where mistakes are cheap.
Closed platforms need open interfaces if they are supposed to matter beyond one installation.

IIMQL is one of those interfaces.

It gives the open model a practical way to be used outside Kraken.
That matters because I do not want IIM to become “the format Kraken uses”.

That would be boring and useless.

IIM should be usable by researchers, SOC teams, CERTs, public-sector defenders, vendors, open-source projects and internal tooling.
IIMQL helps with that because it makes the data searchable without requiring the whole Malwarebox stack.

• Install the tool
• Load chains
• Run queries
• Break it

Tell me what is wrong.

That is a healthier path than pretending the first version is perfect because the logo looks official.

A small example of the bigger picture

Take a campaign where the concrete infrastructure rotates every few days.

• New domain
• New IP
• New payload hash
• New redirector
• Same operator logic

Classic IOC tracking sees change everywhere

IIM sees the chain:

entry
to staging
to payload
to dead-drop resolver
to dynamic DNS
to C2

IIMQL lets you ask for that shape:

MATCH (:entry)-->(:staging)-->(:payload)-->(:redirector)-->(:c2)

Or stricter:

MATCH (:entry)-[:download]->(:staging)-[:drops]->(:payload)-[:connect]->(:redirector)-[:resolves-to]->(:c2)

Then you can filter:

WHERE chain.confidence IN ["confirmed", "likely"]

And return what matters:

RETURN chain.chain_id, chain.actor_id, c.entity.value

That is the difference.

You are no longer asking whether one artifact is bad.
You are asking whether an operation behaves like something you already understand.

That is where infrastructure intelligence becomes more than indicator management.

Where do I find chains to query?

You can create your own chains or watch my IIM Feed Repository.
There's already some chains and patterns in there, but i'll continue to upload more in the future.
If you have patterns & chains you want to contribute, feel free to reach out or create a push request.

License

IIMQL is published under the Apache License 2.0.

Keep the license notice and attribution intact.

• Build with it
• Ship with it
• Break it properly

Next

Part five will pull the ecosystem together.

Kraken, IIM, IIMQL, ACDP and the broader Malwarebox direction.

As one loop:

• Observe infrastructure
• Model the chain
• Query the structure
• Prioritize defensively
• Feed the lessons back into the model

That is the actual point of the ecosystem.

Not collecting more data.
Everyone has more data.
The point is making adversary infrastructure understandable, comparable and queryable in a way that survives rotation.
And if that can help push a more independent European CTI ecosystem into existence, even better.

For now:

• Read the IIM article
• Try IIMQL
• Run it against the examples
• Write ugly queries
• Find the weird edge cases
• Open issues

That is how this gets better.

by Robin Dost

Part 3 of 7 of building the Malwarebox Ecosystem
Official Website: https://iim.malwarebox.eu
GitHub: https://github.com/MalwareboxEU/IIM

EDIT: I released part 4 / 7 “IIMQL – The Query Language for Adversary Infrastructure (4/7)“

Threat intelligence has a small problem.

We have more data than ever. Blocklists with millions of entries. Feeds that refresh every thirty seconds. Vendors that will happily sell you a TAXII endpoint streaming 200 indicators per minute, all guaranteed to be expired by the time your SIEM finishes ingesting them.

And somehow, with all this data, we still don’t really know what we’re looking at.

That’s not a tooling problem. It’s a structure problem. After enough time staring at infrastructure rotations from groups like Gamaredon and concluding that “shift everything daily” is in fact a coherent strategy when nobody has the language to describe what’s actually shifting, I decided to try and fix it.

This is part 3 of 7 on the Malwarebox ecosystem. We’re starting today with IIM, the Infrastructure Intelligence Model. Part 4 will cover IIMQL, the query language built on top of it. Part 5 will tie the whole thing together. ACDP already has its own write-up, so I’m leaving it out here.

Two pillars and a hole

Classical threat intelligence rests on two pillars.

On one side: IOCs. Domains, IPs, hashes. Concrete, actionable and useful for roughly the time it takes an attacker to spin up a new Cloudflare Worker. The half-life of a C2 domain in 2026 is somewhere between “a coffee” and “a long lunch.”
Blocklists describe what existed and not what will exist tomorrow.

On the other side: MITRE ATT&CK®. A genuinely good behavioral framework.
Stable, well-maintained, internationally adopted.
Tells you what adversaries do on endpoints, process injection, credential dumping, lateral movement.

What ATT&CK very deliberately does not tell you is anything about infrastructure.
Hosting, routing, resolution, gating, none of it lives in the model. That’s by design.
ATT&CK was never meant to describe how a phishing redirect chain is composed.

So here’s the picture:

On one side, you have millions of indicators that go stale before lunch.
On the other side, you have a few hundred techniques describing adversary behavior, mostly from the endpoint perspective.
And in between sits the operational reality of how a campaign is actually delivered, routed, staged, resolved, gated and defended.
That layer is still mostly captured in analyst writeups, vendor reports and free-form descriptions.

• There are standards for exchanging threat intelligence
• There are frameworks for describing adversary behavior
• There are platforms for storing indicators

But there is no widely adopted, infrastructure-focused model for describing the logic of a delivery chain itself.

• There are standards for exchanging threat intelligence.
• There are frameworks for describing adversary behavior.
• There are platforms for storing indicators.

But

• No shared vocabulary for saying what role a host plays
• No consistent way to distinguish an entry point from a redirector, a staging host, a payload location or a C2 endpoint
• No clean structure for expressing how those pieces relate to each other over time

So the same patterns keep reappearing in analyst notes, vendor whitepapers and PDF reports, just described with slightly different words.

Adversaries operate as systems.

We have been treating those systems as events too much imo.

What “infrastructure” actually means

Quick definition. Because everyone in TI uses “infrastructure” to mean something slightly different and that’s part of the problem.

When I say infrastructure, I mean everything between the adversary and the click:

• Where things are hosted
• How DNS resolves
• How traffic is routed
• Who is allowed to reach which node
• How the chain is composed and ordered
• …

This is the layer that survives a sample being detonated, a hash being burned, an IOC list being published. The specific URL changes weekly.
The fact that there is a Cloudflare Worker in front of an HTA-dropping nginx behind a domain that resolves through RegRU, that pattern often survives.

That pattern is what IIM tries to describe.

Six concepts, one chain

IIM is small on purpose.
Six concepts, four primitives, two abstractions.
If a model needs three pages to explain itself, nobody is going to use it easily and I have personally read enough threat intel framework PDFs to consider this a moral position

Entities are the facts. A URL, an IP, a domain, a file hash, a TLS cert.
Pure observation, no interpretation.
An entity exists, has identity and has timestamps. That’s it.

{
  "id": "e3",
  "type": "url",
  "value": "https://worker.example.dev/r",
  "first_seen": "2026-04-10T12:00:00Z"
}

Roles give an entity meaning in context.
The same Cloudflare Worker can be an entry point in one campaign and a redirector in another.
Roles live on the chain position, not the entity itself.
That means: The role isn’t a property of the artifact. The role is what the artifact is doing in this particular operation.

The role catalog is small: entry, redirector, staging, payload, c2.
Five positions, because when I tried to add more I couldn’t honestly justify any of them.

Relations are the actual interactions.
download, redirect, drops, execute, connect, resolves-to, references, communicates-with

Critically: relations carry evidence.
They are observed, not assumed.
If you can’t tell me when and how you saw the redirect, the relation doesn’t go in the chain. We have enough threat intel that’s “well, probably” already.

Techniques are the reusable infrastructure patterns. CDN Abuse, Fast-Flux DNS, Geofenced Delivery, Multi-Hop Redirect, Dead-Drop Resolver.
Twenty-six of them in v1.1.
The catalog will grow, but only when something new actually shows up in the wild.

The thing to internalize: IIM techniques describe infrastructure, not behavior. They are deliberately complementary to ATT&CK, not competitive. If your technique describes what happens on the endpoint, it belongs in ATT&CK. If it describes how traffic flows, where things are hosted or who is allowed to reach what, it belongs here. The two catalogs sit on different axes by design.

Chains are concrete observations. A specific campaigns specific infrastructure at a specific time, modeled as an ordered sequence of role positions, each carrying entities and techniques. (it isn’t as complex as it sounds ^^)
Chains describe what was actually seen.

Patterns are chains with the entities stripped out.
Just the structural fingerprint: role sequence, techniques, match semantics.
Patterns are what you share when you want to publish “this is what these guys infrastructure looks like” without having to ship a list of IOCs that will be dead soon.

That’s the whole model.
Six concepts, deliberately small.

A real example

Let’s run Gamaredon through it.

Scale: an active operation against Ukrainian government and military targets, abusing CVE-2025-6218 to place an HTA loader into the Startup folder without user interaction.

In IIM terms, the chain is not interesting because of one specific domain, one Telegram channel or one IP address.

It is interesting because of the operational shape.

The observed chain looks like this:

entry       > UA government / military-themed spearphishing lure
staging     > RAR archive abusing CVE-2025-6218
staging     > HTA file placed in the Startup folder
redirector  > masqueraded URL using president.gov.ua-style userinfo
payload     > Pteranodon Stage-2 loader
redirector  > Telegram dead-drop channel: oberfarir
redirector  > Telegram dead-drop channel: natural_blood
redirector  > dynamic DNS host: document-downloads.ddns.net
c2          > resolved Telegram-provided endpoint: 194.67.71.75
c2          > resolved Telegram-provided endpoint: 45.33.16.183

The chain contains ten role positions:

entry         > UA gov/military-themed spearphishing sender
staging       > RAR archive triggering CVE-2025-6218
staging       > HTA dropped into Startup
redirector    > URL abusing trusted-looking Ukrainian government branding
payload       > Pteranodon Stage-2 loader
redirector    > Telegram channel used as dead-drop resolver
redirector    > second Telegram channel used as dead-drop resolver
redirector    > dynamic DNS redirector / resolver
c2            > C2 endpoint
c2            > additional resolved C2 endpoint

Techniques attached:

entry          IIM-T019, IIM-T008
staging-1      IIM-T023
staging-2      -
redirector-1   IIM-T006, IIM-T008, IIM-T020
payload        -
redirector-2   IIM-T006, IIM-T013
redirector-3   IIM-T006, IIM-T013, IIM-T023
redirector-4   IIM-T006, IIM-T008, IIM-T020
c2-1           -
c2-2           -

What matters here is the split between volatile infrastructure and reusable structure.

The Telegram channels can rotate. The Dynamic DNS host can disappear. The bulletproof hosting endpoint can be replaced. The loader can be recompiled. The lure, archive name, HTA filename, Telegram channels, DynDNS domain and final IPs are all replaceable pieces.

But the backbone remains visible:

spearphishing entry
  -> archive-based staging
  -> Startup-folder HTA persistence / loader execution
  -> trusted-looking redirector
  -> Pteranodon loader
  -> Telegram dead-drop resolution
  -> dynamic DNS / hosted C2 infrastructure

That is the point of modelling this as infrastructure behavior instead of just collecting indicators.

If you only track the IOCs, every rotation looks like a new campaign. A new Telegram channel, a new DynDNS hostname, a new IP address, a new loader hash.

If you track the pattern, it looks different.

It becomes the same operational design with swapped components.

And that is exactly the layer IIM is meant to describe: not just what was observed, but how the infrastructure was composed, how the pieces related to each other and which parts of the chain are actor tradecraft rather than disposable infrastructure.

Here’s a visual representation of the chain as SVG.

If you want to try yourself, here’s the chain, you can visualize it yourself within the IIM Workbench.

{
  "iim_version": "1.1",
  "chain_id": "gamaredon-2025-zero-click-rar",
  "entities": [
    {
      "id": "e1",
      "type": "file",
      "value": "<UA gov/military-themed spearphishing sender>"
    },
    {
      "id": "e2",
      "type": "file",
      "value": "*.rar (CVE-2025-6218 trigger archive)"
    },
    {
      "id": "e3",
      "type": "file",
      "value": "<docname>.HTA in Startup folder"
    },
    {
      "id": "e4",
      "type": "url",
      "value": "http://president.gov.ua@readers.serveirc.com?/gss_11.11.2025/kidneyfih/broadlyrQZ.pdf"
    },
    {
      "id": "e5",
      "type": "file",
      "value": "Pteranodon (Stage-2 loader)"
    },
    {
      "id": "e6",
      "type": "url",
      "value": "https://www.telegram.me/s/oberfarir"
    },
    {
      "id": "e7",
      "type": "url",
      "value": "https://www.telegram.me/s/natural_blood"
    },
    {
      "id": "e8",
      "type": "url",
      "value": "document-downloads.ddns.net"
    },
    {
      "id": "e9",
      "type": "url",
      "value": "194.67.71.75"
    },
    {
      "id": "e10",
      "type": "ip",
      "value": "45.33.16.183"
    }
  ],
  "chain": [
    {
      "entity_id": "e1",
      "role": "entry",
      "techniques": [
        "IIM-T019",
        "IIM-T008"
      ]
    },
    {
      "entity_id": "e2",
      "role": "staging",
      "techniques": [
        "IIM-T023"
      ]
    },
    {
      "entity_id": "e3",
      "role": "staging",
      "techniques": []
    },
    {
      "entity_id": "e4",
      "role": "redirector",
      "techniques": [
        "IIM-T006",
        "IIM-T008",
        "IIM-T008",
        "IIM-T020"
      ]
    },
    {
      "entity_id": "e5",
      "role": "payload",
      "techniques": []
    },
    {
      "entity_id": "e6",
      "role": "redirector",
      "techniques": [
        "IIM-T006",
        "IIM-T013"
      ]
    },
    {
      "entity_id": "e7",
      "role": "redirector",
      "techniques": [
        "IIM-T006",
        "IIM-T013",
        "IIM-T023"
      ]
    },
    {
      "entity_id": "e8",
      "role": "redirector",
      "techniques": [
        "IIM-T006",
        "IIM-T008",
        "IIM-T020"
      ]
    },
    {
      "entity_id": "e9",
      "role": "c2",
      "techniques": []
    },
    {
      "entity_id": "e10",
      "role": "c2",
      "techniques": []
    }
  ],
  "relations": [
    {
      "from": "e1",
      "to": "e2",
      "type": "references",
      "sequence_order": 1
    },
    {
      "from": "e2",
      "to": "e3",
      "type": "drops",
      "sequence_order": 2
    },
    {
      "from": "e3",
      "to": "e4",
      "type": "resolves-to",
      "sequence_order": 3
    },
    {
      "from": "e4",
      "to": "e5",
      "type": "drops",
      "sequence_order": 4
    },
    {
      "from": "e5",
      "to": "e6",
      "type": "connect",
      "sequence_order": 5
    },
    {
      "from": "e5",
      "to": "e7",
      "type": "connect",
      "sequence_order": 6
    },
    {
      "from": "e5",
      "to": "e9",
      "type": "connect",
      "sequence_order": 7
    },
    {
      "from": "e8",
      "to": "e9",
      "type": "resolves-to",
      "sequence_order": 8
    },
    {
      "from": "e6",
      "to": "e10",
      "type": "resolves-to",
      "sequence_order": 9
    }
  ],
  "confidence": "confirmed",
  "observed_at": "2025-11-22T00:00:00Z"
}

“But isn’t this just STIX?”

No. And this is the section where I save you the GitHub issue.

STIX 2.1 is an exchange format. It defines objects (indicators, infrastructure, attack-patterns, relationships) and lets you serialize them into bundles you can ship between tools. STIX is excellent at what it does. It’s also explicitly not a model of how an operation is structured.

The STIX Infrastructure SDO has a name, a description, an infrastructure_types tag and some first/last seen timestamps.
That’s it.
No notion of a position in a chain. No notion of “this redirector comes after that entry point.” No notion of techniques attached to a specific role. STIX relationships connect any two objects with a flat verb uses, consists-of, related-to and any ordering or semantic position has to be expressed in free text or vendor-specific extensions, which means in practice it isn’t expressed at all.

IIM exports to STIX losslessly. A chain becomes a bundle of Infrastructure objects with x_iim_* custom properties, plus relationships, plus attack-patterns for the techniques.
The reverse direction, STIX to IIM, is an enrichment workflow, not a conversion, because STIX doesn’t carry the information IIM needs and we shouldn’t pretend it does.
Anything inferred on import gets marked tentative and needs_review: true. No silent upgrades.

Diamond Model has four vertices: adversary, capability, infrastructure, victim. “Infrastructure” is one vertex. One. The whole thing collapses into a single bucket.
Diamond is a fine high-level analytical model, but if you try to express how the infrastructure was actually composed in a Diamond representation, you end up writing a paragraph in a notes field. IIM is what happens when you zoom into the infrastructure vertex and give it real structure.

MISP and OpenCTI taxonomies let you tag an IP as c2 or a domain as redirector.
That’s helpful and IIMs role catalog is partially aligned with those tags on purpose. But tagging is flat. You can tag a thousand IPs as C2 and never express that twelve of them rotate through the same dead-drop resolver while the rest don’t.
Tags describe artifacts.
IIM describes operations.

ATT&CK I already covered. Different axis. Same campaign, different facets. Use both.

The principle I stuck to throughout: don’t replace mature standards, fill the gap they don’t cover.
Composability over reinvention.
There’s enough threat intel work to do without forcing everyone to migrate off STIX again.

Why this matters

Here’s the operational case for caring about any of this.

If you’re a defender and you treat every rotation as a new event, you will spend the rest of your career re-blocking the same operation. You will write the same incident report seven times. Your detection coverage will look like a list of last weeks domains, because that’s exactly what it will be.

If you have a structural model, you can ask different questions. Have we seen this shape before? Does the new infrastructure cluster with the previous campaign at the pattern level? Are the same operators behind it, even though every artifact is new? These are the questions that actually matter when the artifacts are gone within hours.

IIM is not the only way to ask those questions. But it’s a way to ask them in a vocabulary that’s the same on Tuesday as it was on Monday and that lets you compare your observations to mine without us having to first agree on what the words mean.

Federation or: why this actually scales

Here’s the part nobody talks about until it’s been built: the actually interesting property of a structural model is what happens when more than one person uses it.

Threat intel sharing today is broken in a very specific way. We share IOCs through MISP, ISACs, vendor feeds and mailing lists. The IOCs are stale by the time they arrive. When we try to share something more durable, TTPs, actor profiles, narrative reports, the format is a PDF.
PDFs do not match against telemetry. Your SOC analyst opens the PDF, ctrl-Fs for “domain,” and copies the obviously-already-burned indicators into a watchlist. We are still doing this in 2026.

What an IIM federation enables, in one sentence: share patterns instead of indicators and the patterns are still good after the rotation.

Concretely. Org A observes a campaign, builds an IIM chain, abstracts it to a pattern (entities stripped, structure preserved) and publishes it. Org B receives the pattern and matches it against their own observations. Org B might be sitting on completely different domains, different IPs, different hashes and still get a hit, because the shape of the operation matches. The same operators with new clothes.
Pattern-level matching survives rotation by definition.

A few things follow from this:

Sharing scales because patterns don’t expire. A pattern published in March is still useful in November, because the structural fingerprint is what the actors are bad at changing. Their hosting provider rotates daily. Their composition logic rotates roughly never. Once you have ten or twenty good patterns for a group, you can attribute new infrastructure to them within minutes of seeing it, regardless of whether any of the indicators have ever been seen before.

Privacy gets easier, not harder. Patterns have no entities. There are no victim domains, no internal IPs, no attributable hostnames. This bypasses an enormous fraction of the “we can’t share because legal” friction that kills useful TI exchange today. Particularly relevant under GDPR, where IOC sharing involving any kind of victim-identifying data is a pain.
At the end it’s your decision if you share your full chain or just a pattern, both have their worth.
Patterns are PII-free by construction.

Attribution becomes contestable. Right now actor attribution is a process that still requires a lot of manual aggregation and verification. With pattern-level federation, you can publish the patterns you used to cluster and someone else can argue with the clustering. This is how science works.

The network effect actually kicks in. Every additional participant in an IIM federation increases the match rate for everyone else, because the same actor groups hit multiple targets. With IOC sharing, the network effect is muted because IOCs burn fast. With pattern sharing, the network effect compounds.

No central authority required. A federation is not hub-and-spoke. There’s no need for a central database, no single point of failure. Every participant publishes their own patterns from their own infrastructure, signed and timestamped. You consume the patterns from the participants you trust. This is structurally different from how most TI sharing currently works and structurally important if you take sovereignty seriously.

The federation layer is what makes the model worth more than the sum of its installations.
A single org running IIM in isolation gets some structural benefits.
A hundred orgs running IIM with shared patterns gets the actual prize: a defensive intelligence ecosystem that doesn’t rot every Tuesday.

Joining a federation is roughly as hard as validating a JSON file: no central registry to negotiate with, no shared infrastructure to maintain, no legal review of victim data because patterns have none and no vendor sitting between you and the people you actually want to share with.

What’s actually built

IIM v1.1 is published as a draft. Spec, JSON schema, technique catalog, reference chains and bidirectional STIX 2.1 tooling are all on GitHub. Composes with the standards you already use; doesn’t try to replace them.

There’s also a Workbench: a local and web tool for building, validating and exporting IIM chains. Runs on your machine, doesn’t phone home, ships with the technique catalog baked in. Use it to model a campaign you’re working on, sketch a pattern for sharing or just play with the model to see if it makes sense.

If a technique you need isn’t in the catalog, open an issue. If a role definition is wrong, even better, open an issue with a specific case it doesn’t handle.
The model is a draft for a reason. I’d rather get it right than get it done fast.

Open core, closed lab

IIM is one piece of Malwarebox, an independent CTI research initiative I’m building in Europe, publishing open frameworks and methodologies for a corner of threat intelligence that doesn’t really have an open ecosystem yet.

The model is roughly open core, with one important inversion.
The frameworks IIM, ACDP, the schemas, the catalogs, the reference implementations are open. They have to be.
You can’t ask the community to standardize around something they can’t review.

The closed part is Kraken, the working environment behind the research, the platform where adversary infrastructure is actually tracked as a living graph. Kraken stays closed for now and access goes through vetting. Not because closed tooling is the goal, but because some research needs to mature somewhere private before it shapes the public frameworks. Open frameworks need a place where mistakes are cheap.
Kraken is that place.

Why bother with any of this?
Two reasons.

First: civilian threat intelligence research in Europe is structurally underfunded compared to the US, where commercial vendors and government programs subsidize a lot of public work.
We’ve been importing that work for a decade. It worked, mostly.
It has also shaped what European defenders can see and what they can’t and it has made independent research a hobby rather than a profession on this side of the Atlantic.
Open frameworks are one small lever for changing that, they give independent researchers a vocabulary and a publication target that doesn’t require a vendors marketing approval.

Second: a real European CTI federation doesn’t exist yet.
There are bilateral exchanges, sectoral ISACs, vendor-mediated feeds, EU-level initiatives.
None of them constitute a federation in the sense the previous section described.
Building one isn’t a tooling problem.
It’s a structural problem, a trust problem, a vocabulary problem and a sovereignty problem.
IIM is the vocabulary piece. ACDP is the methodology piece. Kraken is the working environment that puts them through their paces.
Together they’re an attempt to be a foundation 🙂

Next

Part four will cover IIMQL the query language that sits on top of IIM.
Once you have a structural model, the next obvious question is “okay, but how do I actually search through thousands of these chains for the patterns I care about.”
That’s what IIMQL is for and it’s where things get more interesting.

Part five will be the partial Malwarebox ecosystem write-up Kraken, IIM/IIMQL, ACDP and how the loop between them is supposed to work in practice.
With a slightly heavier emphasis on the “why this is built in Europe and stays in Europe” argument, because that one deserves its own piece.
All these components are just part of what I’ve actually built and a fraction of what’s planned :3

For now: read the spec, try the workbench, break the model, tell me what’s wrong with it.
You’ll find more real-world examples in the IIM repository soon.

If you want to contact me for feedback or anything else, you can reach me via contact@robin-dost.de

License

IIM is published under the Apache License 2.0.

The reason is simple: IIM is meant to be used.

It should be possible for researchers, vendors, public-sector teams, open-source projects, internal SOC platforms, detection pipelines and threat intelligence tools to adopt the model without asking for permission first.

Apache 2.0 allows free use, modification, distribution and integration, including in commercial products, while still preserving attribution and providing a clear patent grant. That makes it a practical license for an infrastructure intelligence model that is supposed to become interoperable, not decorative.

In short:

You can use it.
You can build on it.
You can integrate it into your own tooling.
You can ship products with it.

Just keep the license notice and attribution intact.

That is the point.

Resources