https://www.linkedin.com/feed/update/urn:li:activity:6625351188235730945

At this point we would like to briefly explain the background to the individual measures. Briefly, because each topic requires some expertise and time. We would like to give you an insight and a starting point to start with. Of course, we are also happy to support you in the implementation 😊!

• Separate admin accounts:
  • Background: Many administrators still work with highly privileged users on the normal office workstation. If the workstation is compromised, e.g. by the Zoom gap described above, the attacker immediately has access not only to the office workstation, but also to all systems for which the user account is authorized.
  • Action: It sounds simple, it is. You must create at least two users for each administrator. One user to do “normal” office work, such as writing mails, surfing, attending meetings, etc. and one or more administrative user to manage servers or applications. This alone makes it a little more difficult for the attacker – he must now also perform a “privilege escalation” – but it really makes sense in combination with other measures such as a privileged administrative workstation (PAW).

• Change all non-personal passwords
  • Background: It is standard practice for users and administrative accounts to change their passwords regularly. But what about the “non-personal accounts”, i.e. service accounts under which a certain service runs, or the krbtgt and AD Safemode password of the Active Directory service? In many cases, companies do not dare to change these passwords regularly. There is a concern that applications or scripts will not work properly after that. For example, if an attacker captures a password hash of a service account, he can crack the password offline in a “Kerberoasting attack”.
  • Action: It is tedious, but it is imperative to analyze service account by service account and document how to change the password. In addition, some applications support “Group managed service accounts” where the Active Directory handles the password change fully automated.

• Reduce high privileged service account
  • Background: Following on from the above point, it should also be noted that many service accounts have too many rights. How often does it happen that when creating a service account it is unclear which rights are needed exactly? Especially in the past, when in doubt, even domain admin rights were assigned. This also leads to the fact that attackers only have to take over a few accounts to gain permissions in the whole environment.
  • Action: Like changing a password, there is no way around analyzing account by account and reducing the rights to the required minimum. Very time-consuming, but also very helpful!

• Introduction of LAPS
  • Background: The “local administrator password solution” (LAPS) is quickly configured and rolled out and increases protection very quickly. Think of the server or client image that is used as a template for all or most computers in the company. In most cases, the same password is used for the local administrator and is never changed again. The password is often set via GPO or startup script, which can be read by all authenticated users. But regardless, even with service providers or internal staff changes, the password is never changed. This means that many people know the local admin password and therefore do not even need a security hole, but only access to the system.
  • Action: Simply explained – LAPS is free of charge and changes the local administrator password regularly. The password is stored in a secured attribute of the computer object within the Active Directory. ACLs can be used to control who is authorized to read the password or force a change. Passwords can be read or changed via PowerShell, ADSI Edit or a LAPS GUI if required.

• Introduction of a tiering model
  • Background: Certainly, one of the more complex topics in this list. Nevertheless, the introduction of a tiering model is the basis for an SAE project or Microsoft ESAE. Briefly explained, this means that you classify your IT systems and divide them into (usually three) layers (Tier0-Tier2). Each layer has its own protection requirements and is protected accordingly.
  • Measure: In our SAE blog series we deal intensively with the topic of tiering – just read on! – https://www.teal-consulting.de/en/blog/

• Fine grained password policies
  • Background: Before Windows 2008 it was only possible to define a password policy for the whole domain. This was valid for normal user accounts, administrator and service accounts. So, a compromise between security and usability had to be found. Usually this resulted in rather short passwords regarding the end user. Of course, longer passwords can be used for administrators and service accounts. However, the usage then depends on the discipline of the administrators. Hashes of short passwords can be cracked in a very short time (8 characters in ~2.5 hours) with the computing power available today.

• • Action: Fine Grained Password Policies were introduced with Windows 2008. With this it is possible to define different password policies based on global AD groups. An example:
    • Tier 0 Admins: 20 characters, Max Password Age: 60 days
    • Tier 1 and 2 Admin: 15 characters, Max Password Age: 60 days
    • Service Accounts: 30 characters, Max Password Age: 90 days
    • User: 8 characters, Max Password Age: 90 days
      By the way, Fine Grained Password Policies are managed with Active Directory Administrative Center or PowerShell.

• PAWs
  • Background: In many cases, administration is done by the admins connecting from their workstation to the server to be administered via RDP or PowerShell Remoting. The same workstation is used for internet browsing and email communication. – See also the first item in this list 😊.
  • Action: To move the administrative work to a dedicated system, it should only be done through specially hardened endpoints. These workstations are also called Priviledged Access Workstation (PAW). PAWs must be fully secured:
    • Installed according to the Clean Source Principle
    • Always on the current patch level incl. firmware
    • Only the minimum necessary software
    • No internet access
    • Crediential Guard and AppLocker
    • Interfaces deactivated
    • 2 factor authentication / biometric authentication
    • Devices are in access-secured offices. At a minimum, they are safely locked away when not in use.
    • …

• Accelerate the patch and OS management process
  • Background: In most companies there are several versions of Microsoft operating systems for client and server systems. Security updates and new OS versions are not rolled out promptly, or not at all. This has the consequence,..:
    • • …known security vulnerabilities are not closed in a timely manner
      • …that operating systems are no longer supported by Microsoft and therefore no more security updates are released for the version.
      • …that new security features such as forcing SMBv3 (supported by Windows 10, Server 2016 or higher) cannot be implemented.
      • …that no current Security Baseline GPOs from Microsoft can be used.

    Therefore, it is absolutely necessary to use supported operating systems and to install updates promptly

• • Measure:
    • Patching
      Patch processes must be streamlined and ensure that security updates are tested and rolled out shortly after release. For example, more and more companies are going straight into production and rolling out patches in several waves. First on a small group of systems to test compatibility and then in ever increasing batches. Only then or in parallel are test environments rolled out.
    • OS Upgrade
      Organizations should not wait until mainstream support or the end of extended support for the operating system version in use has expired (or even beyond) before updating. Updating should be done early to take advantage of new security features in a timely manner.

• Implementation of Device/Credential guard
  • Background: Tools, such as Mimikatz extract password hashes from the Windows LSAS process. If an attacker has stolen the hash, it can be used to log on to various services in the company and, if necessary, steal data or cause damage. We have already read this a few times in this blog article, another technical measure that can make it more difficult for the attacker is Device/Credential Guard.
  • Measure: Credential Guard uses Virtual Secure Mode to create a sealed off area in memory to store credentials. This memory is protected by hardware against access from “normal” memory. However, Credential Guard is not a complete protection against Mimikatz, since attackers with administrative rights can install their own Security Support Provider for Mimikatz or other keyloggers to tap credentials as they are entered. But like I said, we make it a bit harder.

• GPO security baseline
  • Background: Client and server systems must be securely configured. This should prevent, for example, that insecure protocols are used or ensure that vulnerabilities can no longer be exploited. Most companies start with the standard GPOs created during the AD installation (Default Domain Policy, etc.). Little by little, settings are added that meet specific functional requirements. Only a few organizations take the time to analyze the hundreds of settings in terms of security to create a secure baseline.
  • Measure: Microsoft publishes so-called Security Baseline GPOs for current Windows operating systems and Office. The baseline contains all possible GPO settings, an explanation of the setting and a configuration recommendation. For servers, a distinction is made between Member Server and Domain Controller. Microsoft does not always choose the absolutely most secure variant, but also weighs up compatibility and security. Nevertheless, some of the selected settings can lead to problems. Therefore, the settings must be validated in a representative test environment!
    Administrators can download the Security Compliance Toolkit from Microsoft. In addition to the current baselines, a tool for comparing GPO settings is also included. In addition to Microsoft, there are other sources such as CIS or BSI that provide recommendations for the settings. These institutions usually tend to be a little more concerned with security than compatibility.

All these measures make it difficult for attackers to spread and cause damage within the company. Although they cannot prevent security holes in deployed software, as is currently the case with Zoom, they can significantly mitigate the effects of exploited holes!

We hope that with these measures we have been able to create a good starting position for all the stressed administrators out there. As I said, we are happy to help with the implementation or advise you!  By the way, we are now also regularly publishing infographics on social media about the above mentioned topics… Just have a look at LinkedIN (@Teal Technology Consulting GmbH) or Instagram (@tealconsulting).

LATEST POSTS