# Artifact analysis

> Malware and URL artifact analysis: static triage, dynamic detonation in isolation, payload retrieval, and a ledger of the indicators each run produced.

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

Correlate · Artifact analysis

## Every payload becomes indicators, and a receipt.

Captured artefacts go through static triage and, when an admin sends them, dynamic detonation in isolation, and what comes out is minted through the same write path as every feed. A first-party ledger records exactly what each run produced and whether the platform had seen it before.

Pipeline

## Capture to ledger in five steps.

1.  01
    
    ### Capture
    
    A payload dropped on a sensor, an attachment on a reported mail, or a URL the platform fetched into quarantine.
    
2.  02
    
    ### Static triage
    
    Assemblyline unpacks recursively, types the artefact and scores it, without executing anything. Optional, configured separately, with its own retention.
    
3.  03
    
    ### Detonation
    
    When an admin sends it, CAPEv2 runs it and returns full behavioural extraction (contacts, drops, mutexes, network) as relations.
    
4.  04
    
    ### Mint
    
    Hashes, contacted hosts and dropped files become indicators through the same write path as every feed.
    
5.  05
    
    ### Ledger
    
    Each run records which indicators it derived and whether they were new to the platform: the proof of first sight.
    

Two backends, one seam

## Assemblyline for the middle tier, CAPE for the deep one.

-   Triage:Provider
    
    ### Assemblyline static triage
    
    Recursive unpacking, typing and scoring, with nothing executed. Submission, polling and intake jobs; triage panels on the artefact; auto-triage of sensor artefacts and phishing attachments, skipping any hash already triaged.
    
-   Detonation:Provider
    
    ### CAPEv2 detonation
    
    Dynamic analysis with full behavioural extraction, started by an admin and never automatically. Submission and polling jobs, a detail page per run, and an unknown provider fails fast rather than silently disabling it.
    
-   MalwareBazaar
    
    ### Known-sample lookup
    
    Captured artefacts are cross-referenced by hash against MalwareBazaar, so a known sample arrives with its context before anyone decides to detonate it.
    

Appliance supervision

## A stalled analysis backend is noticed, not discovered.

-   end-to-end probe
    
    ### Liveness, not queue age
    
    A small probe file is submitted to Assemblyline on a schedule and must come back analysed. When it does not, dispatch defers and intake queues nothing, instead of submissions failing silently.
    
-   appliance:agent
    
    ### An outbound agent, one verb
    
    An agent on the appliance host reports status outward and collects a single signed, expiring restart document for a unit on an allowlist. There is no inbound command channel and no shell; its API key scope is isolated, so no admin key can drive it.
    
-   off by default
    
    ### Bounded self-heal
    
    Optionally, the platform restarts the stalled components in a fixed order, re-probing between steps, within hard limits. The datastore is never restarted automatically.
    

URLs

## Liveness is a fact about the indicator, so it is stored as one.

-   reachable | unreachable | unknown
    
    ### URL reachability
    
    Malware-delivery and phishing URLs are probed on ingest and rescanned with backoff. Liveness feeds confidence and is a list column analysts sort by.
    
-   delivers
    
    ### Payload retrieval
    
    A reachable malware-delivery URL is fetched into quarantine, typed, routed to triage or the command extractor, and its hash minted with a delivers relation, distinct from the sandbox-observed drops edge.
    
-   SSRF guard
    
    ### Fetching safely
    
    Every outbound fetch passes the platform’s SSRF guard: no private ranges, no metadata endpoints. Sensors never fetch anything: a URL an attacker hands a sensor is recorded, and the platform fetches it later into quarantine.
    

The first-party ledger

## Proof of first sight, per run.

For each triage, detonation, payload retrieval or sensor run, the ledger lists the indicators it derived and marks the ones that did not exist anywhere in the platform when they were minted. That is the number a provider puts in the client report, and the number a feed buyer asks for.

[How the feed uses it](https://wahukeza.com/platform/exchange)

ledger · run 2026-09-14T03:10 · detonationcape

| derived | type | new to platform |
| --- | --- | --- |
| 9f2c41d7…6e0a | hash | yes |
| 203.0.113.10 | ip | yes |
| update-cdn.example | domain | seen before |
| t13d…2ab1 | ja4 | yes |

Illustrative run. 3 of 4 derived indicators were new to the platform when minted.

## Send us a sample.

Drop a payload into a reference deployment and follow it from triage to ledger in one session.

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

[Next: enforcement & integrations](https://wahukeza.com/platform/enforcement)