websecWHAT YOU WILL PRODUCE
A static triage report that separates indicators, uncertainty and the next defensive action.
Answer a bounded question
“Is this a virus?” is usually too broad for the first examination. Start with: what is the file, where did it come from, what can be established without executing it, and what defensive action is justified? The output should be a documented triage decision, not a confident family name based on one indicator.
Work on an authorized sample in a dedicated analysis environment. This guide covers static examination only. Use a benign test file for the practice exercise. It does not require downloading live malware, enabling active document content or running the suspect program.
Preserve provenance first
Assign an evidence identifier. Record the collection source, original name, byte size, acquisition time, analyst and any endpoint alert associated with the file. Keep the original material separate from the working copy and record all transformations, such as extracting an attachment from a supplied message.
Do not double-click a file to discover its type. Disable preview behavior in the analysis workflow and use maintained tools that inspect data without launching its associated application. Even static parsers should run within the dedicated analysis environment.
Hash before interpreting
Calculate SHA-256 on the working file and compare it with the recorded acquisition digest when available. A Windows example that reads the file is:
Get-FileHash -LiteralPath '.\working\suspect.bin' -Algorithm SHA256
Record the command or tool version and result. A matching hash identifies identical bytes under that algorithm; it does not establish whether those bytes are malicious. A changed hash after a documented transformation can be expected, but the relationship between the parent and derived file must remain clear.
Identify the actual file type
Compare the extension with the file structure reported by a maintained identification tool. Record whether the input appears to be an executable, document, script, archive or something the tool cannot identify. A misleading extension is a reason for further review, not a complete diagnosis.
For Windows executables, Microsoft Sigcheck can report file-version information, hashes and digital-signature details. If used, record the local verification result and relevant certificate information. Online reputation options are separate: do not send a confidential sample or its contents to a public service without the case's approved sharing basis.
Build an observation table
| Observation | What it can support | What it does not prove |
|---|---|---|
| SHA-256 digest | Identity of the examined bytes | Maliciousness, execution or attribution |
| File structure | An interpretation of the format | That the filename is trustworthy |
| Signature result | Verification result for the signed object | That the program is harmless |
| Readable strings | Text present in the file | That each string is used at runtime |
| Referenced libraries or capabilities | Possible functionality to investigate | That the behavior actually occurred |
| Detection label | A product's classification at a recorded time | A final family attribution or incident scope |
Record offsets or tool-output locations for significant observations. Treat URLs or domains found as strings as inert evidence; do not visit them from the analysis workstation. High entropy may have several explanations, including legitimate compression. Keep the observation separate from the explanation.
Connect the file to the incident
A file can be suspicious without having executed on the affected computer. Correlate the file's identity with collected endpoint alerts, process records, download history or other available evidence. Record the collection window and gaps before drawing conclusions about execution or impact.
Use “the file contains” for a static observation and “the endpoint recorded” for a telemetry observation. Reserve behavioral claims for evidence that actually supports them. A library name alone should not become a claim of data theft, persistence or command-and-control.
Decide what happens next
Write a short triage conclusion with three parts: supported observations, unresolved questions and the next defensive action. That action may be retaining the file for specialist review, validating an endpoint alert, checking approved software records or passing the case to a suitably isolated analysis lab.
The next stage should be a deliberate decision with defined questions. Running an unknown file on a daily-use computer is not a continuation of this static workflow. SANS' overview of malware analysis distinguishes static examination from behavioral analysis and offers further learning context.
Practice without malware
Create a harmless text file on your own workstation, record its size and SHA-256, then make a working copy and verify the digest matches. Change one character in a separate derived copy, hash it again and document why its digest differs. Do not overwrite the preserved first file.
Complete the static triage worksheet. This exercise tests evidence handling and the precision of your report without requiring a malicious sample. For a real case, add source locators and clearly state that a static triage result is not a complete behavioral analysis.