Basic procedure

The following basic procedure has proven successful on our projects. First, we agree with the customer which hardening standard is used and which systems are in scope. Then we use the manufacturer’s settings documentation to identify the settings that are risky from our experience and check the customer’s environment accordingly (see next sections for selection). Once all issues identified in advance have been resolved, we begin rolling out hardening in waves. We start with a few systems and have the application owner confirm functionality. If these systems continue to run without errors, the rollout is continued in incrementally larger waves.

Hardening problematic settings on the server

Microsoft itself has published an article about problematic settings. Many of the topics are no longer current because the affected operating system versions are no longer in use, but it is definitely advisable to check this in the respective environment. Often there is still a Windows 2000 server system that has to be kept running for valid reasons. Unfortunately, this is often the case, especially in manufacturing companies, when the system controls production machines.

SMB v1

The fact that SMB v1 is outdated and insecure is no longer a secret, at the latest after Wanna Cry. Nevertheless, we see SMB v1 still being used in customer environments time and again. The most explosive example: A board member used an unmanaged tablet to access an old NAS to view presentations stored there…

It is therefore advisable to check in each environment before hardening whether SMB v1 is still in use. To do this, you can enable auditing in smaller environments via PowerShell (Set- SmbServerConfiguration -AuditSmb1Access $true) or distribute the following registry key via GPO in larger environments.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameter s

“AuditSmb1Access”=dword:00000001

Auditing should be performed at least on all domain controllers and file servers. The logs can either be collected via PowerShell or forwarded to a log collector via event log forwarding. Both are nicely described here.

Knowing which systems are still using SMB v1, it is important to check why this is the case. Either the systems can be configured for SMB v2 or v3, or they need to be replaced.

NTLM v1

The NTLM (v1) issue is very similar to SMB v1. The list of attacks is long: ProxyLogon (CVE-2021-28655 , CVE-2021-27065) and ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) from

Orange Tsai, PetitPotam (VDB-179650) from topotam, as well as different vulnerabilities in insecurely configured Active Directory Certificate Services (ADCS) from Will Schroeder and Lee Christensen and probably several more.

The best thing would be to turn off NTLM completely. However, this task would be much bigger than just switching to “v2 only”. The common hardening standards call for turning off v1 and using only v2, which is why we will limit ourselves to that for now in this blog.

In our projects, it was sufficient to enable monitoring on the domain controller via GPO

In principle, you can also activate the audit on member servers. More about this here.

To collect the events, the following PowerShell command can be used, for example:

$Events = Get-WinEvent -Logname Security -FilterXPath “Event[System[(EventID=4624)]]and Event[EventData[Data[@Name=’LmPackageName’]=’NTLM V1′]]” | Select-Object `

@{Label=’Time’;Expression={$_.TimeCreated.ToString(‘g’)}},
@{Label=’UserName’;Expression={$_.Properties[5].Value}},
@{Label=’WorkstationName’;Expression={$_.Properties[11].Value}},
@{Label=’LogonType’;Expression={$_.properties[8].value}},
@{Label=’ImpersonationLevel’;Expression={$_.properties[20].value}}

As with SMB v1, the next step is to examine why NTLM v1 is being used to communicate here. This article describes the problems that can arise from removing NTLMv1 from the IT infrastructure and gives an excellent list of reasons and solutions (the original link to the article from itconnect is unfortunately no longer available).. If a system needs to be reconfigured anyway, this is a good time to move directly to Kerberos if the application supports it.

LDAP Signing and Channel Binding

Microsoft already tried 3 years ago to force LDAP signing (ADV190023). For good reason. See KrbRelayUP:

“This is essentially a universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings).”

Now, where is the challenge in enforcing SMB signing and channel binding? Similar to the two sections before, you first have to find out which systems speak unsigned LDAP and then clarify why.

Again, you can enable logging via registry key on the DCs:

Reg Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v “16 LDAP Interface Events” /t REG_DWORD /d 2

In addition, the Channel Binding Token (CBT) signing event 3041 should be generated. For this, the setting Domain controller: LDAP server channel binding token requirements must also be configured to “When Supported” on the domain controllers. Otherwise, only the general events 3040 and 3041 are generated, which indicate whether there were unsaved binds, but no details of which system triggered this.

The meaning of the different events can be read here at Microsoft. Then you can modify the above Powershell code to collect the relevant events.

Armed with the list of systems, you can now talk to the people responsible for the server and together find out which application establishes an LDAP connection. There is usually little you can do about the fact that the application does this without signing, but in our experience (almost) every application supports LDAPS. Thus it is usually done with a change of the configuration in the software.

However, we have also had the case where the operating system (Linux, domain-joined) communicated via LDAP and it was not possible to change the configuration. Unfortunately, no OpenSSL package that supports signing was available in the manufacturer’s repository for the version of the operating system used. Thus, the server had to be reinstalled with a newer version of the operating system.

User Rights Assignments

Sometimes there are problems with the User Right Assignments.

For example, both CIS and MS Baseline configure “Ensure ‘Access this computer from the network’ is set to ‘Administrators, Authenticated Users'”. However, when using Defender for Identity, it is necessary that the service account used has just this right, see here.

User Rights Assignments can be configured via GPO as well as locally, making it difficult to conclusively check the issue up front. If one uses the Enforce Adminstrator for hardening, then one can match the settings with GPOs when creating the hardening and at least check this way conclusively. To check locally configured settings, one could run a script like this on all systems and check the output.

However, since the problems in this area are not so frequent, we usually leave it to it and find the isolated applications by testing the application managers.

Attack Surface Reduction Rules

Attack Surface Reduction is a fairly new feature of Windows Defender. It is supposed to help prevent cyber attacks. A detailed blog series is available here.

To reduce the attack surface, some functions are disabled, which can lead to applications not being able to run. We have also seen false positives. The rule “Block credential stealing from the Windows local security authority subsystem (lsass.exe)” is particularly noticeable. Here we often saw messages that something was blocked, but the reported application still worked as expected.

To be on the safe side, it is advisable to first configure the rules in audit mode, check the messages in the event viewer and only when all problems have been solved, switch the rules to block mode.

The common curing standards do not call for all ASR Rules to be turned on, however, we think it is a good idea, even if it is a little more work.

Problematic hardening settings at the client

Applications and UNC paths

Applications are often placed on network shares and launched from there via a UNC path to simplify application updates. After applying the Security Baseline for Windows in such cases, you may receive a popup with the security warning: “The publisher could not be verified. Are you sure you want to run the software”. By clicking Run, the user can still launch the application.

This error message is annoying for the user, but can be disabled by adding the UNC path to the Intranet Zone file. For this purpose there is a so-called Site to Zone Mapping which is stored in the registry (the mapping can be set for the whole system or for the user):

• • HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap
  • HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey

Both settings can also be configured via Group Policy configure:

• • Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page
  • User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page

The name of the server is entered there, e.g. file://myserver1 with a value of 2, which stands for the intranet zone.

Microsoft Defender Smartscreen

Microsoft Defender Smartscreen blocks applications that are considered potentially dangerous. In the process, the executed file is checked against a list of known malware. Files can be submitted to Microsoft for examination. Both the Microsoft Baseline for Windows 10 and the CIS Microsoft Windows 10 Enterprise Benchmark enable Defender Smartscreen.

The following error message then appears at the customer when the user tries to run the application:

Actually, this feature of Defender Smartscreen is intended for protecting applications and files from the Internet. But why was the execution of an internal application blocked in this case? The reason was that executable EXE file was classified as originating from the Internet. Defender SmartScreen writes an event to its event log. In the event details, a ZoneId with the value 3 is displayed:

This is the so-called Zone Identifier. This zone identifier is written to the Alternate Data Stream by browsers such as Microsoft Edge or Internet Explorer when files are downloaded (this is a function of the NTFS file system for storing additional metadata). If the zone identifier is set, a warning is displayed in the properties of the file in Windows Explorer:

By clicking on “Unblock” or using the PowerShell cmdlet Unblock-File, the Zone Identifier can be removed. This will unblock the application from Defender SmartScreen.

HTTP Authentication Schemes

The baseline for Microsoft Edge and the CIS Microsoft Edge benchmark disable Basic Authentication among the supported authentication schemes. Basic Authentication is an outdated and insecure authentication method and the clear recommendation here is to switch applications that require it to a more modern login method.

For troubleshooting, Basic Authentication can be re-enabled using the following Group Policy setting:

Computer Configuration > Administrative Templates > Microsoft Edge > HTTP authentication > Supported authentication schemes

Append the value ‘basic’ to the comma-separated list (all values must be lowercase).

Junk mail protection

The Microsoft 365 Apps for Enterprise baseline and the CIS Microsoft Office Outlook benchmark set the Junk E-mail protection level to “high”. However, Microsoft recommends that customers with Exchange Online turn off filtering, otherwise false positives can end up in the junk filter. This is achieved with the following Group Policy setting:

User Configuration > Administrative Templates > Microsoft Outlook 2016 > Outlook Options > Preferences > Junk E-mail > Junk E-mail protection level

Office file formats

A recurring theme in client hardening is the handling of older Office formats. The Microsoft 365 Apps for Enterprise Baseline and the CIS Microsoft Office Excel Benchmark are quite restrictive and disable all older Office formats. This affects all old binary formats of the Office version older than 2007, before Office had introduced modern file formats based on XML. Most companies still use older Office formats at least in some areas and therefore have to soften the Microsoft baseline again in this area.

For Excel, for example, there is a separate setting for each version and its associated file format

For example, to unblock the opening of Excel 2003 documents, the following Group Policy setting is set to “Do not block”:

User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center > File Block Settings > Excel 97-2003 workbooks and templates

As a rule, activating this baseline will first require an inventory if the Office formats used are not known in detail. One problem with this is that you can’t always tell the exact version from the file extension. For example, the file extension . xls stands for Excel files of versions starting from Excel 2 up to Excel 2003 and the settings allow to switch off the exact file format for the respective version.

We provide here a small script that searches a certain directory incl. subdirectories for files with the extension . xls and determines the exact version. However, the script must open the file, so it must only be applied to trusted files, because macro code may be executed when the file is opened, and macros that start automatically and display a dialog box, for example, must be clicked away manually.

After knowing which file formats are available, it should first be checked to what extent the older file formats can be converted into the current XML-based file formats of Office. Here, it should be checked whether there are applications that process these documents automatically (e.g. automated scanning and / or OCR software) and only support the old format.

If older Office formats are still required, it should also be considered whether this is only needed in sub-areas such as controlling and then to allow these files only for these areas in the company.

Conclusion

With this article, we wanted to give you an insight into the basic procedure for implementing hardening for both Windows servers and clients. The detailed issues described are a selection of topics that we encounter at our customers when implementing hardening projects, but do not claim to be complete. As usual, we look forward to your feedback 😊.