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/tomwechsler
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.Advanced 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/tomwechslerUse PowerShell to search for accounts in Active Directory that have gone stale!
Dear Microsoft and Active Directory Friends, In a company/organization, employees come and go. This is completely normal and nothing out of the ordinary. But often, from a technical point of view, the Active Directory is somewhat forgotten and account cleanup is rarely or never done. This means there are outdated or no longer current accounts (ghost accounts). This is not a great situation from either a security or administrative perspective. In this article I would like to show you a possible way. But what exactly does "stale" accounts mean? Let me explain my definition to you: 1. Haven't logged in for X days 2. Hasn't logged in 3. Created at least X days ago We can start first with the CMDLET "Search-ADAccount". This gives once a first result. The #tags are comments. #Using Search-ADAccount Search-ADAccount -AccountInactive -TimeSpan '90.00:00:00' -UsersOnly How many accounts would there be? (Search-ADAccount -AccountInactive -TimeSpan '90.00:00:00' -UsersOnly).count But there are a lot of them. Now let's work with filters. We explicitly examine the "LastLogonTimeStamp" property. For an account that has never been logged in, no value is displayed. #Using a filter Get-ADUser "Freida Lazarus" -Properties LastLogonTimeStamp | Select-Object Name,LastLogonTimeStamp An account that has been used for a login will show a value. This number represents a date, this is in FileTime format. We can generate such value. For example, one hour in the past. $LogonDate = (Get-Date).AddHours(-1).ToFileTime() $LogonDate So, for example, we can check who has not logged in during the last hour. Of course we would not work with only one hour. But I'm going to keep working with this one hour so I can illustrate it to you better. #If it is older than $LogonDate $LogonDate = (Get-Date).AddHours(-1).ToFileTime() Get-ADUser -Filter {LastLogonTimeStamp -lt $LogonDate} Or in numbers it would be so many accounts. Now we search for all accounts that do not have this value. #If it doesn't have value Get-ADUser -Filter {LastLogonTimeStamp -notlike "*"} -Properties LastLogonTimeStamp | Select-Object Name,LastLogonTimeStamp But what if the user has not yet logged in because the account has just been created? Let's take a closer look at this as well. #And if the account was created before $createdDate $createdDate = (Get-Date).AddDays(-14) Get-ADUser -Filter {Created -lt $createdDate} -Properties Created | Select-Object Name,Created Bringing all this together, we can determine what exactly "stale" means to us. #Add them all together: $filter = { ((LastLogonTimeStamp -lt $logonDate) -or (LastLogonTimeStamp -notlike "*")) -and (Created -lt $createdDate) } Get-ADuser -Filter $filter | Select-Object SamAccountName We can create a function from it. Function Get-ADStaleUsers { [cmdletbinding()] Param ( [datetime]$NoLogonSince = (Get-Date).AddDays(-90), [datetime]$CreatedBefore = (Get-Date).AddDays(-14) ) $NoLogonString = $NoLogonSince.ToFileTime() $filter = { ((LastLogonTimeStamp -lt $NoLogonString) -or (LastLogonTimeStamp -notlike "*")) -and (Created -lt $createdBefore) } Write-Host $filter Get-ADuser -Filter $filter } # Usage Get-ADStaleUsers This way we can work with our own values. Moreover, we can delete the accounts directly afterwards or at least check with -WhatIf what exactly would be done! Get-ADStaleUsers -NoLogonSince (Get-Date).AddDays(-30) -CreatedBefore (Get-Date).AddDays(-7) | Remove-ADUser -WhatIf Annotation: In the search result from above two Built-In accounts (e.g.: krbtgt) are displayed among others (this is how it turned out in the search). Such Built-In accounts should never be deactivated or even worse deleted, this has very negative effects on the function of the Active Directory. You should never delete user accounts directly. Instead, the accounts should be disabled for some time first. If the accounts were used for other purposes (unknown to you). You should also avoid setting user accounts as service accounts. This is not according to Microsoft "Best Practice". For service accounts, use the so-called group managed service accounts. I realize that this was not necessarily spectacular. It was simply important for me to share my experience with you. Nevertheless, I hope that this article was helpful. Thank you for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerBLOG: Windows Server / Azure Local keeps setting Live Migration to 1 - here is why
Affected products: Windows Server 2022, Windows Server 2025 Azure Local 21H2, Azure Local 22H2, Azure Local 23H2 Network ATC Dear Community, I have seen numerous reports from customers running Windows Server 2022 servers or Azure Local (Azure Stack HCI) that Live Migration settings are constantly changed to 1 per Hyper-V Host, as mirrored in PowerShell and Hyper-V Host Settings. The customer previously set the value to 4 via PowerShell, so he could prove it was a different value at a certain time. First, I didn't step into intense research why the configuration altered over time, but the stumbled across it, quite accidently, when fetching all parameters of Get-Cluster. According to an article a LCU back in September 2022 changed the default behaviour and allows to specify the live migrations at cluster level. The new live migration default appears to be 1 at cluster level and this forces to change the values on the Hyper-V nodes to 1 accordingly. In contrast to the commandlet documentation, the value is not 2, which would make more sense. Quite unknown, as not documented in the LCU KB5017381 itself, but only referenced in the documentation for the PowerShell commandlet Get-Cluster. Frankly, none of the aren't areas customers nor partners would check quite regularly to spot any of such relevant feature improvements or changes. "Beginning with the 2022-09 Cumulative Update, you can now configure the number of parallel live migrations within a cluster. For more information, see KB5017381 for Windows Server 2022 and KB5017382 for Azure Stack HCI (Azure Local), version 21H2. (Get-Cluster).MaximumParallelMigrations = 2 The example above sets the cluster property MaximumParallelMigrations to a value of 2, limiting the number of live migrations that a cluster node can participate in. Both existing and new cluster nodes inherit this value of 2 because it's a cluster property. Setting the cluster property overrides any values configured using the Set-VMHost command." Network ATC in Azure Local 22H2+ and Windows Server 2025+: When using Network ATC in Windows Server 2025 and Azure Local, it will set the live migration to 1 per default and enforce this across all cluster nodes. Disregarding the Cluster Settings above or Local Hyper-V Settings. To change the number of live migration you can specify a cluster-wide override in Network ATC. Conclusion: The default values for live migration have been changes. The global cluster setting or Network ATC forcing these down to the Hyper-V hosts based on Windows Server 2022+/ Azure Local nodes and ensure consistency. Previously we thought this would happen after using Windows Admin Center (WAC) when opening the WAC cluster settings, but this was not the initial cause. Finding references: Later the day, as my interest grew about this change I found an official announcement. In agreement to another article, on optimizing live migrations, the default value should be 2, but for some reason at most customers, even on fresh installations and clusters, it is set to 1. TLDR: 1. Stop bothering on changing the Livemigration setting manually or PowerShell or DSC / Policy. 2. Today and in future train your muscle memory to change live migration at cluster level with Get-Cluster, or via Network ATC overrides. These will be forced down quite immediately to all nodes and will be automatically corrected if there is any configuration drift on a node. 3. Check and set the live migration value to 2 as per default and follow these recommendations: Optimizing Hyper-V Live Migrations on an Hyperconverged Infrastructure | Microsoft Community Hub Optimizing your Hyper-V hosts | Microsoft Community Hub 4. You can stop blaming WAC or overeager colleagues for changing the LM settings to undesirable values over and over. Starting with Windows Admin Center (WAC) 2306, you can set the Live Migration Settings at cluster level in Cluster > Settings. Happy Clustering! 😀10 hidden Hyper-V features you should know about!
Microsoft added some amazing new features and improvements to Hyper-V over the past few years. A lot of them you can use in Windows Server 2016 Hyper-V today, but there are also a lot of features hidden in the user interface and they are also included in Windows 10 Pro or Enterprise. I think this list should you a good idea about some of them. https://www.thomasmaurer.ch/2017/09/10-hidden-hyper-v-features-you-should-know-about/Add drivers to the Windows Server 2019 ISO Image
In this blog article, I am going to show you how you can add drivers to a Windows Server 2019 ISO Image or WIM file using PowerShell and the DISM module. This will allow you to already have the latest drivers within the Windows Server installation image when you install Windows Server 2019. Find more here: https://www.thomasmaurer.ch/2019/07/add-drivers-to-a-windows-server-2019-iso-image/
Admin accounts which do not have the flag "This account is sensitive and cannot be delegated"
Hi AD Brain trust, I'm currently working on a security assessment for our internal AD environment. One of the item in the report is - Presence of Admin accounts which do not have the flag "This account is sensitive and cannot be delegated": 6 I'm struggling to understand the consequences of setting the flag for admin accounts. If anyone can shed some lights on the implications/recommendations to resolve this detection would be greatly appreciated ! Thank you!
