Attackers use Run Virtual Instance to launch code inside a virtual machine or sandbox and keep the real host separate from the visible activity. This can help them stage tools, avoid simple host checks, or confuse analysis. Defenders should monitor virtualisation use, nested execution, and suspicious creation of guest instances on endpoints.
How Run Virtual Instance helps attackers stay hidden
Attackers use run virtual instance to create a gap between what the defender sees on the host and what actually runs inside the guest. That separation helps with staging, detonation, and quick inspection of whether tooling behaves differently in a controlled environment. It is a visibility tactic, not just an execution method.
Once the payload is inside the VM or sandbox, the operator can observe whether security tools, host checks, or analyst workflows change the program’s behaviour. That is why virtualisation is useful for evasion: it can reduce the chance that suspicious actions are executed on the visible endpoint, while still allowing the attacker to test or prepare the next step.
In ATT&CK terms, this fits the broader idea of execution and defence impairment through environment awareness, so defenders should treat virtual instance creation as a meaningful signal, not a harmless admin action. For a defender-oriented threat mapping view, see the MITRE ATT&CK Guide for Defenders.
What attackers gain from guest execution and sandbox separation
The main operational benefit is control. A virtual guest gives the attacker a place to run helper scripts, unpackers, droppers, and reconnaissance utilities without immediately exposing the full host. That can slow analysis, complicate containment, and make it harder to determine whether activity is real execution, a decoy, or a staged handoff to another process.
It also creates a cleaner boundary for testing. Attackers can use the guest to probe for environment checks, driver presence, instrumentation, or other indicators that reveal monitoring. If the payload behaves differently only outside the guest, the operator learns that the target environment is likely scrutinising them.
Because the technique is often used as part of a larger intrusion chain, analysts should read it alongside other signs of staging, tool loading, and privilege escalation. The broader breach patterns seen across non-human identity and access abuse are summarised in The State of NHI & AI Agent Breach Report 2026.
What defenders should watch for first
Look for virtualisation artefacts that do not match normal endpoint behaviour, especially where a user workstation suddenly creates guest instances, nested execution chains, or short-lived sandboxes. Correlate process ancestry, hypervisor activity, and child process creation so you can tell whether the activity is routine administration or a concealment step.
Also check whether the virtualised environment is being used to shield credential theft, payload unpacking, or staged command execution. In many cases the value of the technique is not the VM itself, but the chance to keep early malicious actions out of the main host telemetry until the operator is ready to proceed.
Risk and Threat Considerations
Run Virtual Instance matters because it can lower the quality of host-side visibility and create a false sense that suspicious activity is isolated. That makes it attractive for staging, analysis evasion, and compartmentalising malicious tools before they touch the real system.
Failure mechanism: The attacker runs the payload in a guest or sandbox so host controls, analyst review, or simple process checks see only part of the activity, while the actual malicious work happens behind the virtual boundary.
Impact: Defenders may miss early execution, misclassify the session as benign testing, or respond too late to stop follow-on actions such as payload unpacking, internal probing, or credential use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1201 — Virtualization/Sandbox Evasion | Virtual instance use is an evasion and analysis-avoidance pattern. |
| T1059 — Command and Scripting Interpreter | Attackers often stage scripts and helper tools inside the guest. | |
| T1055 — Process Injection | Sandboxed execution is often paired with hidden in-memory or staged execution. | |
| Recommendation — Map guest-instance activity to virtualization evasion and hunt for analysis-avoidance indicators. Correlate scripting execution inside guests with the surrounding intrusion chain. Inspect for hidden process execution techniques when virtualization is used to mask activity. | ||
| NIST CSF 2.0 | DE.AE-02 — Analyzed to Ensure Adequate Response | Virtual-instance abuse requires correlating anomalous execution with response decisions. |
| Recommendation — Triage suspicious guest creation as an anomalous event requiring response analysis. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Detecting this technique depends on reviewing endpoint and hypervisor telemetry. |
| Recommendation — Review host and virtualization logs for suspicious guest creation and nested execution. | ||
Practitioner Guidance
What to prioritise: Treat unexpected guest creation, nested virtualisation, and sandbox-like process trees as investigation triggers when they appear on endpoints that do not normally use them. Separate legitimate developer or test activity from concealment by checking whether the instance creation is tied to a known admin workflow.
What to verify: Confirm whether the virtual environment is short-lived, internet-reachable, or paired with tool staging, because those patterns increase the likelihood that it is being used to hide execution rather than support business use. If the guest was created to test behaviour, preserve the telemetry before it disappears.
Practitioner takeaway: The key judgement is not whether a virtual machine exists, but whether it is being used to keep malicious execution out of the telemetry and response path that would normally expose it.