What are the key ANY.RUN best practices?

What matters when using ANY.RUN for analysis

ANY.RUN is most useful when you treat it as a controlled analysis workspace, not a place to “open” suspicious content casually. The key discipline is to keep the session isolated, assume the sample may try to phone home, and watch for process creation, network calls, persistence attempts, and dropped files that can inform later hunting and containment.

Because the value of the tool comes from observing behaviour, the analyst should decide in advance what evidence must be captured before the session ends. That usually includes hashes, domains, IPs, file drops, registry or startup changes, spawned processes, and any commands the sample attempts to run. The point is to leave with evidence that can be validated elsewhere, not just a screenshot of the sandbox verdict.

When the sample is suspicious but not yet confirmed malicious, the safest posture is to keep the scope narrow and avoid giving it access to anything that could create lateral risk. That means using non-production inputs, blocking access to internal credentials and shared storage, and treating any upload as potentially observable by the sample. For malware handling principles and sandbox use, see the Malware Guide.

Safe workflow for suspicious files and URLs

Start with the smallest useful test case. If you only need to understand whether a file is trying to beacon, alter system settings, or stage follow-on payloads, do not introduce extra variables by attaching corporate accounts, internal endpoints, or live data sources. A controlled detonation is most useful when the sample’s behaviour is attributable to itself rather than to the analyst’s environment.

Watch for persistence and post-execution behaviour rather than stopping at the initial alert. Malware often looks benign at first and then reveals its purpose through scheduled tasks, run keys, service creation, WMI subscriptions, browser manipulation, or other startup mechanisms. If the sample shows any signs of that behaviour, capture the sequence carefully so you can compare it with host telemetry and response findings later. The Persistence Techniques Guide is useful when the investigation moves from “what did it do” to “how did it try to stay.”

Do not treat the sandbox output as a final verdict by itself. A sandbox can miss delayed activation, region checks, or environment-aware behaviour, and a benign-looking execution path does not prove the sample is safe. Use the session to collect evidence, then corroborate it with endpoint telemetry, threat intel, file reputation, and any user-reported context you already have.

How to document findings so they are useful later

A good ANY.RUN session ends with enough detail to support hunting, triage, and response. Record the sample name or submission reference, the observable network indicators, notable process tree events, file system changes, and any artifacts that would help another analyst reproduce the conclusion. If you cannot express the result as observable behaviour, it is probably not yet ready for operational use.

When a session reveals credential harvesting, beaconing, or staging behaviour, note which evidence points to likely impact and which points merely to noise. That distinction matters because malware often mixes legitimate-looking activity with malicious steps. A concise behavioural summary is more valuable than a long narrative because it can be turned into detection logic, block rules, or case notes.

If the sample was uploaded from a system that might contain sensitive data, confirm that no confidential material was included in the upload path, browser state, or copied files. The tool should be used in a way that preserves confidentiality and keeps analysis artifacts separate from production data. For a broader view of safe key and credential handling when investigation uncovers exposed secrets, the API Key Management Guide is a useful companion when secret exposure becomes part of the incident.

Practitioner Guidance

What to prioritise: Prioritise evidence capture and containment over curiosity. If the file or URL is likely to execute, make sure the session is isolated and that you know exactly which indicators you need before you start.

What to verify: Verify that the behaviours you record are reproducible enough to support another analyst’s conclusion, and that the sandbox output is consistent with other telemetry before you treat it as actionable.

Common mistake: The most common error is over-trusting the sandbox verdict while under-collecting artifacts. That leaves you with a confidence signal but not enough data to hunt, block, or explain the event.

Practitioner takeaway: Use ANY.RUN as an evidence-generating control, not a decision engine, and let the session prove behaviour in a way that can be validated outside the sandbox.

Related resources from NHI Mgmt Group

• What are the key privileged account best practices?
• What are the key model explainability best practices for fraud?
• What are the key NHI Training best practices?
• What are the key NHI Management best practices?