Behavioural detections and attack coverage

The sensor on each machine reports what processes started and what files changed. This article explains what happens to that stream: how a rule decides that a sequence of ordinary-looking actions is an attack, what a rule contains, which MITRE ATT&CK techniques the shipped rules cover, and — at equal length — which ones they do not.

The gaps section is not an appendix. A coverage map that shows only strengths is marketing, and it teaches you to assume protection you do not have. Every gap listed below is deliberate, has a named cause, and is published inside the product as well as here.

Matching a file, versus watching what it does

There are two ways to recognise something malicious on a machine, and Qorionix uses both. They fail in completely different ways, which is why having only one of them is a poor position.

File-hash matching

A file has a fingerprint — a SHA-256 digest, a long hex string derived from its exact bytes. If that digest appears on a list of known-bad files, the answer is not a judgement: the file either is that file or it is not. This is what threat-intelligence feeds are for, and it is the only path in the product allowed to act without asking you first.

Behavioural detection

No fingerprint is involved. A rule watches for a shape — an Office document spawning a command interpreter, a signed Windows utility downloading and running a payload, thousands of files being rewritten with rising randomness. The file involved may never have been seen anywhere before.

Hash matching is precise and brittle. Change one byte of a malicious file and its digest changes completely, so anybody who repackages their tooling defeats it entirely. Behavioural detection survives repackaging, because it describes what the attacker has to do rather than which file they used to do it.

The cost is symmetrical and worth stating plainly: the same evidence that catches an intruder also describes an administrator doing their job. A remote-management tool creating a service on another machine and running a script is either your IT provider or somebody moving laterally through your network, and at the moment of observation those two look identical. That single fact drives most of the design below — the confidence field, the suppression behaviour, and the reason no behavioural rule is ever allowed to act on its own.

What a rule actually contains

A behavioural rule in Qorionix is a small, fixed structure. It is worth knowing the fields, because every one of them shows up somewhere in an alert you will eventually have to read.

Identifier

A stable string such as behav-t1003-comsvcs-minidump. It is never reused for a different rule, because alert history and your own autonomy settings are keyed on it. If you tune a rule, you are tuning this identifier.

Severity

Across the shipped behavioural set, only two values are in use: critical and high. There is no medium or low behavioural rule. A rule that could not justify high was not worth the queue space.

Confidence

A number between 0 and 1 — for example 0.98 on the LSASS mini-dump rule, 0.78 on the process-injection tooling indicator. Read it as the rule author's documented estimate of precision, in the source, in advance.

Autonomy tier

Either tier0 (alert only, no ticket is ever created) or tier1 (prepare a response ticket and wait for a person). There is no third option here — see below.

Techniques

One or more MITRE ATT&CK identifiers with their tactic, so an alert says which stage of an attack it belongs to rather than only that something happened.

Platforms

Which operating systems the rule applies to. An empty list means it applies everywhere. A Windows-only rule is never evaluated against a Linux observation, so it cannot produce a false positive there.

False positives

A written list of the benign things known to look like this rule. It ships with the rule rather than being discovered by you at three in the morning.

One more property matters and it is invisible in the interface. The matching part of a rule is a pure function: it performs no database queries, makes no network calls and cannot read the clock. It sees exactly one thing — the observation that just arrived, plus a short window of recent activity on the same machine. That makes a detection reproducible and testable, and it makes it impossible for a rule to behave differently on a Tuesday because a lookup was slow.

The five-minute window

Some attacks are a single event. Most are a burst. Ransomware is not one file being encrypted; it is a thousand, quickly. So each machine carries a sliding window of recent activity that a rule can consult: at most five minutes, holding up to 1,024 recent file events and 256 recent process events. Older entries are evicted on a timer.

The ransomware rules read the window's entropy figures. Entropy is a measure of randomness in a file's contents — encrypted or compressed data scores near the theoretical maximum of 8 bits per byte, ordinary documents score much lower. The thresholds are concrete: ciphertext is treated as a floor of 7.5, and a rise of 1.5 bits per byte between a file's previous and current contents is the tell that a file was readable and now is not.

The bound is worth understanding because it is also a limit. An attacker who waits ten minutes between steps produces two windows, not one, and the burst-shaped rules will not correlate them. What links those steps back together is not the window but the process tree — see Incidents and the process tree.

Which ATT&CK techniques are covered

MITRE ATT&CK is a public catalogue of the things attackers actually do, each with an identifier like T1486. It is useful here because it lets a coverage claim be checked rather than believed. The shipped behavioural rules carry techniques across eight ATT&CK tactics: Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Lateral Movement, Command and Control, and Impact.

Where coverage is shown in the console

Two screens carry ATT&CK information, and it is worth knowing which answers which question.

Detection → ATT&CK coverage is the full picture. It draws a real technique-by-tactic grid in a panel headed Techniques by tactic, with a Show as a list mode for the same data if a wide table is awkward to read. Four tiles sit above it: Techniques covered, Tactics, In shadow mode (waiting on telemetry) and Rules.

Each cell in the grid is in one of three states, marked with a glyph as well as a colour so the grid is readable without relying on colour at all:

The screen also carries a What connecting a source would add panel, listing the rules that exist but are blocked on telemetry you have not connected yet. That is the most directly actionable thing on the page: it turns your coverage is thinner than you would like into a specific list of log sources to connect.

Detection rules is the other surface, and it answers per-rule questions. Above the list, a tile reads ATT&CK techniques with the subtitle across {n} tactics. In the list itself, each rule has an ATT&CK column showing its technique and tactic, and there is a Filter by ATT&CK tactic dropdown that defaults to Any tactic. If you are asking which rule covers this? rather than how much do we cover?, that filter is the quicker route.

A few real rule identifiers, so the shape is concrete rather than abstract. These are the strings you will see on an alert and in a hunt result.

New this wave: three detections built on sensor 1.7.0's telemetry breadth

Sensor 1.7.0 added DNS, logon, USB and PowerShell script-block channels — see The endpoint telemetry page for what each one reports and where it goes quiet. Three fixed detections now ride those channels. They are a genuinely different, simpler shape from the compiled behavioural catalogue described above: no confidence score, no autonomy tier, no proposed kill-or-isolate response. Each raises directly to the alert queue against a synthetic detection-rule row — the same one-alert-per-match shape the file-integrity change feed already uses for every reported change (see File integrity monitoring) — rather than going through the tiered, response-proposing engine the rest of this article describes.

Suspicious PowerShell script block — T1059.001

Matches a script block's own visible text against a small, fixed, case-insensitive list of static indicators: encoded-command execution, in-memory download-and-execute patterns, AMSI-bypass strings, and hidden or no-profile invocation. This is deliberately a separate check from the T1059 rule described earlier in this article, which reasons over process command lines with real process ancestry — the script channel carries PowerShell's own decoded block text with no process ancestry attached at all, a narrower and unrelated signal from a narrower and unrelated source. Windows-only, because the script channel itself is Windows-only this wave (PowerShell event 4104 has no equivalent collector on Linux or macOS).

Logon brute-force — T1110

Fires on five failed-logon events for the same sensor and user inside a five-minute window. Stated plainly: this is a Windows-only detection in practice today, because Linux's and macOS's logon channels never report a distinguishable failure event — both report one undifferentiated logon event type with no equivalent to Windows' event 4625. A brute-force attempt against a Linux or macOS account is not invisible to the sensor, but this specific counting rule has nothing on those platforms to count.

Removable storage connected to a server — T1052

Fires on a USB-connect event where the reporting host's most recently reported OS version string looks like a Windows Server SKU. Stated plainly: this heuristic only works on Windows, because Windows is the only platform that reports an OS-edition string this codebase can classify as server versus desktop at all — no host inventory field distinguishes a server role from a workstation role on Linux or macOS today, so the rule cannot be evaluated there, not merely tuned differently.

A fourth item belongs in the same list even though no new rule was written for it: DNS queries are now checked against known-bad domains, for free. A DNS query's queried domain name feeds the same indicator-of-compromise matcher every other channel in the product already used for file hashes and network indicators — see Indicators of compromise. There is no new special-cased detector, no new alert shape and no new table for this; one field was added to the list of things the existing matcher checks, and the DNS channel's own platform coverage (Windows and suitably configured Linux only — see The endpoint telemetry page) is the only limit that applies to it.

The five published gaps

The coverage summary the product computes carries a known gaps section alongside the covered techniques. Five entries, each naming the kernel-level telemetry that would be needed to close it. The common cause is one sentence, and it is the same one in every entry: the sensor ships no driver.

That is a deliberate architectural choice, not an oversight. A kernel driver on every machine in your business is a serious thing to install: it can crash a host, it needs its own signing and update discipline, and a defect in it is a defect in the operating system rather than in an application. We chose a userland agent that samples process and file state on an interval. The bill for that choice is below.

T1055 — Process Injection

Code written into another running process. Seeing this reliably needs kernel callbacks on memory operations, which a userland poller does not receive. What we have instead is an indicator rule that spots the tooling commonly used for injection, at a stated confidence of 0.78 — the lowest in the set, and honestly so.

T1003.001 — LSASS memory, from inside

The rules here catch a separate process reaching for LSASS, which is what most credential theft looks like. They do not catch an implant already running inside a process that reads memory in place. That distinction needs the same kernel visibility as the entry above.

T1071 — Command-and-control traffic

The sensor emits no network-connection events at all. Nothing observes an endpoint beaconing to a server on a schedule. The reverse-shell rule catches the moment an interactive shell is wired to a socket, because that is visible as a process relationship — but ongoing C2 traffic is not visible to this product on the endpoint.

T1021.002 — SMB and admin shares

Lateral movement over file shares is partly visible through the service-creation and PsExec-family rules, which are process events. The network side of it is not, for the same reason as above.

T1562.001 — Impairing defences

This technique appears in both lists, which is the honest outcome rather than a contradiction. A rule catches the observable part — a security control switched off or an exclusion added, visible as a process running a command. The part that needs kernel telemetry, such as tampering that never surfaces as a command line, is recorded as a gap.

Three further limits belong in the same honest paragraph, because they are properties of the same design:

• A process that starts and exits inside one sampling interval is missed. The process snapshot runs every two seconds. Something that lives for less than that may never be observed at all.
• There is no registry telemetry. registry_set exists as a field name in the hunt schema and nothing ever writes one.
• A file rename is reported as a delete followed by a create. The detection engine reassembles the pair by matching size within a burst, so ransomware detection is unaffected, but a rename does not arrive as a single event.

Noisy tooling is downgraded, never dropped

The noisiest benign source in a small business is remote-management and configuration tooling: the software your IT provider uses to reach your machines, plus whatever runs your patching and scripting. It creates services on remote hosts, launches interpreters, and copies files into staging directories, which is a fair description of most of the rules above.

The obvious fix is an allowlist — recognise the tool, drop the detection. We deliberately did not do that. Remote-management tooling is simultaneously the noisiest benign source and one of the most commonly abused footholds in a real intrusion: an attacker who gets into your IT provider's console inherits legitimate software with legitimate reasons to touch every machine you own. An allowlist that dropped those events would blind the product to its single most likely breach scenario.

So the precision layer downgrades rather than drops. When a detection is recognised as likely benign tooling, three things happen together:

1. The tier falls to observe, so no response ticket is created and nobody is asked to approve anything.
2. The confidence figure is reduced, so the detection does not sit at the top of a ranked queue.
3. The reason for the downgrade is recorded on the verdict and in the evidence, so it is searchable afterwards.

Only a subset of rules is eligible for downgrade at all. Two categories are deliberately excluded and can never be quietened this way: LSASS credential dumping and shadow-copy destruction. There is no legitimate remote-management reason to dump credentials from memory or to delete the backup catalogue, so a downgrade there would only ever be wrong.

The practical consequence is that everything the precision layer softened is still there and still findable. In the detections hunt dataset, the autonomy_tier field records the tier the detection actually fired at — after any downgrade — and suppression_reason is non-empty when it was downgraded. A hunt for detections with a suppression reason is a review of everything the product decided not to bother you with, and it is worth running occasionally. Threat hunting shows how.

One counter is published alongside the coverage summary for the same reason: the number of rules that would auto-execute. It exists so that a rule which quietly acquired that permission shows up as a non-zero number in a published figure rather than blending into a list. On a correctly configured tenant, no behavioural rule appears in it.

What to do next

1. Open Detection → ATT&CK coverage and read the grid. Anything marked In shadow mode or listed under What connecting a source would add is coverage you could have without writing a rule — usually by connecting one more log source. Remember it describes your log-detection rules, not the endpoint rules in the table above.
2. Read The endpoint telemetry page — the seven-tab view the three new telemetry detections above are built on, with every platform gap spelled out per channel.
3. Read Incidents and the process tree — a detection tells you a rule fired; the process tree tells you what actually happened.
4. Read Response actions to see what each rule proposes, and what it takes for any of it to run.
5. If a rule is noisy on your estate, Shadow detections, and why some rules stay quiet explains the alternative to switching one off.