As a follow up to No detection of missing Windows Security Patches on Windows 10 PCs · Issue #1500 · greenbone/openvas-scanner · GitHub (as this was also placed on the scanner issue tracker but is very very unlikely a scanner issue):
The VT in question can be started from command line with something like e.g. the following:
cd /path/to/openvas/plugins
# Non-domain user
openvas-nasl -X -B -i /path/to/openvas/plugins -t <targetip> logins.nasl smb_login.nasl smb_registry_access.nasl smb_reg_service_pack.nasl 2023/microsoft/gb_ms_kb5026361.nasl --kb="SMB/login_filled/0=<username>" --kb="SMB/password_filled/0=<password>"
# Domain user
openvas-nasl -X -B -i /path/to/openvas/plugins -t <targetip> logins.nasl smb_login.nasl smb_registry_access.nasl smb_reg_service_pack.nasl 2023/microsoft/gb_ms_kb5026361.nasl --kb="SMB/login_filled/0=<username>" --kb="SMB/password_filled/0=<password>" --kb="SMB/domain_filled/0=<domain>"
When applying the following patch to it:
diff --git a/2023/microsoft/gb_ms_kb5026361.nasl b/2023/microsoft/gb_ms_kb5026361.nasl
index 02a9fff697a..73dc8a5edf8 100644
--- a/2023/microsoft/gb_ms_kb5026361.nasl
+++ b/2023/microsoft/gb_ms_kb5026361.nasl
@@ -84,6 +84,8 @@ if(!build){
exit(0);
}
+display("Build: ", build);
+
if(!("19042" >< build || "19044" >< build || "19045" >< build)){
exit(0);
}
@@ -92,11 +94,15 @@ if(!dllPath ){
exit(0);
}
+display("Path: ", dllPath);
+
fileVer = fetch_file_version(sysPath:dllPath, file_name:"ntoskrnl.exe");
if(!fileVer){
exit(0);
}
+display("File version: ", fileVer);
+
if(version_is_less(version:fileVer, test_version:"10.0.19041.2965"))
{
report = report_fixed_ver(file_checked:dllPath + "\ntoskrnl.exe",
i was able to see / observe the following:
It was possible to log into the remote host using the SMB protocol.
Windows 10 Enterprise 6.3 (22H2) is installed with build number 19045
lib nasl-Message: 14:17:37.717: Build: 19045
lib nasl-Message: 14:17:39.434: Path: C:\Windows\system32
which means that the VT works and reaches the fetch_file_version() function which doesn’t return the file version at all for unknown reasons. And in this case no vulnerability can is reported as the file version is missing.
I’m lacking the knowledge on Windows to further debug this / determine where this problem might originating from (e.g. if there is an actual issue in the NASL code, if there are some configuration problem on the target which prevents reading out the file version, …) but maybe this already helps a little.
I will also create an internal task for the team working on this topic to see / check this case but can’t give any guarantee if / when some one is looking into this.