There's no such thing as "verifying sterility"
In general, there's no such thing as verifying sterility, instead you reduce the risk as much as is reasonable and assume the risk that remains. The usually accepted way to ensure sterility of some system is to restore it to a known good state instead of attempting to verify whether the current state is good.
If you do an in-depth analysis of the malware itself and believe that you've understand everything that it does (and how it does it), then you may see that it doesn't contain any VM escape capability, and (assuming you're right!) that it poses no risk for you.
If you follow basic best practices e.g. the VM system is up to date with fixes for any known bugs enabling escape, the network connections of that VM are properly secured, there are no mapped folders where that VM might write data, etc. then it's plausible that you consider that the risk of VM escape is not meaningful for you.
However, if you do consider that the malware might have a reasonable chance of succeeding in VM escape, then you do NOT attempt to verify sterility of the host system - you treat the host system as possibly compromised and follow the standard course of action, which usually is to nuke it from orbit. If VM escape is within your risk profile, then you assume that host workstations may get compromised, don't keep secret data or credentials on them, implement appropriate network security, and treat them as disposable - you would want a capability to easily re-image the host system to a 'known good' setup after each experiment.