Windows Administration Security
This project allowed me to discover how to enable and disable certain GPO's in a Windows system that will better secure endpoints across an Active Directory network. (08/16/2022)
Last updated
This project allowed me to discover how to enable and disable certain GPO's in a Windows system that will better secure endpoints across an Active Directory network. (08/16/2022)
Last updated
Windows is the most common enterprise operating system (OS) in the world. Not only because of its vast popularity, but also to the untrained, Linux is scary! All jokes aside, there have been a multitude of released versions of Windows OS over the years. The reason new versions are pushed out, or updates run so often, is because security hardening patches need to eliminate holes in the OS. This is fantastic support, but the issue of insecure default configurations remains.
In an Active Directory (AD) network, endpoints can be provisioned on the fly with Access Control Lists (ACL's), Group Policy Objects (GPO's), and other security features to ensure all workstations under the Domain Controller are hardened against threat actor intrusion. Today, I will be walking through the purpose of a select group of these default settings that should be managed upon the provisioning of a new workstation.
Gpedit is a tool that is pre-installed on Windows 11 Pro edition (not Home), as these are utilized in Enterprise level environments that pay for Windows Product Licenses for extra features like Active Directory (AD). It stands for Group Policy Editor, and you guessed it, it allows you to make changes to minute applications or Group Policies on the system locally or across the AD network. These controls can affect users, applications, network protocols, and system activity on a specific level of accuracy. Remember, the concept of least privilege should always extend to your day to day users. Let's take a look at a few of the more important Group Policies below and how they can affect security of the network.
These are a collection of settings and configurations that define the ultimate behavior of a system. They can be local, non-local, or starter GPO's. The main difference is that non-local GPO's can enact changes once they are connected to an AD environment, while local GPO's are native to a single endpoint and all its locally associated users. The starter GPO is relevant for sysadmins when spinning up a new system from a last known good configuration baseline. Below are some of the GPO's I edited that allowed me the ability to strengthen the security of this endpoint.
A couple common password attacks threat actors utilize are bruteforcing, or dictionary password attacks. Both of these involve testing a combination of characters against a known account name in order to obtain a valid login. Bruteforcing takes much more time, considering it involved iterating through consecutive combinations of letters numbers and characters slowly increasing in character count. This process can be inefficient, which is where dictionary attacks come into play. These attacks will iterate through a known password leak file (from a previous breach, if applicable), or even a giant password list full of more than 14 million of the most common passwords in the world, such as rockyou.txt. To eliminate these types of attacks, a GPO for Account Lockout can be implemented and enabled. After a specified number of failed logins, Windows will lock the specified user out for a predetermined period of time. Locking the user out forever is counterintuitive, however, as a lockout indication for the enterprise's Security Operations Center (SOC) could be a false positive. They could have no threat at all, as an employee just forgot their password and triggered the lockout after 3 failed attempts. The lockout time can be adjusted to suit the SOC's needs for investigation, verify the false positive, document, and close the ticket after unlocking the user's account. This is not a fix-all solution though, but it works pretty well at communicating an Indicator of Attack (IOA) to the SOC in a timely manner.
PowerShell is Microsoft's super powerful command line tool that utilizes .NET objects to execute tasks. This tool can be a Sysadmin's best friend, but also their absolute nightmare if unauthorized hands were at the keys! With the PowerShell policies, especially in an AD network, Powershell can be disabled across endpoints where normal users do not require access to it. Following the concept of least privilege, there could be no valid reason for PowerShell access on a workstation. Gpedit and the PowerShell use policies can be disabled so that only an authorized Sysadmin can make such drastic changes to the system with this powerful command line tool. In the picture below, logging is enabled to track exactly what commands are entered into the CLI by what user. The setting to block scripts and execution are also enabled, as to keep malware from executing malicious processes on the host system.
PowerShell logging is one of the most important settings to be enabled on an endpoint, end of discussion. Logs are collected from a variety of sources in the threat hunting activities of an SOC, and PowerShell logs are one of the many data sources that will be aggregated for analysis in the SOC's Security Information and Event Management (SIEM) tool to trigger alerts for Indicators of Compromise (IOC's) or IOA's. Logs don't lie, and they leave a breadcrumb trail for a threat hunter to build a threat profile on their assailants. Below is an example of a PowerShell log, and something any Windows Sysadmin should become familiar with in order to monitor user and threat actor activities alike.
The GPO's and security features gpedit provide access to are invaluable in relation to securing endpoints on a widespread scale across an enterprise level envrionment. No matter how large or small the network may be, simple security features cannot be overlooked. It is important to audit these policies as well, as a means of due dilligence in case something happened to be changed or rolled back to a previous configuration. The security team's budget is limited, so why not capitalize on free defenses that are included with the OS your company already utilizes? Dig through these policies one day, and you might be surprised how much control you actually have at your fingertips to reduce your overall attack surcface.