A malware triage workflow for suspicious files
A sample record linked to its origin, analysis results, confidence and a clear response or escalation decision.
Before you start
Malware triage should answer a bounded response question: what is this file, why is it suspicious, and what evidence should the investigation pursue next? A scanner verdict alone cannot establish whether the file executed on a host or caused the incident.
This workflow covers intake and analysis planning. Handle samples inside your team’s approved analysis environment. Dynamic execution belongs in a separately controlled specialist process; the steps here do not require opening a suspicious file on an ordinary workstation.
Have these ready
- The original file, collection context and case reference.
- An approved sample store and analysis environment.
- Rules for external lookups, sharing and access to sensitive content.
1. Preserve the file and explain why it matters
Record who provided the file, when it was collected, the affected host or message and the question being investigated. Preserve the original and work from a controlled copy. Record a cryptographic hash so later results can be tied to the same bytes; a filename alone is not a reliable identifier.
MWDB uses SHA-256 as its main object identifier and supports files, configurations and text blobs. Its sample documentation also describes parent-child relationships. Preserve those relationships when an attachment is extracted from a message or a file is unpacked from an archive.
2. Start with static observations
Check file type, size and available metadata, then collect the outputs of approved static checks. Record the tool, version, rule set and any processing error. Keep facts such as an embedded URL separate from conclusions about what the file would do if executed.
CIRCL describes Pandora as a static-analysis framework with document previews and metadata views. That role is useful for initial file review. Inspect the worker configuration and data-sharing behavior of the instance you use; the public service’s documented behavior is not a blanket description of every private deployment.
3. Reconcile results with the incident
Compare the file’s properties with the original event. Does the hash match the endpoint alert? Was the attachment merely delivered, saved or executed? Look for corroborating host or network evidence before attributing behavior to it.
Treat conflicting detections as a reason to inspect the evidence. A YARA match identifies a rule condition that was satisfied; its operational meaning depends on the rule and context. Likewise, no match means that those checks did not identify the sample. Record skipped checks, encrypted content, unsupported formats and analysis timeouts as limits on the result.
4. Escalate the question that remains
If static review cannot answer the response question, give a specialist the original reference, hash, analysis package and a precise remaining question. Examples include determining whether a document contains executable content or whether a binary’s configuration matches an observed connection. Keep the approved handling and sharing restrictions with that package.
Karton documents orchestration of analysis services through a pipeline. It can organize stages, but installing the orchestration framework does not by itself provide every analyzer or a safe execution environment. Validate each worker’s inputs, outputs and failure behavior before relying on automated results.
5. Deliver findings with a confidence statement
Return a short finding that distinguishes what was observed, what is inferred and what remains unknown. Include the sample identifier, evidence references, relevant observables and a proposed next step for the incident owner. Use an observation time when reporting network indicators; a URL or address extracted from a file is not proof it remains active.
Keep case-sensitive details in controlled storage and publish only the version approved for the intended audience. MWDB offers different sharing scopes at upload time; inspect the selected scope rather than assuming a sample is private. Preserve the analysis record when later evidence changes the verdict.
Handoff checks
Before passing the work on, confirm that:
- Every result identifies the exact sample and analysis configuration.
- Extracted files retain a reference to their parent.
- External disclosure and sharing choices were deliberate.
- Errors and unsupported content remain visible in the assessment.
- The handoff separates file properties from evidence of execution.
Tools to evaluate
These profiles document different parts of the workflow. Their inclusion is not a ranking or a claim that they form an integrated stack.
MWDB Core
Evaluate for sample records, related objects and controlled sharing. It is a repository component; required analysis services must be assessed separately.
Pandora
Evaluate for static file review and previews. Check which workers are configured and which lookups leave your environment.
Karton
Evaluate for coordinating analysis workers. A useful pipeline needs validated workers, failure handling and the appropriate analysis isolation.
Sources and review
Primary documentation checked on . The numbered sequence and handoff checks are editorial recommendations. Product behavior and availability may change; this guide does not report hands-on testing.
- MWDB — Storing samples and relationships
- CIRCL — Pandora document and file analysis
- Karton — Analysis orchestration documentation
- YARA — Rule conditions and matching