This is a good idea and a good practice in my opinion.
Some malicious code detects when it’s being sandboxed and hides itself until it’s running somewhere it can do damage though.
Once malware is VM aware it can also get outside a VM. Furthermore, malware can be written to seat itself comfortably in your PC and lay low for hours, days, weeks before becoming active. Installing in a VM and waiting for shit to hit the fan is not always reliable.
Getting out of a VM reliably is not usually trivial, and VM escapes are usually designed to target specific configurations rather than an arbitrary deployment. A VM with a minimum amount of shared resources is usually a reasonable security boundary unless you think the malware you’re analyzing has hypervisor-specific 0 days.
If it’s suss use a vm before your main OS.
This is a good idea and a good practice in my opinion. Some malicious code detects when it’s being sandboxed and hides itself until it’s running somewhere it can do damage though.
Once malware is VM aware it can also get outside a VM. Furthermore, malware can be written to seat itself comfortably in your PC and lay low for hours, days, weeks before becoming active. Installing in a VM and waiting for shit to hit the fan is not always reliable.
Getting out of a VM reliably is not usually trivial, and VM escapes are usually designed to target specific configurations rather than an arbitrary deployment. A VM with a minimum amount of shared resources is usually a reasonable security boundary unless you think the malware you’re analyzing has hypervisor-specific 0 days.
the malware has to be very advanced and specifically target your hypervisor version to escape a VM.
in the context of cracked software, it is highly improbable that you’ll find malware with this capabilities.
And start with no network for the VM