Cortex Observable Analysis

Overview#

Submit any observable to a Cortex analyzer from the Argus API and get back a structured, risk-scored report that is persisted, clearance-tagged, and correlated with your wider threat picture automatically.

The Cortex capability connects Argus to the Cortex 3.x observable analysis engine from StrangeBee, the open analysis platform used alongside TheHive across CERTs, SOCs and threat intelligence teams. An analyst can hand an IP address, domain name, file hash, crypto wallet address, entity name or incident identifier to a named Cortex analyzer and receive a normalised taxonomy report with malicious, suspicious, safe or informational verdicts. Argus persists that report, applies a secrecy-level tag for clearance-based access, and emits a threat entity into the shared operational picture, so the result is immediately usable everywhere Argus already aggregates intelligence.

The value is in removing the swivel-chair. Instead of running an analysis in one tool, copying the verdict into a case in another, and re-keying indicators into a third, your teams trigger analysis once and the structured result flows into the platform with full audit history. Crypto-wallet risk scoring, multi-list sanctions screening and incident escalation signals all arrive in the same consistent shape, ready for correlation.

Key Features#

• Direct observable submission: A single call submits an IP address, domain, file hash, crypto wallet address, entity name or incident identifier to a named Cortex analyzer instance and returns the persisted analysis record.
• Structured taxonomy reports: Every result is normalised into the Cortex taxonomy shape (level, namespace, predicate, value) carrying malicious, suspicious, safe or informational verdicts, so downstream consumers read one consistent format regardless of which analyzer produced it.
• Risk scoring and verdicts: Reports carry quantitative risk scores and qualitative flags, for example crypto-wallet scoring across sanctions exposure, mixer interaction and rapid-fire transfer patterns.
• Clearance-aware results: Each analysis record is tagged with a secrecy level and filtered per user clearance on read, so classified results are only ever returned to cleared personnel.
• Automatic threat correlation: On persistence, an operational THREAT entity is emitted into the shared interop picture, linking the Cortex result to the broader Argus intelligence view without a manual enrichment step.
• Full audit trail: Every submission is recorded as an interop ingest event capturing user, organisation, record reference and secrecy level, supporting traceability and compliance reporting.
• Aggregate statistics: A stats endpoint returns totals by status and a count of distinct analyzers used, giving operations leads a real-time view of analysis load without loading every record.
• Deterministic sandbox scenarios: A built-in offline sandbox ships fixtures for crypto-wallet risk scoring, multi-list sanctions screening and incident escalation detection, so teams can evaluate and demo the capability with no live Cortex instance.

Use Cases#

Security Operations Centres#

SOC analysts triage indicators at speed. Hand a suspicious IP, domain or file hash to a Cortex analyzer and receive a verdict and risk score in the same place the rest of your case context lives. Results land clearance-tagged and correlated, so a malicious verdict immediately surfaces against related entities already tracked in Argus.

Threat Intelligence Teams#

Analysts building campaign and actor pictures can enrich entities on demand and keep the structured output. Because each report is persisted and emitted as a threat entity, intelligence accumulates over time and feeds attribution and reporting rather than being discarded after a one-off lookup.

Financial Crime and Crypto Investigations#

Score crypto wallet addresses for sanctions exposure, mixer interaction and rapid-fire transfer behaviour. A high-risk wallet returns a clear malicious verdict with a numeric risk score, while a clean wallet returns an informational result, giving investigators a defensible, repeatable basis for escalation.

Sanctions Screening#

Screen an entity name against multiple consolidated lists in one pass. A single analysis can return matches across the OFAC SDN list, the UN Consolidated List and the EU Financial Sanctions File, each as a discrete taxonomy entry with a match score, supporting compliance workflows that must evidence multi-list coverage.

Incident Escalation Detection#

Feed an incident identifier to an escalation-signal analyzer to detect deteriorating situations. Trend and severity signals, including ePCR deterioration indicators, are returned as taxonomy entries so dispatch and command teams can prioritise responses backed by structured evidence.

Integration#

The capability is exposed through the Argus GraphQL API. Two read fields return data: a clearance-filtered list of analyses and an aggregate statistics field giving counts by status and analyzer. One write operation hands an observable to a named analyzer and persists the report. Every field requires authentication and is scoped to the caller's organisation.

Under the hood, Argus speaks to a Cortex 3.x instance over its REST API at /api/v1/analysis using JSON request and response bodies and an OAuth2 Bearer token for authentication. Customers plug in their existing Cortex deployment by supplying its base URL and API token, with no bespoke connector build required. The benefit is that analysis results are normalised into the platform's shared models on arrival, so the same correlation, clearance and audit machinery that serves every other Argus data source applies to Cortex output too.

Results do not stay siloed. On persistence each report is written to the shared operational entity store as a THREAT entity in the CYBER domain, making it visible in the unified operational picture and available for cross-source correlation alongside other threat intelligence the platform already aggregates.

Open Standards#

• Cortex Analyzer report and taxonomy model (StrangeBee Cortex 3.x): Reports are consumed and stored in the native Cortex taxonomy structure of level, namespace, predicate and value, the same model TheHive and the wider Cortex ecosystem use, so verdicts remain portable and tool-agnostic.
• HTTP REST over /api/v1/analysis: Integration uses the documented Cortex REST endpoint with standard HTTP verbs and status semantics, the same surface any Cortex client targets.
• JSON (RFC 8259): All request and response payloads are exchanged as JSON, the interchange format Cortex publishes natively.
• OAuth2 Bearer Token (RFC 6750): Calls to the Cortex API authenticate with an Authorization: Bearer token, the standard bearer scheme Cortex accepts.
• GraphQL: The customer-facing surface is served over GraphQL, giving callers a typed, introspectable contract for listing, statistics and submission.
• OFAC Specially Designated Nationals (SDN) List: Sanctions screening returns discrete OFAC SDN match entries, the United States Treasury list of sanctioned individuals and entities.
• United Nations Consolidated Sanctions List: Screening also returns UN Consolidated List matches, the global reference list maintained under UN Security Council resolutions.
• European Union Financial Sanctions File (EU FSF): Screening returns EU FSF matches, the consolidated list of persons and entities subject to EU financial sanctions.

Security & Compliance#

Every Cortex field requires an authenticated session and is scoped to the caller's organisation, so one tenant can never read another's analyses. Each persisted report carries a secrecy-level tag and is filtered against the requesting user's clearance on read, meaning classified results are withheld from uncleared personnel. Every submission is recorded as an interop ingest audit event capturing the acting user, organisation, record reference and secrecy level, giving a complete and reviewable trail of who analysed what and when. For evaluation and demonstration, a deterministic offline sandbox returns synthetic fixtures only, with no live API calls, so prospective users can assess the capability without exposing real infrastructure or data.

Last Reviewed: 2026-05-26 Last Updated: 2026-05-26