# Adversary Emulation

> Adversary emulation driven by what your sensors observed: a safe procedure library, a gated engagement with kill switch, and a coverage-gap report.

Source: https://wahukeza.com/platform/emulation

Validate · Adversary Emulation

## Validate against what actually hit you. Safely, by construction.

Exposure validation that starts from your own sensor telemetry rather than someone else’s advisory. A human-reviewed procedure library, a fail-closed authorisation gate, an agent that defaults to dry-run, and a coverage-gap report that names the observed threat each gap came from. In the Complete package or licensed on its own; the platform orchestrates only.

The loop’s last stage

## Observe → recommend → authorise → validate → report.

1.  01
    
    ### Observe
    
    Sensors and endpoints record what attackers actually do (commands, techniques, tooling) as classified behaviour mapped to ATT&CK.
    
2.  02
    
    ### Recommend
    
    Observed TTPs are matched to safe procedures in the library; the recommendation says why: which sessions, which techniques. An attack-surface finding can propose a draft engagement too.
    
3.  03
    
    ### Authorise
    
    An engagement names the targets, the window, the cap and the approver. It is the only thing that can start a task.
    
4.  04
    
    ### Validate
    
    A customer-deployed agent runs benign proxies of the procedure, dry-run by default, re-checking scope locally with its own kill switch.
    
5.  05
    
    ### Report
    
    The coverage-gap report: which observed techniques your controls detected, which they did not, with the operator’s annotations.
    

From exposure to evidence

## An exposure your sensors say is being hunted? Propose a test.

Attack Surface Management finds what you expose from the outside, and your own sensors say which of those exposures attackers are probing this week. From a finding, the platform can propose a draft engagement against the affected asset. It stays a draft: nothing runs until a human names the targets and the window and authorises it.

[Attack Surface Management](https://wahukeza.com/platform/attack-surface)

engagement · draftnot authorised

proposed from

exposure finding · exposed admin panel

pressure

probed on your sensors: 14 sources in 7 days

targets

to be named by the approver

window

to be set by the approver

runs

nothing, until authorised

Illustrative.

Safety architecture

## Six things that must all be true before anything runs.

-   SafeProcedure · review
    
    ### Curated library
    
    Seeded, human-reviewed procedures with an edit-and-re-review workflow. Captured attacker artefacts are never a source of procedures: there is a hard wall between the artefact store and the library.
    
-   Engagement
    
    ### The authorisation primitive
    
    Targets allowlisted, a time window, MaxTargetsPerRun enforced, an approver recorded. Tasks outside a live engagement are refused at the gate and again by the agent.
    
-   emulation/agent
    
    ### Customer-deployed agent
    
    A stdlib-only Go binary you run. It runs benign proxies, defaults to dry-run, re-validates scope locally and carries its own kill switch.
    
-   X-Agent-Token
    
    ### Its own gateway
    
    The agent protocol re-checks the engagement gate per task. No emulation execution capability ships in the platform itself.
    
-   Features.AdversaryEmulation
    
    ### Off by default
    
    The controllers are entitlement-gated and disabled unless licensed. A deployment without the flag has no emulation surface at all.
    
-   audit
    
    ### Every step logged
    
    Engagement creation, approval, task queueing, agent enrolment and report snapshots are sensitive mutations in the audit log.
    

Coverage-gap report

## The deliverable, with the provenance attached.

For each observed technique: was it emulated, was it detected, by which control, and which sessions on which sensors were the reason it was chosen. Live compute or a snapshot; the operator annotates detections; the result is the evidence a validation programme is measured on.

[Where this fits a testing mandate](https://wahukeza.com/solutions/compliance)

coverage-gap · engagement e-17 · snapshot3 gaps / 9 observed

| technique | observed on | emulated | detected |
| --- | --- | --- | --- |
| T1110 brute force | mikrotik ×14 | yes | yes · SIEM rule |
| T1105 ingress tool transfer | fortigate cli ×3 | yes | no |
| T1136 create account | routeros ×5 | yes | yes · EDR |
| T1053 scheduled task | unifi-os ×2 | yes | no |

Illustrative: an excerpt of a sample report.

Straight answer

## What this is not.

-   ### Not a red team
    
    Benign proxies of observed techniques, in a window, on allowlisted targets. It answers “would we have seen it”, not “can we be breached”.
    
-   ### Not post-compromise coverage by default
    
    Sensor-observed techniques skew toward what hits the perimeter. The high-interaction personas are what pull the library past the login wall, and we publish what they catch.
    
-   ### Not a change ticket for the sensing half
    
    Sensor collection is out-of-band: the Deception Fabric needs no agent on a production endpoint and drops no payload. Only the validating needs a change window.
    

## Start from what your sensors saw.

Run one engagement against one host with the agent in dry-run, and read the coverage-gap report with the sessions that justified it.

[Book a demo](https://wahukeza.com/contact?intent=demo)

[See the packages](https://wahukeza.com/pricing)