In case of a virtual machine it is possible to break out of the VM and gain code execution on the host. In that way you could evade any detection mechanism for malware inside the VM and maybe even on the host. In case of the virtual machine malware would then run at ring -1.
Is it possible to subvert a physical system at runtime (no reboot, no physical access) so malware runs on ring -2 or -3? Or do you need to write to the BIOS flash or EEPROMs of other peripherals and reboot the system?
The answer is "it depends".
Your computer has a lot of processors in it. I don't mean CPU cores, I mean physically distinct processors. Many of these are microprocessors or microcontrollers built into the CPU itself, the chipset, the motherboard, the storage devices, RAID controllers, USB controllers, the peripherals (GPU, NIC, mouse, keyboard), the display itself, the TPM, and even your typical "gamer" components with RGB LEDs or onboard displays, like RGB RAM or AIO watercoolers.
Many of these can be reprogrammed at runtime via firmware updates, without needing a reboot. How difficult it is to implement such a thing in practice is extremely variable. What kind of capabilities you might attain from compromising these devices is also extremely variable - flashing malicious firmware onto your mouse offers very different capabilities to flashing malicious firmware onto your SSD.
Some devices will allow you to write configuration variables that are non-volatile. These values are not executable code, but they can often be abused to store data outside the view of EDR and forensics tools. This was popularised using UEFI configuration variables, and this is now a detected technique in most AV/EDR solutions.
Many of these update and configuration interfaces require at least administrative access in order to communicate with them. Some of them require code running in ring 0 (i.e. privileged code) to access things like MSRs and SMBus. However, many drivers for these types of devices expose the interfaces to usermode applications, allowing you to abuse the legitimate config and update tools for low-level access to the hardware device. Other drivers are even worse, and provide far too much access. The "asmmap64.sys" driver from Asus is a well known example of this, because it lets you access all of kernel memory, all the IO ports, and both read and write MSRs. These are often referred to as "rweverything drivers", after the RWEverything developer tool that has a similar purpose.
In practice, abusing these devices for offensive capabilities is almost exclusively restricted to targeted attacks. They are generally only put together by highly capable adversaries like nation states. The cost and engineering work required is too great for the reward in the case of the average criminal, and it's almost impossible to build a single payload that'll work across a wide range of targets.
Overwriting the UEFI flash itself with a modified update should not work. The updates are digitally signed and verified during an update, and the platform firmware (device ROM) checks them. It also validates the integrity and authenticity of each piece of the UEFI boot chain during startup, before any user code runs.
Breaking into Intel CSME and System Management Mode (SMM) is much more complicated, but there have been vulnerabilities in the past that made it potentially feasible. CVE-2019-0090 is a bug in the way that the IOMMU (think "firewall for DMA") is configured during the initial bringup of the MISA (Minute IA System Agent). Normally, this IOMMU prevents devices from making DMA requests into the SMM SRAM, effectively isolating that memory from even privileged code in the kernel. However, during bringup the SRAM page directory is initialised first, before enabling the IOMMU. This means that any device that is capable of DMA'ing into that SRAM (not to be confused with main system memory) can take advantage of that small window of opportunity to modify the execution flow of the SMM and take over it. While the issue only normally occurs in early boot, it also happens when the CSME comes out of sleep mode, which opens up the opportunity to exploit it at runtime. Doing so, however, would certainly require privileged code execution (ring 0), and again this is largely limited to targeted attacks by nation states due to the extreme complexity and cost of developing such capabilites.
