Threat-intelligence feeds

Threat intelligence is a list of things known to be bad — file fingerprints, domains, addresses, URLs — published by somebody who saw them in a real attack. Qorionix can subscribe to eleven such feeds, poll them on their own publishers' schedules, parse seven formats, and store what they contain against your organisation. All of that works.

What happens next is narrower than almost everybody assumes, so it goes at the top rather than in a footnote.

That does not make the feeds worthless — the hash path is real, and the stored indicators are usable at your perimeter and in an investigation. It does mean you should know which half you are buying.

The one thing that is matched, and how

When a file is fetched from an endpoint — through a live-response ticket, whether raised by a person or prepared automatically — the sensor reports the file's SHA-256 digest. On completion, that digest is looked up against your organisation's active indicators of type file_hash.

On a hit, four things happen. An alert is raised with a title of this exact shape:

Known-bad file hash detected: <first 12 characters of the sha256> family=<malware family>

• Its severity is critical, or high when the indicator's own confidence is below 0.7.
• The indicator's last-seen timestamp is updated, so the intelligence record reflects that you have actually encountered it.
• A quarantine_file ticket is created against the machine — waiting for approval, exactly like any other response ticket.
• That ticket is the only one in the entire product eligible to approve itself, and only under the conditions below.

Automatic approval of that quarantine requires all of the following at once: the autonomous tier-2 capability enabled on your cell, the rule set to tier 2, the indicator's confidence at or above a floor that defaults to 0.95, and no policy of yours downgrading it. If any of those fails, the ticket sits in pending_approval like everything else. The approver recorded on an automatic approval is sentinel-q-tier2-auto, and the recorded reason names both numbers:

autonomy tier 2 fast-path: indicator <id>, confidence=0.98 >= floor=0.95

The justification for this being the one automated action is worth repeating, because it explains why nothing else joins it. Quarantine is reversible — the file's original bytes are preserved in a vault on the machine — the blast radius is a single file on a single machine, and the verdict is a hash comparison rather than an inference about intent. The file either is the known-bad file or it is not. What Sentinel-Q is allowed to do covers the wider rule.

The eleven feeds

The catalogue is short on purpose. Everything commercial is excluded, because a preset for a feed you cannot obtain is a dead end in the interface. CERT-EU is excluded because it requires a partnership. Emerging Threats Open is excluded because it ships intrusion-detection rules rather than indicators. Every URL in the list was fetched and checked rather than recalled.

The intervals are not uniform and that is deliberate: polling a daily list every fifteen minutes is ninety-five wasted requests a day against somebody else's free service, and free services that get hammered stop being free services.

The presets also encode three credential subtleties so that you do not have to know them. AlienVault OTX takes its key in a bare X-OTX-API-KEY header. MISP takes the raw key in Authorization with no scheme prefix — declaring either as a bearer token would send Authorization: Bearer <key> and be rejected. PhishTank identifies callers by User-Agent, in the form phishtank/<username>, and answers 403 to anything else: a credential in everything but name, so it is modelled as one.

What the licences let you do

Every preset carries a licence field, and where the terms are restrictive or unconfirmed the field says so rather than rounding "free of charge" up to "free to redistribute". Those are different things, and the difference matters if you resell IT services or push indicators onward to a customer's firewall.

A feed created from a preset stores which preset it came from, so its licence stays traceable after the fact. That is the difference between being able to answer an auditor's question about provenance and having to guess.

Formats and indicator types

Seven format values are accepted. Anything else is refused with this message, which names all seven:

unsupported format "<fmt>": must be one of misp, opencti, otx, csv, text, stix, cisa_kev

STIX is parsed as a supported format. We are not going to state which STIX version or which object types are honoured, because that has not been verified to the standard the rest of this article is written to. The design target is STIX 2.1. If you depend on a specific STIX profile, test it against a small feed before relying on it.

Whatever the source format, indicators are normalised to a small set of types. Source-specific names are folded in: md5, sha1, sha256 and sha512 all become file_hash; hostname becomes domain; ip-dst, ip-src, ipv4 and ipv6 all become ip; uri becomes url.

Each stored indicator carries more than its value: a threat type (ransomware, trojan, worm, apt, cryptominer, infostealer, backdoor or dropper), a confidence between 0 and 1, a source category, a reference back to where it came from, a malware family, first- and last-seen timestamps, an optional expiry and an active flag. The confidence and the expiry are the two that affect behaviour: confidence gates automatic quarantine, and an inactive or expired indicator is not matched.

How refreshing works

A scheduler ticks once a minute and polls each feed whose own interval has elapsed. A feed created without any interval of its own defaults to 900 seconds. There is an initial run at start-up so a newly provisioned tenant hydrates its indicators without waiting a full cycle.

Where the platform runs as more than one process, only one of them polls at a time: each tick tries to take a database advisory lock, and a replica that does not get it skips quietly. The lock is held only for the duration of one polling run and never across ticks, so a process that crashes mid-poll releases it by virtue of its connection closing, and the next tick on any replica picks up. Nobody has to notice.

A feed that fails is backed off rather than retried on every tick, so a publisher having a bad afternoon does not get hammered by your cell. Each feed records when it last succeeded, when it last failed and what the failure said, and the run history is capped — the run table would otherwise grow at one row per feed per interval, forever.

You can also poll a feed on demand, which is the right move after fixing a credential rather than waiting to see whether the next scheduled run works.

The indicators you start with

A new organisation is seeded with six baseline indicators: four file hashes and two domains. The two domains are emotet-tracker.example and lockbit-leak.example — .example is a reserved suffix that can never resolve to a real host, which is the plainest possible signal that this is demonstration data.

The seed exists so that the feature is visibly working on day one, not so that you are covered. Six indicators is not threat coverage and nothing in the product claims otherwise. Subscribe to at least one live feed before treating the hash-match path as a control you rely on.

What to do about domains and addresses instead

Since nothing in Qorionix evaluates a domain or an address against endpoint traffic, the honest advice is to put those indicators where something does look at traffic.

• Your firewall or DNS filtering is the right control for this. Export or read the indicator list and feed it there. Check the licence table above first — Spamhaus DROP and the abuse.ch feeds have real constraints on redistribution, and a managed service provider pushing them to a client's device is redistributing.
• Keep your mail and browsing protections switched on. Microsoft 365's own protections cover phishing URLs arriving by mail. Nothing in this module replaces them, and retiring them on the assumption that we have it covered would leave a real gap.
• Do not expect a block_ip response action to do anything on a machine. It exists in the older response-action model and it is simulated: blocking an address is a perimeter action, not a command a sensor runs on a host. Response actions says which actions are real.
• Use the indicators during an investigation. Sentinel-Q can look an indicator up as part of enriching a decision, and you can search your own stored indicators. That is analyst-initiated rather than automatic, and it is genuinely useful when you already have something to check.

Who can manage feeds

Feeds are governed by the detection-rule permissions rather than by a feeds-specific one: reading feeds and their run history needs rules read, creating, editing, testing or polling one needs rules write, and deleting one needs rules delete. In practice that means an administrator manages feeds and an analyst can see them. Roles and permissions has the full mapping.

What to do next

1. Subscribe to one live hash-bearing feed rather than five archives. abusech-threatfox and botvrij-sha256 are the ones that carry file fingerprints.
2. Read Response actions — the quarantine that a hash match prepares is a ticket, and the article explains what has to happen for it to run.
3. Read Behavioural detections and attack coverage for the other half of detection, the half that works without a fingerprint.