Reusing passwords across multiple accounts can put you at significant risk because hackers can exploit this practice through a technique called 'credential stuffing'. Here's how it works and why it's dangerous:   Data Breaches When a company or service is hacked, user data, including usernames and passwords, can be stolen. These credentials are often sold or shared on the dark web or hacker forums. Even if only one account is compromised, it can have ripple effects if you reuse the same password across different accounts.   Credential Stuffing Hackers use automated tools to take usernames and passwords from one breached site and try them on many others. For example, if your email and password were exposed in a breach from an e-commerce site, a hacker might try to log into your bank, social media accounts, and email using the same credentials. If you’ve reused the same password, the hacker could gain access to multiple accounts.   Chain Reaction of Hacks Once hackers gain access to one account, they often look for ways to escalate their attack: Email Compromise: If they gain access to your email account, they can initiate password reset requests for other services, further expanding their control over your digital life. Social Media Exploits: Hackers can hijack social media accounts to send phishing messages to your contacts, spreading the attack even further. Financial Loss: Access to financial accounts can lead to unauthorized transactions, drained accounts, or identity theft.   Increased Success Rate Automated scripts used in credential stuffing can check thousands of accounts in minutes. Reusing passwords increases the likelihood that the hacker’s efforts will succeed, making it easier for them to penetrate more accounts with minimal effort.   Difficulty in Detecting Since hackers use the correct username and password combinations during these attacks, it may not immediately trigger security alerts. Many services assume that a correct login attempt is legitimate, making it difficult for you or the service to detect the breach before damage is done.   Inability to Track Breaches When you reuse passwords, it becomes hard to know which service caused the security breach. If you use the same password for ten different sites, and one gets hacked, you'll need to change the password for all ten sites. In contrast, if you used a unique password for each site, only the compromised service would be affected.   How to Protect Yourself: Use Unique Passwords for Each Account: This ensures that even if one password is compromised, your other accounts remain secure. Utilize a Password Manager: These tools help generate and store complex, unique passwords for each site, so you don’t have to remember them all. Enable Two-Factor Authentication (2FA): Adding an extra layer of security can prevent hackers from accessing your accounts even if they have your password.   By avoiding password reuse, you significantly reduce the risk of widespread damage from a single data breach.

Intune's Autopilot automates the configuration and setup of new devices, allowing users to start working with pre-configured settings, applications, and security policies as soon as they power on their device. In this blog, we’ll explore how Microsoft Intune Autopilot works, let's get started. Dynamic Group for Deployment Profile From within Intune, browse to Groups and then click on New Group. To ensure that every newly registered device is associated with Autopilot automatically you need to first create a dynamic Azure AD (Entra) Security Group. Edit the Dynamic Query, then paste the following string and Save. (device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]")) Enrollment Configuration From within Intune, browse to Devices, Windows, then Enrollment. Device Platform Restrictions Intune Device Platform Restrictions controls which types of device can access organizational resources based on their platform (e.g., Windows, iOS, Android, macOS). This feature helps enhance security by limiting access to only approved device types and blocking untrusted or unsupported platforms. This step isn't necessary for Autopilot to work as the default is to allow all devices, however we will block Windows Personally owned devices. Click on 'All Users' link. Change Personally owned devices for Windows (MDM) to Block. Deployment Profiles Autopilot deployment profiles in Microsoft Intune are configuration templates that define how new devices are set up and managed during the out-of-box experience (OOBE). These profiles allow automated and customizable deployment processes, specifying settings like Azure AD join type, user-driven or self-deploying mode. Navigate to Deployment Profiles within the Enrollment tab, then select Create Profile. Provide name and select Yes for 'Convert all targeted devices to Autopilot', this enables all non-Autopilot, or current members of Entra to become Autopilot registered when they are assigned to the profile group. Select User-Driven and any other pertinent settings. Assign the Windows Autopilot group created earlier and then save the changes. That covers the basics of configuring auto enrollment. I'll skip the Enrollment Status Page for now, as it's not essential for this introductory guide. Enrollment of a Device For the purposes of this blog, a Windows 11 23H2 OS has been installed on Hyper-V, and the setup has been progressed to the Region selection page. Press Shift & F10 for an Administrative shell Type the following to download the Autopilot PowerShell module. Powershell install-script get-windowsautopilotinfo set-executionpolicy -ex bypass get-windowsautopilotinfo -online Enter Azure credentials to register the device. Accept the permissions request. Wait while the device completes the registration. Go back to Autopilot under the Devices section and verify that the device has been successfully registered. Restart the device, which will then connect to Intune and retrieve the assigned policies. Enter your Azure credentials. Once the device is ready, login, and after a brief wait, any assigned applications will begin to install. That wraps up this quick configuration guide for Intune Autopilot. Links: https://learn.microsoft.com/en-us/autopilot/enrollment-autopilot

<# .Synopsis Disable Admin Shares ​ .Description Disable Admin Shares C$, IPC$, ADMIN$ to prevent remote access and local access via \\127.0.0.1\c$ from a browser, shortcut or cmd. Disabling admin shares will prevent ConfigMgr from deploying the client agent and remote administrative access. ​ .Version #> #AutoShareWks New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\LanmanServer\Parameters' -name AutoShareWks -PropertyType DWORD -Value 0 ​ #AutoShareServer New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\LanmanServer\Parameters' -name AutoShareServer -PropertyType DWORD -Value 0

When delving into the intricate workings of Windows file system architecture, one of the more technical concepts that often emerges is file altitude. If you’ve ever explored file system filter drivers or engaged in low-level system development, understanding this concept is crucial. This blog aims to break down the complexities of Windows file altitude, the role it plays in the kernel, and how it affects file system operations.   What is a Windows File System Filter Driver?  Before diving into file altitude, it’s essential to understand the role of file system filter drivers. In Windows, a filter driver operates within the kernel mode and can monitor, modify, or extend the functionality of file system operations. These drivers can be inserted into the I/O request path, between the application and the underlying file system, to intercept and possibly modify file operations such as read, write, and delete requests.   File system filter drivers are typically used for:  Antivirus solutions: to monitor and block malicious activities. File encryption or compression: to apply encryption or compression on the fly. Backup solutions: to intercept and manage file access for consistent backups. File system auditing or monitoring: for logging file system activities or imposing policies.   Introducing the Concept of File Altitude  In a system where multiple filter drivers are installed, there needs to be a way to define their order of operation. This is where altitude comes into play. Simply put, file altitude is a numerical value that dictates the position of a filter driver within the file system stack. The higher the altitude, the closer a driver is to the application layer (and further from the actual file system).   Windows ensures that these altitudes are registered and properly sequenced to avoid conflicts between drivers that might need to operate in a specific order.   How Altitude Works  Imagine a scenario where multiple drivers are installed for various purposes (e.g., an antivirus, a backup tool, and a logging tool). These drivers all want to interact with I/O requests. Without an ordering mechanism, there could be conflicts:   An antivirus might want to inspect a file before any backup software reads it. The backup software might need to know the original state of a file before encryption is applied.   Altitude values help resolve this by assigning each filter driver a priority based on its altitude. Windows ensures that the drivers with the highest altitudes receive I/O requests first, while those with lower altitudes are closer to the file system (and see the request last).   Altitude Numbering System  The altitude value is a floating-point number ranging from 0.000000 to 999999.999999. By convention, the lower the altitude number, the closer the driver is to the file system itself, and the higher the number, the closer it is to user mode operations.   Upper-range altitudes (e.g., 380000-499999) are typically reserved for drivers like encryption and compression tools that need to operate closer to user-mode applications. Middle-range altitudes (e.g., 200000-379999) are often used by antivirus software, which needs to filter I/O requests before they reach the disk. Lower-range altitudes (e.g., 0-199999) are usually occupied by drivers that need to interact closely with the file system itself, such as volume managers and file system encryption.   Each filter driver registered with the system must provide a unique altitude to prevent collisions or ordering issues.   Managing Altitude in Windows The Windows OS provides a centralized mechanism for managing filter driver altitudes. Filter Manager, a built-in component of Windows starting from Windows Server 2003, facilitates the registration and sequencing of these filter drivers. It ensures that drivers operate in the correct order based on their altitude, preventing lower-altitude drivers from inadvertently disrupting higher-altitude ones.   Querying Altitude  You can query a system's file system filter driver altitudes using the `fltmc` utility in the command prompt. This utility displays loaded filter drivers, their altitudes, and their current operational state.   fltmc filter   The output of this command might look like: Registering a Driver with an Altitude  When developing or installing a new file system filter driver, you need to register the driver with an appropriate altitude to ensure that it functions correctly within the filter stack. The driver installation process typically handles this via INF files or registry entries.   Altitudes are not chosen arbitrarily; they are managed and assigned by Microsoft. Developers must register for an altitude by contacting Microsoft’s filter manager team to ensure that no two drivers conflict by using the same altitude.   Handling Altitude Conflicts  Altitude conflicts can arise when two or more drivers attempt to register for the same or similar altitudes, especially if one driver isn’t aware of the other. If a conflict occurs:   It can lead to unpredictable system behavior, including I/O request handling errors. In worst-case scenarios, it could result in BSODs (Blue Screens of Death) due to improper sequencing of I/O operations.   By adhering to the altitude registration process, conflicts are minimized. The filter manager enforces altitude uniqueness to prevent these kinds of operational failures.   Practical Example: Antivirus and Backup Solutions  Consider a scenario where an antivirus solution and a backup tool are installed on the same machine:   Antivirus Filter: This filter driver operates at an altitude of 350000. When an application requests to read or write a file, the antivirus filter intercepts the request first. It scans the file for malicious content before passing it down the stack.   Backup Filter: This filter driver is at altitude 250000. After the antivirus completes its scanning, the request moves to the backup filter, which monitors the file for any changes, making a backup copy if necessary.   File System Operations: Finally, the request is passed down to the actual file system, which handles the physical read or write operations.   Without the correct altitude order, the backup software might try to back up a file before it has been scanned by the antivirus software, potentially saving a corrupted or infected file.   Conclusion  In summary, file altitude is a critical mechanism in the Windows file system architecture that governs the order in which filter drivers process I/O requests. By assigning a specific altitude to each filter driver, Windows ensures that drivers operate in the correct sequence, minimizing conflicts and ensuring the integrity of file system operations. Whether you're developing file system tools or managing enterprise-level systems, understanding and properly handling file altitude is crucial for maintaining system stability and security.

Windows Autopilot's Device Preparation is it's new 'user-driven' workflow. Instead of IT staff registering all devices prior to giving them over to staff there's the option for the device to be shipped directly from an OEM to the end-user. With minimal steps—powering the device, selecting locale, connecting to Wi-Fi, and signing in with Microsoft Entra credentials—the system automates the rest. The device automatically joins Microsoft Entra ID, enrolls in Intune, installs key apps, and runs essential scripts, streamlining setup for users while reducing IT workload. Key Features: The device joins Microsoft Entra ID. Intune enrollment with preconfigured policies. Automated installation of up to 10 essential apps and PowerShell scripts. This article covers the configuration steps for setting up Windows Autopilot device preparation using a user-driven Microsoft Entra join workflow. Requirements: Windows 11, version 23H2 with KB5035942 or later. Windows 11, version 22H2 with KB5035942 or later. Enrollment Config - Entra Navigate to Entra with the following URL, allowing users to enroll devices. https://portal.azure.com/#home Then to Device Settings, Microsoft Entra ID > Devices (left hand Window) > Device Settings. Allow 'All' users to join devices Enrollment Config - Intune Now navigate to Intune to configure the MDM User scope. https://intune.microsoft.com/#home Then to, Devices > Enrollment > Automatic Enrollment Select 'All' for the MDM User Scope. User and Device Group A couple of Groups will be required to allow named Users the ability to enroll devices and for the Devices themselves. From within Intune navigate to Groups. Create a Security Group with a name that reflects its purpose eg: AutoPilot_DevicePrepartion_Users. Add named users or all users to this group. Create a 2nd Security Group for devices, don't add any members. Modify the Device Groups Owners. Add the built-in service, provided by Microsoft 'Intune Provisioning Client' as the owner. This will provide the 'Just in Time' rights for device auto enrollment. AutoPilot Device Preparation Navigate to Devices, Windows, Enrollment. Select 'Device Preparation Policies'. Provide a Name. Add the 'AutoPilot_DevicePreparation_Device' Group. Under Configuration Settings leave the defaults. I've added some Apps and scripts, the maximum is 10. For Applications to install the user must be a member of the deployment group. Add the 'AutoPilot_DevicePrepartation_Users' group, these can be users who are part of the IT team that adds devices to Intune or all users. Save Deployment Sign in with an approved account, then sit back while the magic happens Links: https://learn.microsoft.com/en-us/autopilot/device-preparation/tutorial/user-driven/entra-join-device-group

<# .Synopsis Disable Admin Account and Sets Random Password ​ .Description ​ .Version #> #Password length $length = 20 ​ #Minimum number of symbols to use in the password #Do not set to high as this will remove complexity and make passwords easier to compromise $random = 5 ​ #Creates random password $assembly = Add-Type -AssemblyName system.web $randPass = [System.Web.Security.Membership]::GeneratePassword($length,$random) ​ #Var for Administrator Account $admin = "Administrator" ​ #Sets Administrator password net user $admin $randPass /YES #Disable Administrator account net user $admin /active:yes ​

​To set a time server by either IP or fqdn for non-domain joined clients. ​ For instructions on how to deploy from MDT (here) <# .Synopsis Set Time Server for non-domain joined clients (0x8) to fqdn's address ​ .Description ​​ .Version #> ​ Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Parameters' -name NTPServer -Value "pool.ntp.org time.windows.com,0x8 time.google.com,0x8 " -Force ​ ​ <# .Synopsis ​Set Time Server for non-domain joined clients (0x8) to time server IP address ​ .Description ​​ .Version #> Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Parameters' -name NTPServer -Value "192.168.0.10,0x8 192.168.0.11,0x8" -Force

It's standard for applications services to run with System. In many cases, this is excessive and leaves the Operating System vulnerable to escalation attacks particularly if there is an unquoted path or an unpatched vulnerability. ​ The following is a script deployable from MDT or SCCM for use on standalone and domain-joined systems. It's when the service account doesn't require a domain account but benefits from the least privilege and randomized passwords. The script creates a service account without any elevated privileges and adds to the 'Logon as Service' Right and then updates the Windows Service for the targeted application. ​ The password for each svc account is unique to prevent one compromised password from allowing all systems with that account and password combination to be compromised. Passwords are not written out to disk, otherwise its possible recover the files and password with recovery tools. ​ The github script is downloadable from (here) <# .Synopsis Update a Windows Service that is using system to a non-priv user account .Description List the service account name and name of the Windows Service to be updated. ​ Create the User account and strip out Local User group so its not interactive, set a randomized password ​ Update the Service with account and password ​ Export and update User Rights Assignments for the Service Account to have 'Logon as a Service' right .Version #> #List of Service Accounts (svc_) and the application the svc_ will run as a service $svc1 = @{"svc_splunk" = "splunk"} $svc2 = @{"svc_account2" = "Application2"} $svc3 = @{"svc_account3" = "Application3"} ​ $svcUsers = $svc1, $svc2, $svc3 ​ #Create Service Account, randomised password #Find Windows Service and update to use Service account foreach ($svcAcc in $svcUsers) { #Svc Account $svcAccount = $svcAcc.Keys #Application Name $appName = $svcAcc.Values ​ #Password length $length = 12 ​ #Number of random characters $random = 3 ​ #Creates complex random password for each svc account $assembly = Add-Type -AssemblyName system.web $randPass = [System.Web.Security.Membership]::GeneratePassword($length,$random) ​ #Create svc account with randomized password and unable to change own password. net user $svcAccount $randPass /PASSWORDCHG:NO /ADD /YES ​ #remove user group so its a service account and not able to interactively logon net localgroup users $svcAccount /DELETE ​ #if account needs access to read security events, normally if service account event forwards to SIEM if ($svcAccount -eq "svc_splunk") { #add to eventlog users group to read security event logs net localgroup "Event Log Readers" $svcAccount /ADD } #sets password to never expire WMIC useraccount where "Name='$svcAccount'" SET PasswordExpires=FALSE ​ #get the Windows Service based on the name of the listed App $svcName = gwmi Win32_service -Filter "name='$appName'" ​ #Update Windows Service so the svc account and password replace system service $svcNAme.change($null,$null,$null,$null,$null,$false,".\$svcAccount",$randPass) } #Hostname $hn = hostname ​ #Create new folder to export security template to $path = "C:\Logs\Services" New-Item $path -ItemType Directory -Force ​ #Export Security Settings inc User Rights Assignments with secedit.exe secEdit.exe /export /cfg $path\currentTemplate.inf ​ #List the current user account SID's for 'Logon as a service' $logonAsRight = Select-String $path\currentTemplate.inf -Pattern "SEServiceLogonRight" $origSids = $logonAsRight.Line ​ #Create an empty Template Add-Content -Path $path\newTemplate.inf -Value '[Unicode]' Add-Content -Path $path\newTemplate.inf -Value 'unicode=YES' Add-Content -Path $path\newTemplate.inf -Value '[System Access]' Add-Content -Path $path\newTemplate.inf -Value '[Event Audit]' Add-Content -Path $path\newTemplate.inf -Value '[Registry Values]' Add-Content -Path $path\newTemplate.inf -Value '[version]' Add-Content -Path $path\newTemplate.inf -Value 'signature="$CHICAGO$"' Add-Content -Path $path\newTemplate.inf -Value 'Revision=1' Add-Content -Path $path\newTemplate.inf -Value '[Privilege Rights]' ​ #array for new service accounts and their sids $svcSid=@() foreach ($svcAcc in $svcUsers) { #Service Account $svcAcc = $svcAcc.Keys ​ #Application Name for Service $appName = $svcAcc.Values ​ #new object for each service account $objUser = New-Object System.Security.Principal.NTAccount("$hn\$svcAcc") $strSid = $objUser.Translate([System.Security.Principal.SecurityIdentifier]) $svcSid += $strSid.Value } #take original sids and add to new list of sids $sidOld =@() $sidOld += $origSids ​ #combined list of sids foreach ($svc in $svcSid) { $sidCombine += ",*$svc" } ​ #foreach sid add to the newTemplate.inf foreach ($sidIndi in $sidCombine) { Add-Content -Value $sidIndi -Path $path\newTemplate.inf -NoNewline } ​ #Run the SecEdit command to import the all accounts and add to Logon as a Service. secedit.exe /configure /db $path\secEdit.sdb /cfg $path\newTemplate.inf /log $path\newTemplate.log ​

The following tweaks are for disabling network features that are either legacy but still enabled or not required. ​ Each setting can be applied by running an elevated PowerShell directly or deployed from MDT or ConfigMgr. <# .Synopsis ​ .Description If IPv6 isnt deployed on the network should be disabled correctly via the Registry and not by unchecking the IPv6 component in network connections. ​ .Version #> #Disable IPv6 by setting 0xff, do not set fffffff as it slows down bootup New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters' -Name DisabledComponents -PropertyType DWORD -Value 0xff -Force ​ ​ <# .Synopsis Disable LLMNR ​ .Description LLMNR or Responder should be actively disabled as it broadcasts the password hash and account name of the user or service account. Open Run and type '\\server\share' as this is very unlikely to exist the client will query the network by broadcasting on port 5355 containing your account with the password hash. Kali running Responder will pick this up and feed it into 'John the Ripper', ​ Block ports TCP\UDP 5355 both InBound and OutBound ​ Or set 'Turn on Responder (RSPNDR) Driver' to 'Disable' in GPO 'Computer > Policies > Administrative Templates > Network > Link-Layer Topology Discovery' ​ .Version #> #Disabled LLMNR New-Item "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT" -Name DNSClient -ForceNew-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMultiCast -Value 0 -PropertyType DWORD -Force ​ <# .Synopsis Disable both LMHosts and NetBios ​ .Description LMHosts is the legacy file used for name resolution. ​ NetBios is often enabled by default on Windows system but is legacy for SMB and Printer traffic, it can be abused leading to the system being exploited. Port 139 is used by Nbtstat to query for Windows devices. ​ Block ports UDP 137-138 both InBound and OutBound Block ports TCP 139 both InBound and OutBound .Version #> #Disable LMHOSTS File in Network Settings $lmhost = @{ { DNSEnabledForWINSResolution = $false WINSEnableLMHostsLookup = $false } Invoke-CimMethod -ClassName win32_networkadapterconfiguration -methodName enableWins -Arguments $lmhost #Disable NetBios in Network Settings $netbios = Get-ChildItem -Recurse "HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces" | where {$_.property -eq "NetBiosOptions"} foreach ($op in $netbios) { cd hklm: $opPath = $op.Name.Replace("HKEY_LOCAL_MACHINE","HKLM:") Set-ItemProperty $opPath -name NetBiosOptions -Value 2 -Force } ​ ​ ​ <# .Synopsis Disable Universal Plug and Play for network devices ​ .Description uPnP allows devices to discover and share data with other network devices, there is a small risk of this service being abused. Its a small but potential risk, more importantly it's a service that isn't needed, so it's disabled ​ Block port TCP 5000 Inbound Block port UDP 1901 Inbound ​ Stopping 'UPnP Device Host' Windows Service ​ .Version #> #Disable uPnP (Network Discovery) Set-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LLTD" -name AllowLLTDIOOnDomain -Value 0 -Force Set-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LLTD" -name AllowLLTDIOOnPublicNet -Value 0 -Force Set-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LLTD" -name AllowRspndrOnDomain -Value 0 -Force Set-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LLTD" -name AllowRspndrOnPublicNet -Value 0 -Force Set-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LLTD" -name EnableLLTDIO -Value 0 -Force Set-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LLTD" -name EnableRspndr -Value 0 -Force Set-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LLTD" -name ProhibitLLTDIOOnPrivateNet -Value 1 -Force Set-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LLTD" -name ProhibitRspndrOnPrivateNet -Value 1 -Force ​ ​

​There's been a few instances where setting folder permissions is required and I've found the following useful. ​ <# .Synopsis Change FOLDER permission for Authenticated User ​ .Description ​​ .Version #> ​ #Declares Inheritance $inherNone = [System.Security.AccessControl.InheritanceFlags]::None $propNone = [System.Security.AccessControl.PropagationFlags]::None $inherCnIn = [System.Security.AccessControl.InheritanceFlags]::ContainerInherit $propInOn = [System.Security.AccessControl.PropagationFlags]::InheritOnly $inherObIn = [System.Security.AccessControl.InheritanceFlags]::ObjectInherit $propNoPr = [System.Security.AccessControl.PropagationFlags]::NoPropagateInherit #Declare Auth User $user = "Authenticated users" #Path to Folder $path = "C:\SomeFolder" ​ #Return current permissions (get-acl C:\SomeFolder).Access ​ #Removes Inheritance $aclInh = get-acl $path $aclInh.SetAccessRuleProtection($true,$true) Set-Acl $path $aclInh ​ #Remove Permissions $getAcl = Get-Acl $path $fileAcc = New-Object System.Security.AccessControl.FileSystemAccessRule("$User","FULL","$inherCnIn ,$inherObIn","None","Allow") $getAcl.SetAccessRule($fileAcc) $getAcl.removeAccessRuleAll($fileAcc) Set-Acl $path $getAcl #Add Permissions $getAcl = Get-Acl $path $fileAcc = New-Object System.Security.AccessControl.FileSystemAccessRule("$user","READ","$inherCnIn,$inherObIn", "None","Allow") $getAcl.SetAccessRule($fileAcc) Set-Acl $path $getAcl ​ #Add a DENY permission $getAcl = Get-Acl $path $fileAcc = New-Object System.Security.AccessControl.FileSystemAccessRule("$user","READ","$inherCnIn,$inherObIn","None","deny") $getAcl.SetAccessRule($fileAcc) Set-Acl $path $getAcl

Disabling Microsoft Windows Recovery Environment is a good idea because it reduces the risk of malicious software being installed on your computer. It also prevents unauthorized access to system files, which could lead to data loss or corruption. Additionally, disabling this feature helps prevent accidental changes to critical system settings that can cause serious problems and even render your computer unusable. ​ <# .Synopsis Updates Windows Boot and Recovery options ​ .Description Updates Windows Boot and Recovery options to prevent any boot options from being launched during the Windows boot. Windows will boot with a blank screen and provide no recovery options, This is one of a series of mitigations to prevent booting into PXE, Kali or Recovery options to perform attacks against the system. UEFI\BIOS - Update Boot order and remove PXE, USB and CD\DVD Boot Options UEFI\BIOS - Add a complex password to prevent unauthorised changed Bitlocker - Always encrypt the System drive with Bitlocker or alternative full disk encryption. Recovery Partition - Remove Recovery Partition from MDT\ConfigMgr disk configuration Bitlocker should be configured with TPM and Pin to prevent LPC (Low Pin Count) Bus sniffing attack ​​ .Version #> #disables automatic repair options for Windows cmd.exe /c "bcdedit.exe /set {default} recoveryenabled no" ​ #disables Windows Error Recovery screen cmd.exe /c "bcdedit.exe /set {default} BootStatusPolicy IgnoreAllFailures" ​ #disables all UI elements, logo, status, status messages cmd.exe /c "bcdedit.exe /set {default} bootuxdisabled on" #disables advanced startup options (F8) cmd.exe /c "bcdedit.exe /set {default} advancedoptions false" ​ #disables advanced startup option (F10) cmd.exe /c "bcdedit.exe /set {default} optionsedit false" ​​ #sets boot timeout out to zero cmd.exe /c "bcdedit.exe /timeout 0" ​ ​

By disabling Memory Dumps it's no longer possible to recover the dump file and extract secure data that is held in memory in the clear. ​ <# .Synopsis Disables Windows Memory Dumps ​ .Description ​ Disabled Memory Dump to prevent extracting cleat text passwords using WinDbg ​ 0 = None 1 = Complete Memory Dump 2 = Kernel Memory Dump 3 = Small Memory Dump 7 = Automatic Memory Dump (Default) ​ .Version #> Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -name CrashDumpEnabled -Value 0 -Force ​