For internal scanning, I’m currently using OpenVAS as packaged within OSSIM. I’ll changing to running it in GSA on Parrot Linux soon. Anyway, within OSSIM, I was using the “Deep and Full, Non-Destructive” option for the scan. OSSIM packages the scan choices its own way. So this scan was testing for default/easy credential use, and knocked out one of our ESXi management agents. It didn’t just lock it out temporarily, it made it inaccessible. The vm guests are still running, and obviously the ESXi host is also. Its just that Vsphere cannot connect to that host or its vm’s until the agent is restarted.
So how do I avoid this? Use GSA with different scan options? Or is it a known issue with ESXi? Or none of the above?
That is not known to us, please contact your packet maintainer, we DO not support any form of OSSIM uncoordinated installation, as far we know many of the uncoordinated installation are broken or out-dated. I suggest use a GCE and do a Full&Fast Scan optional you can enter ESXi V-Center credentials that should scan your hypervisor without crashing anything too.
The following of Read Before Use is matching quite good here:
Remember that triggering faults, crashes or locking with default settings means that an attacker can do the very same at unplanned times and to an unplanned extent. Finding out about it earlier than the attacker is the key to resilience.
If a device / system / software is crashing while being scanned it is recommended (Especially when using the Non-Ultimate Scan Configs) to contact the vendor of this device / system / software about possible issues / vulnerabilities in the used product. A verification if there are newer updates / versions available and (if available) and update to those might already help to mitigate such issues.
Once the vendor acknowledge an issue you could enable the log_whole_attack setting of the scanner and watch the mentioned logfiles to see which VT was active at the point of the crash so that the vendor might be able to reproduce this behavior.