Accessing trials and kits for Windows Server
Updated May 20, 2022: This issue is now resolved. Please visit the Microsoft Evaluation Center at www.microsoft.com/EvalCenter for access to the latest trials and evaluations for Windows client, Windows Server, and other Microsoft products and kits. As you may have noticed, the Microsoft Evaluation Center is temporarily unavailable. While work is underway to restore this valuable service, you can access Windows Server and Windows client trials, evaluations, and related kits at the links below. Windows Server 180-day evaluations Windows Server 2022 Windows Server 2019 de-de: ISO de-de: ISO en-us: ISO en-us: ISO en-us: VHD en-us: VHD en-us: LOF - ISO en-us: FOD - ISO es-es: ISO es-es: ISO fr-fr: ISO fr-fr: ISO it-it: ISO it-it: ISO ja-jp: ISO ja-jp: ISO ru-ru: ISO ru-ru: ISO zh-cn: ISO zh-cn: ISO Windows Server on Azure Windows Server on Azure Create a Windows Server VM in Azure LOF = language packs and optional features FOD = features on demand Windows Virtual Hardware Lab Kit (VHLK) VHD version VHLK for Windows 11 VHLK for Windows Server 2022 VHLK for Windows 10, version 2004 Windows client 90-day evaluations Windows 11 Enterprise Windows 10 Enterprise Windows 10 Enterprise LTSC de-de: x64 de-de: x64 | x86 de-de: x64 | x86 en-gb: x64 en-gb: x64 | x86 en-gb: x64 | x86 en-us: x64 en-us: x64 | x86 en-us: x64 | x86 es-es: x64 es-es: x64 | x86 es-es: x64 | x86 fr-fr: x64 fr-fr: x64 | x86 fr-fr: x64 | x86 it-it: x64 it-it: x64 | x86 it-it: x64 | x86 ja-jp: x64 ja-jp: x64 | x86 ja-jp: x64 | x86 ko-kr: x64 ko-kr: x64 | x86 ko-kr: x64 | x86 pt-br: x64 pt-br: x64 | x86 pt-br: x64 | x86 zh-cn: x64 zh-cn: x64 | x86 zh-cn: x64 | x86 zh-tw: x64 zh-tw: x64 | x86 zh-tw: x64 | x86 Deployment lab kits Lab kit Windows 11 and Office 365 Deployment Lab Kit (+ lab guides) Windows 10 and Office 365 Deployment Lab Kit (+ lab guides) Note: The Deployment Lab Kits include the 90-day evaluations of Windows 11 or Windows 10 listed above. They are updated every 90 days with a fresh version of the 90-day evaluation software. As a result, please note that the Windows 10 deployment lab kit will be refreshed by May 16 th with a new 90-day evaluation of Windows 10 Enterprise.HOW-TO: Import Out of Band Updates to WSUS using Microsoft Edge Chromium IE Mode and PowerShell
----- I recommend using https://www.powershellgallery.com/packages/Import-WSUSUpdate Full instructions to install the module are located here - https://www.ajtek.ca/blog/the-new-way-to-import-updates-into-wsus/ ----- History: 09/12/2023 - adding PowerShell method to the OP 07/30/2023 - please follow the latest comments for the updated approach using PowerShell. The method in the OP has become obsolete 01/13/2022 - update links and clarification to prevent an error "This update cannot be imported into Windows Server Update Services, because it is not compatible with your version of WSUS", added Troubleshooting and Q&A section. 02/11/2021 - initial version PREREQUISITES: Windows 10 / 11 / Windows Server 2016 or later with WSUS RSAT Tool installed. latest Microsoft Edge installed, version 97 as of time of writing. Internet Explorer (mode) is installed in Settings > Apps > Optional Features or equivalent location in Windows 11 HOW-TO: - Open Edge 97 or later - Open Microsoft Edge Options > Default Browser - Change "Allow Sites to be reloaded in Internet Explorer Mode" to 'Allow' - Add links to add to Microsoft Edge IE Mode - Remove all other links in the scope of *.catalog.update.microsoft.com, only these shall remain for the catalog.update.microsoft.com page. https://catalog.update.microsoft.com/ https://catalog.update.microsoft.com/v7/site/Home.aspx see screenshots below for better illustration. - Close Edge and all catalog tabs if there were any open, especially if you use "Open tabs from the previous session" feature - Open WSUS MMC and right click Updates from the tree > Import Updates - The link in Edge should open in IE mode, there are several indicators on this the open tab to point to https://catalog.update.microsoft.com/v7/site/Home.aspx?SKU=WSUS&Version=10.0.xxxxx.xxxx&ServerName=YOURSERVER.CONTOSO.LOCAL&PortNumber=8531&Ssl=True&Protocol=1.20 NOTES 1.When the link opened in importing updates from WSUS MMC does not contain the "v7/site/" part or does contain a https://www.update instead of https://catalog.update your configuration is wrong. 2. The "Default" setting will not be sufficient to allow the installation and use of the ActiveX plugin. Go back to your update catalog tab, Install the ActiveX if you have not done on this box already. Check if you have not setup restrictions to execute or install ActiveX plugins in IE directly or via group policy. 3. Edge now has the ability to an IE Mode button. Also it has a new feature to automatically add pages to the exception list. Do not use this ability as shown in the picture for this use case as it might add wrong exceptions to the list. 4. When there are wrong exceptions in the exception list for IE mode it might not work correctly and cause a missing but very important redirection, which ultimately cause the import to fail. More troubleshooting assistance below. LINKS STARTING FROM DECEMBER 2021 / JANUARY 2022: Links to add to Microsoft Edge IE Mode https://catalog.update.microsoft.com/ https://catalog.update.microsoft.com/v7/site/Home.aspx TROUBLESHOOTING: Q 1: Microsoft Edge does not allow me to configure any IE Site Mode links (greyed out). A: Either you have not enabled "Allow Sites to be reloaded in Internet Explorer Mode" to 'Allow', or your enterprise has set policies to prevent that. This should be clearly indicated by a lock and message in the Edge settings tab. Q 2: I have followed this guide or a previous version. I can see the cart to import into WSUS but cannot import any or just specific updates. Others fail with a message "This update cannot be imported into Windows Server Update Services, because it is not compatible with your version of WSUS". A: This is a "known" issue and the guide has been updated to reflect this issue and a potential change on the server-side. Please make sure only the two links are included in your IE mode list. They may not include www in the link name. You need to include both links, not just one or the other as in the previous version of this guide. Q 3: May I use the new Edge feature in Settings > Appearance > Internet Explorer Mode button A: I would recommend to refrain using this feature, as the mechanism between WSUS update import and the browser is extremly picky. It would not work if you just copy the same link into a browser tab. The feature of the cart to import into WSUS will be likely missing and you can just download to the Download folder instead. Q 4: Edge offers me to restart this tab in IE mode next time. A: you should not receive this message, otherwise the exceptions as stated in the guide are invalid or you have more than the stated links in place. Go through the guide again and double-check. Do not use this otherwise nice feature. It will cause to add more catalog links to the exception list which will cause an issue to import updates to WSUS, as described in Q #2. Thanks for the hint Eric_VanAelstyn, thanks to abbodi1406 for additional hints after this guide got invalid a redirection change in December 2021 / January 2022. cc AriaUpdated MissyQ cc for the other teams as I did not want to repost it in Edge and Servicing communities, unless you insist 🙂Active Directory Advanced Threat Hunting - Tracing the cause of account lockouts and password errors
Dear Microsoft Active Directory friends, In this article we are going on a "search for clues" :-). In the life of an IT administrator, you have certainly often had to reset a user's password or remove an account lockout. Now the question arises on which system the account was locked or on which system the password was entered incorrectly. In order to determine this information with PowerShell, some preparations must be made. "Advanced Audit Policy Configuration" must be configured in the group policies. This article from Microsoft provides a good starting point: https://learn.microsoft.com/en-us/defender-for-identity/deploy/event-collection-overview In my example, I have adapted the Default Domain Controls Policy. Before we begin, here is some important information about MITRE techniques: Account Access Removal: https://attack.mitre.org/techniques/T1531/ User Account: https://attack.mitre.org/datasources/DS0002/ Brute Force: Password Spraying: https://attack.mitre.org/techniques/T1110/003/ Account lockouts are logged in the Windows event logs with the ID 4740. We will therefore focus on this event ID first. The start of the PowerShell script looks like this: #Prep work for lockouts, Account lockout Event ID $LockOutID = 4740 #Find the PDC (Get-ADDomain).PDCEmulator $PDCEmulator = (Get-ADDomain).PDCEmulator #Connect to the PDC Enter-PSSession -ComputerName $PDCEmulator #Query event log Get-WinEvent -ComputerName $PDCEmulator -FilterHashtable @{ LogName = 'Security' ID = $LockOutID } #Parse the event and assign to a variable $events = Get-WinEvent -ComputerName $PDCEmulator -FilterHashtable @{ LogName = 'Security' ID = $LockOutID } #Examine some properties $events[0].Message #Regex? $events[0].Message -match 'Caller Computer Name:\s+(?<caller>[^\s]+)' $Matches.caller #Cool, but not as easy as: $events[0].Properties $events[0].Properties[1].Value #For all events: ForEach($event in $events){ [pscustomobject]@{ UserName = $event.Properties[0].Value CallerComputer = $event.Properties[1].Value TimeStamp = $event.TimeCreated } } #And we'll make that a function Function Get-ADUserLockouts { [CmdletBinding( DefaultParameterSetName = 'All' )] Param ( [Parameter( ValueFromPipeline = $true, ParameterSetName = 'ByUser' )] [Microsoft.ActiveDirectory.Management.ADUser]$Identity ) Begin{ $LockOutID = 4740 $PDCEmulator = (Get-ADDomain).PDCEmulator } Process { If($PSCmdlet.ParameterSetName -eq 'All'){ #Query event log $events = Get-WinEvent -ComputerName $PDCEmulator -FilterHashtable @{ LogName = 'Security' ID = $LockOutID } }ElseIf($PSCmdlet.ParameterSetName -eq 'ByUser'){ $user = Get-ADUser $Identity #Query event log $events = Get-WinEvent -ComputerName $PDCEmulator -FilterHashtable @{ LogName = 'Security' ID = $LockOutID } | Where-Object {$_.Properties[0].Value -eq $user.SamAccountName} } ForEach($event in $events){ [pscustomobject]@{ UserName = $event.Properties[0].Value CallerComputer = $event.Properties[1].Value TimeStamp = $event.TimeCreated } } } End{} } #Usage Get-ADUserLockouts #Single user Get-ADUser 'jesse.pinkman' | Get-ADUserLockouts Now we come to the incorrectly entered passwords. These events are logged in the Windows event logs with the ID 4625. #Prep work for bad passwords - Event ID $badPwId = 4625 #Get the events from the PDC $events = Get-WinEvent -ComputerName $PDCEmulator -FilterHashtable @{ LogName = 'Security' ID = $badPwId } #Correlate the logon types $LogonType = @{ '2' = 'Interactive' '3' = 'Network' '4' = 'Batch' '5' = 'Service' '7' = 'Unlock' '8' = 'Networkcleartext' '9' = 'NewCredentials' '10' = 'RemoteInteractive' '11' = 'CachedInteractive' } #Format the properties ForEach($event in $events){ [pscustomobject]@{ TargetAccount = $event.properties.Value[5] LogonType = $LogonType["$($event.properties.Value[10])"] CallingComputer = $event.Properties.Value[13] IPAddress = $event.Properties.Value[19] TimeStamp = $event.TimeCreated } } #Bring it all together in a function Function Get-ADUserBadPasswords { [CmdletBinding( DefaultParameterSetName = 'All' )] Param ( [Parameter( ValueFromPipeline = $true, ParameterSetName = 'ByUser' )] [Microsoft.ActiveDirectory.Management.ADUser]$Identity ) Begin { $badPwId = 4625 $PDCEmulator = (Get-ADDomain).PDCEmulator $LogonType = @{ '2' = 'Interactive' '3' = 'Network' '4' = 'Batch' '5' = 'Service' '7' = 'Unlock' '8' = 'Networkcleartext' '9' = 'NewCredentials' '10' = 'RemoteInteractive' '11' = 'CachedInteractive' } } Process { If($PSCmdlet.ParameterSetName -eq 'All'){ #Query event log $events = Get-WinEvent -ComputerName $PDCEmulator -FilterHashtable @{ LogName = 'Security' ID = $badPwId } }ElseIf($PSCmdlet.ParameterSetName -eq 'ByUser'){ $user = Get-ADUser $Identity #Query event log $events = Get-WinEvent -ComputerName $PDCEmulator -FilterHashtable @{ LogName = 'Security' ID = $badPwId } | Where-Object {$_.Properties[5].Value -eq $user.SamAccountName} } ForEach($event in $events){ [pscustomobject]@{ TargetAccount = $event.properties.Value[5] LogonType = $LogonType["$($event.properties.Value[10])"] CallingComputer = $event.Properties.Value[13] IPAddress = $event.Properties.Value[19] TimeStamp = $event.TimeCreated } } } End{} } #Usage Get-ADUserBadPasswords | Format-Table #Single account Get-ADUser administrator | Get-ADUserBadPasswords | Format-Table I hope that this information is helpful to you and that you have been given a good "little" foundation. This article/information is by no means complete and exhaustive. But I still hope that this information is helpful to you. Thank you for taking the time to read the article. Happy Hunting, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerBypass LBFO Teaming deprecation on Hyper-V and Windows Server 2022
Starting with Windows Server 1903 and 1909, Hyper-V virtual switches on an LBFO-type network adapter cluster are deprecated (see documentation). The technology remains supported, but it will not evolve. It is recommended to create an aggregate of type SET. In practice The SET is a very interesting technology that has some constraints. The interfaces used must have identical characteristics: Manufacturer Model Link speed Configuration Even if these constraints do not seem huge, we are very far from the flexibility of LBFO Teaming. As a reminder, this one has absolutely no constraints. In practice the SET is recommended with network interfaces of 10Gb or more. Therefore, we are very far from the target of the LBFO (use of all integrated boards with motherboard pro, Home Lab, refurbish). If SET cannot be used As of Windows Server 2022, it is not possible to use the Hyper-V Management Console to create a virtual switch with LBFO, as it will prompt an error saying that LBFO have been depreciated. However, it is possible to use PowerShell to create this virtual switch. First, create the Teaming of your network cards using the Server Manager, in my case the teaming will be with LACP mode and Dynamic load balancing mode. Then execute the below PowerShell Command to create the virtual switch based on the teaming created in the previous step: New-VMSwitch -Name "LAN" -NetAdapterName "LINK-AGGREGATION" -AllowNetLbfoTeams $true -AllowManagementOS $true In detail: The virtual switch will be named "LAN" The network adapter cluster teaming is named "LINK-AGGREGATION" The aggregate remains usable to access the Hyper-V host. You will see your network teaming up and running on Hyper-V host. Thats it!Server 2022 KMS host key bug; Can't activate Win10 Enterprise LTSB/LTSC
We recently dropped our new Server 2022 KMS host key onto our KMS server. After the necessary update to accept the 2022 key and activating the new 2022 host key, we were able to activate our most common OS types in a quick test afterward -- Win10 Education 21H1, Server 2022, Server 2019, etc. In the next few days, and even more today, we've been getting reports that Win10 Enterprise LTSB/LTSC across some signage devices and laboratory machines stopped activating. Sure enough, I could reproduce the issue from a known good network. Just this morning I spun up entirely fresh VMs and verified all the above is still reproducible with the following results: Windows Server 2022 = Successfully activated Windows Server 2019 = Successfully activated Windows Server 2016 = Successfully activated Windows 10 Education 21H1 = Successfully activated Windows 10 Enterprise LTSC 2021 = FAILED ACTIVATION (0xC004F074: License server reported that the computer could not be activated.) Windows 10 Enterprise LTSC 2019 = FAILED ACTIVATION (0xC004F074: License server reported that the computer could not be activated.) Windows 10 Enterprise 2016 LTSB = FAILED ACTIVATION (0xC004F074: License server reported that the computer could not be activated.) Windows 10 Enterprise 2015 LTSB = Successfully activated (odd, after the previous two) Windows 8.1 Enterprise = Successfully activated Windows 7 Enterprise = Successfully activated Anyone else seeing this or could possibly test and confirm? I feel like this **has** to be a bug with 2022 host keys, but it's so new that I can't find anyone else in the same boat. I have a Premier ticket open for this.
Hostname Character Limit
Still being limited to 15 characters for hostnames in 2019 is very upsetting. In an age where we are deploying servers in multiple data centres, whether that be on premise or in the cloud and having multiple environments as well means trying to come up with sensible hostnames in just 15 characters is basically impossible. I’m sure I am not the only person who is frustrated by this limit and would very much like it if Microsoft was to revisit this limit and increase it to bring it in line with the wonderful limit our Linux friends enjoy.
Windows Server OSConfig and DSCv3
Introduction I wanted to formalize putting a post out here to get some discussion going on the attempts at modernization of Windows configuration, and importantly, infrastructure-as-code. Hopefully this is a healthy discussion that others can engage in. Much of what I'm going to try and post about is stuff we already are aware of, but I want to highlight how this is an ongoing concern with the Windows Server platform that makes it difficult to encourage people to even consider Windows in their environment other than for extremely legacy purposes. I want Windows Server to be the best it can be, and I encourage others to join in on the conversation! Problem Statement Windows Server needs a modernized configuration-as-code system. Must be capable of orchestrating without cloud tools (offline orchestration) Must provide for regular validation and attestation Ideally should be easily available to 3rd party configuration tools. Since Microsoft appears to have little interest in building their own modernized system that isn't Azure-based, this means that this MUST be orchestrated easily and securely by 3rd party tools. Should be as robust as GPO at maintaining and enforcing state. Security configurations in Windows are a right pain to manage with any 3rd party tooling, with the closest coming to it being the SecurityDSC module which wraps secedit.exe and security policy INFs. Why is OSConfig not the answer? OSConfig doesn't provide for me, as an engineer, to clearly define what the state of my machines are based on my company's business requirements. While the built-in Microsoft policy recommendations are great, there are reasons to deviate from these policies in a predictable and idempotent manner. Applying an OSConfig Baseline -> Then changing settings as-needed with special PowerShell commands This is not the answer. This is a bunch of imperative code that serves nobody. And it makes implementing this feature extremely challenging in today's modern world of Kubernetes, Docker, etc. I encourage the Windows Server team to engage with the PowerShell team on DSC 3.0. I think that team has it right, but they are a small group of people and do not have the resources to implement everything that would make DSC 3.0 a first-class configuration as code platform on Windows. And this is where the Windows team should come in. Steve Lee and crew have done a bangup job working on DSC 3.0, including taking feedback from folks to leverage Azure Bicep language for configuration. Security Policy Challenge The way to access security policies need to change. Even if I were to take DSC 3.0 I'd end up having to create a similar security policy INF file to import into Windows. It just seems so silly to me to have to write all of that out when Windows really should just provide an interface for doing this. In fact, security policy remains to be one of the largest problems to getting a good platform stood up. Windows Firewall Policy and GPO - The reason why host-based firewalling is painful to manage at scale in a Windows environment. GPO is definitely not the right place to be managing Windows firewall policy at scale. Particularly when you often have a core set of management rules you want to implement and application-specific needs. Making robust changes becomes a challenge since each policy is separate, preventing you from doing things like inheriting rules for higher level policies. While this is an inherent limitation of Group Policy, it highlights the need to get off of GPO as the core policy configuration tool for Windows. My recommendations I'd like for the Windows team to implement DSC 3.0-compatible resources for managing all core functionality of Windows. If you can do it in a GPO, you should be able to do it with Configuration as Code. Please stop relying on the community to make this work. All of this should be first party to the platform itself. Furthermore, I'd like to recommend that Microsoft either work with 3rd party configuration systems (Chef, Ansible, Puppet, Octopus, etc.) OR to also provide a way to hit the ground running. Perhaps something that integrates visually into Windows Admin Center would be nice. Conclusion This is a huge problem in the Windows world and continues to seem to fall on some deaf ears somewhere in the organization. While I no doubt am confident that the engineers on all of these teams very well know these issues and maybe even have discussed fixing them, clearly there's a breakdown somewhere.Active Directory Advanced Threat Hunting - Compare GPOs with the Security Compliance Toolkit
Dear Microsoft Active Directory friends, Even in the age of digital transformation, group policy settings (still) play a crucial role in maintaining network security and compliance. Advanced Hunting, an advanced technique for monitoring and analyzing these settings, is an indispensable tool for administrators. This method makes it possible to gain in-depth insights into the configuration and security situation of Windows networks. By using specific tools and scripts, professionals can detect security vulnerabilities, identify configuration errors and ensure that all group policies meet the highest security and compliance requirements. This article introduces the concept of Advanced Hunting for Group Policy settings and how it can transform management and security in IT infrastructures. Do we now need additional software and/or expensive tools? No, all we need is a little time, curiosity and the "Security Compliance Toolkit", which Microsoft is making available to us free of charge (thanks to Microsoft at this point). But first let's take a closer look at the MITRE techniques and the relevant Windows Event IDs. Before we start analyzing the group policy settings. We start with a list of MITRE techniques: Domain Policy Modification https://attack.mitre.org/techniques/T1484/ Domain Policy Modification: Group Policy Modification https://attack.mitre.org/techniques/T1484/001/ Group Policy Discovery https://attack.mitre.org/techniques/T1615/ Domain Policy Modification: Domain Trust Modification https://attack.mitre.org/techniques/T1484/002/ Unsecured Credentials: Group Policy Preferences https://attack.mitre.org/techniques/T1552/006/ The Windows Event ID's for the MITRE techniques: Domain Policy Modification 4739(S): Domain Policy was changed https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4739 Group Policy Discovery Appendix L: Events to Monitor https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor Domain Policy Modification: Domain Trust Modification 4716(S): Trusted domain information was modified https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4716 Compare the Default Domain Controllers Policy with the security baselines using the Policy Analyzer! So that we can compare the Default Domain Controllers Policy, we create a backup: Security Compliance Toolkit and Baselines can be downloaded here: https://www.microsoft.com/en-us/download/details.aspx?id=55319 We need the necessary tools and baselines: Extract the files: From the Windows-Server-2022-Security-Baseline-FINAL folder, copy the following file: Paste the file in the Policy Analyzer folder: Open the Policy Analyzer: NOTE: If you have a low screen resolution you may not be able to see the bottom part of the application. It is important that you see the bottom part so that you can adjust the path to the policy rule sets (see red marker). Now we have to add the default domain controller policy: Click on the import button: Give it a name and then click on safe: Now you can compare the policy with the security baseline: HAPPY COMPARING! If you want to examine your Active Directory with PowerShell, you will find a "small" compilation of various PowerShell scripts in the following link: https://github.com/tomwechsler/Active_Directory_Advanced_Threat_Hunting/tree/main/PowerShell NOTE: Before using these scripts, make sure that you have the necessary authorizations. This should always be in writing. Although the scripts do not change any settings or manipulate the system, it is your responsibility how you use these scripts! I hope that this information is helpful to you and that you have been given a good "little" foundation. This article/information is by no means complete and exhaustive. But I still hope that this information is helpful to you. Thank you for taking the time to read the article. Happy Comparing and Hunting, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerAdvanced threat hunting within Active Directory Domain Services - Knowledge is power!
Dear Microsoft Active Directory friends, What is this article about? Showing attacks, compromising domain controllers or even introducing and showing hacking tools? NO. It is about giving you a jump start on how to gather targeted information about attacks and threats in your Active Directory. Is this also a complete and accomplished listing, again no. But my goal is to give you a solid foundation to build on. Let's start with the different event ID's from the event viewer. This assumes, of course, that extended logging has been configured on your domain controllers. If not, this should definitely be done immediately. Event logs are best examined in a SIEM (Security Information and Event Management). Such a tool is not always available, which makes finding information somewhat more difficult. Event ID 4769 Search for attacks from user accounts used as service accounts (search for service accounts - with a login on a client system - IP address). https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769 Search for computer with "Trusted for Delegation": Get-ADComputer -Filter {TrustedforDelegation -eq $true} (Domaincontroller's are not interesting) Best practices: There's no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It's only relevant on domain controllers and stand-alone devices https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation Event ID 4624 Successful logins (search for users/service accounts that have logged in to systems that are TrustedforDelegation). https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4624 In ADUC (Active Directory Users and Computers) search in the properties of a user account in the Account tab, for "Account is sensitive and cannot be delegated". Not even the administrator has this configured by default. Sensitive accounts should be configured with this option. Event ID 4624 Type 3 - Network Logon (searching for logons from remote systems) Event ID 4611 (often generated by mimikatz) A trusted logon process has been registered with the local System authority. https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4611 Event ID 4673 (often generated by mimikatz) When the tool tries to assign itself missing permissions. https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4673 Event ID 4675 - SIDs were filtered https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4675 Note: If you have a SIEM at your disposal, just search for "mimikatz or rebeus" maybe the names of the tools were not changed because the attacker was too lazy. Note: Install Sysinternals "sysmon" for detailed information https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon Protected Accounts and Groups in Active Directory Adminsdholder: The purpose of the AdminSDHolder object is to provide "template" permissions for the protected accounts and groups in the domain. AdminSDHolder is automatically created as an object in the System container of every Active Directory domain. Its path is: CN=AdminSDHolder,CN=System,DC=<domain_component>,DC=<domain_component>?. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory SDProp: SDProp is a process that runs every 60 minutes (by default) on the domain controller that holds the domain's PDC Emulator (PDCE). SDProp compares the permissions on the domain's AdminSDHolder object with the permissions on the protected accounts and groups in the domain. If the permissions on any of the protected accounts and groups do not match the permissions on the AdminSDHolder object, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory Securable objects use an access mask format in which the four high-order bits specify generic access rights. Each type of securable object maps these bits to a set of its standard and object-specific access rights. GenericAll - Full rights to the object (add users to a group or reset user's password) https://learn.microsoft.com/en-us/windows/win32/secauthz/generic-access-rights Let's let pictures do the talking at this point. Take a closer look at the "Dom" user account. This account has no elevated privileges, BUT a "GenericAll" connection. Now please take a close look at the following pictures. net group "domain admins" dom /add /domain Add-ADGroupMember -Identity "domain admins" -Members dom Using powerview: Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"} Event ID 5136 (However, domain controllers must be configured to record this event.) A directory service object was modified https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5136 In ADUC and ADSI Edit under System, examine the AdminSDHolder object. If necessary, you should restore the permissions. The user "Dom" could add himself to the group "Domain Admins" because the security properties of AdminSDHolder were manipulated. Another topic is group policies. Examine the group policies in particular the permissions of the group policies. Get-GPO -All Get-GPPermission „nameofgpo“ -All How to give users access to Group Policy Objects: https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/give-users-access-group-policy-objects The next topic is SID History. Security assessment: Unsecure SID History attributes SID History: Get-ADUser -Filter * -Properties cn,memberof,sidhistory Get-ADUser -Properties sidhistory,memberof -Filter {sidhistory -like '*'} https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-unsecure-sid-history-attribute DCSync is a legitimate Active Directory feature that domain controllers only use for replicating changes, but illegitimate security principals can also use it. Event ID 4662 An operation was performed on an object. https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662 Domain controller synchronization, looking for the following GUIDs: ("1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" or "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" or "89e95b76-444d-4c62-991a-0facbeda640c") https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1522b774-6464-41a3-87a5-1e5633c3fbbb Do you know all your domain controllers? If yes, no synchronization should have been started that does not originate from a domain controller. The synchronization should be executed only between the DC's you know. (The exception may be Azure AD Connect - this service generates similar events). Look for a synchronization that was not started by a domain controller. I hope that this information is helpful to you and that you have received a good "little" foundation. This is certainly not an exhaustive list. But I still hope that this information is helpful for you. Thank you for taking the time to read the article. Happy Hunting, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechsler
