Over the summer, I rebuilt my Active Directory lab environment with multiple regional domains. Instead of manually configuring common issues, I decided to create a PowerShell script to do this for me.
Sep 16 2025
Detecting Active Directory Password Spraying Article
I recently published an article on the TrustedSec blog site called “Detecting Active Directory Password-Spraying with a Honeypot Account“. This article describes how to use an Active Directory honeypot account in order to detect Password Spraying.
Read the article here:
https://trustedsec.com/blog/detecting-password-spraying-with-a-honeypot-account
Sep 15 2025
Active Directory Security Tip #3: Computer Accounts
Active Directory computers should be reviewed about once a year. Old operating systems can hold back security progress like keeping SMBv1 and NTLMv1 active. Inactive computers should be discovered and disabled when no longer in use (and eventually removed).
The OperatingSystem & PasswordLastSet attributes are self-explanatory, though we can use the LastLogonDate which represents the last reboot of the computer. The computer password should change every ~30 days by default. We can correlate the PasswordLastSet & LastLogonDate attribute values to determine if a computer is active or not. A blank LastLogonDate value means the computer object is just that and not associated with an actual system.
Computer Password Information
PowerShell code (using the Active Directory PowerShell module):
$Domain = $env:userdnsdomain
$DomainDC = (Get-ADDomainController -Discover -DomainName $Domain).Name
Get-ADComputer -filter * -Prop name,OperatingSystem,LastLogonDate,PasswordLastSet -Server $DomainDC | sort OperatingSystem | select name,OperatingSystem,LastLogonDate,PasswordLastSetSep 15 2025
Active Directory Forest & Domain Levels
An important Active Directory setting determines what security capabilities are available which relates to the level of the forest and/or domain. This post collects the relevant capabilities of Windows domain and forest functional levels.
Continue readingSep 14 2025
Active Directory Security Tip #2: Active Directory User Accounts
There are several different types of user accounts – at least how they are used. There are standard user accounts, service accounts, and admin accounts.
There are numerous user account settings that can make them vulnerable. These configurations include:
- Inactive – account has not logged on or changed the password in over 180 days which may flag this account as inactive/stale – Accounts known to be inactive should be disabled.
- Reversible encryption – effectively clear-text on DCs – there’s no reason for this to be set.
- Password not required – account may not have an associated password – possibly set by provisioning system – There’s no reason for this to be set. * Password never expires – password very likely to be old – should not be set on standard user accounts.
- Kerberos DES encryption enabled – DES is a weaker encryption method which enables faster password brute-forcing. There’s no reason for this to be set.
- Account does not require Kerberos pre-authentication – enables a trivial attack method for discovering the account’s password (AS-REProasting). May have been set for a compatibility issue with an application. Kerberos pre-authentication should always be required.
- Account cannot change password – password may not change. Standard user accounts should not have this set. Attackers will look for these configurations, so best to review and adjust regularly. Admin accounts and service accounts require additional protection above and beyond standard user accounts.
PowerShell code (using Active Directory PowerShell module):
https://github.com/PyroTek3/Misc/blob/main/Get-VulnerableUserAccounts.ps1
Sep 12 2025
Active Directory Security Tip #1: Active Directory Admins
A critical part of Active Directory security is regularly reviewing your AD admins. The simplest way to do this is to recursively enumerate the membership of the domain Administrators group (that group’s members and all member group members).
Check the AD Admins output for the following:
- Are all the admin accounts associated with people expected?
- Are there service accounts that shouldn’t require AD admin rights (VMware, Exchange, LDAP, VPN, Sharepoint, etc.)?
- Are the associated passwords current?
- Are they as expected with no outliers (all within 2 years but one has a password that’s 10 years old)?
- Has the default domain Administrator account logged on recently?
- Is that expected/known?
- Are all accounts enabled?
- Disabled accounts should be removed from being an AD Admin.
- Do all accounts require Kerberos preauthentication?
- They must if they are AD admins.
- Do any use Kerberos DES?
- If so fix that.
- Are any set to never expire their password?
- Is that expected?
- Accounts with this set rarely change their password.
- Are there any passwords in Active Directory user attributes (commonly description notes/info, Exchange custom attributes, etc.)?
- Practically all of the attributes are visible to users.
PowerShell code (using Active Directory PowerShell modules):
https://github.com/PyroTek3/Misc/blob/main/Get-ADAdmins.ps1
Aug 18 2025
The Art of the Honeypot Account: Making the Unusual Look Normal
This article was originally posted on the Trimarc Content Hub on August 6, 2020.
Updated here with authentication PowerShell code on August 18, 2025. ADSecurity.org is the new home for this article and all updates will occur here.
I have had the idea for a post describing how to best create a honeypot (or honeytoken) account for many years and only recently gained enough clarity around how to format and structure such an article for it to be useful. Shout-out to Carlos Perez (@Carlos_Perez) for a recent chat about Kerberoasting and the Detecting Kerberoast article I posted a while back which got me thinking enough about this to start writing.
This article covers how to create accounts used as honeypots (or honeytokens) that look like they provide something an attacker wants (access), but ultimately provides something the defender wants (detection). The focus is making honeypot accounts look normal and “real” in Active Directory and this premise should be somewhat portable to other systems.
AD Recon 101
I have previously covered AD recon in presentations (DEF CON 2016: Beyond the MCSE, Red-Teaming Active Directory), but provide expanded detail here focused on privileged AD account recon. When an attacker is performing reconnaissance of Active Directory, there are a few key items to review:
- Identify Privileged Accounts
- Identify Privileged Accounts with Old Passwords
- Identify Privileged Accounts with Kerberos Service Principal Names (SPNs)
- Identify Privileged Accounts with Network Sessions on Regular Workstations
In most Active Directory environments, we can scan the AD forest for all of these as a regular AD user (and in some cases without valid AD credentials).
1. Identify Privileged Accounts
Let’s start with #1. We can either recursively enumerate the Administrators group in every domain in the AD forest or we can scan all AD user accounts in each domain that have the user attribute “AdminCount” set to 1. I presented about how useful the AdminCount attribute can be in 2015 (DerbyCon – “Red vs Blue Active Directory Attack & Defense”).
The AdminCount attribute is automatically set to 1 on any AD accounts that are added to privileged AD groups such as Administrators, Domain Admins, Enterprise Admins, etc. The limiting factor in the usefulness of this technique is that we may also find accounts that used to be in a privileged AD group but no longer a member. This means that scanning for AD accounts with AdminCount=1 provides a quick list of potentially privileged accounts (without group enumeration).
Continue readingAug 18 2025
Detecting Password Spraying with Security Event Auditing
This article was originally posted on the Trimarc Content Hub on February 10, 2017.
A common method attackers leverage as well as many penetration testers and Red Teamers is called “password spraying”. Password spraying is interesting because it’s automated password guessing. This automated password guessing against all users typically avoids account lockout since the logon attempts with a specific password are performed against against every user and not one specific one which is what account lockout was designed to defeat. The attacker starts with a list list of passwords they’re going to try which starts with the most likely passwords (“Fall2017”, “Winter2018”, etc).
I spoke about password spraying and how to detect it at BSides Charm 2017 in my talk “Detecting the Elusive: Active Directory Threat Hunting” (Slides & Video are available).
When password spraying begins, we start with the first password in the list. That first password is used in an attempt to authenticate as every user in Active Directory. This one password is attempted against each AD user and once all users have been tested with that password, we move on to the next one.
Since the Active Directory user lockout threshold is 5, we can try 4 different passwords for every user. Then we wait for >30 minutes (lockoutobservationwindow where the DCs keep the lockout count, after this it resets to 0), and try again. It’s trivial to gather the information about the AD environment’s password policy and have the password spraying tool automatically adjust to them.
Graphic shows the Domain Password Policy for the lab domain environment using the AD PowerShell cmdlet Get-ADDefaultDomainPasswordPolicy cmdlet.
This works most of the time because users have bad passwords (especially if the password policy includes a password minimum of <10 characters). Often password spraying connects to an SMB share or a network service, so let’s start with connections to the PDC’s netlogon share (\\PDC\NETLOGON) which is common on many networks. After password spraying has run for a while, we have discovered many user passwords, which may also include privileged accounts.
Continue readingAug 10 2025
Entra & Azure Elevated Access Revisited
In early 2020, I published an article on how a Global Administrator could gain control of Azure resources, that no one would know about it, and how this access would persist even after removing them from Global Administrator.
From that article:
“While Azure leverages Azure Active Directory for some things, Azure AD roles don’t directly affect Azure (or Azure RBAC) typically. This article details a known configuration (at least to those who have dug into Azure AD configuration options) where it’s possible for a Global Administrator (aka Company Administrator) in Azure Active Directory to gain control of Azure through a tenant option. This is “by design” as a “break-glass” (emergency) option that can be used to (re)gain Azure admin rights if such access is lost. In this post I explore the danger associated with this option how it is currently configured (as of May 2020). The key takeaway here is that if you don’t carefully protect and control Global Administrator role membership and associated accounts, you could lose positive control of systems hosted in all Azure subscriptions as well as Office 365 service data.”
Elevated Access
There is a switch that can be flipped from “No” to “Yes” that allows a Global Administrator to gain “manage access to all Azure subscriptions and management groups in this directory”. Flipping this switch to Yes adds the current user to the Azure role User Access Administrator at the root level. Once this access is provided, the current user can then add themself to other roles like Subscription Admin.
The graphic below shows this flow.
May 29 2020
Attacking Active Directory Group Managed Service Accounts (GMSAs)
In May 2020, I presented some Active Directory security topics in a Trimarc Webcast called “Securing Active Directory: Resolving Common Issues” and included some information I put together relating to the security of AD Group Managed Service Accounts (GMSA). This post includes the expanded version of attacking and defending GMSAs I covered in the webcast.
I put this information together after speaking with someone about using GMSAs running services on servers that have privileged AD rights and there was confusion about what GMSAs actually do and what they can’t. The confusion seemed to be rooted in the belief that GMSA credentials are protected more than regular accounts (they aren’t). The key benefit is that their passwords change automatically, not that the credential data has stronger protections.
This post is meant to highlight what GMSAs can do and what an attacker can do if not protected appropriately. We have seen limited usage of Group Managed Service Accounts in AD environments when we perform Active Directory Security Assessments at Trimarc. GMSAs should be used wherever possible to replace user accounts as service accounts since the passwords will rotate automatically.
Group Managed Service Accounts (GMSAs)
User accounts created to be used as service accounts rarely have their password changed. Group Managed Service Accounts (GMSAs) provide a better approach (starting in the Windows 2012 timeframe). The password is managed by AD and automatically changed. This means that the GMSA has to have security principals explicitly delegated to have access to the clear-text password. Much like with other areas where delegation controls access (LAPS), determining who should have be delegated access needs to be be carefully considered.
Key Points for Group Managed Service Accounts (GMSAs) :
- The GMSA password managed by AD.
- Computers hosting GMSA service account(s) request current password from Active Directory to start service.
- Configure the GMSA to allow computer accounts access to password.
- If an attacker compromises computer hosting services using GMSA, the GMSA is compromised.
- If attacker compromises an account with rights to request GMSA password, the GMSA is compromised.
Group Managed Service Accounts have the object class “msDS-GroupManagedServiceAccount” and associated attributes specific to GMSAs. These properties include:
- msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) – stores the security principals that can access the GMSA password.
- msds-ManagedPassword – This attribute contains a BLOB with password information for group-managed service accounts.
- msDS-ManagedPasswordId – This constructed attribute contains the key identifier for the current managed password data for a group MSA.
- msDS-ManagedPasswordInterval – This attribute is used to retrieve the number of days before a managed password is automatically changed for a group MSA.
Running the AD PowerShell cmdlet Get-ADServiceAccount, we can retrieve information about the GMSA, including specific GMSA attrbiutes. This GMSA is a member of the domain Administrators group which has full AD & DC admin rights to the domain. The screenshot shows that the password changed recently and won’t change for a few weeks – changed on 5/11/2020 and configured to change every 30 days. This means that if we can get the password for this account, we have almost a month to use the account credentials before it changes. We can also identify a group that can retrieve the password data. We’ll take a look at this is a bit.
Continue reading
Recent Comments