Guides

How to Use Malware INFO Safely: Complete Investigation Workflow and Feature Guide

A safety-first guide to Malware INFO—from initial triage and Live Protection through intelligence, memory, API and DLL analysis, verified evidence export, and executive reporting.

How to Use Malware INFO Safely: Complete Investigation Workflow and Feature Guide

What Malware INFO is—and what it is not

Malware INFO is a local-first Windows malware research and incident-analysis workstation. It helps an analyst move from an alert, suspicious file, process, URL, domain, IP address, persistence entry, memory artifact, or endpoint event to evidence that can be reviewed, preserved, correlated, and explained.

It is designed to work with your existing antivirus, Endpoint Security, EDR/XDR, SIEM, SOC, CERT/CSIRT, and incident-response procedures. It does not replace those systems. Its purpose is to expose artifacts and relationships that an existing security product may not show in enough detail, then help a user make a better evidence-based decision.

The application is most effective when the user understands both the evidence and its limits. A beginner can follow its guided workflow and Help, while an experienced analyst can use its deeper process, memory, API, DLL, intelligence, and correlation views. A finding, score, API name, rule match, or exported report is evidence for review—not an automatic malware verdict or authority to contain an endpoint.

Critical safety warning: Malware INFO does not make unknown code safe to execute. Live execution, API tracing, DLL tracing, and behavior testing belong only in an authorized disposable isolated analysis VM with no trusted network, credentials, shares, or sensitive data. Bounded execution, matching-bitness workers, consent gates, cleanup controls, and VM snapshots reduce operational risk; they are not sandbox containment or a guarantee that every system change will be rolled back.

Before you begin: choose the correct environment

Use an ordinary investigation workstation for non-execution tasks such as indicator lookup, local file inspection, evidence review, reporting, and administration. Use the authorized disposable VM for any workflow that may launch, load, attach to, debug, or unpack untrusted code. Keep production credentials, browser sessions, mapped drives, shared folders, clipboard integration, and trusted network access out of that VM.

Before handling an artifact, record:

  1. Original path and file name.
  2. File size and SHA-256.
  3. Discovery time, source, user, alert, email, download, or parent process.
  4. Any action already taken by antivirus, EDR, email security, or another responder.
  5. The case ID, affected device, analyst, and collection time.

Preserve the original evidence. Analyze a controlled working copy according to your organization’s policy, and keep the original and working-copy hashes with the case record.

1. Start at Command Center

Malware INFO Command Center showing license, Guard health, scan readiness, and recent findings
Malware INFO Command Center showing license, Guard health, scan readiness, and recent findings

Command Center provides the fastest operational overview. Confirm the active edition, license state, Guard/Live Protection state, engine readiness, recent findings, scan activity, Help language, update state, and any degraded or stopped component before starting an investigation.

A red, amber, paused, stopped, starting, recovering, stale, degraded, blind, unsupported, or disconnected state needs attention, but it is not automatically a malware detection. Green or On is meaningful only when required providers are initialized, observations are fresh, queues and loss remain within budget, historical recovery is complete, and no required blind interval remains. Read the accompanying status and diagnostics; missing telemetry is unavailable coverage, not proof that no activity occurred.

The in-app Help is available in 22 languages. Changing Help language changes the documentation content; the application interface remains English.

2. Use Threat Lookup without losing the privacy boundary

Threat Lookup report workspace for a selected file hash
Threat Lookup report workspace for a selected file hash

Threat Lookup can investigate:

  • SHA-256, SHA-1, and MD5 indicators
  • Files, when an explicit upload is permitted
  • URLs and domains
  • IPv4 and IPv6 addresses
  • Reputation, relationships, detections, comments, and available provider context

Begin with a SHA-256 lookup when possible. Sending an indicator is different from uploading a complete file. Malware INFO does not silently upload a sample, memory capture, Guard history, API Trace evidence, quarantine item, or private rule database for cloud analysis. A complete file leaves the computer only after the user deliberately chooses an upload action and confirms it, and only when organizational policy permits sharing it with that provider.

Third-party reputation is intelligence context—not an automatic local verdict. Review provider, detection ratio, first/last seen times, comments, relationships, signer, path, and local evidence together.

3. Use Scan Studio as layered triage

Scan Studio with Rapid Scan, Deep Signature Scan, and Zero-Day Analysis results
Scan Studio with Rapid Scan, Deep Signature Scan, and Zero-Day Analysis results

Scan Studio brings several local investigation paths together:

  • Rapid Scan checks supported files against local hash intelligence.
  • Deep Signature Scan reviews supported files with HEX signatures and YARA rules.
  • Zero-Day Analysis adds bounded static, heuristic, structure, trust, and behavior-oriented triage evidence.
  • Memory and persistence-related inspection can add context where the selected workflow supports it.

Current legacy Rapid hash and Deep Signature HEX/YARA findings are AlertOnly, even for an exact match or a score of 100. Their grids support review, details, copy/export, approved reputation lookup, and evidence preservation, but they do not authorize process termination, quarantine, delete, blacklist, whitelist/exception, IP block, or policy mutation.

A Zero-Day Analysis score is also triage evidence, not response authority. A score is not probability, confidence, severity, or proof of malware. Read source, engine, rule or indicator identity, provenance, signer, path, coverage, operation state, contradictions, suppressors, and related activity before deciding what to do next.

Professional and Enterprise users may also have access to the current evidence-bound Automated Unpacker workflow. A valid PE file is not automatically packed, malicious, benign, or supported. Use Preflight, exact path/architecture/size/SHA-256 review, fresh per-session consent, and an isolated lab. Dump, Candidate, and Fixed artifacts are evidence classifications—not permission to run recovered output. Never execute an unpacked artifact merely because repair or import reconstruction completed.

4. Read Protection Matrix and Live Protection evidence

Protection Matrix showing Guard state, protection controls, engine settings, and activity evidence
Protection Matrix showing Guard state, protection controls, engine settings, and activity evidence

Professional and Enterprise editions add continuous endpoint visibility through Live Protection and Protection Matrix. Depending on the supported environment and current state, the workspace can present bounded evidence for:

  • File creation, modification, rename, delete, and related scanning
  • Process start and process relationships
  • Registry activity
  • Network connections
  • Memory-related observations
  • Security timeline and behavior correlation
  • Queue, provider, freshness, and coverage health

File Activity separates the Writer Process from the Scan Subject. Exact writer attribution requires the same live PID, process start time, executable path, and executable file identity. When those facts are partial, unavailable, ambiguous, stale, or unsupported, treat the row as unresolved or unattributed—never guess the writer from timing, filename, or proximity. Hidden unresolved telemetry and yield counts describe collection coverage, not cleanliness.

Interpret decision words carefully:

  • Observed means activity was recorded without a malicious verdict.
  • Allowed means current policy did not block the event; it does not certify safety.
  • AlertOnly means review is required but response authority was not established.
  • Detected means a configured confirmed-detection source matched under its applicable policy.
  • Quarantined means the supported file-containment transaction completed successfully for the named artifact.

No single row tells the complete story. Correlate exact process identity, parent and child processes, file writes, persistence, registry activity, network destinations, signer state, memory evidence, timestamps, sensor coverage, and separately governed detection evidence. Process, File, Registry, and Network observations may be exported as one manifest-verified Guard Case Evidence package for analyst-selected case correlation, but package integrity does not turn those rows into a malware verdict or response authority.

5. Review Quarantine Vault safely

Quarantine Vault showing supported containment review and restore controls
Quarantine Vault showing supported containment review and restore controls

Quarantine Vault lets you review supported contained files, associated metadata, reason, source, timestamps, and available restore or deletion operations. Quarantine, restore, and permanent deletion are Guard-owned mutations with exact identity, audit, and postcondition requirements; a scan-result grid or report does not independently authorize them.

Quarantine is containment, not permanent deletion and not proof that every related artifact has been removed. Before restoring or permanently deleting an item, confirm exact identity, business purpose, detection source, related activity, recovery location, and authorization.

Never restore an uncertain file directly into a startup folder, service location, Registry Run path, scheduled-task target, shared production directory, or another active execution path. Restoring a file does not make it trusted. If the final state is only partially proven, preserve Partially Committed or Recovery Required as the actual result and complete the supported recovery review before retrying.

6. Use Ransomware Shield as one layer of protection

Ransomware Shield policy, protected folders, canary controls, and allowed writers
Ransomware Shield policy, protected folders, canary controls, and allowed writers

Ransomware Shield adds protected-root, canary, mass-change, actor-attribution, and response-oriented monitoring where prerequisites and policy allow it.

Check protected roots, watcher and canary readiness, Guard health, audit readiness, allowed writers, thresholds, queue/loss state, and recovery state before relying on coverage. A potential ransomware-impact finding is an analytical warning, not a ransomware-family identification. File-system mass-change or canary evidence may not identify the responsible actor by itself; response requires the separately governed exact-writer and policy gates. Correlate exact process identity, handle-linked activity, API evidence, memory evidence, canaries, and the security timeline.

7. Add Threat Intelligence and external context

Threat Intelligence workspace with reusable search templates and detection-focused context
Threat Intelligence workspace with reusable search templates and detection-focused context

Malware INFO includes user-facing intelligence workflows for different investigation needs:

  • Threat Intelligence search and API exploration
  • Threat Briefing through supported RSS/Atom feeds
  • Vulnerability Alerts
  • Organization-owned licensed Threat and CVE providers
  • Dark Web Intelligence reader for a supported licensed provider
  • Organization watchlists and private intelligence workflows in eligible editions

Provider availability, license, credentials, retention, and organizational policy still apply. Intelligence can strengthen or contradict local evidence, but it does not silently create containment authority.

8. Investigate startup and persistence

Startup and Persistence Manager reviewing Registry Run, Startup, and Scheduled Task entries
Startup and Persistence Manager reviewing Registry Run, Startup, and Scheduled Task entries

Startup & Persistence Manager inventories supported Registry Run/RunOnce entries, Startup Folder files, and enabled executable Scheduled Tasks. It can help an authorized analyst review suspicious persistence and request transaction-backed removal or restoration through Guard Service.

Persistence changes affect a live system. Confirm the exact entry, executable identity, signer, business owner, dependencies, current process activity, and recovery path before changing it. Guard re-discovers the selected entry and refuses a missing, changed, ambiguous, unsupported, or read-only identity. Completed, Cancelled, Refused, Failed, Partial, and Recovery Required remain different outcomes. Do not remove an entry because its name merely looks unusual.

9. Capture and analyze selected-process memory

Payload and Memory Analyzer static-analysis workspace
Payload and Memory Analyzer static-analysis workspace

Enterprise selected-process workflows include Process Memory Capture and Payload & Memory Analyzer. Every process action refreshes and revalidates the compound identity—PID, process start time, executable path, architecture, and Windows session—so an exited process, reused PID, or changed executable is refused instead of silently captured as the original target.

Process Memory Capture currently offers six explicit formats:

  1. Windows MiniDump
  2. Full User-Mode Dump
  3. Raw Process Memory Image
  4. Individual Memory Region Dump
  5. PE Image Dump
  6. MalwareInfo Custom Memory Format

Each memory artifact is limited to exactly 1 GiB (1,073,741,824 bytes). Format and provider coverage still matter: a completed capture does not mean every address or historical action was available, and Raw Process Memory Image or MalwareInfo Custom Memory Format may retain explicitly Partial evidence. Cancellation, failure, and Recovery Required are separate from a successful capture.

Payload & Memory Analyzer performs static-only local analysis of an ordinary EXE, DLL, SYS, or supported producer artifact up to the same exact 1 GiB limit. Preflight shows producer/format information, manifest state, selected outer identity, analyzed inner identity, coverage, warnings, contradictions, and unavailable evidence before analysis. The complete report is streamed without an aggregate report-size ceiling; the 16 MiB retained analysis window is an internal working-memory boundary, not an input or export limit.

Static imports, strings, sections, metadata, API references, and capability findings show what bytes were present or what a file may be prepared to do. They do not prove that the corresponding action executed. Exact runtime API evidence and contextual NotApiCall observations remain separate evidence families. An RX or RWX region likewise shows that readable bytes existed with recorded protection at a point in time; it does not by itself prove injection or malicious execution.

Memory privacy warning: A memory capture can contain passwords, cookies, tokens, private keys, documents, conversations, internal paths, decrypted configuration, commands, and executable malicious bytes. Do not share a dump or Analyzer bundle with another person or service unless an authorized evidence-sharing policy explicitly permits it. Keep it in access-controlled storage, use an approved secure transfer channel, and never publish or automatically execute recovered content.

10. Choose Guided, Deep, or API Hook Trace deliberately

API Hook Trace controlled-launch workspace for reviewed API evidence
API Hook Trace controlled-launch workspace for reviewed API evidence

Enterprise API analysis provides different collection boundaries:

  • Guided API Trace is the least-invasive guided workflow and should normally be considered first.
  • Deep API Trace uses a matching-bitness debugger collector to record supported API entry and return evidence. It changes timing and may trigger anti-debug behavior.
  • API Hook Trace is currently carried in Version 1.2.1 as an Enterprise Developer Preview, not as the production API Hook Trace release. It actually executes the selected x86 or x64 target after Preflight and fresh per-session consent, and its evidence remains AlertOnly.

Use the least invasive mode that can answer the approved question. A live attach records only from the verified collector-ready boundary and cannot reconstruct earlier activity. Deep tracing and API hooking can change timing or control flow, add compatibility and privacy risk, and expose collection to anti-debug or anti-instrumentation behavior. Direct system calls, custom code, unsupported APIs, pre-attach activity, and host-dependent actions may still be missed. A quiet trace may mean inactivity, incomplete coverage, an incompatible path, or behavior that required a different host or trigger.

No trace mode is a sandbox, a complete execution record, a malware verdict, proof of attacker intent, rollback authority, or automatic-containment authority. Protected buffers and memory evidence require deliberate reveal/export and may contain credentials or other private data.

11. Use DLL Behavior Trace for supported native DLLs

DLL Behavior Trace controlled native DLL investigation workspace
DLL Behavior Trace controlled native DLL investigation workspace

DLL Behavior Trace is an Enterprise workflow for supported native x86 and x64 PE DLLs. Managed .NET DLLs, drivers, unsupported architectures, oversized inputs, reparse-point paths, and targets outside the supported local fixed-disk boundary are rejected. Static preflight records architecture, imports, exports, and TLS evidence before any invocation, but those facts are capability/readiness evidence rather than runtime proof.

A DLL must not be loaded into the desktop process merely for inspection. The controlled matching-bitness host supports LoadOnly, Rundll32Export, RegisterServer, and UnregisterServer. LoadOnly can still execute TLS callbacks and DllMain. Rundll32Export requires an independently confirmed compatible callback contract; a named export, ordinal, or suggestive name does not prove compatibility or behavior. Forwarded and ordinal-only exports are not invoked, and named export selection is exact and case-sensitive.

DllRegisterServer and DllUnregisterServer can modify the Registry or other system state, and unregistering does not guarantee reversal of every earlier change. Use an authorized isolated VM, review the selected invocation and expected side effects, and treat bounded runtime, suspended startup, collector readiness, Job Object cleanup, API timeline, memory snapshot, diagnostics, and verified HTML/ZIP output as observation controls—not sandbox containment or rollback.

Host-dependent, service, plug-in, and side-loaded DLLs may remain quiet in the generic host because their real behavior depends on an authentic application, configuration, environment, or trigger. When authorized, investigate the legitimate host EXE with the appropriate process/API workflow instead of guessing from an export name or a sparse DLL trace.

12. Connect evidence to an organization-controlled platform

Security Connectors configuration for an organization-controlled HTTPS receiver
Security Connectors configuration for an organization-controlled HTTPS receiver

Security Connectors can send normalized events or an already-issued AuthorizedResponse to an organization-controlled HTTPS receiver. This supports SIEM/SOC integration, including deployments such as Wazuh, without making the external platform a new malware-scoring, confirmation, or response authority. Transport never constructs missing containment authority from a path, PID, score, severity, or reason string.

Configure destination, authentication, TLS, proxy, redaction, retry, retention, event classes, and role/edition policy deliberately. Sharing is not the same as local collection: review exactly which normalized fields will leave the computer. Delivery success only proves receiver acceptance; it does not prove analyst review, successful containment, or detection correctness. Local analysis must remain usable when the connector is unavailable, and queued, retrying, rejected, or dead-lettered delivery state must remain visible.

For an implementation example, read Connect Malware INFO to an External Security Platform: Wazuh Deployment Example.

13. Manage private intelligence and product controls

Detection Library for private hashes, signatures, YARA rules, and managed intelligence
Detection Library for private hashes, signatures, YARA rules, and managed intelligence

Eligible Enterprise administration workflows include:

  • User-managed local update sources
  • Private encrypted database and rule packages
  • Organization watchlists and endpoint policy options
  • Detection Library review
  • Local Update and update-state review
  • App Lock for restricting access to protected application areas

User-supplied, imported, private, generic, or unreviewed indicators remain untrusted input. A private hash, HEX signature, YARA rule, label, score, or source name does not automatically establish confirmation or response authority. Test new intelligence against representative benign and malicious material and preserve its provenance and version.

14. Preserve Reports & Evidence

Reports and Evidence workspace for investigation records and operational logs
Reports and Evidence workspace for investigation records and operational logs

Use Reports & Evidence and each feature’s verified export path to preserve an analyst-readable handoff. Keep the complete package, manifest, and referenced sidecars together and unchanged. A readable HTML page or copied row is not a substitute for the verified package that binds source identity, inventory, byte length, and SHA-256. Record:

  1. Case ID and incident title.
  2. Source computer and user context.
  3. Malware INFO version, edition, and relevant component state.
  4. UTC collection time and analyst.
  5. Exact file or process identity.
  6. Coverage, unavailable sources, failures, contradictions, and known unknowns.
  7. Actions already taken and their postconditions.
  8. SHA-256 inventory for transferred evidence.

Reports, memory captures, trace packages, quarantine exports, and archives can contain malicious bytes and sensitive evidence. Apply the required redaction mode, keep access and retention bounded, and transfer them only through an organization-approved channel. Do not publish raw dumps, recovered payloads, credentials, or customer evidence as demonstration material.

15. Build the Final Report to CISO

Final Report to CISO workspace for evidence validation, human review, and verified export
Final Report to CISO workspace for evidence validation, human review, and verified export

Final Report to CISO is the final Enterprise reporting workspace—not another scanner. It reads the analyst-selected source folder on demand and verifies each supported package independently. Current eligible families are API Hook Trace, Deep API Trace, API Hook-derived Payload Analysis, Deep-derived Payload Analysis, and the manifest-verified Guard Case Evidence package. A valid package can still be reported when an unsupported, corrupt, ineligible, or unrecognized neighbor is isolated.

Process Memory Capture-derived and Automated Unpacker-derived Analyzer packages remain valuable local technical reports, but they are not Final CISO evidence inputs. Final CISO does not read raw .memimg, .mimem, .dmp, or .bin content, loose HTML, or copied report rows. It preserves static capability, exact runtime evidence, and Context / NotApiCall observations as different evidence families; time proximity alone is not treated as causality.

The analyst reviews source coverage, package integrity, admitted and omitted evidence, correlated findings, contradictions, business context, known unknowns, and recommended actions before explicitly confirming human review. The workflow can then export a verified package containing a local/offline HTML report, executive PDF, normalized JSON, source inventory, and SHA-256 manifest.

It runs locally using deterministic rules. It does not require cloud AI, upload case evidence, execute recovered content, scan or quarantine files, modify endpoint state, convert AlertOnly evidence into response authority, or issue an automatic malware verdict. The Incident Handler remains responsible for containment, disclosure, attribution, and executive recommendations.

A practical investigation sequence

Not every case needs every feature. A safe default sequence is:

  1. Check Command Center, license, engine, Guard, sensor, update, and Help state.
  2. Preserve original identity and case context.
  3. Use Threat Lookup when indicator sharing is permitted.
  4. Run the smallest necessary Rapid, Deep Signature, and Zero-Day workflow.
  5. Review Protection Matrix, timeline, process, file, registry, network, and memory context.
  6. Review persistence, ransomware, intelligence, and quarantine evidence when relevant.
  7. Escalate to Process Memory Capture, Payload analysis, Automated Unpacker, API Trace, API Hook Trace, or DLL Behavior Trace only in an authorized isolated lab when the remaining question requires it.
  8. Preserve verified exports, manifests, source identities, limitations, contradictions, and sensitive-evidence handling decisions.
  9. Assemble only eligible, unchanged packages in an analyst-selected folder before using Final Report to CISO for a management-facing handoff.
  10. Take containment or remediation action only through the separately authorized Guard/organizational workflow, then verify and record the postcondition.

Edition overview

  • Free provides core investigation, including Threat Lookup, Rapid Scan, Deep Signature Scan, Quarantine Vault review, Reports & Evidence, Detection Library, Threat Briefing, Vulnerability Alerts, and Help Center.
  • Professional adds Zero-Day Analysis, Threat Intelligence, licensed intelligence providers, custom feeds, Live Protection, Ransomware Shield, and the current evidence-bound Experimental Automated Unpacker workflow.
  • Enterprise builds on Professional and adds Administration, private packages and watchlists, App Lock, Security Connectors, Startup & Persistence Manager, Process Memory Capture, Payload & Memory Analyzer, Guided and Deep API Trace, DLL Behavior Trace, the API Hook Trace Developer Preview, and Final Report to CISO.

Availability still depends on license, target architecture, Windows access, provider readiness, evidence quality, organizational policy, and exact feature prerequisites. Edition access does not strengthen a finding, fill a coverage gap, or create response authority.

Continue with Help, FAQ, and feature comparison

Open the in-app Help for step-by-step workflows, evidence meanings, troubleshooting, safe-lab guidance, edition details, and feature-specific limitations. Help is available in 22 languages.

For deeper workflows, read Process Memory Capture: Collecting Live Process Evidence Safely, Understanding Payload & Memory Analyzer Evidence, and DLL Behavior Trace: Investigating Supported Native x86 and x64 DLLs.

You can also review the complete FAQ, Edition Comparison, Capabilities, Documentation, and Release & Build History.