Adding pentest templates for internal infrastructure and AD

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}}

submissions/description/active_directory/configuration_weaknesses/recommendations.md

@@ -0,0 +1,3 @@
+# recommendation(s)
+
+The specific remediation depends on the specific finding but should follow Microsoft's Active Directory security best practices. In general, enforce strong password policies, deploy LAPS for local administrator password management, remove unnecessary privileged group memberships, and implement an automated account lifecycle process.

submissions/description/active_directory/configuration_weaknesses/shared_administrator_passwords/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/shared_administrator_passwords/recommendations.md

@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Deploy Microsoft Local Administrator Password Solution (LAPS) to manage unique, automatically rotated local administrator passwords for every domain-joined device. Additionally, remove all Group Policy Preferences that store local administrator credentials, as GPP passwords are encrypted with a publicly known key and can be trivially decrypted. Disable the built-in Administrator account where possible and use named administrative accounts for accountability.

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

@@ -0,0 +1,20 @@
+Shared administrator passwords is a configuration weakness where multiple systems in the Active Directory environment use the same local administrator password. This commonly occurs when the local administrator account is configured through Group Policy Preferences, a golden image, or manual deployment without unique password management. An attacker who recovers the local administrator password from any single system can use the same credential to authenticate to all systems sharing that password. This enables lateral movement across the entire environment without needing additional credential theft or exploitation.
+
+**Business Risk**
+
+Shared local administrator passwords allow a single credential compromise to grant access to every system using the same password. An attacker can move laterally across workstations, servers, and infrastructure systems without triggering additional authentication failures. 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. Obtain local administrator access on {{initial_system}} using {{initial_access_method}}
+1. Extract the local administrator password hash from {{initial_system}} using {{credential_extraction_tool}}
+1. Attempt to authenticate to {{second_system}} using the same local administrator credential via {{authentication_method}}
+1. Confirm successful authentication on {{second_system}} with local administrator privileges
+1. Repeat authentication against {{additional_systems}} to demonstrate the scope of password reuse
+1. Document the total number of systems accessible using the shared credential at {{reuse_count}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/active_directory/configuration_weaknesses/template.md

@@ -0,0 +1,17 @@
+Active Directory (AD) configuration weaknesses are insecure settings in the domain environment that increase the attack surface for credential theft, privilege escalation, and domain compromise. Common weaknesses include weak password policies, excessive privileged group membership, and shared local administrator passwords, amongst others. These confoguration weaknesses reduce the effort needed for an attacker to compromise the domain.
+
+**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.
+
+**Steps to Reproduce**
+
+1. Authenticate to the domain as a low privileged user from {{attacker_host}}
+1. Enumerate the specific configuration weaknesses in the domain
+1. Compare and the observed configuration against the security baseline at {{baseline_reference}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/active_directory/configuration_weaknesses/weak_domain_password_policy/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/weak_domain_password_policy/recommendations.md

@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Update the default domain policy to require a minimum password length of 14 characters, enable complexity requirements, set an account lockout threshold, and enforce a maximum password age. Additionally, implement fine-grained password policies for privileged accounts requiring longer minimum passwords of 20 or more characters. Deploy a banned password list to prevent the use of common and organization-specific passwords.

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

@@ -0,0 +1,20 @@
+A weak domain password policy is a configuration weakness where the Active Directory default domain password policy does not enforce sufficient complexity, length, or rotation requirements. Common weaknesses include minimum password lengths below 12 characters, disabled complexity requirements, no account lockout threshold, and excessively long maximum password ages. A weak policy allows attackers to crack password hashes obtained through techniques such as Kerberoasting or NTLM hash extraction using dictionary and brute-force attacks in a short time. The weak policy also increases the likelihood that users select easily guessable passwords. This weakness allows an attacker to gain authenticated access to domain resources and escalate privileges.
+
+**Business Risk**
+
+A weak password policy increases the success rate of password cracking and guessing attacks across the entire domain. Attackers who obtain password hashes through credential dumping, Kerberoasting, or network interception can crack weak passwords in minutes. 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. Retrieve the default domain password policy from {{domain_controller}} using {{policy_query_tool}}
+1. Document the policy settings including minimum length at {{min_length}}, complexity requirement at {{complexity_setting}}, lockout threshold at {{lockout_threshold}}, and maximum password age at {{max_age}}
+1. Compare the observed policy against industry benchmarks such as {{benchmark_reference}}
+1. Demonstrate the weakness by performing a password spray or hash cracking exercise against {{test_target}} using {{attack_tool}}
+1. Confirm that {{number_of_accounts}} accounts are compromised due to the weak policy settings
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/active_directory/dacl_abuse/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/dacl_abuse/recommendations.md

@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Audit DACLs across the directory and remove dangerous permissions such as GenericAll, GenericWrite, WriteDACL, WriteOwner, and ForceChangePassword from non-administrative accounts and groups. Additionally, use tools such as BloodHound in a defensive capacity to map all attack paths through DACL permissions and prioritize remediation of the shortest paths to Domain Admins. Implement AdminSDHolder protections for sensitive accounts and groups.

submissions/description/active_directory/dacl_abuse/template.md

@@ -0,0 +1,20 @@
+Discretionary Access Control List (DACL) abuse is a vulnerability in Active Directory where misconfigured object permissions grant low-privileged users dangerous rights over other objects in the directory. Common exploitable permissions include GenericAll, GenericWrite, WriteDACL, WriteOwner, ForceChangePassword, and AddMember on user accounts, groups, computer objects, or organizational units. An attacker with a low-privileged domain account can enumerate DACLs across the directory to identify objects where they (or their group memberships) hold excessive permissions, then escalate their privilege from a low-privileged domain user to a domain administrator.
+
+**Business Risk**
+
+Misconfigured DACLs allow low-privileged users to modify critical Active Directory objects without needing to exploit a software vulnerability. 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 DACL permissions across Active Directory objects in {{domain_name}} using {{enumeration_tool}}
+1. Identify the target object {{target_object}} where {{low_privileged_user}} or a group it belongs to holds {{dangerous_permission}}
+1. Exploit the identified permission on {{target_object}} by executing {{exploitation_action}} using {{exploitation_tool}}
+1. Confirm that {{exploitation_result}} was achieved, such as group membership change or password reset
+1. Validate the escalated access by authenticating to {{domain_controller}} with the modified privileges
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/active_directory/kerberos_abuse/domain_compromise_unconstrained_delegated/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/kerberos_abuse/domain_compromise_unconstrained_delegated/recommendations.md

@@ -0,0 +1,5 @@
+# recommendation(s)
+
+Disable Unconstrained Delegation on the affected system/account. Where delegation is strictly necessary, consider migrating more restrictive delegation types (such as Resource-Based Constrained Delegation (RBCD)). 
+
+Ensure that highly privileged accounts are protected from delegation by enabling the "Account is sensitive and cannot be delegated" option in Active Directory.