Merge pull request #564 from bugcrowd/Q3-2025-pentesting-additions

Adding pentest templates for internal infrastructure and AD

Author: RRudder

submissions/description/active_directory/configuration_weaknesses/dormant_enabled_user_accounts/guidance.md

@@ -0,0 +1,5 @@
+# Guidance
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed up triage time and result in faster rewards. Please include specific details on where you identified the vulnerability, how you identified it, and what actions you were able to perform as a result.
+
+Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

submissions/description/active_directory/configuration_weaknesses/dormant_enabled_user_accounts/recommendations.md

@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Implement an automated script or identity governance process that disables accounts inactive for more than 90 days and deletes them after a further grace period. Additionally, integrate account lifecycle management with the HR offboarding process to ensure accounts are disabled promptly when employees depart. Audit dormant accounts quarterly and review group memberships before disabling to confirm no critical service dependencies exist. Tag service accounts with a clear naming convention so they are not mistakenly identified as dormant user accounts.

submissions/description/active_directory/configuration_weaknesses/dormant_enabled_user_accounts/template.md

@@ -0,0 +1,20 @@
+Active Directory accounts that have not been used for authentication in over 90 dayshave been identified. These accounts are often forgotten service accounts, former employee accounts, or test accounts that were never disabled. An attacker can target dormant accounts for password spraying or brute-force attacks because they are less likely to be monitored, less likely to trigger user-reported alerts, and may have weak or never-rotated passwords. If a dormant account holds group memberships or access permissions, compromising it grants the attacker those same privileges. This allows an attacker to gain an authenticated foothold in the domain through an account that is unlikely to be noticed.
+
+**Business Risk**
+
+Dormant accounts represent unmonitored entry points into the domain. Compromising a dormant account is less likely to trigger security alerts or be reported by a legitimate user. This could result in indirect financial losses, damage to the organization's reputation, and erosion of customer trust, especially if sensitive customer information is compromised
+
+**Steps to Reproduce**
+
+1. Authenticate to the domain as {{low_privileged_user}} from {{attacker_host}}
+1. Query Active Directory for user accounts with a lastLogonTimestamp older than 90 days using {{query_tool}} against {{domain_controller}}
+1. Filter the results to show only enabled accounts at {{filter_criteria}}
+1. Identify {{dormant_account_count}} enabled accounts that have not authenticated in over 90 days
+1. Document representative dormant accounts including {{example_account}} with last logon at {{last_logon_date}}
+1. Verify the group memberships of {{example_account}} to assess the potential access granted if compromised at {{group_membership}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/active_directory/configuration_weaknesses/excessive_domain_admin_membership/guidance.md

@@ -0,0 +1,5 @@
+# Guidance
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed up triage time and result in faster rewards. Please include specific details on where you identified the vulnerability, how you identified it, and what actions you were able to perform as a result.
+
+Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

submissions/description/active_directory/configuration_weaknesses/excessive_domain_admin_membership/recommendations.md

@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Audit all Domain Admins, Enterprise Admins, and Schema Admins group memberships and remove accounts that do not have a documented need for domain-level administrative access. Additionally, implement a tiered administration model where day-to-day administrative tasks use delegated permissions rather than full domain admin rights. Deploy Privileged Access Workstations (PAWs) for accounts that must retain domain admin membership. Enable just-in-time access through Privileged Access Management (PAM) solutions to grant temporary elevated access only when needed.

submissions/description/active_directory/configuration_weaknesses/excessive_domain_admin_membership/template.md

@@ -0,0 +1,20 @@
+It was identified that too many user accounts are members of the Domain Admins, Enterprise Admins, or other highly privileged Active Directory groups. Each account in these groups has full administrative control over the entire domain or forest. A large number of privileged accounts increases the attack surface for credential theft, phishing, and Kerberoasting. If any one of these accounts is compromised through password cracking, phishing, or credential dumping, an attacker gains full domain administrative privileges.
+
+**Business Risk**
+
+Excessive membership increases the probability that at least one account has a weak password, is targeted by phishing, or is used on a compromised workstation. This could result in indirect financial losses, damage to the organization's reputation, and erosion of customer trust, especially if sensitive customer information is compromised
+
+**Steps to Reproduce**
+
+1. Authenticate to the domain as {{low_privileged_user}} from {{attacker_host}}
+1. Enumerate the membership of the Domain Admins group in {{domain_name}} using {{enumeration_tool}}
+1. Enumerate the membership of the Enterprise Admins and Schema Admins groups using {{enumeration_tool}}
+1. Document the total number of accounts in each privileged group at {{admin_count}}
+1. Identify accounts in privileged groups that do not require domain-level administrative access, such as {{example_unnecessary_account}}
+1. Compare the observed membership count against the organization's operational requirements documented at {{baseline_reference}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/active_directory/configuration_weaknesses/guidance.md

@@ -0,0 +1,5 @@
+# Guidance
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed up triage time and result in faster rewards. Please include specific details on where you identified the vulnerability, how you identified it, and what actions you were able to perform as a result.
+
+Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

submissions/description/active_directory/configuration_weaknesses/passwords_found_domain_description/guidance.md

@@ -0,0 +1,5 @@
+# Guidance
+
+Provide a step-by-step walkthrough with a screenshot on how you exploited the vulnerability. This will speed up triage time and result in faster rewards. Please include specific details on where you identified the vulnerability, how you identified it, and what actions you were able to perform as a result.
+
+Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).

submissions/description/active_directory/configuration_weaknesses/passwords_found_domain_description/recommendations.md

@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Remove passwords and other sensitive information from all AD user account description fields. Rotate any affected account passwords immediately, and enforce a policy prohibiting the storage of credentials in directory attributes. Additionally, implement a privileged access management solution or password vault for storing service account credentials. Conduct regular audits of LDAP attributes across all user and computer objects to detect credential storage.

submissions/description/active_directory/configuration_weaknesses/passwords_found_domain_description/template.md

@@ -0,0 +1,21 @@
+Active Directory (AD) user accounts were discovered with plaintext or easily decipherable passwords (or password fragments/hints) stored within their "Description" attribute. These attributes are readable by all authenticated domain users through standard LDAP queries. An attacker with any authenticated domain account can query Active Directory for user objects and read the description fields of all accounts in the domain. This allows an attacker with access to any valid domain user could retrieve the sensitive data stored in account descriptions and leverage any resulting credentials to compromise the affected accounts. 
+
+
+**Business Risk**
+
+This vulnerability may lead to an attacker compromising the affected user accounts. The extent of malicious impact is dependent on the permissions of the compromised user. This could result in financial losses, damage to the organization's reputation, and erosion of customer trust, especially if sensitive customer information is compromised
+
+**Steps to Reproduce**
+
+1. Authenticate to the domain as {{low_privileged_user}} from {{attacker_host}}
+1. Query Active Directory for user objects with populated description fields using {{ldap_query_tool}} against {{domain_controller}}
+1. Filter the results for description fields containing password-like strings using {{filter_method}}
+1. Identify the account {{affected_account}} with a password stored in the description field at {{description_content}}
+1. Authenticate to {{target_system}} as {{affected_account}} using the recovered password
+1. Confirm successful authentication and note the access level granted
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}