VCyber Twin

Detection Reality Index · Vol.2

Measured on IBM QRadar · July 2026

Measured, not declared — on a real enterprise SIEM

What IBM QRadar actually detected — replayed, timed, reproducible

We replayed three real ATT&CK techniques against a live IBM QRadar 7.3.3 deployment and measured whether an alert actually fired — not whether a rule exists. QRadar caught the loud one in 5.4 seconds. Network recon and ransomware file-encryption produced zero alerts — and the reason is the part nobody puts on a slide.

5.4s

MTTD for SSH brute-force (T1110.001) — measured on QRadar, not estimated

0

Alerts for network recon and ransomware file-encryption — both ran for real

100%

Reproducible — raw Ariel event data + attack harness retained with this report

The one sentence a CISO should take away

"We have QRadar" and "QRadar would catch this" are different statements. On this deployment QRadar detected the noisy technique fast — and was completely blind to the quiet ones, because the host telemetry pipeline never sent those events. You did not choose that gap. The default configuration chose it for you.

Results — 3 techniques replayed against live QRadar

ATT&CK technique	Result	MTTD	Why — measured, not assumed
T1110.001 Brute Force: Password Guessing hydra, SSH, 5×7 creds, 0 valid	ALERTED	5.39 s	sshd writes "Failed password" to authpriv → rsyslog → QRadar. QRadar auto-classified it ("User failed to login to SSH, incorrect password"), parsed the real attacker IP (192.168.99.50), log source LinuxServer @ victim-ubuntu. 7 events.
T1046 Network Service Discovery nmap TCP scan, ports 1–1000	MISSED	—	The scan ran and found port 22 open. QRadar received 0 events for it. A port scan generates no host syslog, and there is no network sensor (NIDS) feeding QRadar. Nothing to detect because nothing was sent.
T1486 Data Encrypted for Impact 6 files renamed to .LOCKED	MISSED	—	Six files were encrypted/renamed for real. QRadar received 0 events. File-integrity telemetry (auditd/FIM) was inactive on the host, so the encryption left no trace in syslog. The console cannot show what it never received.

This is not a knock on QRadar. QRadar detected everything it was actually fed, and did it fast. The two misses are telemetry-not-collected — a pipeline and configuration reality, not a product weakness. That distinction is the whole point: detection is decided by what reaches the SIEM, and most teams have never measured that on their own stack.

A matched slice, run on our bench

We run a matched slice on request. You choose the technique that actually concerns you. We replay it on our bench against a build matched to yours and send back a one-page readout: what fired, which rule, measured time to detect, what stayed silent and why.

It runs in our lab. Nothing touches your environment, nobody gets access, no data leaves your side, and there is nothing to sign to receive it.

We run these one at a time, so how soon we can start depends on what is already on the bench. If it is useful, there is a paid engagement on the other side of it; if it is not, you have spent one email.

dongnx@atkvn.com or use the form

VCyber Twin

Detection Reality Index · Vol.2

Method · Evidence · What it means

Three uncomfortable truths

1 — "Having a rule" is not detecting.

QRadar fired on the one technique that generates authentication logs. Every technique that stays off the log pipeline — reconnaissance, file encryption — produced nothing, no matter how capable the SIEM.

2 — Telemetry and config decide coverage, and the default leaves gaps you didn't choose.

auditd was inactive and there was no network sensor. Two entire attack categories were invisible not because of the analytics, but because the events never arrived. A coverage percentage on a slide cannot see this.

3 — Only replay tells you the truth about your own stack.

The only way to know whether a technique fires on your QRadar is to run it and watch. That is exactly what this measurement does — and what a vendor datasheet never will.

How we measured (transparent)

SIEM: IBM QRadar CE 7.3.3, live VM.
Attacker: Kali → Victim: Ubuntu (rsyslog *.* @@qradar:514, TCP).
Per technique: mark T0, execute the real action, then query the QRadar Ariel API within the window — record ALERTED (which QID, MITRE, source, MTTD) / MISSED.
MTTD = first QRadar-indexed event − attack launch (hosts NTP-synced; ±a few seconds inter-host).
This mirrors the exact logic of the VCyber Twin QRadar connector — the same instrument we point at a client's own SIEM.

Raw evidence (Vol.1's missing piece)

T1110.001 → ALERTED QID : "User failed to login to SSH, incorrect password" src : 192.168.99.50 log : LinuxServer @ victim-ubuntu MTTD: 5.39 s (7 events) T1046 nmap scan → QRadar rows: 0 T1486 ransomware → QRadar rows: 0

Every number here is backed by retained Ariel event data + the attack harness — reproducible on demand. No hand-entered figures.

What it means if you run QRadar

Your coverage report says you're protected against these techniques. Two of the three left no trace on your console. The fix is not more rules — it is measuring what actually fires, closing the telemetry gaps (auditd, network detection), and re-measuring. Replay → gap → tune → replay.

Get your own number — Detection Reality Check

We stand up an isolated digital twin of your SIEM (QRadar / Splunk / Wazuh), replay a fixed technique set, and hand you your number — what fired, what stayed silent, how fast, and a prioritized fix plan. The twin is isolated; your data never leaves your environment. Async, founder-run, no live call required.

Limitations, stated plainly. One deployment, one telemetry configuration — not generalizable to "every QRadar." The two misses are telemetry-not-collected (fixable with auditd / a network sensor), not "QRadar can't." Vendor-authored; method is open to scrutiny; numbers are real measurements against a live SIEM, not a survey.

VCyber Twin

Detection Reality Index · Vol.2.1

Update — we closed the gaps and re-measured

The other half of the loop — replay → gap → tune → replay

We fixed the two blind spots and re-ran the attacks — both now fire

Vol.2 found two techniques QRadar never saw. A reality check isn't finished at "you have a gap" — it tells you which gap and proves the fix. We closed the telemetry on the same live QRadar 7.3.3 bench and replayed. Both blind spots now alert — and closing them surfaced the sharpest finding of the whole exercise.

3.3s

MTTD for network recon (T1046) — after adding a network sensor. Was: 0 alerts.

2 / 2

Blind spots converted MISSED → DETECTED once the right telemetry was fed to QRadar

0 of 51,937

Rules that fired on the port scan with a full ET ruleset loaded — until one correct rule was added

The finding that outranks every MTTD number here

We loaded the network sensor with 51,937 detection rules and replayed the port scan. It fired zero of them. One purpose-built threshold rule, and the scan lit up in 3.3 seconds. Loaded-rule-count is not coverage. "51,937 rules enabled" and "the scan was detected" are unrelated statements until you replay the technique and watch.

Re-measured — same bench, telemetry closed

ATT&CK technique	Vol.2	Fix applied	Vol.2.1	MTTD
T1046 Network Service Discovery	MISSED	Added a network sensor (Suricata) on the scanned segment → alerts forwarded to QRadar via syslog.	ALERTED	3.27 s
T1486 Data Encrypted for Impact	MISSED	Enabled host file-write auditing (auditd + watch rule) → syscall events forwarded to QRadar.	ALERTED	near-real-time*

* T1486 file-write events index on QRadar as syscall telemetry from the host. On this Community-Edition bench, precise sub-second MTTD is dominated by platform ingest latency (~60–90 s to searchable) plus inter-host clock skew — not detection logic. Reported as "detected, near-real-time at the sensor." A licensed/production QRadar times this cleanly.

What this proves about the method

The value isn't "your SIEM is bad" — it's the closed loop: measure what actually fires, name the exact gap (missing sensor, disabled audit), close it, and re-measure to confirm the alert now lands. That is a remediation plan grounded in evidence, not a coverage percentage on a slide.

Raw evidence (reproducible)

T1046 nmap → ALERTED sid : 9000001 "Port Scan Detected" src : 192.168.99.50 → .20:443 MTTD: 3.27 s (QRadar-indexed) T1486 file-encrypt → ALERTED audisp-syslog SYSCALL openat key : ransom_write (log source: LinuxServer @ victim-ubuntu)

Stated plainly. These are fixes on one bench, one configuration — standard detection engineering (a network sensor; host audit), not a product trick. The point of showing them is that the reality check closes its own loop: it doesn't just tell you what's blind, it proves what makes it see. Replay → gap → tune → replay.

What IBM QRadar actually detected — replayed, timed, reproducible

We fixed the two blind spots and re-ran the attacks — both now fire

If you want this on a build of yours