Cortex Analyzers: Automated Observable Analysis

What Cortex Is

Cortex is an open source engine that exposes observable analysis and response as a uniform API. Instead of an analyst manually visiting a dozen websites to check whether an IP is malicious, Cortex lets you submit the IP once and have it queried against every configured source in parallel, returning structured results. It is the natural enrichment back end for TheHive and for a SOAR layer such as n8n.

Architecturally, Cortex runs a catalogue of analyzers and responders as isolated jobs, commonly in containers, each wrapping one data source or action. You submit an observable and an analyzer name, Cortex schedules the job, and you poll for the result. Because the interface is consistent across every analyzer, the calling system does not need to know how each underlying source works.

Cortex is what turns enrichment from a manual chore into an automated step. In a SOC handling real volume, this is not a nicety; it is the only way the math works. No team can hand-enrich the observable count that a busy environment produces, and Cortex is the component that makes automated enrichment practical.

Analyzers: Enriching Observables

An analyzer takes one observable of a supported data type and returns a verdict. Cortex ships with a large catalogue covering the common needs. For an IP address you might run reputation services and geolocation; for a file hash, multi-engine malware verdicts and sandbox reports; for a domain, registration age, category and passive DNS; for an email address, breach and reputation data; for a URL, detonation and categorisation.

Each analyzer declares which observable data types it accepts, so Cortex only offers relevant analyzers for a given observable. Analyzers return two things: a short taxonomy result that summarises the verdict in a machine-readable level (safe, suspicious, malicious or info, with a value), and a full report with the complete detail. The taxonomy is what automation branches on; the report is what an analyst reads when they need depth.

In practice you do not run every analyzer on every observable. You define which analyzers run for which data types, and often a tiered policy: cheap, fast, free analyzers first, and expensive or rate-limited ones only when the first tier is inconclusive or the observable is high value. This keeps latency and API spend under control while still giving rich verdicts where they matter.

Analyzers Worth Configuring First

A few analyzers earn their place in almost every deployment. The VirusTotal analyzer gives multi-engine verdicts for hashes, URLs and domains and is the workhorse of file and URL triage. Reputation analyzers such as AbuseIPDB give fast IP reputation that catches known-bad sources cheaply.

The MISP analyzer is special because it queries your own threat intelligence. It checks an observable against your MISP instance and tells you whether you have seen this indicator before, in which event, and at what confidence. An indicator that matches a recent MISP event from a sharing community is far more interesting than an unknown one, and this analyzer is how that context reaches the case.

Beyond those, passive DNS analyzers reveal an IP's hosting history, sandbox analyzers detonate suspicious files in isolation, and WHOIS analyzers expose newly registered domains, a common phishing signal. Start with VirusTotal, an IP reputation source and the MISP analyzer, prove the workflow, then add analyzers as specific investigation needs appear rather than enabling everything at once.

Responders: Taking Action

Where analyzers gather information, responders act on it. A responder takes an observable or a case and performs an operation: block an IP on the firewall or EDR, add a domain to a proxy blocklist, push an indicator into MISP as a new attribute, disable a compromised user account, or send a notification to a channel.

Responders close the loop from detection to containment without leaving the case. From inside TheHive, an analyst who has confirmed an IP is malicious runs a block responder and the firewall rule is created, with the action logged on the case. In a SOAR pipeline, a responder can be triggered automatically for high-confidence, low-risk actions, such as pushing a confirmed-malicious hash to MISP so it strengthens detection everywhere.

Automated response demands guardrails. Destructive or broad actions (blocking a CIDR, disabling an account) should require human confirmation, while safe, reversible, narrow actions (tagging, sharing intelligence, notifying) are good candidates for full automation. Define which responders may run unattended and which always need an analyst's hand on the trigger, and log every responder action for audit.

The Enrichment Workflow End to End

Put together, the workflow runs like this. A detection fires and an alert with observables lands in TheHive, created by the SIEM or the SOAR layer. Enrichment kicks off, either automatically through n8n or on demand by an analyst: each observable is submitted to Cortex, which runs the configured analyzers and returns taxonomy verdicts plus reports.

The verdicts feed back to the case. Malicious verdicts raise the case severity and may trigger responders; clean verdicts on low-impact assets may let the SOAR layer auto-close the alert. The analyst, if one is involved, now sees a case where the observables are already labelled safe, suspicious or malicious, with full reports a click away, instead of a bare list of artefacts to research from scratch.

This is the difference Cortex makes. The analyst's time goes to judgement and decisions, not to copy-pasting indicators into search boxes. The same enrichment that would take a person twenty minutes per observable happens in seconds across every observable, consistently, every time, and the results are recorded on the case as evidence.

There is a quality benefit on top of the speed one. Manual enrichment is inconsistent: a tired analyst at the end of a shift checks fewer sources than a fresh one at the start, and two analysts rarely look up exactly the same things. Automated enrichment runs the identical set of analyzers against every observable regardless of who is on duty or how busy the queue is, so the floor of investigation quality is fixed and high. The case record then shows precisely which sources were consulted and what each returned, which is exactly the kind of defensible, repeatable evidence trail an auditor or an incident review expects to see.

Operating Cortex in Production

Three operational concerns dominate. First, API keys and quotas: many analyzers wrap commercial services with rate limits, so manage keys carefully, watch usage, and use caching so the same observable is not re-queried needlessly within a short window. A file hash verdict is stable for hours, so cache it.

Second, analyzer selection and cost: run a tiered policy so cheap analyzers triage first and expensive ones run only when needed. Disable analyzers you do not use to reduce surface and noise. Review which analyzers actually changed an outcome and prune the ones that never do.

Third, data sensitivity: some analyzers send the observable to a third party, which for sensitive internal data (an internal hostname, a private file) may be a disclosure you do not want. Mark such observables so they are only run against local analyzers like the MISP lookup, and document which analyzers are safe for which TLP levels. Getting this policy right keeps automated enrichment from quietly leaking data.