Host-Based Analysis · Topic 5 of 5
Reading Malware Analysis Reports
Interpret a sandbox or detonation chamber report, including file hashes, URLs, and the system, event and network behaviour that decides a verdict.
- 4 min
- A sandbox runs a file in isolation and records what it does.
- A hash is a fingerprint of a file, and any change gives a different hash.
- SHA-256 is preferred over MD5 and SHA-1.
What it is
A sandbox, also called a detonation chamber, runs a suspicious file in a safe isolated environment and writes a report on what the file did.
The analyst reads that report to decide whether the file is malicious and what to look for elsewhere. Cisco Secure Malware Analytics, formerly known as Threat Grid, is one example of such a product.
Reports hold three kinds of information. These are identifiers such as hashes, web addresses the sample used, and behaviour on the system and the network.
How it works
The report turns observed behaviour into a verdict and a list of indicators.
Hashes
A hash is a fixed length fingerprint of a file. The same file always gives the same hash, and a change of even one byte gives a different one.
Reports list hashes such as MD5, SHA-1 and SHA-256. SHA-256 is the preferred one today, because MD5 and SHA-1 have known weaknesses. You can compute a hash yourself to compare with the report.
$ sha256sum sample.exe
PS C:\> Get-FileHash sample.exe -Algorithm SHA256Analysts search for the hash in threat intelligence and across their own endpoints. A match shows whether the file is known, and where else it has been seen. A hash that no one has seen may be a new variant.
URLs
The report lists the web addresses that the sample contacted or tried to contact, and the domains and addresses behind them. These may be where it downloads more malware, where it sends stolen data, or its command and control server.
Block them at the proxy and firewall, and search logs for any host that has already contacted them.
Systems, events and networking
The report records behaviour in several areas.
| Area | What the report may show |
|---|---|
| File system | Files created, changed or deleted, such as a dropped program in a temporary folder |
| Registry | Keys added, such as a run key for persistence |
| Processes | Processes started, such as a shell started by a document |
| Memory | Code injected into another process |
| Network | DNS lookups, connections, addresses, ports and data sent |
| Other | Services created, scheduled tasks added, anti analysis checks |
Behaviours are often mapped to a threat score or a list of tags. A high score means that many suspicious behaviours were seen.
Reading a report in order
- Check the verdict or score to see how the tool rates the sample.
- Note the hashes and look them up.
- List the network indicators, which are the domains, addresses, ports and URLs.
- Review process behaviour, in particular unusual parent and child processes.
- List persistence, such as run keys and new services.
- Turn the findings into indicators of compromise and search your network for them.
For example, a report may show that a document opened a command shell, which ran a script that downloaded a file from a rare domain. It then added a run key. The domain and the file hash are indicators to hunt for, and the run key is where to look on infected hosts.
Limits of sandboxes
Some malware checks whether it is in a virtual machine and stays quiet if it is. Some waits for a long time before acting, or needs a user action. A clean report does not prove that a file is safe.
What to remember for the exam
Seven facts cover most questions on this topic.
- A sandbox runs a file in isolation and records what it does.
- A hash is a fingerprint of a file, and any change gives a different hash.
- SHA-256 is preferred over MD5 and SHA-1.
- A report lists URLs and domains that the sample contacted.
- System behaviour includes files, registry keys and processes.
- Network behaviour includes DNS lookups, connections and addresses.
- Findings become indicators of compromise that can be hunted across the network.
Hashes and network addresses from the report are the easiest indicators to search for in your logs.
Common mistakes
These four errors appear often.
Treating a clean report as proof of safety. The sample may detect the sandbox and hide its behaviour.
Searching only for the hash. A changed file has a new hash, so use domains and behaviour too.
Ignoring persistence. Run keys and new services show how the malware survives a reboot.
Opening unknown files on a normal workstation. Use an isolated analysis system.
Run a suspicious file only inside an isolated, controlled environment.
Check yourself
Work through these three questions.
Why can hashes alone miss a malware variant?
A change of even one byte gives a different hash, so a changed file will not match a known hash.
What do the URLs and domains in a sandbox report help you do?
They help you block the addresses and search logs for hosts that already contacted them.
Why might a sandbox report look clean for a malicious file?
The malware may detect the virtual environment or wait before acting, so it shows no bad behaviour during the run.
Topic 5 of 5 in Host-Based Analysis
Test yourself on Host-Based Analysis
The full Cisco CCNA 200-201 CBROPS question bank has 754 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Cisco. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.