From Correlated Telemetry to Exact Runtime Evidence: Understanding Malware INFO Deep API Trace

Why API evidence matters

Windows programs reveal themselves through several different evidence layers. A Portable Executable import table can show that a file references CreateFileW, VirtualProtect, or connect. Strings can reveal paths, URLs, service names, or commands. Those facts are useful, but they describe capability or retained content. They do not establish that the program reached the corresponding function during a particular execution.

Runtime evidence answers a narrower question: what activity was observed from this process instance, during this collection window, through the sources that were available?

Even that question has levels. A Guard file event can associate a write with a verified process identity. ETW can show image-load or process metadata. An exact supported API observation can add the function boundary, bounded parameters, return outcome, thread, order, duration, and caller location. These records complement one another; one should never be relabelled as another.

None of them is a malware verdict by itself. VirtualProtect, registry writes, cryptography, process creation, and network connections all have legitimate uses. Meaning comes from identity, sequence, targets, outcomes, neighboring evidence, contradictions, collection health, and the investigation context.

Three observation models

Malware INFO separates three models because they answer different questions and impose different costs.

Guided API Trace: identity-bound correlation

Guided API Trace is the normal starting point. It correlates available Guard and Windows telemetry with a compound process identity. Its rows can describe process, image, file, Registry, and network observations without debugger breakpoint interception.

This lower-impact model is useful for establishing a behavioral outline, checking whether expected sources are healthy, and deciding whether an unanswered question really requires call-level evidence. Guided rows remain correlated evidence and retain the NotApiCall boundary. They do not invent API parameters, return values, or caller addresses.

Missing Guided telemetry is not benign evidence. A source may be stopped, unavailable, late, filtered, or outside the observation window. Read source state and gaps before interpreting an empty result.

Deep API Trace: exact supported boundaries

Deep API Trace uses a verified matching-bitness x86 or x64 worker and bounded debugger-based observation. It is designed for questions such as:

• Which supported function was actually reached?
• What bounded arguments were available at entry?
• Did the call return, and what outcome was recorded?
• Which thread made the call, and how long did the paired operation take?
• Which loaded module and relative call site led to the function?
• In what order did the observed operations occur?

Only events that satisfy the exact worker and session contract can become Observed - Exact. Guard, ETW, Sysmon, managed-runtime metadata, worker-health events, and Guided observations do not become exact API calls merely because they appear in the same timeline.

API Hook Trace: an unavailable, more invasive model

API Hook Trace is a product-disabled design and is not currently available in Malware INFO. Its intended model would place hook or trampoline logic inside the observed process. In theory, that can provide flexible wrapper-level interception and richer in-process context. It also changes the target more directly: code or data may be injected, function prologues may be modified, hook integrity must be maintained, and anti-tamper or anti-hook logic may react.

Those intended trade-offs must not be presented as implemented capability. No analyst should plan an investigation around API Hook Trace until the product explicitly enables and validates it.

How Deep API Trace works

Deep API Trace is not a request to record every instruction or every Windows system call. It is a controlled observation contract around a reviewed set of supported native API boundaries.

Matching architecture and verified identity

An x86 target requires the x86 worker; an x64 target requires the x64 worker. Before evidence is accepted, the session binds the target by more than PID alone. Process creation time, executable identity, architecture, session identity, worker identity, and launch or attach context protect the trace from PID reuse and accidental cross-session attribution.

For a disk launch, Preflight establishes whether the selected file and architecture are eligible before controlled execution. For a running target, the selected process instance must still be revalidated. A row retained from one process instance is not rebound merely because another process later receives the same PID.

Reviewed allowlist and breakpoint coverage

The collector resolves supported exports from the current allowlist and records whether each boundary was configured, installed, unavailable, shared, pending, or failed. Configured means the product knows how to attempt that boundary. Installed means observation was established for that session. Observed means the target reached the installed boundary during the effective window. These states are not interchangeable.

Software breakpoints can change timing. Loader state, shared addresses, export forwarding, late module loads, or a failed breakpoint write can create explicit coverage gaps. Direct syscalls, copied syscall stubs, custom code, unsupported wrappers, execution in another PID, and activity before collector readiness can remain outside exact coverage.

Entry, return, and bounded values

For a supported call, the worker can pair entry and return evidence when the contract permits it. The resulting row can carry bounded parameter metadata, a return value or status, thread identity, elapsed time, and a caller address. Raw file, network, registry, cryptographic, credential, or memory buffers are not automatically copied simply because their pointer appeared in a call.

Readable operational text is a separate trace-start choice. Even when enabled, sensitive credential-shaped values, tokens, cookies, authorization data, passwords, and key material must remain redacted. An investigator may preserve authorized sensitive source evidence through the product's protected evidence workflow, but ordinary reports should not expose it.

Call-site attribution and authenticated ingestion

A return address can be mapped to a verified loaded module and relative virtual address when the session has sufficient module context. This is more useful than a function name alone: it can distinguish a call originating from the main image, a loaded DLL, or an unattributed region. Attribution can still be unavailable or partial and must remain labelled as such.

Before the Guard Service accepts a Deep row, the event is checked against the expected session, PID and start identity, worker instance, architecture, sequence, time window, schema, and per-API contract. Replay, wrong-worker, stale, future, malformed, gap, or post-terminal records are rejected or counted as diagnostics rather than silently promoted.

Why Guided normally comes first

An investigator should choose the least invasive source that can answer the approved question. Guided API Trace often provides enough identity-bound context to show that a process started a child, loaded an image, touched a file or Registry path, or attempted network activity. It can also reveal whether the surrounding telemetry is healthy before the analyst changes the target's timing with a debugger.

Deep becomes justified when the remaining question depends on exact supported parameters, outcomes, ordering, or call-site evidence. Examples include distinguishing a failed attempt from a successful operation, resolving which module initiated a supported call, or testing whether a suspected API sequence appeared during a reproducible path.

Starting with Guided is not a rule that Guided evidence is weaker in every respect. A verified Guard file event may prove a system effect that an API entry row cannot. Deep and Guided represent different evidence classes, and the best investigation preserves both without double-counting one root observation.

A safe Deep Trace workflow

Deep API Trace executes or attaches to code; it is not a sandbox. Use it only inside an authorized disposable analysis VM with a recoverable clean snapshot, no credentials or customer data, no shared clipboard or folders, no connected business drives or devices, and no trusted network path.

1. Preserve the original artifact, source, path, timestamps, signer context, and SHA-256.
2. Define the exact question that correlated telemetry could not answer.
3. Run Preflight and verify target architecture, process identity, worker readiness, and expected coverage.
4. Prefer Guided API Trace first unless call-level evidence is already necessary.
5. Select the exact running process or native disk executable and review arguments and working context.
6. Read the controlled-execution warning and provide consent only for this bounded lab run.
7. Keep the observation window short enough to control risk but long enough to exercise the approved path.
8. Monitor Session Health, coverage transitions, dropped records, and the effective API window.
9. Stop and finalize the session deliberately; do not interpret a still-draining evidence set as complete.
10. Export a verified terminal evidence package and preserve its checksum inventory and limitations.

The consent boundary matters because a target can modify or encrypt files, change persistence, access credentials, create processes, communicate over available networks, exploit a vulnerability, or crash the VM before the analyst stops it. Terminating the controlled process does not reverse those effects.

The evidence journey

The useful unit is not an isolated API name. It is the path from target identity and collector readiness through exact and supporting observations to a coverage-aware report.

1. Establish the effective window

The timeline begins with lifecycle and readiness events. Confirm requested mode, effective mode, worker architecture, target PID and start identity, collector-ready time, and terminal state. Rows before exact readiness or after finalization do not acquire exact authority.

2. Follow exact calls back to their caller

Call-site Attribution groups accepted API observations by caller kind, loaded module, RVA, virtual address, evidence sequence, and confidence. This can connect a runtime operation to code inside a particular loaded image without claiming that the module is malicious.

3. Read the report from collection truth outward

The readable HTML report is a navigation and interpretation layer. Begin with Collection Verdict, not the behavior-risk panel. Confirm that Deep was both requested and effective, that the matching worker was verified, and that exact rows reached the final timeline. Keep the exact count separate from correlated NotApiCall rows.

4. Reconcile coverage and retained memory artifacts

Evidence Coverage and Alignment separates readable timeline rows, exact API rows, distinct supported APIs, supporting telemetry, static capability context, gaps, and retained memory artifacts. A memory artifact is a separate static-analysis handoff. Bytes present in a snapshot do not prove which API created, decrypted, protected, or executed them.

How to read the exported evidence

The original structured JSON and JSONL records plus their hashes remain the forensic source of truth. HTML is an analyst-readable view, not a replacement evidence source.

Read the package in this order:

1. Collection Verdict: Was Deep actually active, or merely requested? Did the worker and session reach a valid terminal state?
2. Target identity: Do PID, creation time, executable identity, architecture, and session binding describe the intended process instance?
3. Effective window: When did exact collection become ready, and when did it stop?
4. Coverage: Which supported boundaries were installed, unavailable, pending, shared, failed, or observed?
5. Diagnostics: Were rows dropped, malformed, rejected, late, or unavailable during final drain?
6. Exact rows: Use Observed - Exact only for accepted supported calls. Review parameters, result, duration, thread, and caller together.
7. Supporting rows: Keep Guard, ETW, Sysmon, Guided, managed-runtime, and lifecycle records as correlated or NotApiCall evidence.
8. Derived views: Treat behavior chains, resource lineage, execution graphs, and risk scores as traceable analysis built from cited evidence, not new independent observations.
9. Memory handoff: Analyze retained artifacts statically and reconcile session ID, PID, capture time, base address, artifact identity, and hash.

A high collection confidence says that the stated record passed its evidence contract. It does not mean the action was malicious. A deterministic behavior-risk score is a triage aid, not probability, malware-family attribution, confirmation, severity, or containment authority.

Guided versus Deep versus API Hook Trace

Evidence class

• Guided API Trace: identity-bound Guard and Windows correlation; rows remain supporting evidence or NotApiCall.
• Deep API Trace: exact observation only for accepted supported debugger boundaries; other sources retain their original authority.
• API Hook Trace: intended in-process hook evidence; product-disabled and not currently available.

Target impact and startup visibility

• Guided: lower impact and no debugger breakpoint interception, but visibility depends on the participating telemetry sources.
• Deep: changes scheduling and timing through debugger control and software breakpoints. A suspended disk launch can establish readiness before the controlled target resumes, while attach scenarios may miss earlier activity.
• API Hook: intended to modify the process more directly through injected hook logic or patched call paths. Startup coverage would depend on how early and reliably the hooks were installed.

Parameters and payload visibility

• Guided: does not provide exact function parameters or return values.
• Deep: records only bounded values defined by the supported API contract. Raw buffers and sensitive values are excluded or redacted by policy.
• API Hook: could theoretically inspect richer in-process context, but that would increase privacy, storage, parser, and secret-handling risk. This has not been enabled or validated as a current product capability.

Evasion and blind spots

• Guided: can miss activity when required providers are unavailable or when an action does not surface through collected telemetry.
• Deep: can alter timing or trigger anti-debug behavior. Unsupported APIs, activity outside the effective window, another PID, direct syscalls, copied stubs, and custom code may remain unseen.
• API Hook: would be exposed to hook bypass, prologue integrity checks, unhooking, alternate exports, direct syscalls, and anti-instrumentation behavior in addition to installation gaps.

Privacy and storage

• Guided: generally retains lower-volume metadata, still subject to path, identity, and operational-data controls.
• Deep: adds call-level records, bounded parameters, caller attribution, diagnostics, and optional protected memory artifacts. Storage and review cost are higher.
• API Hook: richer in-process capture would create the highest risk of collecting buffers, secrets, or customer data and would require a separately validated privacy contract.

Current availability

• Guided API Trace: available for selected-process correlation when its prerequisites and sources are healthy.
• Deep API Trace: available for supported native x86/x64 investigations when Preflight, identity, worker, policy, and consent gates succeed.
• API Hook Trace: product-disabled and not currently available.

What Deep API Trace cannot prove

Deep API Trace cannot independently prove:

• that a file belongs to a particular malware family;
• that an observed API use was malicious or attacker-directed;
• that every behavior of the target was captured;
• that an unobserved call never occurred;
• that a configured API breakpoint was installed or reached;
• generic visibility into direct syscalls, copied syscall stubs, arbitrary custom code, or unsupported wrappers;
• exact behavior that ran before readiness, after stop, or in an untraced child or peer process;
• that bytes found in memory were allocated, decrypted, protected, or executed by a particular observed call;
• sandbox containment, rollback, or safety for the host environment;
• authority to quarantine, terminate, delete, block, or perform another automatic response.

Sparse results may mean minimal activity. They may also mean the wrong execution path, missing configuration, a loader failure, anti-debug behavior, early exit, another process, unsupported code, or incomplete coverage. The correct statement is “not observed within the available coverage,” not “did not happen.”

When to use Deep API Trace

Use Deep API Trace when all of the following are true:

• The investigation is authorized and runs in a disposable isolated lab.
• A precise question remains after static analysis and lower-impact correlation.
• The answer depends on supported parameters, return outcomes, ordering, duration, thread, or caller attribution.
• The target is an eligible native x86 or x64 process or disk executable.
• Debugger timing and anti-debug impact are acceptable limitations.
• The analyst can review readiness, gaps, dropped records, identity, and finalization rather than treating the event count as complete coverage.

Stay with Guided API Trace when identity-bound process, file, Registry, image, or network context answers the question, when a debugger would materially disturb the target, or when the target cannot satisfy Deep prerequisites. Use static analysis and memory analysis when the question concerns retained code or data rather than observed execution.

The strongest conclusion is often a layered one: static evidence describes capability, Guided evidence describes correlated system activity, Deep evidence establishes selected supported calls, and memory evidence preserves retained bytes. Each layer should say exactly what it observed, exactly what it could not observe, and no more.