Authenticated scans on Windows filesystem and registry

Dear all,

we have configured a domain user for the authenticated scans (according to Configuring a Domain Account for Authenticated Scans) on our windows machines.
The settings are propagated via GPO.
As described on the manual we have set the permissions on %systemdrive% and the registry hives in order to (section: Configuring the Policy to Give Read Permissions Only to the Registry for the Group Greenbone Local Scan) the deny the write access to the scan user.
But these settings only work for the main folder (C: drive) and for the main hives (MACHINE, USER, CLASSES) but not for the underlaying folders/key as the permissions are not inherited to the subfolders (and we do not want to change the inherit settings on systemfolders).
My question: Is this a wanted result? The security gain of this two actions is very low (the scan user has write access to all subfolders but not on the main folder/hive).

does anybody have an idea why this should be done?

Hi schl_la,

sorry for the late reply. As this topic is quite complex i cannot make a precise statement here.

Our developers made this decision. And even if it does not lead to a major improvement in security, it will certainly serve the integration in Windows.

1 Like

Why not just use the option to deny interactive login and treat it like a DA service account?

The account is used as a service account (local and remote logon denied), but the user has the right to access the C: drive and the remote registry using the port 445. The instructions says to set the permissions on the hives/folder to read-only, but this permission is not inheritated to the subfolders (for example %windir%, system files, program files, the “Software”-hive in the registry) and at the end the user has full access to the subfolders/hives (local admin).
If the serviceuser gets compromised, he can place files and change the registry.

There is a best practice how to generate a scan user:

1 Like

Yeah - indeed it does. But with a complex password and good password hygiene - I would argue your risk is extremely low and Assuming you have other controls in place. I think the risk of creating a mess to clean up later by manually making the registry changes outweighs the security benefits - but every organization needs to weigh the acceptance of that risk. I’ve seen hundreds of OpenVas deployments but never once has the registry restrictions been in place. Hope that helps. Good luck!

1 Like