Malanta IOPA STIX/TAXII Feed

TAXII 2.1 · STIX 2.1 · Pre-Attack Indicators · Clusters · Relationships

Version 1.0 | October 2026

Contents

• Overview
• • Base URL
  • Collection
• Authentication
• Endpoints
• • Discovery
  • API root
  • List collections
  • Collection metadata
  • Get objects
  • Manifest
• Pagination and incremental sync
• Recommended sync use cases
• • Use case A — Full dump, then API intervals
  • Use case B — API full active set, then daily intervals
  • What not to do
• STIX object model
• • Indicator
  • Labels
  • • Classification
    • Always added by the feed
    • APT attribution
    • Other pass-through labels
    • Cluster labels
  • Cluster (intrusion-set)
  • Relationship
• Platform setup examples
• • OpenCTI
  • ThreatQ
  • Python
  • cURL smoke test
• Errors
• Limitations
• Quick reference

Overview

Malanta delivers pre-attack threat intelligence over TAXII 2.1 as STIX 2.1 objects. Use this guide to connect your TIP, SOAR, SIEM, or custom collector.

The feed exposes Malanta’s attack-infrastructure graph so you can:

• Ingest malicious / pre-attack indicators (primarily domains)
• See clusters of related attack infrastructure (intrusion-set)
• Follow relationships between indicators and clusters

Data is marked TLP:AMBER. Treat accordingly.

Support: support@malanta.ai

Base URL

Always start from the discovery URL. Discovery advertises the API root; do not hardcode alternate hosts unless Malanta tells you to.

Collection

The collection is read-only (can_read: true, can_write: false).

↑ Back to top

Authentication

All requests require your Malanta API key. Keys are prefixed with malanta_. A missing or invalid key is rejected before the request reaches the service (401/403).

Supported transports (first match wins):

Recommended: x-api-key.

Basic Auth is provided for platforms (for example ThreatQ) that only expose username/password fields. Put the API key in the password field; username can be anything non-empty.

Required headers

Accept: application/taxii+json;version=2.1
x-api-key: malanta_xxxxxxxxxxxxx

Responses use Content-Type: application/taxii+json;version=2.1 and include X-TAXII-Content-Type with the same media type.

Keep your API key private. Never expose it in frontend code, mobile apps, or public repositories.

↑ Back to top

Endpoints

Base: https://app.malanta.ai/feeds/taxii2

Trailing slashes are accepted. Prefer not relying on HTTP redirects; redirects can drop auth headers.

Discovery

Endpoint: GET /taxii2

Returns TAXII server information and available API roots.

Example request

curl --request GET \
  --url 'https://app.malanta.ai/feeds/taxii2' \
  --header 'Accept: application/taxii+json;version=2.1' \
  --header 'x-api-key: malanta_xxxxxxxxxxxxx'

API root

Endpoint: GET /taxii2/default

Returns API root metadata (supported versions, max content length).

List collections

Endpoint: GET /taxii2/default/collections

Returns available collections.

Example request

curl --request GET \
  --url 'https://app.malanta.ai/feeds/taxii2/default/collections' \
  --header 'Accept: application/taxii+json;version=2.1' \
  --header 'x-api-key: malanta_xxxxxxxxxxxxx'

Collection metadata

Endpoint: GET /taxii2/default/collections/{collection_id}

Path parameters

• collection_id — use pre-attack-indicators

Example request

curl --request GET \
  --url 'https://app.malanta.ai/feeds/taxii2/default/collections/pre-attack-indicators' \
  --header 'Accept: application/taxii+json;version=2.1' \
  --header 'x-api-key: malanta_xxxxxxxxxxxxx'

Get objects

Endpoint: GET /taxii2/default/collections/{collection_id}/objects

Returns STIX 2.1 objects in a TAXII envelope (paginated).

Path parameters

• collection_id — use pre-attack-indicators

Query parameters

Example request

curl --request GET \
  --url 'https://app.malanta.ai/feeds/taxii2/default/collections/pre-attack-indicators/objects?limit=2000' \
  --header 'Accept: application/taxii+json;version=2.1' \
  --header 'x-api-key: malanta_xxxxxxxxxxxxx'

Example response

{
  "objects": [ /* STIX 2.1 SDOs / SROs */ ],
  "more": true,
  "next": "<opaque-token>"
}

Response fields

• objects — STIX objects for this page
• more — true → call again with next; false → drain complete
• next — pagination token (present when more is true)

Response headers

Use X-TAXII-Date-Added-Last as the next added_after value for incremental sync.

Paginated request

curl --request GET \
  --url 'https://app.malanta.ai/feeds/taxii2/default/collections/pre-attack-indicators/objects?next=<token>' \
  --header 'Accept: application/taxii+json;version=2.1' \
  --header 'x-api-key: malanta_xxxxxxxxxxxxx'

Manifest

Endpoint: GET /taxii2/default/collections/{collection_id}/manifest

Returns object metadata without full STIX bodies. Same query parameters as Get objects (limit, next, added_after).

↑ Back to top

Pagination and incremental sync

Full drain (initial load)

1. GET .../objects?limit=2000
2. While response.more == true:
       GET .../objects?next=<token>
3. When more == false → collection fully drained for this cycle

Do not keep polling the final token. When more is false, the cycle is finished.

Incremental sync (deltas)

Start a new request with added_after set to the last watermark you observed (typically X-TAXII-Date-Added-Last from the previous successful sync):

curl --request GET \
  --url 'https://app.malanta.ai/feeds/taxii2/default/collections/pre-attack-indicators/objects?limit=2000&added_after=2026-04-01T12:00:00.000Z' \
  --header 'Accept: application/taxii+json;version=2.1' \
  --header 'x-api-key: malanta_xxxxxxxxxxxxx'

Then follow next until more is false, same as a full drain.

added_after must be valid RFC 3339. Invalid values return HTTP 400 with a TAXII error resource.

Object order

Within one drain cycle, objects arrive in this order across pages:

1. Indicators (reputation / observables)
2. Clusters (intrusion-set)
3. Relationships (indicator → cluster, type indicates)

A page never mixes streams; handoff to the next stream happens on the next HTTP call via next.

↑ Back to top

Recommended sync use cases

Pick one of these patterns for first-time onboarding, then stay on incremental API pulls. Do not invent a hybrid that starts mid-history with a date filter.

Important — clustering completeness. Your first load of the graph must be a complete baseline: either a Malanta full dump, or a TAXII drain with no added_after (empty date).

If the first TAXII call uses a specific added_after (for example “last 7 days”), you can lose clustering data. Older intrusion-set / relationship objects fall outside the window, while newer indicators may still appear — your TIP ends up with orphan indicators and a broken cluster graph. Only use added_after after a successful full baseline.

Use case A — Full dump, then API intervals

Best when: you need historical / inactive indicators as well as the live active set, and the full cluster graph in one shot.

[Full dump: active + inactive + clusters + relationships]
                ↓
        load once into TIP
                ↓
[TAXII] ?added_after=<watermark>  →  daily / hourly intervals

Contact your Malanta account team or support@malanta.ai to obtain the dump and confirm the handoff watermark.

Use case B — API full active set, then daily intervals

Best when: you only need the currently active feed via TAXII and do not require inactive history from a dump.

[TAXII] no added_after  →  full active baseline (indicators + clusters + relationships)
                ↓
        persist X-TAXII-Date-Added-Last
                ↓
[TAXII] ?added_after=<watermark>  →  every day (or chosen interval)

What not to do

↑ Back to top

STIX object model

Every page begins with a short preamble:

1. Malanta identity
2. TLP:AMBER marking-definition

Then the page’s feed objects.

Indicator

Supported observable types in patterns: domain-name, ipv4-addr, url, file (SHA-256).

Labels

Every indicator carries STIX labels so you can filter and prioritize in your TIP. Labels come from two places: always added by the feed, and passed through from Malanta’s reputation data when present.

Classification (always one of these)

Always added by the feed

APT attribution (apt:…) — when available

• APT is returned only via labels — there is no separate STIX APT field on indicators or clusters in this feed.
• Not every indicator has APT tags. If none are known, apt:… is simply omitted.
• Comma-joined values are split so TIP filters can match exactly: apt:APT17,APT5 → apt:APT17 + apt:APT5.
• Use apt:… for hunting, TIP tagging, and (with OpenCTI) connectors that map these labels to Intrusion Sets / Threat Actors.

Other pass-through labels (when available)

Upstream reputation labels are forwarded after normalization. Besides IOC / IOPA / apt:…, you may also see free-form or prefixed tags such as:

Treat unknown labels as opaque tags — keep them for filtering; do not drop the indicator because a label is unfamiliar.

Cluster labels (on intrusion-set)

Clusters use a fixed label set (not the indicator taxonomy above):

How to use this as a customer

• Prefer IOPA when you want Malanta’s early / predictive coverage (pre-attack).
• Prefer IOC when you want confirmed malicious indicators with external provenance.
• Many SOCs ingest both: IOPA for proactive blocking / hunting, IOC for correlation with existing TI feeds.
• Use source:… to attribute origin; use apt:… when present for actor-focused triage.
• Do not drop either class solely because the word “IOC” or “IOPA” is unfamiliar — both are first-class objects in this feed.

Cluster (intrusion-set)

A Malanta cluster is a group of related attack-infrastructure indicators that share ownership, certificates, or other linkage. In STIX it is published as an intrusion-set.

How to use this as a customer

• Treat each intrusion-set as a cluster of related infrastructure, not necessarily a named APT group.
• Join indicators to clusters via relationships (below) — do not invent joins from indicator labels alone.
• Keep clusters even if you primarily alert on indicators; without them the graph (and indicates edges) is incomplete.

Relationship

Edges that connect indicators to clusters. In this feed every relationship is type indicates: the indicator points at the intrusion-set it belongs to.

Direction

indicator  --indicates-->  intrusion-set (cluster)

How to use this as a customer

• Resolve source_ref / target_ref against objects already ingested (or pending in the same drain).
• Because object order is indicators → clusters → relationships, a full drain without added_after (or a dump baseline) keeps refs resolvable.
• STIX IDs for indicators, clusters, and relationships are deterministic (stable across days), so TIP snapshot diffs stay clean.

↑ Back to top

Platform setup examples

OpenCTI

1. Data → Connectors (or Ingestion) → add a TAXII 2 connector / feed.
2. Discovery URL: https://app.malanta.ai/feeds/taxii2
3. Auth: API key via x-api-key or Bearer, depending on connector fields.
4. Select collection pre-attack-indicators.
5. Enable periodic sync. Prefer connectors that honor added_after / date-added headers for deltas.

OpenCTI expects a finite drain (more: false) then a new poll with a time filter — that matches Malanta’s behavior.

ThreatQ

1. TAXII URL: https://app.malanta.ai/feeds/taxii2
2. Username: your org name or any placeholder
3. Password: your full malanta_… API key
4. Collection: pre-attack-indicators

Python

import httpx

BASE = "https://app.malanta.ai/feeds"
HEADERS = {
    "Accept": "application/taxii+json;version=2.1",
    "x-api-key": "malanta_xxxxxxxxxxxxx",
}

def drain_collection(collection_id: str, *, added_after: str | None = None):
    params: dict = {"limit": 2000}
    if added_after:
        params["added_after"] = added_after

    url = f"{BASE}/taxii2/default/collections/{collection_id}/objects"
    watermark = added_after

    with httpx.Client(headers=HEADERS, timeout=120.0) as client:
        while True:
            r = client.get(url, params=params)
            r.raise_for_status()
            body = r.json()
            yield from body.get("objects") or []

            last = r.headers.get("X-TAXII-Date-Added-Last")
            if last:
                watermark = last

            if not body.get("more"):
                break
            params = {"next": body["next"]}  # do not re-send limit/added_after with next

    return watermark

cURL smoke test

curl --request GET \
  --url 'https://app.malanta.ai/feeds/taxii2' \
  --header 'Accept: application/taxii+json;version=2.1' \
  --header 'x-api-key: malanta_xxxxxxxxxxxxx'

Expected: JSON with title, default, and api_roots.

curl --request GET \
  --url 'https://app.malanta.ai/feeds/taxii2/default/collections/pre-attack-indicators/objects?limit=10' \
  --header 'Accept: application/taxii+json;version=2.1' \
  --header 'x-api-key: malanta_xxxxxxxxxxxxx'

↑ Back to top

Errors

TAXII error bodies follow TAXII 2.1 error resources, for example:

{
  "title": "Invalid Query Parameter",
  "description": "...",
  "http_status": "400"
}

↑ Back to top

Limitations

• Collection object-by-id lookup resolves the Malanta identity and TLP:AMBER marking. Individual feed indicators / clusters / relationships are consumed via the paginated /objects stream.
• match[…] query filters may be accepted by the router; rely on collection choice + added_after for supported filtering unless Malanta confirms additional match support for your account.
• Feed is pull-only (no TAXII write / inbox).

↑ Back to top

Quick reference

• Discovery: https://app.malanta.ai/feeds/taxii2
• API root: https://app.malanta.ai/feeds/taxii2/default
• Collection: pre-attack-indicators
• Auth: x-api-key: malanta_xxxxxxxxxxxxx (also Bearer / Basic)
• Accept: application/taxii+json;version=2.1
• Baseline (once): full dump (active+inactive) or TAXII with no added_after (active only)
• Then intervals: GET objects?added_after=<watermark> → while more: follow next → stop
• Always baseline first before any dated incremental — otherwise clustering can break
• Respect TLP:AMBER — do not redistribute outside your organization without agreement

Questions or onboarding help: support@malanta.ai

↑ Back to top

Updated on: 13/10/2026