Adding pentest templates for internal infrastructure and AD

submissions/description/active_directory/domain_compromise_via_unconstrained_delegation/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/domain_compromise_via_unconstrained_delegation/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.

submissions/description/active_directory/domain_compromise_via_unconstrained_delegation/template.md

@@ -0,0 +1,21 @@
+A system configured with unconstrained delegation was compromised during the assessment, leading to domain privilege escalation. 
+
+Unconstrained delegation is a Kerberos feature introduced with Server 2000 which allows a service to impersonate any user who authenticates to it and subsequently access any other service in the domain on behalf of that user. This is a highly permissive configuration and the least restrictive form of delegation available in an active directory environment. 
+
+When a user authenticates to a service configured with unconstrained delegation, the Key Distribution Center (KDC) issues a Ticket-Granting Ticket (TGT) for the user, and a copy of this TGT is forwarded to and stored in the memory of the delegating service. If this delegating service account is compromised, an attacker can extract these cached TGTs. With a user's TGT, the attacker can then request service tickets for any service within the domain, effectively impersonating that user to any resource. 
+
+Rather than waiting for a highly privileged user to authenticate to the service, unconstrained delegation is usually combined with authentication coercion techniques where the target account is forcibly triggered to authenticate to the controlled service. A typical abuse pathway is to coerce authentication from a Domain Controller (DC) machine account, which is then leveraged to perform a DCSync attack. The DCSync simulates the replication process of one DC to another in order to retrieve the stored credentials/hashes of domain-wide user accounts. With access to these hashes, the attacker can then forge additional TGT’s on behalf of any arbitrary user in the domain (including privileged domain administrator accounts), resulting in full domain compromise.
+
+**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**
+
+<Provide numbered steps to reproduce this issue in the context of the in-scope domain>
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

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

@@ -0,0 +1,6 @@
+# recommendation(s)
+
+The Domain Administrators group should contain only accounts that strictly require such authority to complete their roles. The accounts themselves should be used infrequently, so as to further reduce the chance of compromise. 
+
+Ensure that regular auditing of security group membership and user access rights is undertaken to prevent unnecessary permissions from being granted to user accounts.
+

submissions/description/active_directory/excessive_domain_admin_membership/template.md

@@ -0,0 +1,19 @@
+The Active Directory (AD) domain had a large number of user accounts belonging to the highly privileged “Domain Admins” security group. 
+
+The "Domain Admins" group possesses the highest level of administrative authority within an Active Directory domain, granting full control over all domain controllers, workstations, servers, and every object in the domain.
+
+Having an excessive number of Domain Admins (DA) enlarges the attack surface by presenting a broad range of high-value targets, in turn increasing the likelihood of domain compromise.
+
+**Business Risk**
+
+Having an excessive number of highly privileged accounts in the domain expands the attack surface and increases the risk of an attacker compromising the domain. In turn, this could 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**
+
+<Provide numbered steps to reproduce this issue in the context of the in-scope domain>
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

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

@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Install the KB2962486 patch on all affected systems to prevent new credentials from being placed in Group Policy Preferences. As this patch will not fix existing Group Policy Preference files, refer to the vendor security bulletin MS14-025, where Microsoft has provided a PowerShell script to detect existing stored passwords for removal.

submissions/description/active_directory/group_policy_preferences_password_elevation_of_privilege/template.md

@@ -0,0 +1,19 @@
+The Group Policy implementation was vulnerable to Microsoft Security Bulletin MS14-025, which allows an attacker to retrieve and decrypt passwords stored within Group Policy Preferences (GPP).
+
+In Older Windows servers, when GPP are used to deploy local user accounts, the passwords for these accounts are stored as encrypted strings within XML files (e.g., Groups.xml, Services.xml, ScheduledTasks.xml) hosted on the SYSVOL share. The private key used to encrypt the stored passwords has been publicly shared by Microsoft. 
+
+As SYSVOL is accessible to all authenticated users, an attacker in possession of a domain account can search the SYSVOL share for XML files containing stored passwords. With access to the XML file(s), the attacker could then use the publicly available encryption key to decrypt the GPP password and retrieve the plaintext credential(s). This presents a trivial attack vector for a malicious user to escalate privileges or gain lateral movement within the domain.
+
+**Business Risk**
+
+An attacker could leverage the credentials obtained through this vulnerability to 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**
+
+<Provide numbered steps to reproduce this issue in the context of the in-scope domain>
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/active_directory/insecure_name_resolution_protocols_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).

submissions/description/active_directory/insecure_name_resolution_protocols_enabled/recommendations.md

@@ -0,0 +1,15 @@
+# recommendation(s)
+
+Disable LLMNR and NBT-NS protocols across the network.
+
+To disable LLMNR, the Group Policy Object (GPO) “Turn off multicast name resolution” should be set to ‘Enabled’ and applied to all domain-joined devices. 
+
+NBT-NS can be disabled on a network adaptor of a machine by navigating to Network Connections > Network Adapter Properties > TCP/IPv4 Properties > Advanced tab > WINS tab and selecting “Disable NetBIOS over TCP/IP”. 
+
+Whilst there is no GPO to disable NBT-NS across the domain, as a workaround, the following PowerShell script can be added to Group Policy under the path: Computer Configuration > Policies > Windows Settings > Scripts > Startup > PowerShell:
+
+```
+
+Scripts.$regkey = “HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces”
+Get-ChildItem $regkey |foreach { Set-ItemProperty -Path “$regkey\$($_.pschildname)” -Name NetbiosOptions -Value 2 -Verbose}
+```

submissions/description/active_directory/insecure_name_resolution_protocols_enabled/template.md

@@ -0,0 +1,21 @@
+Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are Microsoft Windows protocols for name resolution – translating hostnames to IP addresses.
+
+Windows systems will fall back to name resolution via LLMNR and NBT-NS when DNS (Domain Name System) has failed to resolve a hostname in the local network. To resolve hostnames, these protocols initiate a broadcast message to the network requesting the address of the resource it needs.  
+
+An attacker situated within the same network segment can exploit LLMNR and NBT-NS queries by replying with spoofed responses impersonating the requested hostname. This process, known as poisoning, tricks victims into communicating with the attacker-controlled system. If the query is for a resource that requires authentication (such as a fileshare), the victim's system will send the user’s Net-NTLM(v1/2) hash to the attacker's machine. 
+
+After poisoning a hostname resolution query, an attacker can proceed by attempting to crack the retrieved password hash offline using brute force methods. More commonly, the attacker will relay the authentication to another target in order to perform actions on the targeted system with the privileges of the impersonated user. 
+
+**Business Risk**
+
+This vulnerability could allow an unauthenticated attacker situated within the network to compromise domain user accounts and gain lateral movement across systems in the domain. In turn, this could 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**
+
+<Provide numbered steps to reproduce this issue in the context of the in-scope domain>
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

submissions/description/active_directory/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).

submissions/description/active_directory/insecure_service_account_management/recommendations.md

@@ -0,0 +1,6 @@
+# recommendation(s)
+
+Ensure that service accounts follow the principle of least privilege such that only the minimum permissions necessary to perform their required functions are granted, thereby limiting their potential for misuse if compromised. A strong password policy should also be enforced, ensuring that all service account passwords are long, complex, and unique.
+
+For a more robust and sustainable solution, organizations should consider transitioning to the use of Managed Service Accounts (MSAs) or Group Managed Service Accounts (gMSAs) wherever possible. These accounts offer automatic password management and rotation, in turn reducing administrative burden and preventing the risk of using weak or reused passwords.
+

submissions/description/active_directory/insecure_service_account_management/template.md

@@ -0,0 +1,19 @@
+Insecure service account management occurs when an overly privileged domain user is configured to run a service.
+
+<Add details on the vulnerable user(s) identified, the service the user is associated with, and their privileges (e.g membership of domain admins) within the domain>
+
+When a domain account is configured to run a service, a Service Principal Name (SPN) is used in the domain to associate the service with a login account. Any valid (including low privileged) domain user can request an SPN for a registered service and receive a Kerberos service ticket that is signed with the NTLM password hash of the account running that service. This data can then be extracted and subjected to offline brute-force password guessing with the aim of recovering the account's plaintext password. This attack pathway is referred to as 'Kerberoasting' and is used by an adversary to escalate their privileges within a domain. Accounts which use short and non-complex passwords increase the likelihood of a successful Kerberoasting attack.
+
+**Business Risk**
+
+This vulnerability could allow a low-privileged malicious user to escalate their privileges over 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**
+
+<Provide numbered steps to reproduce this issue in the context of the in-scope domain>
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

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

@@ -0,0 +1,5 @@
+# recommendation(s)
+
+Apply the Microsoft security updates addressing CVE-2019-1040 and CVE-2019-1166 to the affected system. These patches modify how the server validates the MIC, preventing the bypass.
+
+Additionally, for comprehensive protection across the domain, consider enforcing signing requirements on all servers where possible. 

submissions/description/active_directory/ntlm_tampering_vulnerability_drop_the_mic/template.md

@@ -0,0 +1,19 @@
+The server was vulnerable to a NT LAN Manager (NTLM) tampering vulnerability referred to as “Drop the Mic”, which allows Message Integrity Code (MIC) protections to be bypassed. 
+
+The MIC is a cryptographic checksum designed to provide integrity protection for the NTLM authentication exchange. It serves as a protection mechanism against attempts to downgrade security features such as session signing which are negotiated during the exchange.
+
+Drop the Mic (CVE-2019-1040) and Drop the Mic 2 (CVE-2019-1166) are vulnerabilities which allow the protections provided by the MIC to be circumvented, in turn permitting the attacker to overcome session signing negotiation. As a result, affected servers which do not enforce session signing become vulnerable to NTLM relay attacks. In an NTLM relay attack, an attacker intercepts an NTLM authentication attempt from a client and "relays" it to the targeted server in order to perform actions with the privileges of the impersonated user.
+
+**Business Risk**
+
+This vulnerability could allow an unauthenticated attacker to gain a foothold on the domain or pursue lateral movement vectors using NTLM relay attack(s). In turn, this could 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**
+
+<Provide numbered steps to reproduce this issue in the context of the in-scope domain>
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

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

@@ -0,0 +1,3 @@
+# recommendation(s)
+
+Remove passwords and other sensitive information from all AD user account description fields.

submissions/description/active_directory/passwords_found_within_domain_user_account_description/template.md

@@ -0,0 +1,19 @@
+Active Directory (AD) user accounts were discovered with plaintext or easily decipherable passwords (or password fragments/hints) stored within their "Description" attribute.
+
+Storing passwords or sensitive information in the Description fields of user accounts may be practiced for administrative convenience, however, these account descriptions are retrievable by any authenticated domain user without any special privileges. 
+
+As a result, 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.
+
+**Steps to Reproduce**
+
+<Provide numbered steps to reproduce this issue in the context of the in-scope domain>
+
+**Proof of Concept (PoC)**
+
+The screenshot(s) below demonstrate(s) the vulnerability:
+>
+> {{screenshot}}

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

@@ -0,0 +1,4 @@
+# recommendation(s)
+
+Reconfigure PXE deployment to disable unknown computer support. Additionally, ensure that boot media is protected with a suitably complex password.
+