Sandbox Analysis Before Software Install: What It Shows

Reading a vendor's website tells you what the vendor says the software does. Running the installer in an isolated environment shows what it actually does. Sandbox analysis before software install is the practice of detonating an installer and its application in a controlled virtual machine and recording its behavior, so that a decision to allow it is based on observation.

What a sandbox run records

A good run captures several kinds of evidence.

• Network activity. Domains, IP addresses, ports and protocols the software contacts, including during installation, at first launch and while idle. This answers where data could go.
• File system changes. Where files are written, which executables and libraries are dropped and whether anything is written to locations that users can modify.
• Registry and configuration changes. Keys created or modified, including auto-start entries and security settings.
• Processes. Child processes spawned, scripting engines launched and command lines used.
• Services and drivers. Whether a Windows service or a kernel-mode driver is installed, which carries a different risk level than a user-mode application.
• Privileges. Whether the software needs administrator elevation or runs as a standard user.
• Signatures and reputation. Whether the installer and the files it drops are signed and whether the signing chain is trusted, plus how multi-engine reputation services score the files.

Turning observations into decisions

Raw telemetry is only useful when it feeds a decision. Network destinations become an allowlist for a host firewall or proxy, so the software can reach only what it needs. Persistence mechanisms and dropped files show what the software changes on a system, which informs your baseline configuration. Elevation requests inform whether the application can run under least privilege. A dropped kernel driver is usually a significant finding that needs justification, because drivers run with the highest privileges.

These observations connect to several NIST SP 800-171 Rev 2 practices. Observed network traffic supports boundary protection and deny-by-default communication, SC.L2-3.13.1 and SC.L2-3.13.6. Services and unnecessary features relate to least functionality, CM.L2-3.4.6 and CM.L2-3.4.7. Privilege findings relate to AC.L2-3.1.5, and malicious behavior relates to SI.L2-3.14.2. The wording of each requirement is in NIST SP 800-171 Rev 2.

Hashes and trust chain

Record the SHA-256 hash of the installer and of the main binaries you tested. A hash proves that the file you deploy is the file you analyzed, and it is the basis for hash-based rules in your application control policy, compared in our WDAC and AppLocker guide. Check signatures too: a valid signature from a trusted publisher is useful evidence of origin, and a revoked, expired or untrusted signature is a finding.

What a sandbox cannot tell you

Sandbox analysis has limits, and a report should say so.

• Evasion. Some malware detects virtual environments and behaves innocently until it believes it is on a real system.
• Time and trigger conditions. Behavior that starts after days, on a specific date or after a remote command will not appear in a short run.
• Coverage. A run exercises the paths the analyst exercises. Features that need an account, a license server or specific hardware may not be reached.
• Encrypted traffic. Destinations are visible, but the content of encrypted connections usually is not.
• Absence of evidence. A clean run reduces risk. It does not prove the software is safe.

For these reasons sandbox results should be combined with vendor screening, signature checks and the product's vulnerability record, as described in the third-party software risk assessment guide.

Practical tips for a useful run

Use a clean snapshot each time. Match the target operating system and architecture of your environment. Run the installer and then use the application's main functions. Observe idle behavior for long enough to see update checks and telemetry. Repeat on a second configuration if the first result is ambiguous. Save the full report, not only the verdict.

Where DigVel fits

Phase 2 of DigVel's service is a sandboxed dynamic analysis of the actual installer, with network telemetry, file and registry changes, privilege and trust-chain checks, and a hardening blueprint that you can use for firewall and application control rules. See the methodology and a description of what the report contains, or the service overview.