Some of our Windows target machines have recently started becoming unresponsive during scans. We have tracked the problem down to the
wmi_query calls in
wmi_file.inc. Specifically, the queries to the
CIM_DataFile table are extremely slow, and may consume 100% of the CPU for multiple minutes.
We note that this may not be an issue with the plugin’s implementation, but with WMI itself on the remote Windows machines (particularly machines with only 1 core). We lessened the impact of this issue by adding 10-second sleeps before every call to
wmi_file.inc, but this is not a good long-term solution for multiple reasons.
Given that this started happening only recently, I’m curious about any recent changes to
wmi_file.inc that may have exacerbated this issue. Anybody aware of anything recently changed, or even (grasping at straws) a change in Windows’ own WMI service? Any ideas for solving this problem that are better than sleep-ing?
The usage of WMI queries to the
CIM_DataFile is the following described in the VT “Options for Local Security Checks” (OID: 184.108.40.206.4.1.256220.127.116.11509):
Disable file search via WMI on Windows:
Various VTs are using WMI to search for files on Windows targets. Depending on the attached storage and its size this routine might put high load on the target and could slow down the scan. Setting this option to ‘yes’ disables the usage of this search with the risk of lower scan coverage against Windows targets.
So any recent storage addition to the problematic system, especially network based storages might cause this seen behavior.
Furthermore it can’t be ruled out that any additional change on the problematic host (e.g. Windows Updates, installation or update of a AV solution, …) could be responsible as well.
Those might give some info what to check to find the root cause of the high CPU usage.
The last functionality change to this include was done back in October 2019 so this can be ruled out as the cause of this.