Hide Artifacts: Run Virtual Instance

Adversaries may carry out malicious operations using a virtual instance to avoid detection. A wide variety of virtualization technologies exist that allow for the emulation of a computer or computing environment. By running malicious code inside of a virtual instance, adversaries can hide artifacts associated with their behavior from security tools that are unable to monitor activity inside the virtual instance.^[2] Additionally, depending on the virtual networking implementation (ex: bridged adapter), network traffic generated by the virtual instance can be difficult to trace back to the compromised host as the IP address and hostname might not match known values.^[3]

Adversaries may utilize native support for virtualization (ex: Hyper-V), deploy lightweight emulators (ex: QEMU), or drop the necessary files to run a virtual instance (ex: VirtualBox binaries).^[4] After running a virtual instance, adversaries may create a shared folder between the guest and host with permissions that enable the virtual instance to interact with the host file system.^[5]

Threat actors may also leverage temporary virtualized environments such as the Windows Sandbox, which supports the use of .wsb configuration files for defining execution parameters. For example, the <MappedFolder> property supports the creation of a shared folder, while the <LogonCommand> property allows the specification of a payload.^[6][7][8]

In VMWare environments, adversaries may leverage the vCenter console to create new virtual machines. However, they may also create virtual machines directly on ESXi servers by running a valid .vmx file with the /bin/vmx utility. Adding this command to /etc/rc.local.d/local.sh (i.e., RC Scripts) will cause the VM to persistently restart.^[9] Creating a VM this way prevents it from appearing in the vCenter console or in the output to the vim-cmd vmsvc/getallvms command on the ESXi server, thereby hiding it from typical administrative activities.^[1]