The ubiquity of the Microsoft Windows Operating System is a contributing factor that enabled growth of the Information Technology Field. From earlier renditions of Windows 9x, Windows 2000, Windows XP, to Windows 10 and Windows 11 the Redmond software manufacturer's OS established a consistent interface that has rarely changed, facilitates training, and enabled Original Equipment Manufacturers such as Dell, HP, or others, an OS users were familiar with and easy for novices to click through a Graphical User Interface and connect to extraneous devices or services on the internet. That ubiquitous through "Plug-and-Play" style concepts is also another factor in why the OS is generally so targeted by Threat Actors. By facilitating an OS that users can plug into a simple networking device and communicate with other computers or media devices on the network with no advanced configuration requiring in-depth knowledge, users are generally employing an OS with extraneous communication standards and protocols that are not secure by design.
The problem described above was first a thought experiment when managing a small Managed Security Service Provider to alleviate the security and IT requirements of organizations. In recent years Cloud Service Providers are considered the standard to provide an initial security defensive posture. Both Amazon Web Services and Microsoft Azure, CSP offerings from both giants in the industry, were examined with more analysis afforded to Azure. In the end, the offering and options Azure could provide a MSSP or other organizations was quite obvious, due to the administrative management options, however the cost for the small MSSP was the main restrictive factor. In the course of the evaluation, however, it was noted the benefits Azure could provide an organization could be achieved through similar utilities of Group Policy Objects and script files, at least to achieve additional security of the end device at the local machine. The task of providing additional security to the MSSP's clients was re-focused back to the MSSP's Remote Monitoring and Management platform, ConnectWise Automate, which provides automation and monitoring capabilities.
ConnectWise Automate provides many features, but the script management feature enables MSSP's to run command-line scripts in Microsoft Windows Powershell, the go-to for modern automation tasks in Windows environments for Administrators lacking advanced automation tools. This guide will serve as a combination of steps in ConnectWise Automate and Powershell utilizing the Microsoft Security Compliance Toolkit, GPOs, and scripts to modify the Local Security Policy GPO of a Windows Professional or Enterprise workstation to achieve a secure configuration baseline. While many examples and guides, and CSPs, are available for end users and administrators, the following guide was unique at the time due to its ability for domain-joined, non-domain-joined, member servers, or Active Directory server options to enhance a security baseline.
Without turning this writing into a comprehensive ConnectWise Automate "How-To", the guide will outline just the highlights for the point of brevity. Below is an example of the scripting function within the Automation function of Automate. Highlighted are the relevant Name, Notes, and Steps of the actual script.
This security baselines requires a number of components to download to deliver additional security on the Windows clients. The first of these is Microsoft NuGet, which is a package manager for packaging, distributing, and consuming software libraries written using .NET and the .NET framework. NuGet is a Microsoft-supported open-source tools that simplifies the process of managing dependencies and integrating external libraries into .NET projects. Simply, NuGet allows developers to create, share, and consume reunsable code packages, known as NuGet packages using a .nupkg extension. At the time this process was compiled, the various guides on the Internet for installing NuGet resulted in error, which resulted in the author's own methodologies to achieve the goal.
Within the Steps of an Automate script, the administrator has the option to establish individual steps the administrator wishes to run.
The individual steps can be clicked on to set a note in Automate. In the example below, the option exists for a Remark step to make notes to keep track of what the author overall intended to preface the actual Run steps.
Achieving functionality with the Script steps requires individual steps for the sake of simplicity. The Function: File Write Text with a path to a Powershell .ps1 extension will enable Automate to write to a file on the end device where the script will run.
The payload of the script is set in the Data Field. In this guide, to install the Microsoft NuGet provider, the steps "Set-ExecutionPolicy Unrestricted -Force", "Install-PackageProvider -Name NuGet -Force ", and "Import-PackageProvider -Name NuGet -Force" will set the Powershell execution policy, install, and then import NuGet. At the time of the initial writing, the goal was to achieve the desired results in a quick manner. This step could be re-written to define the execution policy more succinctly.
At this point, the initial steps have only written the data to the local end device in a Powershell .ps1 file. ConnectWise Automate still needs to call, or execute the remote file. The Function: Powershell Command achieved this by calling the file we wrote earlier using the "& 'C:\Windows\LTSvc\Blog\Blog.ps1'" execution method.
The end result will be the previous commands written earlier are executed by the ConnectWise Automate agent without user interaction or the user aware of changes to the back end or underlying changes of the OS.
When completed, a good script step is cleanup by using the Function: File Delete to delete the .ps1 file written to earlier so it doesn't remain on the filesystem.
With the initial idea conveyed of script execution in Automate, the additional tasks follows to achieve the desired result by orchestrating downloads on the end device to install additional Powershell Modules.
Using the Function: File Write Text to create a file on the filesystem, as specified earlier, Automate can install the Powershell Modules ProcessMitigations, PolicyFileEditor, and PowershellGet.
ProcessMitigations is a module that can be downloaded from the Powershell Gallery, which is the official repository for Powershell modules and scripts. ProcessMitigations provides functionalities to configure and audit exploit mitigations for increased process security or for converting the existing Enhanced Mitigation Experience Toolkit policy settings. With ProcessMitigations, users can enable and disable process mitigations or set them in bulk from an XML file. Overall, it allows users to manage various exploit mitigations to enhance the security of processes on Windows end devices. The available cmdlets ProcessMitigations provides are:
ConvertTo-ProcessMitigationPolicy: Converts an XML file containing process mitigation settings to a ProcessMitigationPolicy object.
Get-ProcessMitigation: Retrieves the current process mitigation settings for a specified process.
Set-ProcessMitigation: Configures process mitigation settings for a specified process.
The Set-ProcessMitigation cmdlet will be the specific utility to achieve further desired results.
While the PolicyFileEditor provides a number of uses, the main use within this article will be to modify the local GPO registry.pol files and Administrative Templates. The module allows the user to programmatically set the local GPO using the Set-PolicyFileEntry to change the value of registry settings.
The PowershellGet module provides cmdlets for discovering, installing, updating, and publishing additional Powershell modules and scripts from various repositories.
At the time of the development of this process, the previous steps were intended to bootstrap the whole process for easier administration later through Automate.
With the above script blocks set, called, and deleted to ensure a clean filesystem, a user can test the processes by setting a local GPO. While Windows Optional Components -Features on Demand is typically an option set to specify where to update components of the OS, using the same Write, Execute, Delete methodology established earlier, Automate can import the PolicyFileEditor installed above to manipulate the local GPO to now change the setting within the LGPO.
The below is the direct code for the Write step of the Automate script to initialize the PolicyFileEditor installed earlier.
#LGP:Computer Configuration\Administrative Templates\System\Specify Settings for Optional Components. i.e. Features on Demand.
#https://www.powershellgallery.com/packages/PolicyFileEditor/3.0.1
#https://gist.github.com/thoroc/86d354d029dda303598a
#RegType Options = Unknown, String, ExpandString, Binary, DWord, MultiString, QWord, None"
Import-Module PolicyFileEditor
#From GP: This policy setting specifies the network locations that will be used for the repair of operating system corruption and for enabling optional features that have had their payload files removed. ie, this allows "Download repair content and optional features directly from Microsoft."
$machinedir = "$env:windir\system32\GroupPolicy\Machine\Registry.pol"
$RegPath = 'SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing'
$RegName = 'RepairContentServerSource'
$RegData = '2'
$RegType = 'DWORD'
Set-PolicyFileEntry -Path $MachineDir -Key $RegPath -ValueName $RegName -Data $RegData -Type $RegType
gpupdate /forceOnce the script has been run, the desired result can be checked by using gpedit.msc to check the Computer Configuration\Administrative Templates\System\Specify Settings for Optional Components installation and component repair i.e. Features on Demand.
