Automated Auditing and Hardening of Windows
HardeningKitty, the twin sister of KleptoKitty, is a script based on PowerShell for checking the hardening of a Windows system or individual applications such as Microsoft Office and Microsoft Edge. Finding lists are used to read and evaluate Windows settings. For information retrieval, HardeningKitty uses various modules, such as registry keys, defined guidelines for user group rights and audit/logging settings. The evaluation is done based on stored severity levels in the finding list.
The automated reading of the Windows configuration is the result of a further development that started with a collection of hardening recommendations from the article Windows 10 Client Hardening in December 2016 and continued with the creation of a Hardening Checklist in autumn 2017. After that we tried to analyze the configuration of a system with the Microsoft tool Policy Analyzer from the Microsoft Security Compliance Toolkit 1.0 using checklists and checking for hardening settings, which we recommend to our customers in Configuration Reviews. After several attempts, we found that the Policy Analyzer is not the right tool for our requirements. On the one hand, we could not implement all checks and on the other hand we need more freedom in processing the results. For example, we were not able to read the BitLocker status or the presence of Windows features such as SMBv1 or PowerShellv2 as intended. Therefore we decided to write our own script.
The PowerShell script HardeningKitty is available in our GitHub repository for free use and reuse.
By querying the Registry most of the test points can be processed. However, HardeningKitty has additional modules that use tools such as
secedit.exe, as well as PowerShell cmdlets such as
Get-Processmitigation to access system information outside of the registry. Using the tool AccessChk there is also an external dependency, all other modules use standard system components. Local administrator rights are required to read all system settings. If a value cannot be read out because the required values are missing, we have first maintained a default value in the Finding list. In the update from HardeningKitty to version 0.4.2 we have implemented an additional check which does not evaluate a test point if local administrator rights are missing to avoid false positive results.
The execution is possible with user or administrator rights. If only registry values are read out, this can be done without administrator rights. For other modules, however, extended privileges are necessary. In the Finding List, the module used is defined for each test point. If an evaluation of specific user settings is to be performed, such as when checking Microsoft Office or Microsoft Edge, the script should be started with the respective user whose settings are to be evaluated.
HardeningKitty_ is loaded and executed using the following commands:
PS C:\> Import-Module -Force Invoke-HardeningKitty.ps1 PS C:\> Invoke-HardeningKitty -FileFindingList .\lists\finding_list_0x6d69636b_machine.csv =^._.^= _( )/ HardeningKitty [*] 10/7/2020 9:23:49 AM - Starting HardeningKitty [*] 10/7/2020 9:23:49 AM - Getting machine information [*] Hostname: w10-client [*] Domain: WORKGROUP [*] Domain role: StandaloneWorkstation ... [*] 10/7/2020 9:23:51 AM - Getting user information [*] Username: w10-client\administrator [*] Is Admin: True [*] 10/7/2020 9:23:51 AM - Starting Category Features [+] ID 1000, SMBv1 Support, Result=Disabled, Severity=Passed [*] 10/7/2020 9:23:52 AM - Starting Category Account Policies [+] ID 1100, Account lockout duration, Result=15, Severity=Passed [+] ID 1101, Account lockout threshold, Result=5, Severity=Passed [+] ID 1102, Reset account lockout counter, Result=15, Severity=Passed ...
FileFindingList specifies which finding list is used. The parameters
Report save all output of the script with timestamps in a text file and all results in a CSV file. The parameters
Report can be used independently. It is also possible to define the respective storage location of the files.
Currently, HardeningKitty includes the following finding lists:
The Finding Lists are available as CSV files and can therefore be easily edited and supplemented. To add checkpoints, the method for reading the value must be known. In case of registry entries the path and name of the key is required. Also the recommended value as well as the severity can be set according to own needs. In the following example the ID 1300 represents a check of a registry entry, while for the ID 1000 a module for checking Windows Features was developed.
"ID","Category","Name","Method","MethodArgument","RegistryPath","RegistryItem","ClassName","Namespace","Property","DefaultValue","RecommendedValue","Operator","Severity" 1000,"Features","SMBv1 Support","WindowsOptionalFeature","smb1protocol",,,,,,"Enabled","Disabled","=","High" 1300,"Security Options","Accounts: Block Microsoft accounts","Registry",,"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System","NoConnectedUser",,,,0,3,"=","Low"
For each entry, a recommended value called
RecommendedValue, the default value
DefaultValue if the setting has not been configured explicitly, and a severity level
Severity if the actual value differs from the recommended value are defined. The field
Operator defines whether the value should be exactly the same as the recommendation or whether multiple values are possible. For example, 15 minutes or more is recommended for the duration of an account’s suspension.
If there are checklists such as Security Baselines from Microsoft, CIS Benchmarks or company-specific guidelines in the form of registry values, these can simply be converted into a Finding List as a CSV file and then used with HardeningKitty.
Reading out system information has various pitfalls. Ideally the desired value is listed in a Microsoft documentation. The Microsoft Security Baseline for Windows 10 contains a registry path for most of the defaults and the corresponding name of the key. However, it is not documented which is the recommended value for the key. This can be
1 depending on the wording of a policy. Since the structure of the registry has grown over the years and has been maintained with different concepts and different development teams, no uniform structure is apparent.
This is aggravated by the fact that different registry paths exist depending on the settings. The Windows Firewall can be activated via a policy guideline under the path
HKLM:\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile with the key
EnableFirewall. However, if no policy policy is used, but the firewall is maintained via the administration interface, then the key
EnableFirewall under the registry path
HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile is valid. For the Microsoft Security Baseline for Microsoft Edge, Microsoft only specifies policy paths that must first be imported into the group policy management using a GPO template. For the development of an automated script, the correct selection of the path is particularly important to ensure that no false statements are made. In the case of the Windows firewall settings, we have chosen to read and evaluate both paths.
Windows policies and the output of tools like
auditpol.exe depend on the language of the operating system. At the moment we only support the English version of Windows. We have tested the operating systems Windows 10, Windows Server 2016 and 2019. If someone runs the script on other versions or with another language, we are interested in an exchange of experiences.
The finding lists of HardeningKitty are supplemented and updated with new findings when a new version of the respective security baseline is available from Microsoft. The development of further functions is planned, including the comparison of results. This feature is suitable, among other things, for performing regular automated checks, listing the difference and detecting changes in the configuration. It is also planned to use HardeningKitty to perform a hardening of the system. This feature should be mainly useful for standalone systems. It is also planned to output an index value and statistics about the number of passed test points and how many findings per severity level are available. Feedback on the results is very valuable for the further development and quality of the finding lists, especially in case of false-positive results. Every system has its own peculiarities and this cannot be fully simulated in a test environment. We are also happy about new or extended Finding-Lists.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here