VCyber Twin · Breach & attack simulation on a digital twin

Your detection rate is a number.

Most teams have never seen it.

Coverage percentages come from counting rules. We get the number the other way round: replay the technique, watch the SIEM, and write down what fired, what stayed silent, and how long each one took.

T1110.001 · same attack, three SIEMs
Measured on ATK’s bench alert time from first attempt
3 / 24
Techniques caught by an out-of-the-box deployment on our bench. Defaults are a low bar, and nobody publishes how low.
50 → 83 %
Coverage on the same build, run over run, after adding two detection rules.
~70
ATT&CK techniques in the library, across ~57 scenarios and ~54 Sigma rules.
3
SIEMs measured natively — Wazuh, Splunk and IBM QRadar — with the same attack and the same clock.
How it works

Nothing touches
your environment.

01 · Model

We build a twin of the stack you want measured — hosts, roles, network zones and the SIEM configuration — as a graph. No agent is installed on your side and no production system is involved.

02 · Replay

Real techniques run against the twin: credential brute force, lateral movement, ransomware behaviour, command and control. Not synthetic log injection — the attack actually executes.

03 · Time it

Every technique is timed against the SIEM's own alert stream. The same SSH brute force (T1110.001) alerted in roughly 0–2 s on Wazuh, ~4 s on Splunk and ~4–8 s on QRadar. Those are clock readings, not estimates.

04 · Close the loop

Silent techniques come back with the detection content that would have caught them. Add the rules, run again, and the delta is the part you can put in front of someone who signs.


What you get

Two pages that
settle an argument.

What fired. What stayed silent. How long each one took.

A report on one stack profile, in language a technical buyer can check and a non-technical one can act on. It runs on our bench, so nothing goes through your change board and nothing goes through your procurement.

For a provider

A number you can put in a renewal conversation or a competitive pitch — evidence that the tuning you did is worth what you charge for it, rather than an assertion the client is asked to trust.

For an in-house team

A third-party measurement. A number your own team produced is the one a board quietly discounts; the one that travels is the one you did not produce yourself.


Scope

What this is not.

The honest sentence

We configure a build to match one of your stack profiles and measure that. The report characterises that build, not your live estate — and it says so, in the report, in those words. Anyone selling you a bench result as a measurement of production is selling you something they cannot deliver.

Not a penetration test

A pentest answers can this be exploited? This answers would anyone have seen it? The two are complementary, and a pentest report carries no detection telemetry.

Not a scorecard on your vendors

This measures configuration and deployment. It is not a verdict on any product you have partnered with or resold.

Current status

Pilot. Live demo environment, single-tenant per twin, no production customer deployment yet. We would rather tell you that here than have you find out in week three.


Pick one representative stack.

Tell us the shape you see most often across your customers — SIEM, endpoint, and roughly how it is tuned — and we will scope the measurement against that. Pricing follows the number of stack profiles, so it is a short conversation.