Search this site

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

Ivanti's Endpoint Protection's Application Control: Ivanti Endpoint Protection is a comprehensive security solution that provides organizations with a comprehensive set of security tools designed to protect their endpoints, networks, and data. It is designed to protect users from the latest threats, such as malware, ransomware, and phishing attacks. It also provides advanced capabilities, such as patch management, application control, and user privilege management. With Ivanti Endpoint Protection, organizations can ensure their endpoints are secure and protected from the latest threats. This article focuses on the initial setup of Ivanti Endpoint Manager and Endpoint Security Application Control, agent deployment and policy. This will provide the bases for the next round of 'verses' articles having thoroughly abused Windows Applocker, WDAC and GPO. The following has been extracted from the Ivanti Endpoint Protection user guide downloadable from (here). Ivanti® Endpoint Manager and Endpoint Security for Endpoint Manager consists of a wide variety of powerful and easy-to-use tools you can use to help manage and protect your Windows, Macintosh, mobile, Linux, and UNIX devices. Endpoint Manager and Security tools are proven to increase end user and IT administrator productivity and efficiencyLANDesk Application control offers the following system-level security: Kernel-level, rule-based file-system protection Registry Protection Startup Control Detection of stealth rootkits Network filtering Process and file/application certification File protection rules that restrict actions that executable programs can perform on specified files The initial Ivanti setup focus's on Ivanti Endpoint Protection's (EP) Application Control to compare and pit against Microsoft's Applocker and WDAC. Ivanti's EP Firewall, Device Control and AV policies won't be configured, although it is capable of providing a full management suite of protections from within a single console. The focus is Ivant EP vs Microsoft's application control, the paid 3rd part tools versus the free inbuilt tools. Ivanti Download: The good news, Ivanti provides 45 day, fully featured trial software, allowing plenty of time for EP to be put through its paces. The bad news, the trial software is not current, the download is for the 2020.1 version and not the latest 2022.2 or higher. A little sub-optimal considering it's for endpoint protection and security. Links to access Ivanti Endpoint Manager 2020.1: 45 day trial sign-up (here). Installation guide (here), Domain with a SQL server is required. Exclaimers: After following the installation guide, Ivanti will require a fair amount of fettling to deploy Application Control in enforcement mode. Remember, it's only for application execution to provide a direct comparison to Applocker and WDAC and a baseline reference for EP configuration. I'm not an Ivanti expert, I've spent a day installing and learning Ivanti. It's expected that the lack of experience with this product results in some ambiguity, I'm not interested in the journey but the net result of trying to exploit Windows with Ivanti Endpoint Protection enabled. Initial Login: Let's get to it...... From the Start Menu launch 'Ivanti Management Console', and enter the account details used during setup. Add LDAP Configuration: To integrate AD, providing search and deployment of policy, agent and software: Click on 'Configuration' in the lower left pane. Right-click on 'Directory' and 'Manage Directory...' 'Add', follow the wizard to include the domain structure using the Domain Admin account. Initial Agent Audit Policy: Initially, the endpoint and its software is unknown and an agent is required to be deployed. Click 'Configuration' in the bottom left windows and then select 'Agent Configuration', then the top left. In the 'Agent Configuration' window, bottom right, right-click and select 'New Windows agent configuration'. Update the 'Agent Configuration': Update 'Configuration Name' with something meaningful. Check the 'Endpoint Security option. Browse and then select 'Endpoint Protection' under 'Distribute and Patch' and then 'Security and Compliance'. Click 'Configure'. Within 'Endpoint Security' check 'Application Control:' and then click on '....' to configure the Application Control policy. Select 'Advanced' under 'Application Protection' and click on 'Learning'. With the initial policy when Ivanti is 'Learning' there is no reason to tempt fate by locking ourselves out of the client. Select 'Learning' for 'Whitelisting'. Save the changes and close both the 'Application Control' and 'Agent Configuration wizards. Agent Deployment: The agent and EP policy has been created and requires deploying to a client. Ivanti Management is fully featured and comes with LANDesk. For those that aren't familiar it's on par with SCCM\MECM. Here's a guide to assist in deploying the Ivanti agent (here). For expedience, I've opted for manual agent deployment. Right-click on the new agent and select 'Advance Agent'. Copy the URL and log on to the Windows 10 or 11 client. Download the .exe and install. Both Windows Defender and SmartScreen GPO's required updating to allow the Ivanti agent to install. Once the agent's installed, launch 'Ivanti Endpoint Security' from the Start Menu for a quick review. Excellent, Application Control and Whitelist learning policies are in effect. In preparation for blocking mode, launch installed applications on the client and run through some user activity. This activity is audited and logged to the Ivanti server for approval. It's time for a long coffee break, the file activity can take a little while to report back to the Ivanti server console. The initial audit results will take a few hours, a full audit will take overnight. Audited Files: With the agent installed the 'Win10-01' client becomes available to manage by right-clicking. Top tip, from Diagnostics its possible to see Ivant client and core logs. To view the audited files select 'Security and Patch' then 'Application Information'. As this is a new installation of Ivanti Endpoint Protection the audited files are classed as 'undecided'. It's not as simple as clicking and then approving the files, this can only be accomplished by updating the 'Agent Configuration' settings. Endpoint Security Policy - Blocking Mode: The agent has been deployed in learning mode, enabling file data collection to be available in the console. At this point, those files require authorising and blocking mode enabling. The easiest method of updating the client from learning to blocking was to update the agent and not just the Endpoint Security policy, having failed repeated attempts. Right-click the 'Agent Deployment - Initial Config', Copy and then Paste, maintaining the original agent settings. Rename the agent configuration to reflect its purpose, 'Agent Deployment - Windows Client Blocking'. Right-click the new agent config, 'Properties'. Navigate to 'Endpoint Security' via 'Distribution and Patch' and then 'Security and Compliance'. Click 'Configure...' and in the 'Configure endpoint security setting' click 'New'. Add a meaningful name to the 'Endpoint Security' wizard. Click on 'Default Policy' and select ... next to the 'Application control' dropdown. Click on 'New...' On the 'General Settings' update the name. Click on 'Application Protection' and check the following: Enable application behaviour protections Prevent master boot record (MBR) encryption Auto detect and blacklist crypto-ransomware Under 'File protection rules' select all the options, not all these options may be suitable for an enterprise, and some trial and error may be required. Under 'Application Protection' click on 'Advanced' and 'Blocking', and remove any checks for 'Learning mode ...' Under 'Whitelisting' check all options and 'Configure' and select all the script options. Scripts will require authorising to work. Again on the 'Advanced' page select 'Blocking' and uncheck 'Learning mode ...' save the changes. Highlight the new policy and then 'Use Selected'. Enable Microsoft * as a trusted signer, under 'Digital Signatures'. As Ivanti is authorising files by hash it seems prudent to trust and thus allow all Microsoft files. Ivanti operates at the kernel level, any file not authorised will be denied including system files, it's reasonable to expect blue bends (BSoD) in this case. Click 'Add...' on the 'Application File List'. Click 'New'. To authorise collected from the client click on the yellow circle with a downward arrow. Click 'Import from other application file lists... ' Check the 'Computer' and select the client. Ctrl + A to highlight all files and right-click, the 'Override reputation...' Enable 'Good'. To ensure that blocking mode is enabled, set CMD.exe's reputation to 'Bad'. Click 'Next', returning to the Application File List. Highlight CMD.exe and then click on the pencil, 'Edit Application Files'. Set the execution from Allow to Block. OK the changes, close the Application File List, returning to the 'Configure Application File Lists'. Highlight the new blocking policy then click 'Use selected'. Update the 'Learning list:' drop down to that of the Win10 approval file list and save the changes. Ensure the 'Machine Configuration' is configured with the new Windows 10 Client Policy and save the changes. Point of note: No Dll's were listed in the authorised file list, from previous testing bypassing application protections can be achieved when dll file types arent protected. Read this (here) where Applocker was successfully bypassed by malware with a DLL file extention. Deploy Agent in Blocking Mode: Click on 'Configuration' in the bottom left pane and then 'Agent Configuration'. In the bottom right pane select 'My Configurations'. Right-click and properties on the 'Agent Deployment - Windows Client Blocking' As the target client already has the agent installed a 'scheduled agent deployment' or 'scheduled update to agent settings' should work. I've opted for the agent deployment, removing the old agent and settings alnd installing the new agent with the new blocking configuration. Click on 'Targets', then 'Targeted Devices', and click on 'Add'. Select the Windows client with the agent installed and ensure the client box is checked. In 'Schedule task', select 'Start Now' and then 'Save'. The Client: Log in to the client and after about 15 minutes the Ivanti agent with the blocking configuring will have been deployed. The client is likely to show that the 'Status' is disabled for all components with 'Application Control' also displaying 'Off'. Reboot the client. After the reboot the agent should show the following: Launching cmd.exe displays the following Ivanti message, cmd is indeed blocked and policy and settings are successfully applied. The process of creating and deploying Ivanti EP is understood and is repeatable. The next step is to test how effective Ivanti EP is at protecting Windows from various Remote Code Exploits, Local Code Exploits and Reverse Shells following the same patterns used testing Applocker and Device Guard (WDAC). To follow shortly......

<# .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 ​

There are 2 methods for hiding the C: or any other drive, GPO and a Regedt32 tweak. ​ There's obvious benefits preventing access to browse the System Drive like being able to Explore to a file and run it. However hiding C: needs to be considered as only part of the solution to prevent access. Its still possible to open PowerShell and cmd then 'cd' without restrictions, create desktop shortcuts to a named file and many others. Even after locking all routes down the audio control icon, assuming the user requires sound control provides a route into browsing the system. ​ There are,It's# .Synopsis Remove access to C: ​ .Description ​ Removes access to the C:\ by setting NoDrives and the value of 4 in the registry or set the User GPO settings 'Prevent access to drives from My Computer'. ​ .Version #> #Hides C for all users including Administrator New-ItemProperty -path 'HKLM:/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/Explorer' -Name NoDrives -PropertyType DWORD -Value 4 ​ #Hides C for the user the setting is applied against. ​ New-ItemProperty -path 'HKCU:/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/Explorer' -Name NoDrives -PropertyType DWORD -Value 4 ​ User GPO Settings ​

Device Guard has the following requirements: Hardware Requirements UEFI Native Mode Windows 10/2016 x64 SLAT and Virtualization Extensions (Intel VT or AMD V) TPM ​ Windows Features Windows Defender Application Guard (Isolation mode prior to 1703) Hyper-V Platform (Not required after 1603) Hyper-V Hypervisor ​ GPO Settings Computer Configuration > Administrative Templates > System > Device Guard Turn on Virtualization Based Security (enable) Secure Boot and DMA Protection Enable Virtualization Based Protection of Code Deploy Code Integrity Policy (enable) C:\DeviceGuard\SIPolicy.p7b ​ (C:\DeviceGuard\SIPolicy.p7b is automatically copied and converted to C:\Windows\System32\Codeintegrity\) ​ From PowerShell execute Invoke-CimMethod -Namespace root/Microsoft/Windows/CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName update -Arguments @{filepath = "C:\Windows\system32\CodeIntegrity\SIPolicy.p7b"} The system will create SIPolicy.p7b and a reboot will enforce Device Guard. ​ To create a Device Guard Policy run the following. ​ <# .Synopsis ​ .Description ​ .Version #> #Sets Working Folder for DG $CIPolicyPath = "C:\DeviceGuard" ​ #C:\DeviceGuard\InitalScan.xml $IntialCIPolicy = $CIPolicyPath+"\initialScan.xml" ​ #C:\DeviceGuard\SIPolicy.p7b $CIPolicyBin = $CIPolicyPath+"\SIPolicy.p7b" ​ #C:\DeviceGuard\CIPolicy.txt - Output from initial policy audit $CIPolicyTxt = $CIPolicyPath+"\CIPolicy.txt" ​ #Creates SIPolicy.p7b based on the IntialCIPolicy.xml New-CIPolicy -Level FilePublisher -Fallback Hash -FilePath $IntialCIPolicy -UserPEs 3> $CIPolicyTxt -ScanPath C:\ ​ #Enforces UMCI Set-RuleOption -FilePath $IntialCIPolicy -Option 0 #Enforcement Mode enabled Set-RuleOption -FilePath $IntialCIPolicy -Option 3 -delete ​ #Converts the audit to a p7b file copies to C:\DeviceGuard\ #GPO is set to move SIPolicy.p7b to C:\Windows\System32\CodeIntegrity ConvertFrom-CIPolicy -XmlFilePath $IntialCIPolicy -BinaryFilePath $CIPolicyBin ​ #Enable DG to enforce Invoke-CimMethod -Namespace root/Microsoft/Windows/CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName update -Arguments @{filepath = "C:\Windows\System32\CodeIntegrity\SIPolicy.p7b"}