GUARDIANVIGIL

INTELSTACK SAAS // PRODUCT SPECIFICATION & ROADMAP

STATUS: IN DEVELOPMENT
VERSION: V1.0 PRE-RELEASE
Pre-Release

IntelStack

A threat intelligence platform that shows its working. It scans an indicator against twenty providers and tells you which one contributed each point of the verdict, detonates files and URLs in an isolated worker, and records what it observes as a graph you can pivot through. The capabilities below are running in the current build.

Request Early Access Beta

Join our waitlist to be among the first security teams to test IntelStack V1.

Join Beta Waitlist
Providers
20 CTI Sources
Scoring
Evidence-Itemised
Detonation
Isolated Execution
AI
Optional Add-On

Why We Are Building IntelStack

Solving the Core Challenges in Modern Threat Intelligence

The Problem: IOC Overload

Fragmented & Stale Feeds

A SOC ingests millions of disconnected hashes and addresses. Without correlation there is no way to tell whether an address is live attacker infrastructure or a CDN edge node that happened to appear in a feed.

The Gap: Slow Manual Triage

Hours Lost on Manual Reports

Pulling indicators out of a PDF advisory and checking each one by hand costs hours per incident — hours spent during the window where containment still matters.

The IntelStack Solution

Automated Graph Intelligence

IntelStack scans against every configured provider at once, shows which one contributed each point of the verdict, and records what it observed — so the next analyst to see that indicator starts from what is already known about it.

Core Platform Capabilities

Deep Dive into IntelStack's Modular Engine

20 CTI Providers, Published Weights

Multi-Source Indicator Scanning

An indicator is scanned against twenty threat intelligence providers in parallel. Each provider carries a weight that is visible in the source rather than buried in a model, because a MalwareBazaar hit and a GreyNoise classification are not the same claim and should not count the same.

20 provider clients across IP, domain, URL, hash and email indicators
Every point in a verdict traces back to the provider that contributed it
A failed lookup returns Unknown and a missing key returns Unconfigured — never Clean
Enrichment such as geolocation returns Info: unscored, and excluded from coverage
Static Structure and Dynamic Analysis

File and URL Detonation

Submissions are asynchronous — you get an identifier back and the report when it is ready. The pipeline reads the file's structure, recovers its strings including the hidden ones, inspects URL, DNS and certificate behaviour, and where execution is enabled, runs the sample in an isolated environment built for the purpose.

A fresh isolated environment per sample, destroyed when the run ends
Capability detection, recovery of obfuscated strings, emulation and signature matching
CTI pre-check before detonation and cloud reputation after
A tool that did not run says so, with the reason — never a silent pass
Observed Relationships Only

Graph Topology and Similarity

Indicators and the infrastructure behind them are stored as a graph an analyst can pivot through rather than a table they have to join by hand. The rule that keeps it trustworthy is that an edge is only ever written from a relationship actually observed — never inferred from the fact that something scored badly.

Multi-hop pivoting across indicators and observed infrastructure
Edges written from observed relationships, never inferred from a verdict
Infrastructure similarity computed only over signals that are genuinely collected
Every similarity match carries the shared attributes that produced its score
The Real Framework, No Model Involved

MITRE ATT&CK Navigator

The full Enterprise matrix, loaded from the official MITRE dataset that ships with the platform. An earlier build asked a language model to generate the framework instead, which rendered invented technique IDs and group attributions as though they were real. It now reads the real thing.

Full Enterprise matrix from the bundled official MITRE data
Technique coverage mapped from scan and detonation evidence
No API key required — this is public data and it ships with the platform
AI assistance is an optional add-on, and every view works without it

Where We Sit in an Intrusion

Seven Stages, and What Is Actually Visible at Each

An attack is a sequence, not an event. The useful question about any threat intelligence platform is which parts of that sequence it can genuinely see — so here is ours, including the two stages where the honest answer is that we cannot.

1ReconPARTIAL2WeaponizeNOT VISIBLE3DeliverOBSERVED4ExploitOBSERVED5InstallOBSERVED6C2OBSERVED7ObjectivePARTIAL
1. ReconnaissancePartial
They

Maps your exposed surface and picks a way in.

We see

Exposure data on the infrastructure they stage from — open services, certificates, hosting.

2. WeaponizationNot visible
They

Builds the payload. This happens entirely on their side.

We see

Nothing, and we say so. A platform claiming visibility here is guessing.

3. DeliveryObserved
They

Sends the link or the attachment.

We see

The URL or file, checked against every configured source before anyone opens it.

4. ExploitationObserved
They

Runs code on the target.

We see

Behaviour recorded while the sample executes in an isolated environment.

5. InstallationObserved
They

Establishes a foothold that survives a reboot.

We see

Persistence artefacts the sample creates, captured during analysis.

6. Command & ControlObserved
They

Calls home and waits for instructions.

We see

The strongest signal we get — every destination contacted, and what else has contacted it.

7. Actions on ObjectivesPartial
They

Takes what they came for.

We see

Destinations that appeared during analysis. What leaves your network is your telemetry, not ours.

Two of seven are honest greys

Weaponization happens on the attacker's machine and exfiltration happens inside your network. We mark both rather than claiming coverage we do not have — a chain drawn all in one colour is a sales diagram, not a capability map.

What Each Provider Is Worth

The Weights, and the Reasoning Behind Them

Most scanners count votes. We do not, because a MalwareBazaar hit means somebody submitted the actual binary and a GreyNoise hit means the address scans the internet — and those are not the same claim. Here is the whole table. Disagree with it if you like; that is why it is published.

Multi-engine aggregate30
Malware corpus30
Behavioural detonation28
Curated abuse reports25
Curated distribution URLs25
Curated indicator corpus25
Community attack telemetry20
Page behaviour analysis18
Aggregated risk score18
Community pulses15
Internet scan classification12
Exposure surface8

Enrichment sources are absent from this table on purpose. Geolocation and exposure lookups return Info: unscored, and excluded from the coverage figure, because knowing where an address lives is not a judgement about it.

Four Rules We Broke First

Each One Is a Defect We Shipped and Removed

None of these were hypothetical. Each was written by somebody making a failure path stop crashing, and each put a green badge in front of an analyst where no evidence existed.

WasLookup failed → Clean
NowLookup failed → Error

We asked and learned nothing. That is not a finding.

WasNo credential → Clean
NowNo credential → Unconfigured

We never asked. Coverage you do not have cannot reassure you.

WasGeolocation → Clean
NowGeolocation → Info

Enrichment is context, not corroboration. It scores nothing.

Was12 points, 35 threshold → Clean
NowAny malicious report → at least Suspicious

Source counts set the floor, independently of the arithmetic.

What Happens to a Submitted File

Five Phases, and What Each One Can Tell You

STEP 01/5
Reputation First
Checked against every configured source before anything is executed.
STEP 12/5
Structure
What the file claims to be, and whether its internals agree.
STEP 23/5
Strings
Readable content, including what the sample tried to hide.
STEP 34/5
Execution
Run in an isolated environment; behaviour and contacts recorded.
STEP 45/5
Corroboration
What we observed, checked back against external sources.
Execution is opt-in

Detonating an unknown sample is a privileged operation, so it stays switched off until an operator turns it on deliberately. The platform reports whether it is available rather than leaving you to assume.

A skipped step says so

When part of the analysis does not run, the report names it and the reason. A missing result is never rendered as a passed check.

Only What Was Observed

How an Edge Gets Written, and When It Does Not

contactedresolved fromshares certificateSAMPLEsha256:4f2a…c19bHOST192.0.2.41DOMAINupdate-service.invalidHOST192.0.2.87VERDICT: MALICIOUSno edges — a score is not a relationship

Every edge above records something that was seen happening: the sample contacted the host, the host was resolved from that domain, the two hosts presented the same certificate. The verdict sits outside the graph with nothing attached to it. Drawing an edge because something scored badly is how a graph starts asserting attribution it cannot support — so the writer refuses to.

Where a Request Gets Checked

One Boundary, No Way Around It

A browser never reaches an analysis service directly. Every request crosses a boundary that establishes who is asking before anything downstream will act on it.

The analyst

Signed in, working an indicator.

A session, and nothing else.

The boundary

Every request is checked here, without exception.

Decides whether the request continues at all.

Analysis services

Scanning and detonation, reachable only from the boundary.

Verify independently — they do not trust the caller.

The shortcut we removed

A convenience route once let the browser skip the boundary entirely, taking every session check with it. It was deleted, and the reason it must not come back is written down where the next person will find it.

Nothing is trusted by position

Each analysis service checks its own caller rather than assuming that anything which reached it was allowed to. Being inside the network is not an authorisation.

Build Status

What Is Built, What Is Being Built, and What Is Not

ImplementedBuilt

Working in the Pre-Release Build

Scanning pipeline across 20 CTI providers with evidence-itemised scoring
File and URL detonation with static analysis and an isolated worker
Infrastructure graph and similarity search
MITRE ATT&CK navigator from the bundled official dataset
Durable scan and report history, with full-text search across reports
Organisation workspaces, role-based access and an audit log
In DevelopmentActive

Work Toward the V1 Release

Closed beta hardening with a small group of security teams
Broader provider coverage beyond the current twenty clients
Self-service onboarding, workspace billing and usage metering
Operator and analyst documentation
PlannedNot Started

Under Consideration After V1

Self-hosted deployment for teams that cannot send indicators off-site
A public read API over scan history and the graph
Additional indicator types and submission formats

Interested in Early Beta Access or Technical Partnership?

Reach out to the engineering team directly and we will walk you through the build.

Contact Engineering Team