diff --git a/submissions/description/active_directory/configuration_weaknesses/dormant_enabled_user_accounts/guidance.md b/submissions/description/active_directory/configuration_weaknesses/dormant_enabled_user_accounts/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/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).
diff --git a/submissions/description/active_directory/configuration_weaknesses/dormant_enabled_user_accounts/recommendations.md b/submissions/description/active_directory/configuration_weaknesses/dormant_enabled_user_accounts/recommendations.md
new file mode 100644
index 00000000..94581a77
--- /dev/null
+++ b/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.
diff --git a/submissions/description/active_directory/configuration_weaknesses/dormant_enabled_user_accounts/template.md b/submissions/description/active_directory/configuration_weaknesses/dormant_enabled_user_accounts/template.md
new file mode 100644
index 00000000..2bbf3588
--- /dev/null
+++ b/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}}
diff --git a/submissions/description/active_directory/configuration_weaknesses/excessive_domain_admin_membership/guidance.md b/submissions/description/active_directory/configuration_weaknesses/excessive_domain_admin_membership/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/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).
diff --git a/submissions/description/active_directory/configuration_weaknesses/excessive_domain_admin_membership/recommendations.md b/submissions/description/active_directory/configuration_weaknesses/excessive_domain_admin_membership/recommendations.md
new file mode 100644
index 00000000..08c28aa9
--- /dev/null
+++ b/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.
diff --git a/submissions/description/active_directory/configuration_weaknesses/excessive_domain_admin_membership/template.md b/submissions/description/active_directory/configuration_weaknesses/excessive_domain_admin_membership/template.md
new file mode 100644
index 00000000..ee7dd433
--- /dev/null
+++ b/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}}
diff --git a/submissions/description/active_directory/configuration_weaknesses/guidance.md b/submissions/description/active_directory/configuration_weaknesses/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/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).
diff --git a/submissions/description/active_directory/configuration_weaknesses/passwords_found_domain_description/guidance.md b/submissions/description/active_directory/configuration_weaknesses/passwords_found_domain_description/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/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).
diff --git a/submissions/description/active_directory/configuration_weaknesses/passwords_found_domain_description/recommendations.md b/submissions/description/active_directory/configuration_weaknesses/passwords_found_domain_description/recommendations.md
new file mode 100644
index 00000000..83b660fa
--- /dev/null
+++ b/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.
diff --git a/submissions/description/active_directory/configuration_weaknesses/passwords_found_domain_description/template.md b/submissions/description/active_directory/configuration_weaknesses/passwords_found_domain_description/template.md
new file mode 100644
index 00000000..ce4c04ef
--- /dev/null
+++ b/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}}
diff --git a/submissions/description/active_directory/configuration_weaknesses/recommendations.md b/submissions/description/active_directory/configuration_weaknesses/recommendations.md
new file mode 100644
index 00000000..278be85b
--- /dev/null
+++ b/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.
diff --git a/submissions/description/active_directory/configuration_weaknesses/shared_administrator_passwords/guidance.md b/submissions/description/active_directory/configuration_weaknesses/shared_administrator_passwords/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/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).
diff --git a/submissions/description/active_directory/configuration_weaknesses/shared_administrator_passwords/recommendations.md b/submissions/description/active_directory/configuration_weaknesses/shared_administrator_passwords/recommendations.md
new file mode 100644
index 00000000..994d6583
--- /dev/null
+++ b/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.
diff --git a/submissions/description/active_directory/configuration_weaknesses/shared_administrator_passwords/template.md b/submissions/description/active_directory/configuration_weaknesses/shared_administrator_passwords/template.md
new file mode 100644
index 00000000..1902949c
--- /dev/null
+++ b/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}}
diff --git a/submissions/description/active_directory/configuration_weaknesses/template.md b/submissions/description/active_directory/configuration_weaknesses/template.md
new file mode 100644
index 00000000..93b27eb0
--- /dev/null
+++ b/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}}
diff --git a/submissions/description/active_directory/configuration_weaknesses/weak_domain_password_policy/guidance.md b/submissions/description/active_directory/configuration_weaknesses/weak_domain_password_policy/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/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).
diff --git a/submissions/description/active_directory/configuration_weaknesses/weak_domain_password_policy/recommendations.md b/submissions/description/active_directory/configuration_weaknesses/weak_domain_password_policy/recommendations.md
new file mode 100644
index 00000000..fe5a8226
--- /dev/null
+++ b/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.
diff --git a/submissions/description/active_directory/configuration_weaknesses/weak_domain_password_policy/template.md b/submissions/description/active_directory/configuration_weaknesses/weak_domain_password_policy/template.md
new file mode 100644
index 00000000..789f90f5
--- /dev/null
+++ b/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}}
diff --git a/submissions/description/active_directory/dacl_abuse/guidance.md b/submissions/description/active_directory/dacl_abuse/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/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).
diff --git a/submissions/description/active_directory/dacl_abuse/recommendations.md b/submissions/description/active_directory/dacl_abuse/recommendations.md
new file mode 100644
index 00000000..415acaf9
--- /dev/null
+++ b/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.
diff --git a/submissions/description/active_directory/dacl_abuse/template.md b/submissions/description/active_directory/dacl_abuse/template.md
new file mode 100644
index 00000000..d65d7e1c
--- /dev/null
+++ b/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}}
diff --git a/submissions/description/active_directory/kerberos_abuse/domain_compromise_unconstrained_delegated/guidance.md b/submissions/description/active_directory/kerberos_abuse/domain_compromise_unconstrained_delegated/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/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).
diff --git a/submissions/description/active_directory/kerberos_abuse/domain_compromise_unconstrained_delegated/recommendations.md b/submissions/description/active_directory/kerberos_abuse/domain_compromise_unconstrained_delegated/recommendations.md
new file mode 100644
index 00000000..1b9cf4e4
--- /dev/null
+++ b/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.
diff --git a/submissions/description/active_directory/kerberos_abuse/domain_compromise_unconstrained_delegated/template.md b/submissions/description/active_directory/kerberos_abuse/domain_compromise_unconstrained_delegated/template.md
new file mode 100644
index 00000000..215cd388
--- /dev/null
+++ b/submissions/description/active_directory/kerberos_abuse/domain_compromise_unconstrained_delegated/template.md
@@ -0,0 +1,20 @@
+Unconstrained Kerberos delegation is a misconfiguration where a computer or service account in Active Directory is trusted to delegate any user's credentials to any service. When a user authenticates to a server configured with unconstrained delegation, their Ticket Granting Ticket (TGT) is cached in memory on that server. An attacker who compromises a server with unconstrained delegation can extract these cached TGTs and use them to impersonate any user who has authenticated to the compromised server. If a domain administrator authenticates to the compromised server, the attacker can extract the administrator's TGT and use it to authenticate to any service in the domain, including domain controllers. This allows an attacker to gain full domain compromise through credential impersonation.
+
+**Business Risk**
+
+This vulnerability could be abused by an attacker to gain unauthorised access to any user account, effectively leading to full domain compromise. 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. Enumerate Active Directory for computer accounts with unconstrained delegation enabled using {{enumeration_tool}} against {{domain_controller}}
+1. Identify the delegated server at {{delegated_server_hostname}} with the TRUSTED_FOR_DELEGATION flag set
+1. Obtain local administrator access on {{delegated_server_hostname}} using {{initial_access_method}}
+1. Use a tool such as `Rubeus` or `Mimikatz` on {{delegated_server_hostname}} to monitor for and extract cached TGTs from memory
+1. Coerce or wait for a privileged user to authenticate to {{delegated_server_hostname}}, or trigger authentication using {{coercion_method}}
+1. Extract the cached TGT for {{privileged_account}} and use it to authenticate to {{domain_controller}} to confirm domain-level access
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/kerberos_abuse/guidance.md b/submissions/description/active_directory/kerberos_abuse/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/kerberos_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).
diff --git a/submissions/description/active_directory/kerberos_abuse/insecure_service_account_management/guidance.md b/submissions/description/active_directory/kerberos_abuse/insecure_service_account_management/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/kerberos_abuse/insecure_service_account_management/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).
diff --git a/submissions/description/active_directory/kerberos_abuse/insecure_service_account_management/recommendations.md b/submissions/description/active_directory/kerberos_abuse/insecure_service_account_management/recommendations.md
new file mode 100644
index 00000000..5c2728f9
--- /dev/null
+++ b/submissions/description/active_directory/kerberos_abuse/insecure_service_account_management/recommendations.md
@@ -0,0 +1,5 @@
+# recommendation(s)
+
+Use Group Managed Service Accounts (gMSA) which automatically rotate 240-character cryptographically random passwords. For accounts that cannot use gMSA, enforce passwords of at least 25 characters with regular rotation. 
+
+Additionally, audit all accounts with registered SPNs and remove SPNs from accounts that do not require them. Apply the principle of least privilege to all service accounts. Monitor for high volumes of TGS requests from single accounts using Windows Security Event 4769, a pattern which indicates Kerberoasting activity.
diff --git a/submissions/description/active_directory/kerberos_abuse/insecure_service_account_management/template.md b/submissions/description/active_directory/kerberos_abuse/insecure_service_account_management/template.md
new file mode 100644
index 00000000..38b760fe
--- /dev/null
+++ b/submissions/description/active_directory/kerberos_abuse/insecure_service_account_management/template.md
@@ -0,0 +1,20 @@
+Kerberoasting is an attack against Active Directory service accounts that have a Service Principal Name (SPN) registered. Any authenticated domain user can request a Kerberos service ticket (TGS) for any SPN in the domain. The service ticket is encrypted using the service account's password hash. An attacker with a low-privileged domain account can request TGS tickets for all accounts with SPNs and then perform offline brute-force or dictionary attacks against the ticket encryption to recover the service account's plaintext password. Service accounts frequently have weak or long-lived passwords and elevated domain privileges. This allows an attacker to recover service account credentials and use them for lateral movement or privilege escalation.
+
+**Business Risk**
+
+Kerberoasting allows any authenticated domain user to target service account credentials for offline cracking. 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. Enumerate accounts with registered SPNs in {{domain_name}} using {{enumeration_tool}}
+1. Identify the target service account {{service_account}} with SPN {{spn_value}}.
+1. Request a TGS ticket for {{spn_value}} using {{ticket_request_tool}}
+1. Export the TGS ticket and perform offline password cracking using {{cracking_tool}} with {{wordlist}}
+1. Confirm that the plaintext password for {{service_account}} is recovered
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/kerberos_abuse/no_pre_authentication/guidance.md b/submissions/description/active_directory/kerberos_abuse/no_pre_authentication/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/kerberos_abuse/no_pre_authentication/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).
diff --git a/submissions/description/active_directory/kerberos_abuse/no_pre_authentication/recommendations.md b/submissions/description/active_directory/kerberos_abuse/no_pre_authentication/recommendations.md
new file mode 100644
index 00000000..9f53b8e3
--- /dev/null
+++ b/submissions/description/active_directory/kerberos_abuse/no_pre_authentication/recommendations.md
@@ -0,0 +1,3 @@
+# recommendation(s)
+
+For all user accounts, ensure that the "Do not require Kerberos preauthentication" option is disabled in Active Directory. This setting can be found in the user account properties under the "Account" tab. Additionally, enforce a strong domain password policy with a minimum of 15 characters to make offline cracking significantly more difficult.
diff --git a/submissions/description/active_directory/kerberos_abuse/no_pre_authentication/template.md b/submissions/description/active_directory/kerberos_abuse/no_pre_authentication/template.md
new file mode 100644
index 00000000..71457dcb
--- /dev/null
+++ b/submissions/description/active_directory/kerberos_abuse/no_pre_authentication/template.md
@@ -0,0 +1,20 @@
+A domain user was vulnerable to an attack referred to as ASREPRoasting due to preauthentication being disabled for the account. ASREPRoasting targets Active Directory user accounts that have the "Do not require Kerberos preauthentication" flag enabled. When preauthentication is disabled, an attacker can send an AS-REQ request for the account without providing a valid password. The domain controller responds with an AS-REP containing a portion encrypted with the user's password hash. An attacker does not need any domain credentials to perform this request against accounts with preauthentication disabled. This allows an attacker to gain authenticated domain access or, if the targeted account has elevated privileges, to escalate privileges within the domain.
+
+**Business Risk**
+
+This vulnerability could result in an attacker gaining a foothold or escalating privileges in the domain. In turn, this would allow unauthorized access, data theft, and malicious activities. Such incidents can result in significant financial losses, damage to the organization's reputation, and erosion of customer trust, especially if sensitive customer information is compromised.
+
+**Steps to Reproduce**
+
+1. Enumerate accounts with preauthentication disabled in {{domain_name}} using {{enumeration_tool}} from {{attacker_host}}
+1. Identify the target account {{target_account}} with the DONT_REQUIRE_PREAUTH flag set
+1. Send an AS-REQ request for {{target_account}} to the domain controller at {{domain_controller}} using {{asrep_tool}}
+1. Capture the AS-REP response containing the encrypted portion of the ticket
+1. Perform offline password cracking against the AS-REP hash using {{cracking_tool}} with {{wordlist}}
+1. Confirm that the plaintext password for {{target_account}} is recovered
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/kerberos_abuse/recommendations.md b/submissions/description/active_directory/kerberos_abuse/recommendations.md
new file mode 100644
index 00000000..1b9cf4e4
--- /dev/null
+++ b/submissions/description/active_directory/kerberos_abuse/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.
diff --git a/submissions/description/active_directory/kerberos_abuse/template.md b/submissions/description/active_directory/kerberos_abuse/template.md
new file mode 100644
index 00000000..ca5ff02a
--- /dev/null
+++ b/submissions/description/active_directory/kerberos_abuse/template.md
@@ -0,0 +1,17 @@
+Kerberos is the default authentication protocol in Active Directory environments. Misconfigurations such as unconstrained delegation, weak service account passwords with registered SPNs, and disabled pre-authentication each provide a distinct attack path. An attacker can exploit these weaknesses to extract Ticket Granting Tickets from delegated servers, crack service ticket encryption offline to recover service account passwords, or request AS-REP hashes for accounts without pre-authentication.
+
+**Business Risk**
+
+Kerberos abuse can result in credential theft, privilege escalation, and full domain compromise depending on the specific misconfiguration. 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. Enumerate the Kerberos misconfiguration in {{domain_name}} using {{enumeration_tool}} against {{domain_controller}}
+1. Identify the target account or system at {{target}} with {{kerberos_weakness}}
+1. Exploit the identified weakness using {{exploitation_tool}} to obtain {{ticket_or_hash}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/misconfigured_active_directory_certificate_services/guidance.md b/submissions/description/active_directory/misconfigured_active_directory_certificate_services/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/misconfigured_active_directory_certificate_services/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).
diff --git a/submissions/description/active_directory/misconfigured_active_directory_certificate_services/recommendations.md b/submissions/description/active_directory/misconfigured_active_directory_certificate_services/recommendations.md
new file mode 100644
index 00000000..1519201e
--- /dev/null
+++ b/submissions/description/active_directory/misconfigured_active_directory_certificate_services/recommendations.md
@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Audit all certificate templates and remove the `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` flag from templates that enable client authentication. Restrict enrollment permissions to only the accounts and groups that require each template. Additionally, enable Manager Approval on sensitive templates so that certificate requests require CA administrator authorization before issuance. Remove unnecessary templates from publication on the CA.
diff --git a/submissions/description/active_directory/misconfigured_active_directory_certificate_services/template.md b/submissions/description/active_directory/misconfigured_active_directory_certificate_services/template.md
new file mode 100644
index 00000000..89233e38
--- /dev/null
+++ b/submissions/description/active_directory/misconfigured_active_directory_certificate_services/template.md
@@ -0,0 +1,20 @@
+Misconfigured Active Directory Certificate Services (ADCS) is a vulnerability where certificate templates or enrollment permissions are configured in a way that allows a low-privileged user to request certificates that grant elevated privileges. An attacker with a low-privileged domain account can identify vulnerable templates, request a certificate with a SAN specifying a domain administrator, and use the issued certificate to authenticate as that administrator. This allows full domain compromise through certificate-based impersonation.
+
+**Business Risk**
+
+Misconfigured ADCS templates allow a low-privileged user to obtain certificates that impersonate domain administrators or other privileged accounts. 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. Enumerate vulnerable certificate templates on {{ca_server}} using {{enumeration_tool}}
+1. Identify the vulnerable template {{template_name}} with {{misconfiguration_detail}}
+1. Request a certificate from {{ca_server}} using template {{template_name}} with a SAN specifying {{target_privileged_account}}
+1. Receive the issued certificate and use it to authenticate to {{domain_controller}} as {{target_privileged_account}} using {{authentication_tool}}
+1. Confirm domain administrator access by executing {{verification_action}} on {{domain_controller}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/sensitive_data_exposure/ldap_anonymous_bind_enabled/guidance.md b/submissions/description/active_directory/sensitive_data_exposure/ldap_anonymous_bind_enabled/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/sensitive_data_exposure/ldap_anonymous_bind_enabled/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).
diff --git a/submissions/description/active_directory/sensitive_data_exposure/ldap_anonymous_bind_enabled/recommendations.md b/submissions/description/active_directory/sensitive_data_exposure/ldap_anonymous_bind_enabled/recommendations.md
new file mode 100644
index 00000000..0ed268c9
--- /dev/null
+++ b/submissions/description/active_directory/sensitive_data_exposure/ldap_anonymous_bind_enabled/recommendations.md
@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Disable anonymous LDAP binds by modifying the `dsHeuristics` attribute on the Directory Service configuration object. Additionally, enforce LDAP signing and channel binding on all domain controllers to prevent LDAP interception attacks. Restrict network access to LDAP ports using firewall rules to limit connections to authorized management networks.
diff --git a/submissions/description/active_directory/sensitive_data_exposure/ldap_anonymous_bind_enabled/template.md b/submissions/description/active_directory/sensitive_data_exposure/ldap_anonymous_bind_enabled/template.md
new file mode 100644
index 00000000..9bf021cd
--- /dev/null
+++ b/submissions/description/active_directory/sensitive_data_exposure/ldap_anonymous_bind_enabled/template.md
@@ -0,0 +1,20 @@
+The Active Directory domain controller accepts LDAP queries without authentication. An unauthenticated attacker with network access to the domain controller can query the directory for user accounts, group memberships, organizational units, computer objects, and other directory metadata. This exposes the full structure of the Active Directory environment without requiring any credentials. An attacker can use this information to identify high-value targets, map trust relationships, enumerate privileged group membership, and plan further attacks against the domain.
+
+**Business Risk**
+
+Anonymous LDAP access exposes the full Active Directory directory structure to any network-connected attacker. User account names, email addresses, group memberships, and organizational hierarchy can be enumerated without authentication. 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. Identify the domain controller at {{domain_controller_ip}} with LDAP service available on port {{ldap_port}}
+1. Attempt an anonymous LDAP bind to {{domain_controller_ip}} using {{ldap_tool}}
+1. Confirm the bind succeeds without providing credentials
+1. Execute an LDAP search query for {{search_base}} to enumerate user objects at {{search_filter}}
+1. Retrieve directory information including {{enumerated_attributes}} for the returned objects
+1. Confirm that sensitive directory data such as {{example_data}} is returned without authentication
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/sensitive_data_exposure/sensitive_data_in_open_file_shares/guidance.md b/submissions/description/active_directory/sensitive_data_exposure/sensitive_data_in_open_file_shares/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/sensitive_data_exposure/sensitive_data_in_open_file_shares/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).
diff --git a/submissions/description/active_directory/sensitive_data_exposure/sensitive_data_in_open_file_shares/recommendations.md b/submissions/description/active_directory/sensitive_data_exposure/sensitive_data_in_open_file_shares/recommendations.md
new file mode 100644
index 00000000..62c843ab
--- /dev/null
+++ b/submissions/description/active_directory/sensitive_data_exposure/sensitive_data_in_open_file_shares/recommendations.md
@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Audit all network shares and replace broad access groups with specific security groups that use the principle of least privilege. Additionally, audit NTFS permissions on the underlying folders to ensure they align with share-level permissions. Remove sensitive files such as credentials, database backups, and PII from general-purpose file shares.
diff --git a/submissions/description/active_directory/sensitive_data_exposure/sensitive_data_in_open_file_shares/template.md b/submissions/description/active_directory/sensitive_data_exposure/sensitive_data_in_open_file_shares/template.md
new file mode 100644
index 00000000..a1814a22
--- /dev/null
+++ b/submissions/description/active_directory/sensitive_data_exposure/sensitive_data_in_open_file_shares/template.md
@@ -0,0 +1,20 @@
+Sensitive data was identified in network file shares within the Active Directory environment and are accessible without authentication, or with permissions that are overly broad for authenticated domain users. These shares may contain documents with credentials, internal infrastructure diagrams, database backups, source code, financial records, or personally identifiable information. An attacker who can access these shares can browse and download sensitive content without exploiting any application vulnerability. The exposure results from misconfigured share permissions, inherited NTFS permissions, or the use of the "Everyone" or "Authenticated Users" groups for share access.
+
+**Business Risk**
+
+Open file shares expose sensitive organizational data to any user or attacker with network or domain access. Credentials found in shared documents can be used for lateral movement and privilege escalation. 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}}, or connect to the network without authentication
+1. Enumerate network file shares across the domain using {{enumeration_tool}} targeting {{target_network_range}}
+1. Identify the accessible share at {{share_path}} with {{permission_level}} permissions
+1. Browse the share contents and locate sensitive data at {{file_path}}
+1. Download {{sensitive_file}} from the share
+1. Confirm that {{sensitive_data_description}} is present in the downloaded file
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/sscm_abuse/automatic_device_approval/guidance.md b/submissions/description/active_directory/sscm_abuse/automatic_device_approval/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/automatic_device_approval/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).
diff --git a/submissions/description/active_directory/sscm_abuse/automatic_device_approval/recommendations.md b/submissions/description/active_directory/sscm_abuse/automatic_device_approval/recommendations.md
new file mode 100644
index 00000000..5411c51a
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/automatic_device_approval/recommendations.md
@@ -0,0 +1,7 @@
+# recommendation(s)
+
+There is no single technique to protect fromdDistribution point anonymous access abuse. However, the following best practices should be adhered to:
+
+- Change the site setting to require manual approval for new clients or to enforce PKI-based client authentication.
+- Deploy SCCM in PKI mode so that only devices with a valid client certificate issued by the internal CA can register.
+- Regularly review collection membership rules to limit which deployments are available to newly approved devices, and audit the list of approved clients on a regular schedule.
diff --git a/submissions/description/active_directory/sscm_abuse/automatic_device_approval/template.md b/submissions/description/active_directory/sscm_abuse/automatic_device_approval/template.md
new file mode 100644
index 00000000..8a1de169
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/automatic_device_approval/template.md
@@ -0,0 +1,19 @@
+Automatic device approval is a misconfiguration in System Center Configuration Manager (SCCM) where new client devices are automatically approved for management without administrator review. An attacker can register a rogue device with the SCCM site by installing the SCCM client and pointing it at the management point. The rogue device is automatically approved and receives all policies, software deployments, and configuration baselines assigned to its collection. This may include applications containing credentials, scripts with privileged account details, or compliance policies that reveal internal security configurations.
+
+**Business Risk**
+
+Automatic device approval can 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. Install the SCCM client on {{attacker_device}} and configure it to register with the management point at {{management_point_hostname}}
+1. Submit a client registration request from {{attacker_device}} to {{management_point_hostname}}
+1. Confirm that {{attacker_device}} is automatically approved without administrator intervention by checking the client status at {{sccm_console_path}}
+1. Wait for policy and deployment assignments to be applied to {{attacker_device}}
+1. Examine the received policies and software deployments on {{attacker_device}} at {{local_policy_path}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/sscm_abuse/distribution_point_anonymous_access/guidance.md b/submissions/description/active_directory/sscm_abuse/distribution_point_anonymous_access/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/distribution_point_anonymous_access/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).
diff --git a/submissions/description/active_directory/sscm_abuse/distribution_point_anonymous_access/recommendations.md b/submissions/description/active_directory/sscm_abuse/distribution_point_anonymous_access/recommendations.md
new file mode 100644
index 00000000..ef391553
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/distribution_point_anonymous_access/recommendations.md
@@ -0,0 +1,7 @@
+# recommendation(s)
+
+There is no single technique to protect from distribution point anonymous access abuse. However, the following best practices should be adhered to:
+
+- Disable anonymous access on all distribution points and require HTTPS client communication.
+- Audit all hosted packages and scripts for hardcoded credentials and replace them with secure credential retrieval methods such as task sequence variables stored with encryption. 
+- Enable Enhanced HTTP or full PKI mode for SCCM client communication to enforce mutual authentication.
diff --git a/submissions/description/active_directory/sscm_abuse/distribution_point_anonymous_access/template.md b/submissions/description/active_directory/sscm_abuse/distribution_point_anonymous_access/template.md
new file mode 100644
index 00000000..99fee0f4
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/distribution_point_anonymous_access/template.md
@@ -0,0 +1,19 @@
+System Center Configuration Manager (SCCM) distribution point anonymous access is a misconfiguration where the SCCM distribution point allows unauthenticated HTTP access to software packages, operating system images, and scripts hosted for client deployment. An attacker with network access to the distribution point can browse and download all hosted content without authentication. This content may include application installers, scripts containing hardcoded credentials, configuration files with internal infrastructure details, and operating system deployment packages. This access allows an attacker to harvest sensitive data, recover credentials, and map internal infrastructure for further attacks.
+
+**Business Risk**
+
+Distribution point anonymous access can 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. Identify the SCCM infrastructure components including the site server, management point, and distribution points at {{sccm_infrastructure_targets}}
+1. Send an unauthenticated HTTP request to `{{distribution_point_url}}/SMS_DP_SMSPKG$/` to list available packages
+1. Browse the directory listing at {{package_directory_url}} to identify available content
+1. Download {{package_or_file}} from the distribution point without providing credentials
+1. Examine the downloaded content for credentials, scripts, or sensitive configuration data at {{file_path}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/sscm_abuse/guidance.md b/submissions/description/active_directory/sscm_abuse/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/sscm_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).
diff --git a/submissions/description/active_directory/sscm_abuse/ntlm_automatic_push_installation/guidance.md b/submissions/description/active_directory/sscm_abuse/ntlm_automatic_push_installation/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/ntlm_automatic_push_installation/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).
diff --git a/submissions/description/active_directory/sscm_abuse/ntlm_automatic_push_installation/recommendations.md b/submissions/description/active_directory/sscm_abuse/ntlm_automatic_push_installation/recommendations.md
new file mode 100644
index 00000000..b2506a9f
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/ntlm_automatic_push_installation/recommendations.md
@@ -0,0 +1,6 @@
+# recommendation(s)
+
+There is no single technique to protect fromd SSCM abuse. However, the following best practices should be adhered to:
+
+- Disable automatic client push installation and use alternative client deployment methods, such as Group Policy-based installation, manual push with Kerberos enforcement, or task sequence-based deployment.
+- If client push installation must remain enabled, restrict the push installation account to the minimum required permissions, enforce SMB signing on all endpoints, and enable EPA. Remove local administrator rights from the push installation account where possible. Consider using PKI-based client authentication to eliminate NTLM dependency.
diff --git a/submissions/description/active_directory/sscm_abuse/ntlm_automatic_push_installation/template.md b/submissions/description/active_directory/sscm_abuse/ntlm_automatic_push_installation/template.md
new file mode 100644
index 00000000..8bb7eb4e
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/ntlm_automatic_push_installation/template.md
@@ -0,0 +1,20 @@
+NTLM relay via System Center Configuration Manager (SCCM) automatic client push installation is a vulnerability where the site server automatically connects to newly discovered devices to install the SCCM client using a configured push installation account, which authenticates to the target device using NTLM. An attacker who controls a device or DNS entry on the network can cause the site server to initiate a push installation to an attacker-controlled host. The attacker can then relay the push installation account's NTLM credentials to a high-value target such as a domain controller or the site database server. The push installation account is often granted local administrator privileges across managed devices.
+
+**Business Risk**
+
+Successful NTLM relay of this account allows an attacker to gain administrative access to domain controllers, site database servers, or other critical infrastructure. This can 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. Identify the SCCM site server at {{site_server_hostname}} with automatic client push installation enabled
+1. Register a new device or DNS record for {{attacker_controlled_hostname}} on the network to trigger automatic client push discovery
+1. Set up an NTLM relay tool on {{attacker_host}} configured to relay captured authentication to {{target_hostname}} on port {{target_port}}
+1. Wait for the site server to initiate a client push installation to {{attacker_controlled_hostname}}
+1. Capture the NTLM authentication from the push installation account and relay it to {{target_hostname}}
+1. Confirm that the relayed authentication grants administrative access on {{target_hostname}} by executing {{verification_action}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/sscm_abuse/ntlm_management_point_site_database/guidance.md b/submissions/description/active_directory/sscm_abuse/ntlm_management_point_site_database/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/ntlm_management_point_site_database/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).
diff --git a/submissions/description/active_directory/sscm_abuse/ntlm_management_point_site_database/recommendations.md b/submissions/description/active_directory/sscm_abuse/ntlm_management_point_site_database/recommendations.md
new file mode 100644
index 00000000..72765fd0
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/ntlm_management_point_site_database/recommendations.md
@@ -0,0 +1,8 @@
+# recommendation(s)
+
+There is no single technique to protect fromd SSCM abuse. However, the following best practices should be adhered to:
+
+- Enforce Kerberos authentication between the management point and the site database
+- Enable SMB signing on all SCCM site systems
+- Disable NTLM authentication where possible via Group Policy
+- Ensure the management point and site database communicate over a secured and segmented network
diff --git a/submissions/description/active_directory/sscm_abuse/ntlm_management_point_site_database/template.md b/submissions/description/active_directory/sscm_abuse/ntlm_management_point_site_database/template.md
new file mode 100644
index 00000000..e7ba6b88
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/ntlm_management_point_site_database/template.md
@@ -0,0 +1,20 @@
+NTLM relay from the System Center Configuration Manager (SCCM) management point to the site database is a vulnerability where the management point authenticates to the SQL Server site database using NTLM rather than Kerberos. An attacker who can intercept or coerce NTLM authentication from the management point can relay those credentials to the site database server. Successful relay grants the attacker the management point's database permissions, which typically include read and write access to the SCCM site database. This allows an attacker to modify site configuration, inject malicious deployments, elevate SCCM privileges, or extract credentials stored in the database.
+
+**Business Risk**
+
+Successful NTLM relay to the site database grants an attacker direct read and write access to SCCM configuration and deployment data. This can 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. Identify the SCCM management point at {{management_point_hostname}} and the site database server at {{site_database_hostname}}
+1. Set up an NTLM relay tool on {{attacker_host}} configured to relay captured authentication to {{site_database_hostname}} on port {{sql_port}}
+1. Coerce NTLM authentication from {{management_point_hostname}} to {{attacker_host}} using {{coercion_method}}
+1. Observe the relayed authentication succeeding against {{site_database_hostname}}
+1. Execute a SQL query against the SCCM site database at {{site_database_hostname}} using the relayed session to confirm access, such as querying {{query}}
+1. Confirm that {{database_output}} is returned, demonstrating read or write access to the site database
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/sscm_abuse/ntlm_site_server_site_system/guidance.md b/submissions/description/active_directory/sscm_abuse/ntlm_site_server_site_system/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/ntlm_site_server_site_system/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).
diff --git a/submissions/description/active_directory/sscm_abuse/ntlm_site_server_site_system/recommendations.md b/submissions/description/active_directory/sscm_abuse/ntlm_site_server_site_system/recommendations.md
new file mode 100644
index 00000000..cf51e60b
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/ntlm_site_server_site_system/recommendations.md
@@ -0,0 +1,9 @@
+# recommendation(s)
+
+There is no single technique to protect fromd SSCM abuse. However, the following best practices should be adhered to:
+
+- Enforce Kerberos authentication between all SCCM site systems and enable SMB signing and EPA on all site system roles.
+- Disable NTLM authentication for SCCM inter-site communication where supported
+- Segment SCCM site systems on a dedicated management network
+- Apply the principle of least privilege to the site server account
+- Enable HTTPS communication between all site system roles
diff --git a/submissions/description/active_directory/sscm_abuse/ntlm_site_server_site_system/template.md b/submissions/description/active_directory/sscm_abuse/ntlm_site_server_site_system/template.md
new file mode 100644
index 00000000..98e2bc6b
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/ntlm_site_server_site_system/template.md
@@ -0,0 +1,20 @@
+NTLM relay from the System Center Configuration Manager (SCCM) site server to site systems is a vulnerability where the site server uses NTLM authentication when communicating with other SCCM site system roles such as distribution points, management points, or software update points. An attacker who can intercept NTLM authentication from the site server can relay those credentials to other site systems. The site server typically authenticates with high-privilege domain credentials, so a successful relay grants the attacker administrative access to the target site system. This can be used to compromise site system roles, inject malicious content, or pivot to additional infrastructure within the SCCM hierarchy.
+
+**Business Risk**
+
+Successful NTLM relay of the site server's credentials allows an attacker to take administrative control of distribution points, management points, or other site roles. This can 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. Identify the SCCM site server at {{site_server_hostname}} and a target site system at {{target_site_system_hostname}}
+1. Set up an NTLM relay tool on {{attacker_host}} configured to relay captured authentication to {{target_site_system_hostname}} on port {{target_port}}
+1. Coerce NTLM authentication from {{site_server_hostname}} to {{attacker_host}} using {{coercion_method}}
+1. Observe the relayed authentication succeeding
+1. Execute a privileged action on {{target_site_system_hostname}} using the relayed session, such as {{privileged_action}}
+1. Confirm that {{action_result}} demonstrates administrative access to the target site system
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/sscm_abuse/privileged_credentials_exposed/guidance.md b/submissions/description/active_directory/sscm_abuse/privileged_credentials_exposed/guidance.md
new file mode 100644
index 00000000..ee88d9d2
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/privileged_credentials_exposed/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).
diff --git a/submissions/description/active_directory/sscm_abuse/privileged_credentials_exposed/recommendations.md b/submissions/description/active_directory/sscm_abuse/privileged_credentials_exposed/recommendations.md
new file mode 100644
index 00000000..b2506a9f
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/privileged_credentials_exposed/recommendations.md
@@ -0,0 +1,6 @@
+# recommendation(s)
+
+There is no single technique to protect fromd SSCM abuse. However, the following best practices should be adhered to:
+
+- Disable automatic client push installation and use alternative client deployment methods, such as Group Policy-based installation, manual push with Kerberos enforcement, or task sequence-based deployment.
+- If client push installation must remain enabled, restrict the push installation account to the minimum required permissions, enforce SMB signing on all endpoints, and enable EPA. Remove local administrator rights from the push installation account where possible. Consider using PKI-based client authentication to eliminate NTLM dependency.
diff --git a/submissions/description/active_directory/sscm_abuse/privileged_credentials_exposed/template.md b/submissions/description/active_directory/sscm_abuse/privileged_credentials_exposed/template.md
new file mode 100644
index 00000000..48a35ded
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/privileged_credentials_exposed/template.md
@@ -0,0 +1,20 @@
+Privileged credential exposure in System Center Configuration Manager (SCCM) occurs when sensitive credentials are stored in task sequences, collection variables, or the Network Access Account (NAA) in a manner that allows retrieval by low-privileged users or managed devices. SCCM encrypts these credentials using a key that is available to any approved SCCM client. An attacker with access to a managed device or a low-privileged domain account can query the SCCM management point for policy data and decrypt the stored credentials. These credentials are often domain accounts with elevated privileges such as domain join accounts, local administrator accounts, or service accounts. This allows an attacker to recover plaintext credentials and use them for lateral movement or privilege escalation within the Active Directory environment.
+
+**Business Risk**
+
+Exposed privileged credentials in SCCM configuration data can grant an attacker access to domain join accounts, service accounts, or local administrator accounts. This can 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. Log in to a managed SCCM client at {{managed_device}} as {{low_privileged_user}}
+1. Use a tool such as `SharpSCCM` or `sccmhunter` to request policy data from the management point at {{management_point_hostname}}
+1. Retrieve the encrypted credential blob from {{policy_source}} containing {{credential_type}}
+1. Decrypt the recovered credential blob using the SCCM client's policy decryption key at {{decryption_method}}
+1. Confirm that the plaintext credential for {{account_name}} is recovered
+1. Validate the recovered credential by authenticating to {{validation_target}} without elevated privileges
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/sscm_abuse/pxe_boot_media_theft/guidance.md b/submissions/description/active_directory/sscm_abuse/pxe_boot_media_theft/guidance.md
new file mode 100644
index 00000000..7baa231f
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/pxe_boot_media_theft/guidance.md
@@ -0,0 +1,4 @@
+# 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.
+Include screenshots showing the PXE boot request and successful retrieval of the boot image. Show extracted credentials or sensitive data found within the image. Do not use recovered credentials to authenticate to production systems. Attempt to escalate the vulnerability to perform additional actions. If this is possible, provide a full Proof of Concept (PoC).
diff --git a/submissions/description/active_directory/sscm_abuse/pxe_boot_media_theft/recommendations.md b/submissions/description/active_directory/sscm_abuse/pxe_boot_media_theft/recommendations.md
new file mode 100644
index 00000000..74e498bb
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/pxe_boot_media_theft/recommendations.md
@@ -0,0 +1,5 @@
+# recommendation(s)
+
+Reconfigure PXE deployment to disable unknown computer support. Require a PXE boot password on all task sequences and enable the "Require a password when computers use PXE" option in the distribution point properties.
+
+Additionally, configure SCCM to use HTTPS for client communication, remove sensitive credentials from task sequences and boot images, and segment the PXE deployment network from general user VLANs. Use network access accounts with least privilege and consider migrating to Enhanced HTTP or PKI-based certificate authentication.
diff --git a/submissions/description/active_directory/sscm_abuse/pxe_boot_media_theft/template.md b/submissions/description/active_directory/sscm_abuse/pxe_boot_media_theft/template.md
new file mode 100644
index 00000000..85e5ced2
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/pxe_boot_media_theft/template.md
@@ -0,0 +1,19 @@
+Pre-Boot Execution Environment (PXE) Boot media theft is a vulnerability in Microsoft System Center Configuration Manager (SCCM) where the PXE boot process exposes operating system deployment media to unauthorized network access. An attacker with access to the same network segment as the PXE-enabled distribution point can intercept PXE boot responses and retrieve the boot image. The boot image may contain domain join credentials, task sequence variables, or other sensitive configuration data embedded during the OS deployment process. This allows an attacker to extract credentials and configuration details that can be used to move laterally within the Active Directory environment.
+
+**Business Risk**
+
+An attacker could leverage the credentials obtained through this vulnerability to gain a foothold in the domain, escalate privileges or exploit lateral movement vectors. In turn, this would allow unauthorized access, data theft, and malicious activities. Such incidents can 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. Connect to the same network segment as the SCCM PXE-enabled distribution point at {{distribution_point_hostname}}
+1. Configure a PXE client or use a tool such as `pxethief` to send a DHCP PXE boot request to {{distribution_point_ip}}
+1. Capture the PXE boot image file returned by {{distribution_point_hostname}}
+1. Mount or extract the captured boot image
+1. Search the extracted contents for credentials, task sequence variables, or sensitive configuration data at {{file_path}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}
diff --git a/submissions/description/active_directory/sscm_abuse/recommendations.md b/submissions/description/active_directory/sscm_abuse/recommendations.md
new file mode 100644
index 00000000..2d18cfaf
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/recommendations.md
@@ -0,0 +1,14 @@
+# recommendation(s)
+
+There is no single technique to protect from SSCM abuse. However, the following best practices should be adhered to:
+
+- Enforce HTTPS communication between all site systems, require PKI-based client authentication, disable automatic client push installation, and remove all stored credentials from task sequences and the Network Access Account. 
+- Enforce SMB signing on all SCCM site systems and enable Extended Protection for Authentication on the site database SQL instance, and segment SCCM management traffic on a dedicated network.
+- Audit all task sequences and collection variables for embedded credentials and replace them with secure alternatives. 
+- Require PXE boot passwords on all deployment task sequences.
+
+For more information, view the following resources:
+
+- <https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/plan-for-security>
+- <https://learn.microsoft.com/en-us/mem/configmgr/osd/plan-design/security-and-privacy-for-operating-system-deployment>
+- <https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html>
diff --git a/submissions/description/active_directory/sscm_abuse/template.md b/submissions/description/active_directory/sscm_abuse/template.md
new file mode 100644
index 00000000..b52b4cce
--- /dev/null
+++ b/submissions/description/active_directory/sscm_abuse/template.md
@@ -0,0 +1,21 @@
+System Center Configuration Manager (SCCM) abuse is a class of vulnerabilities where misconfigurations in the SCCM deployment hierarchy allow an attacker to compromise managed endpoints, escalate privileges, or move laterally within the Active Directory environment. SCCM manages operating system deployment, software distribution, and client policy enforcement across domain-joined devices. An attacker could leverage the credentials obtained through this vulnerability to gain a foothold in the domain, escalate privileges or exploit lateral movement vectors. The specific impact depends on which component is misconfigured and the privilege level of the credentials or access exposed.
+
+
+**Business Risk**
+
+SCCM abuse can 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. Identify the SCCM infrastructure components including the site server, management point, and distribution points at {{sccm_infrastructure_targets}}
+1. Determine the specific SCCM misconfiguration present at {{misconfiguration_detail}}
+1. Exploit the identified misconfiguration from {{attacker_position}} using {{exploitation_tool}}
+1. Capture or demonstrate the resulting access, credential exposure, or policy manipulation at {{exploitation_output}}
+1. Validate the impact by confirming {{impact_evidence}} on {{affected_system}}
+1. Document the scope of affected systems or credentials at {{scope_detail}}
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}