href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&display=swap">

HANDS-ON LAB: SECURE AI AT RUNTIME WITH GHS & CROWDSTRIKE | Oct 13

REGISTER HERE

IBM i CURRENCY DEBT WEBINAR | OCT 8

REGISTER HERE

INTRODUCE AI WITHOUT REBUILDING YOUR IT ENVIRONMENT WEBINAR

GET THE RECORDING

ON-DEMAND GOOGLE'S AGENTIC SECOPS WEBINAR

Watch Recording

WIZ CLOUD SECURITY BLUEPRINT WEBINAR

REGISTER HERE

MITRE ATT&CK · Synthetic telemetry

Real attack telemetry. Without the attack.

Pick the tactics. TTXAgent builds the campaign and writes the Windows event logs to match — files on your machine, no agent, nothing touching your network.

Currently allowlisted. Every request is read by a person.

One run · E2B8502E

5
Stages
161
Events
466s
Stage span
9
Files
527 KB
On disk
  1. T1566.001Initial Access
  2. T1059.001Execution
  3. T1574.001Stealth
  4. T1685.001Defense Impairment
  5. T1219.002Command & Control

Four tactics requested, five resolved · ATT&CK v19.2 · 3,754 Sigma rules evaluated · ten checks passed

Getting attack telemetry means building somewhere for the attack to happen.

Atomic tests, attack ranges, BAS agents — every route to it starts with an environment you stand up, instrument, and run something hostile inside.

TTXAgent skips the environment. It writes what the intrusion would have left behind: the campaign, the process tree underneath it, and the Windows event log to match.

Building it yourself

  1. Stand up a lab
  2. Instrument it
  3. Run something hostile
  4. Collect the logs

and again for the next technique

With TTXAgent

  1. Name the tactics
  2. Read the logs

What TTXAgent does

  1. 01

    Build the campaign

    Name the tactics. It resolves a chain ATT&CK actually permits, in the order an operator would run it.

  2. 02

    Write the telemetry

    Windows event XML with real process lineage: parent PIDs, process GUIDs, one logon session across every stage.

  3. 03

    Hand it over

    One folder. The exercise document, the event log, and the JSON behind both.

It survives a close read.

Fake telemetry falls apart the moment an analyst pivots on it. Every stage here inherits from the one before — real parent PIDs, real process GUIDs, one logon session.

One lineage · run E2B8502E
OUTLOOK.EXE3360
WINWORD.EXE3364 T1566.001 spawns
powershell.exe3508 T1059.001 spawns
T1574.001 · T1685.001 · T1219.002 attach — same pid, no new process

Five stages, one process tree. Three of them never spawn anything — they act as pid 3508, so the remote-access beacon has a parent you can trace all the way back to the attachment.

Campaign record · E2B8502E
started
2026-08-25T20:07:46Z
computed
host
TTX-LAB-E2B8502E-WS01
computed
pid · guid
3364 · {b36b902b…}
computed
tactic order
TA0001 → TA0002 → TA0005 → TA0112 → TA0011
computed
timeline
669s story · 466s event
computed
every table
rendered from the above
computed
technique
T1566.001
model picks
narrative
“The adversary uses Spearphishing Attachment…”
model writes

It picks the technique and writes the sentence. Everything else is derived from them.

The model writes two fields out of eight.

Anything that has to be internally consistent — hosts, PIDs, timestamps, tactic order — is computed and rendered from data. Technique names are read from the ATT&CK bundle on every call, never from model recall.

Safe to put in production.

Every event carries the campaign's own hostname prefix, so it stays identifiable wherever the logs end up — including in a SIEM already full of your own traffic. Adversary addresses come from RFC 5737 and cannot route anywhere.

Your SIEM, after ingest
  1. your traffic
  2. TTX-LAB-E2B8502E-WS01Sysmon 11invoice.cplsynthetic
  3. your traffic
  4. TTX-LAB-E2B8502E-WS01Sysmon 1powershell.exesynthetic
  5. your traffic
  6. TTX-LAB-E2B8502E-WS01Sysmon 22cdn-e2b8502e.example-c2.netsynthetic
  7. your traffic
Isolate this campaign
principal.hostname = /^TTX-LAB-E2B8502E/
Exclude all synthetic data
principal.hostname = /^TTX-LAB-/
This run's C2 address
203.0.113.46

Where the output lands

Loads into

  • Splunk
  • Microsoft Sentinel
  • Elastic
  • Google SecOps
  • QRadar

Standard Windows event XML. If your SIEM reads Sysmon, it reads this.

One folder. Everything self-describing.

Someone opening a run folder weeks later can tell what the campaign was, which ATT&CK and Sigma versions it was built against, and how to find it in the SIEM — without this tool installed.

out/E2B8502E/
  1. TTX-E2B8502E.md29.1 KBthe exercise document
  2. WINDOWS_SYSMON.xml230.3 KBreplayable Windows event XML
  3. events.json197.4 KBevery event, structured
  4. entities.json12.1 KBhosts, users, processes, infrastructure
  5. timeline.json48.8 KBstage offsets and dwell
  6. chain.json4.9 KBthe ATT&CK chain and why each technique
  7. validation.json1.7 KBten checks, all passing
  8. manifest.json1.5 KBversions, marker hosts, SIEM query
  9. oracle.json1.3 KBSigma rules evaluated

Nine files, 527 KB. No database, no proprietary format.

Three ways teams use a run.

  1. Tests your content

    Detection engineering

    Fire a rule against a full chain before it ships, not against one hand-written event.

  2. Tests your process

    Tabletop exercises

    Injects, discussion questions and facilitator notes ship in the document. Seventy-five minutes, already written.

  3. Tests your people

    Analyst training

    New analysts pivot a real chain in your own SIEM, not in a vendor’s sandbox.

Load one into your SIEM and see what fires.

Tell us which tactics you want to exercise. We build the campaign, hand you the bundle, and walk your team through what the SOC caught.

Every request is reviewed by hand before an address is added to the allowlist. We use what you send here only to reply about access.