Sep 16 2025
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 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
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
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:
PowerShell code (using Active Directory PowerShell module):
https://github.com/PyroTek3/Misc/blob/main/Get-VulnerableUserAccounts.ps1
Sep 12 2025
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:
PowerShell code (using Active Directory PowerShell modules):
https://github.com/PyroTek3/Misc/blob/main/Get-ADAdmins.ps1
Aug 18 2025
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:
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
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
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
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) :
Group Managed Service Accounts have the object class “msDS-GroupManagedServiceAccount” and associated attributes specific to GMSAs. These properties include:
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 readingMay 27 2020
For most of 2019, I was digging into Office 365 and Azure AD and looking at features as part of the development of the new Trimarc Microsoft Cloud Security Assessment which focuses on improving customer Microsoft Office 365 and Azure AD security posture. As I went through each of them, I found one that was very interesting.
In May 2020, I presented some Microsoft Office 365 & Azure Active Directory security topics in a Trimarc Webcast called “Securing Office 365 and Azure AD: Protect Your Tenant” and included the attack path described in this article that takes advantage of a little known feature.
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.
Note:
Most of the research around this issue was performed during August 2019 through December 2019 and Microsoft may have incorporated changes since then in functionality and/or capability.
Attack Scenario:
In this scenario, Acme has an on-premises Active Directory environment. Acme embraced Azure Infrastructure as a Service (IAAS) as an additional datacenter and deployed Domain Controllers to Azure for their on-prem AD (as their “cloud datacenter”). Acme IT locked down the DCs following hardening advice and limited Azure administration to the VMs hosting the DCs. Acme has other sensitive applications hosted on servers in Azure.
Acme signed up for Office 365 and started a pilot. All of the Active Directory and Exchange admins (and many other IT admins) are granted temporary Global Administrator (aka Global Admin or GA) rights to facilitate the pilot. So, more than should be there and not well protected.
The Global Administrator role provides full admin rights to Azure AD and ultimately all Office 365 services.
The Microsoft online document provides key information (5/26/2020): https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles
Note that there is nothing stated here about Azure capability.
Recent Comments