diff --git a/submissions/description/active_directory/domain_compromise_via_unconstrained_delegation/guidance.md b/submissions/description/active_directory/domain_compromise_via_unconstrained_delegation/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/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). diff --git a/submissions/description/active_directory/domain_compromise_via_unconstrained_delegation/recommendations.md b/submissions/description/active_directory/domain_compromise_via_unconstrained_delegation/recommendations.md new file mode 100644 index 00000000..1b9cf4e4 --- /dev/null +++ b/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. diff --git a/submissions/description/active_directory/domain_compromise_via_unconstrained_delegation/template.md b/submissions/description/active_directory/domain_compromise_via_unconstrained_delegation/template.md new file mode 100644 index 00000000..5815df37 --- /dev/null +++ b/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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/active_directory/excessive_domain_admin_membership/guidance.md b/submissions/description/active_directory/excessive_domain_admin_membership/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/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). diff --git a/submissions/description/active_directory/excessive_domain_admin_membership/recommendations.md b/submissions/description/active_directory/excessive_domain_admin_membership/recommendations.md new file mode 100644 index 00000000..21b1c07e --- /dev/null +++ b/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. + \ No newline at end of file diff --git a/submissions/description/active_directory/excessive_domain_admin_membership/template.md b/submissions/description/active_directory/excessive_domain_admin_membership/template.md new file mode 100644 index 00000000..b2578875 --- /dev/null +++ b/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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/active_directory/group_policy_preferences_password_elevation_of_privilege/guidance.md b/submissions/description/active_directory/group_policy_preferences_password_elevation_of_privilege/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/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). diff --git a/submissions/description/active_directory/group_policy_preferences_password_elevation_of_privilege/recommendations.md b/submissions/description/active_directory/group_policy_preferences_password_elevation_of_privilege/recommendations.md new file mode 100644 index 00000000..cc75dcb8 --- /dev/null +++ b/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. diff --git a/submissions/description/active_directory/group_policy_preferences_password_elevation_of_privilege/template.md b/submissions/description/active_directory/group_policy_preferences_password_elevation_of_privilege/template.md new file mode 100644 index 00000000..fdd66583 --- /dev/null +++ b/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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/active_directory/insecure_name_resolution_protocols_enabled/guidance.md b/submissions/description/active_directory/insecure_name_resolution_protocols_enabled/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/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). diff --git a/submissions/description/active_directory/insecure_name_resolution_protocols_enabled/recommendations.md b/submissions/description/active_directory/insecure_name_resolution_protocols_enabled/recommendations.md new file mode 100644 index 00000000..ced9ce00 --- /dev/null +++ b/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} +``` diff --git a/submissions/description/active_directory/insecure_name_resolution_protocols_enabled/template.md b/submissions/description/active_directory/insecure_name_resolution_protocols_enabled/template.md new file mode 100644 index 00000000..42289484 --- /dev/null +++ b/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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/active_directory/insecure_service_account_management/guidance.md b/submissions/description/active_directory/insecure_service_account_management/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/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). diff --git a/submissions/description/active_directory/insecure_service_account_management/recommendations.md b/submissions/description/active_directory/insecure_service_account_management/recommendations.md new file mode 100644 index 00000000..423e6092 --- /dev/null +++ b/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. + diff --git a/submissions/description/active_directory/insecure_service_account_management/template.md b/submissions/description/active_directory/insecure_service_account_management/template.md new file mode 100644 index 00000000..b88059b3 --- /dev/null +++ b/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. + + + +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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/active_directory/ntlm_tampering_vulnerability_drop_the_mic/guidance.md b/submissions/description/active_directory/ntlm_tampering_vulnerability_drop_the_mic/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/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). diff --git a/submissions/description/active_directory/ntlm_tampering_vulnerability_drop_the_mic/recommendations.md b/submissions/description/active_directory/ntlm_tampering_vulnerability_drop_the_mic/recommendations.md new file mode 100644 index 00000000..e2c8474e --- /dev/null +++ b/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. diff --git a/submissions/description/active_directory/ntlm_tampering_vulnerability_drop_the_mic/template.md b/submissions/description/active_directory/ntlm_tampering_vulnerability_drop_the_mic/template.md new file mode 100644 index 00000000..5f0bace0 --- /dev/null +++ b/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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/active_directory/passwords_found_within_domain_user_account_description/guidance.md b/submissions/description/active_directory/passwords_found_within_domain_user_account_description/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/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). diff --git a/submissions/description/active_directory/passwords_found_within_domain_user_account_description/recommendations.md b/submissions/description/active_directory/passwords_found_within_domain_user_account_description/recommendations.md new file mode 100644 index 00000000..4edfb56d --- /dev/null +++ b/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. diff --git a/submissions/description/active_directory/passwords_found_within_domain_user_account_description/template.md b/submissions/description/active_directory/passwords_found_within_domain_user_account_description/template.md new file mode 100644 index 00000000..5356d769 --- /dev/null +++ b/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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/active_directory/pre_boot_execution_environment_boot_media_theft/guidance.md b/submissions/description/active_directory/pre_boot_execution_environment_boot_media_theft/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/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). diff --git a/submissions/description/active_directory/pre_boot_execution_environment_boot_media_theft/recommendations.md b/submissions/description/active_directory/pre_boot_execution_environment_boot_media_theft/recommendations.md new file mode 100644 index 00000000..00bbe5e8 --- /dev/null +++ b/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. + diff --git a/submissions/description/active_directory/pre_boot_execution_environment_boot_media_theft/template.md b/submissions/description/active_directory/pre_boot_execution_environment_boot_media_theft/template.md new file mode 100644 index 00000000..d5a02ad3 --- /dev/null +++ b/submissions/description/active_directory/pre_boot_execution_environment_boot_media_theft/template.md @@ -0,0 +1,20 @@ +An insecure Pre-Boot Execution Environment (PXE) configuration was identified which would allow an attacker to retrieve boot media and obtain secrets contained within. + +The PXE is a mechanism which allows clients to request and deploy operating systems over the network. Instead of booting from a CD drive, USB key or hard disk, the PC will use the network to retrieve boot media from the PXE server. + +When PXE deployment is configured to support unknown computers, and the PXE media is protected with either a blank or weak password, then an attacker may abuse this configuration to retrieve and decrypt boot media. In turn, this enables access to any secrets and credential material held within the media file. This may include local administrator passwords that are reused in other devices, or credentials for potentially privileged domain-joined accounts. + + +**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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/active_directory/sensitive_data_in_domain_file_shares/guidance.md b/submissions/description/active_directory/sensitive_data_in_domain_file_shares/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/active_directory/sensitive_data_in_domain_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_in_domain_file_shares/recommendations.md b/submissions/description/active_directory/sensitive_data_in_domain_file_shares/recommendations.md new file mode 100644 index 00000000..082a900e --- /dev/null +++ b/submissions/description/active_directory/sensitive_data_in_domain_file_shares/recommendations.md @@ -0,0 +1,4 @@ +# recommendation(s) + +Conduct a thorough audit to identify, review and restrict access to all sensitive network file shares based on the principle of least privilege to ensure that only authorized individuals or groups with a legitimate business need have access to sensitive data. The practice of storing plaintext credentials within files should be avoided and replaced with secure credential management solutions (e.g., password vaults, secrets management systems). +Furthermore, consider educating employees on data handling policies, the importance of protecting sensitive information, and the risks associated with unauthorized access. diff --git a/submissions/description/active_directory/sensitive_data_in_domain_file_shares/template.md b/submissions/description/active_directory/sensitive_data_in_domain_file_shares/template.md new file mode 100644 index 00000000..c446d275 --- /dev/null +++ b/submissions/description/active_directory/sensitive_data_in_domain_file_shares/template.md @@ -0,0 +1,26 @@ +Sensitive data was disclosed in network file shares which were accessible to all authenticated users in the Active Directory domain. + +Due to the permissive access controls, an attacker who had successfully compromised a domain user account could abuse this access to obtain a variety of sensitive data, including: + +- Employee PII (e.g., HR records, payroll information) +- Customer data (e.g., contact lists, contract details) +- Financial documents (e.g., budgets, invoices, bank statements) +- Proprietary business plans or intellectual property + +< Customise the above as needed > + +Furthermore, plaintext credentials were also discovered within the exposed shares. Equipped with these credentials, an attacker could look to compromise additional systems and accounts, or elevate privileges within the domain. + +**Business Risk** + +This vulnerability could be abused by an attacker to view, exfiltrate and potentially modify sensitive data. 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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/active_directory/user_does_not_require_preauthentication/guidance.md b/submissions/description/active_directory/user_does_not_require_preauthentication/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/active_directory/user_does_not_require_preauthentication/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/user_does_not_require_preauthentication/recommendations.md b/submissions/description/active_directory/user_does_not_require_preauthentication/recommendations.md new file mode 100644 index 00000000..10b0e61f --- /dev/null +++ b/submissions/description/active_directory/user_does_not_require_preauthentication/recommendations.md @@ -0,0 +1,4 @@ +# 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. + diff --git a/submissions/description/active_directory/user_does_not_require_preauthentication/template.md b/submissions/description/active_directory/user_does_not_require_preauthentication/template.md new file mode 100644 index 00000000..d608d2f0 --- /dev/null +++ b/submissions/description/active_directory/user_does_not_require_preauthentication/template.md @@ -0,0 +1,21 @@ +A domain user was vulnerable to an attack referred to as ASREPRoasting due to preauthentication being disabled for the account. + +The ASREPRoast attack targets the first step of the Kerberos authentication process, where the client supplies their User Principal Name (UPN) in a request to receive a ticket from the Authentication Service. Importantly, the resultant ticket is signed with the associated user’s password hash. + +Kerberos preauthentication performs checks to validate the identity of the requestor against the UPN supplied in the request, to ensure that only a requestor in possession of the associated user password will receive a ticket. + +When preauthentication is disabled, an unauthenticated attacker can request a ticket on behalf of the vulnerable user and attempt to crack the password hash in order to retrieve their plaintext password. Accounts which use short and non-complex passwords increase the likelihood of a successful ASREPRoast attack. + +**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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/active_directory/weak_machine_account_password/guidance.md b/submissions/description/active_directory/weak_machine_account_password/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/active_directory/weak_machine_account_password/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/weak_machine_account_password/recommendations.md b/submissions/description/active_directory/weak_machine_account_password/recommendations.md new file mode 100644 index 00000000..5c3f5af3 --- /dev/null +++ b/submissions/description/active_directory/weak_machine_account_password/recommendations.md @@ -0,0 +1,9 @@ +# recommendation(s) + +Reset the computer account password to a suitably secure value. + +To address weak machine account passwords and potential timeroasting vulnerabilities which may be present in the wider network: + +- **Audit Pre-Windows 2000 Compatibility:** For computers created for pre-Windows 2000 compatibility within the last 30 days, ensure passwords are reset to suitably secure values. These accounts are initialized with a default weak password (matches the first 14 characters of their computer name) which will persist until being rotated. +- **Enable Automated Rotation:** Ensure the GPO "Domain member: Disable machine account password changes" is not enabled, allowing the default 30-day password rotation for all machine accounts. +- **Identify and Reset Stale Passwords:** Identify any machine accounts whose passwords have not expired/rotated in the last 30 days to identify and rectify issues preventing automated rotation. diff --git a/submissions/description/active_directory/weak_machine_account_password/template.md b/submissions/description/active_directory/weak_machine_account_password/template.md new file mode 100644 index 00000000..0df404ef --- /dev/null +++ b/submissions/description/active_directory/weak_machine_account_password/template.md @@ -0,0 +1,21 @@ +A workstation/server was configured with a weak computer account password, which allowed the system to be compromised via a “Timeroasting” attack. + +Timeroasting is a technique which abuses the Windows authentication mechanism of the Network Time Protocol (NTP) to extract password hashes for computer accounts. + +The Network Time Protocol enables domain-joined computers to synchronise their clocks with a Domain Controller (DC), which acts as the centralised time server. Due to concerns with time spoofing, Microsoft implemented an extension to the protocol (MS-SNTP) to provide a means for the time server (DC) to verify its identity. In this process, the clients (computer accounts) supply their RIDs in requests to the time server, which in turn looks up the corresponding computer account and generates a response using its password hash. Whilst this extension addresses time spoofing concerns, it also allows any unauthenticated user to retrieve and subject password hashes for any computer account in the domain to brute-force password cracking techniques. + +By default, machine account management for domain-joined systems is automated in Windows systems to ensure that suitably secure values are set for passwords and rotated every 30 days. As a result, machine account passwords typically do not represent attractive candidates for brute force cracking techniques. However, machine account passwords can become vulnerable when weak values are manually set by system administrators, or when the machine was enabled to be pre-windows 2000 compatible (in which case the initial password matches the first 14 characters of the computer name). + +**Business Risk** + +This vulnerability could allow an unauthenticated attacker to gain a foothold on the domain or pursue 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** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/file_transfer_protocol_anonymous_login/guidance.md b/submissions/description/internal_infrastructure/file_transfer_protocol_anonymous_login/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/file_transfer_protocol_anonymous_login/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/internal_infrastructure/file_transfer_protocol_anonymous_login/recommendations.md b/submissions/description/internal_infrastructure/file_transfer_protocol_anonymous_login/recommendations.md new file mode 100644 index 00000000..c1565227 --- /dev/null +++ b/submissions/description/internal_infrastructure/file_transfer_protocol_anonymous_login/recommendations.md @@ -0,0 +1,5 @@ +# recommendation(s) + +Disable anonymous login on FTP if it is not required. + +In the event anonymous logins are required as part of a legitimate business need, compensating controls such as IP allow listing should be put in place to mitigate the risk of truly anonymous connections. Regularly audit the contents of the service and file system permissions to prevent inadvertent exposure of sensitive data. diff --git a/submissions/description/internal_infrastructure/file_transfer_protocol_anonymous_login/template.md b/submissions/description/internal_infrastructure/file_transfer_protocol_anonymous_login/template.md new file mode 100644 index 00000000..3d2f3f02 --- /dev/null +++ b/submissions/description/internal_infrastructure/file_transfer_protocol_anonymous_login/template.md @@ -0,0 +1,19 @@ +A File Transfer Protocol (FTP) server running on the remote host allows anonymous logins. + +Any individual with remote connectivity to the service may gain access to the server without providing a password or unique credentials. + +This would permit an anonymous attacker to access any files made available by the FTP server within the folder to which the anonymous account has permission to view, potentially exposing sensitive material. + +**Business Risk** + +This vulnerability could lead to unauthorised access and data theft. The severity of the impact to the business is dependent on the sensitivity of the data exposed by the service. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/intelligent_platform_management_interface_cipher_zero_authentication_bypass/guidance.md b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_cipher_zero_authentication_bypass/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_cipher_zero_authentication_bypass/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/internal_infrastructure/intelligent_platform_management_interface_cipher_zero_authentication_bypass/recommendations.md b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_cipher_zero_authentication_bypass/recommendations.md new file mode 100644 index 00000000..d8378e43 --- /dev/null +++ b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_cipher_zero_authentication_bypass/recommendations.md @@ -0,0 +1,3 @@ +# recommendation(s) + +Disable support for cipher suite zero on the IPMI device. Enforce the use of strong, unique passwords for all IPMI user accounts. diff --git a/submissions/description/internal_infrastructure/intelligent_platform_management_interface_cipher_zero_authentication_bypass/template.md b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_cipher_zero_authentication_bypass/template.md new file mode 100644 index 00000000..58122d49 --- /dev/null +++ b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_cipher_zero_authentication_bypass/template.md @@ -0,0 +1,19 @@ +The Intelligent Platform Management Interface (IPMI) on the host was affected by the “Cipher Zero” authentication bypass vulnerability. + +IPMI is used by a server's Baseboard Management Controller (BMC) to provide out-of-band management and monitoring capabilities for remote systems. When IPMI is configured to support cipher suite 0 (aka cipher zero), password requirements can be bypassed to authenticate to the BMC with only a valid username (which can be readily found in vendor documentation detailing default accounts). + +Once access has been obtained, an attacker would gain administrator-level control over the underlying hardware for that system. This may include the ability to remotely power cycle systems, modify BIOS settings, deploy firmware, mount remote media, and access keyboard/video/mouse (KVM) functionality. + +**Business Risk** + +This vulnerability could lead to a malicious user gaining unauthorised hardware-level access to the affected server(s). This access could be abused to compromise the integrity and availability of the vulnerable systems. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/intelligent_platform_management_interface_v2_hash_disclosure/guidance.md b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_v2_hash_disclosure/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_v2_hash_disclosure/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/internal_infrastructure/intelligent_platform_management_interface_v2_hash_disclosure/recommendations.md b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_v2_hash_disclosure/recommendations.md new file mode 100644 index 00000000..7e4ee147 --- /dev/null +++ b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_v2_hash_disclosure/recommendations.md @@ -0,0 +1,3 @@ +# recommendation(s) + +This vulnerability stems from an inherent design flaw within the IPMI v2.0 specification itself, and as such there is no patch for remediation. However, strong and unique passwords can be implemented to limit the likelihood of success for off-line dictionary attacks against retrieved hashes. Further mitigations may include implementing access controls or network-level isolation to limit access to IPMI management interfaces. diff --git a/submissions/description/internal_infrastructure/intelligent_platform_management_interface_v2_hash_disclosure/template.md b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_v2_hash_disclosure/template.md new file mode 100644 index 00000000..17364b83 --- /dev/null +++ b/submissions/description/internal_infrastructure/intelligent_platform_management_interface_v2_hash_disclosure/template.md @@ -0,0 +1,21 @@ +The host supported Intelligent Platform Management Interface (IPMI) version 2.0, which is affected by an information disclosure vulnerability. + +IPMI is used by a server's Baseboard Management Controller (BMC) to provide out-of-band management and monitoring capabilities for remote systems. + +The IPMI 2.0 authentication process requires the server to transmit a salted SHA1 or MD5 hash of the requested user's password to the client prior to authentication occurring. This can be leveraged by an attacker to obtain the password hash for any valid user account on the BMC. + +Once obtained, these password hashes can be subjected to offline brute-force or dictionary attacks to recover the plaintext credentials. Successful recovery of these credentials grants an attacker access to the BMC, which provides control over the underlying hardware for that system and any other systems in the IPMI managed group. This may include the ability to remotely power cycle systems, modify BIOS settings, deploy firmware, mount remote media, and access keyboard/video/mouse (KVM) functionality. + +**Business Risk** + +This vulnerability could lead to a malicious user gaining unauthorised hardware-level access to the affected server(s). This access could be abused to compromise the integrity and availability of the vulnerable systems. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_anonymous_bind_enabled/guidance.md b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_anonymous_bind_enabled/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_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/internal_infrastructure/lightweight_directory_access_protocol_anonymous_bind_enabled/recommendations.md b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_anonymous_bind_enabled/recommendations.md new file mode 100644 index 00000000..6b6217b2 --- /dev/null +++ b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_anonymous_bind_enabled/recommendations.md @@ -0,0 +1,3 @@ +# recommendation(s) + +Consult vendor documentation to disable anonymous bind on the LDAP server and ensure that only authenticated users can retrieve sensitive information. diff --git a/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_anonymous_bind_enabled/template.md b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_anonymous_bind_enabled/template.md new file mode 100644 index 00000000..0214ed8d --- /dev/null +++ b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_anonymous_bind_enabled/template.md @@ -0,0 +1,21 @@ +The Windows Lightweight Directory Access Protocol (LDAP) server allows anonymous binds. + +By default, Microsoft Windows Server 2003 and later versions restrict anonymous LDAP operations, with the exception of rootDSE searches and binds. However, anonymous binds may still be encountered on older implementations, such as Windows 2000-based domain controllers, or in more modern environments where this default security setting has been overridden. + +When anonymous binds are permitted, any user can connect to the directory service and query it for information without providing authentication credentials (i.e., with an empty bind Distinguished Name (DN) and password). The information returned from the LDAP server can include details about users, group memberships, domain-joined devices, password policy, and more. + +This information can be leveraged by an attacker to inform further attacks with the aims of gaining a foothold on the domain. For example, the enumerated details may be used to perform targeted phishing attempts, identify valid users for brute-force password guessing attacks, and map valuable targets for further compromise. + +**Business Risk** + +This vulnerability may lead to indirect financial loss and reputational damage if the information exposed by the service is leveraged in more advanced attacks. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_signing_not_enforced/guidance.md b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_signing_not_enforced/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_signing_not_enforced/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/internal_infrastructure/lightweight_directory_access_protocol_signing_not_enforced/recommendations.md b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_signing_not_enforced/recommendations.md new file mode 100644 index 00000000..b15995d5 --- /dev/null +++ b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_signing_not_enforced/recommendations.md @@ -0,0 +1,7 @@ +# recommendation(s) + +Configure all LDAP servers and clients within the environment to require and enforce LDAP signing. This will ensure the integrity of LDAP communication and protect against tampering and NTLM relay attacks. + +For LDAP signing to be enforced, this requirement must be configured on both the domain controllers and clients. If the server requires signing but the client does not support signing, the session will be terminated by the server. On a domain controller LDAP signing is managed using the policy setting Domain controller: LDAP signing requirements. On a Windows LDAP client the signing is managed by the policy setting Network security: LDAP client signing requirements. + +After enforcing LDAP signing on the server, clients that rely on unsigned SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds or on LDAP simple binds over a non-SSL/TLS connection stop working. diff --git a/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_signing_not_enforced/template.md b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_signing_not_enforced/template.md new file mode 100644 index 00000000..55f22f6a --- /dev/null +++ b/submissions/description/internal_infrastructure/lightweight_directory_access_protocol_signing_not_enforced/template.md @@ -0,0 +1,19 @@ +The Windows Lightweight Directory Access Protocol (LDAP) server did not require signing. + +LDAP signing is a security feature of the Simple Authentication and Security Layer (SASL) that ensures the integrity of LDAP communication by requiring messages to be digitally signed. This provides authenticity and integrity verification, by validating the identity of the requestor and ensuring that LDAP messages have not been altered in transit. + +Unsigned network traffic is susceptible to man-in-the-middle (MITM) and replay attacks. In such attacks, a client’s messages are intercepted by the attacker and relayed to the LDAP server, effectively allowing the attacker to perform actions on the LDAP server on behalf of the impersonated client. + +**Business Risk** + +When signing is not enforced, the integrity and authenticity of messages in transit across the network can be compromised. This can be abused by attackers to compromise user accounts and services within the domain, leading to unauthorized access, data theft, and potentially service disruption. These malicious actions could result in reputational damage for the business through the impact to customers’ trust. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/remote_desktop_service_does_not_require_network_level_authentication/guidance.md b/submissions/description/internal_infrastructure/remote_desktop_service_does_not_require_network_level_authentication/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/remote_desktop_service_does_not_require_network_level_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/internal_infrastructure/remote_desktop_service_does_not_require_network_level_authentication/recommendations.md b/submissions/description/internal_infrastructure/remote_desktop_service_does_not_require_network_level_authentication/recommendations.md new file mode 100644 index 00000000..e3f0772d --- /dev/null +++ b/submissions/description/internal_infrastructure/remote_desktop_service_does_not_require_network_level_authentication/recommendations.md @@ -0,0 +1,3 @@ +# recommendation(s) + +Reconfigure the server to require Network Level Authentication (NLA). Note that once enforced, only client computers that support NLA can connect to the RDP server. diff --git a/submissions/description/internal_infrastructure/remote_desktop_service_does_not_require_network_level_authentication/template.md b/submissions/description/internal_infrastructure/remote_desktop_service_does_not_require_network_level_authentication/template.md new file mode 100644 index 00000000..2ca98830 --- /dev/null +++ b/submissions/description/internal_infrastructure/remote_desktop_service_does_not_require_network_level_authentication/template.md @@ -0,0 +1,17 @@ +The Remote Desktop Protocol (RDP) server was not configured to use Network Level Authentication (NLA) only. + +Network level authentication is a security feature of Microsoft’s remote desktop protocol that requires users to authenticate before a session can be established with the remote device. Unlike traditional RDP connections, where the login screen is loaded before authentication, NLA ensures that credentials are validated prior to initiating the connection. This is a more secure authentication method which offers protection against Denial of Service (DoS) attacks which abuse unauthenticated requests to consume server resources, alongside reducing the risk of exposure to various threats that exploit the initial connection phase. + +**Business Risk** + +This vulnerability increases the service's exposure to attacks, including consumption of server resources, which may result in downtime for the affected host. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/sensitive_data_exposed_in_nfs_shares/guidance.md b/submissions/description/internal_infrastructure/sensitive_data_exposed_in_nfs_shares/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/sensitive_data_exposed_in_nfs_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/internal_infrastructure/sensitive_data_exposed_in_nfs_shares/recommendations.md b/submissions/description/internal_infrastructure/sensitive_data_exposed_in_nfs_shares/recommendations.md new file mode 100644 index 00000000..e8dc24d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/sensitive_data_exposed_in_nfs_shares/recommendations.md @@ -0,0 +1,5 @@ +# recommendation(s) + +Implement strict access controls on all NFS shares, ensuring that only explicitly authorized IP addresses and hosts can mount them. Regularly audit NFS export configurations and file system permissions to prevent inadvertent exposure of sensitive data. Apply additional security features such as root_squash to prevent remote root users from having root privileges on the NFS share, nosuid to prevent set-user-ID or set-group-ID bits from taking effect, and noexec to prevent the execution of binaries on the mounted file system. + +If possible, consider employing NFSv4 with Kerberos for robust authentication and encryption, if available and compatible with your environment. diff --git a/submissions/description/internal_infrastructure/sensitive_data_exposed_in_nfs_shares/template.md b/submissions/description/internal_infrastructure/sensitive_data_exposed_in_nfs_shares/template.md new file mode 100644 index 00000000..211e9030 --- /dev/null +++ b/submissions/description/internal_infrastructure/sensitive_data_exposed_in_nfs_shares/template.md @@ -0,0 +1,19 @@ +Sensitive data was discovered to be accessible without authentication from mountable NFS (Network File System) shares. + +NFS (Network File System) allows a server to share directories and files which can be mounted on client machines over the network. NFS Versions 2 and 3 do not support modern authentication standards. Instead, access controls are configured at the host and user level, with defined hostnames (or IP addresses) and specific usernames permitted to mount the shares without providing a password. The most lenient configuration permits any user from any host in the network to mount the available shares. + +When an NFS export is configured overly permissively (e.g., world-readable or accessible to broad IP ranges), any system on the network capable of mounting the share can access its contents without explicit user authentication. This places the files exposed by the NFS share at risk of unauthorised access by an attacker situated in the local network. These files may include sensitive data such as SSH keys, backups, or configuration files. If write access is enabled, an attacker may also make malicious modifications to the share, including actions such as overwriting configuration files or planting malicious executables in efforts to compromise networked systems. + +**Business Risk** + +This vulnerability can lead to data theft and modification and potentially the compromise of additional services or systems in the network. The severity of the impact to the business is dependent on the permissions available to an attacker and the sensitivity of the data exposed by the service. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/server_messaging_block_signing_not_required/guidance.md b/submissions/description/internal_infrastructure/server_messaging_block_signing_not_required/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/server_messaging_block_signing_not_required/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/internal_infrastructure/server_messaging_block_signing_not_required/recommendations.md b/submissions/description/internal_infrastructure/server_messaging_block_signing_not_required/recommendations.md new file mode 100644 index 00000000..f44a05bb --- /dev/null +++ b/submissions/description/internal_infrastructure/server_messaging_block_signing_not_required/recommendations.md @@ -0,0 +1,3 @@ +# recommendation(s) + +Enable and enforce SMB signing on all relevant hosts within the network. This will ensure the authenticity and integrity of SMB communications, protecting against tampering and relay attacks. diff --git a/submissions/description/internal_infrastructure/server_messaging_block_signing_not_required/template.md b/submissions/description/internal_infrastructure/server_messaging_block_signing_not_required/template.md new file mode 100644 index 00000000..47e6bd33 --- /dev/null +++ b/submissions/description/internal_infrastructure/server_messaging_block_signing_not_required/template.md @@ -0,0 +1,19 @@ +Signing was not required on the Server Messaging Block (SMB) server. + +SMB signing is a security mechanism which ensures that every SMB message contains a cryptographic signature which incorporates a hash of the entire SMB message, alongside the original sender and intended recipient. If the message is tampered with, the hash verification will fail. In turn, this allows the recipient of the SMB traffic to confirm the authenticity and integrity of the data. + +An unauthenticated attacker can exploit a lack of SMB signing to conduct man-in-the-middle and relay attacks against the SMB server. + +**Business Risk** + +When signing is not enforced, the integrity and authenticity of messages in transit across the network can be compromised. This can be abused by attackers to compromise user accounts and services within the domain, leading to unauthorized access, data theft, and potentially service disruption. These malicious actions could result in reputational damage for the business through the impact to customers’ trust. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/simple_mail_transfer_protocol_user_enumeration/guidance.md b/submissions/description/internal_infrastructure/simple_mail_transfer_protocol_user_enumeration/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/simple_mail_transfer_protocol_user_enumeration/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/internal_infrastructure/simple_mail_transfer_protocol_user_enumeration/recommendations.md b/submissions/description/internal_infrastructure/simple_mail_transfer_protocol_user_enumeration/recommendations.md new file mode 100644 index 00000000..98231123 --- /dev/null +++ b/submissions/description/internal_infrastructure/simple_mail_transfer_protocol_user_enumeration/recommendations.md @@ -0,0 +1,3 @@ +# recommendation(s) + +Disable the commands VRFY, RCPT and EXPN in the SMTP server configuration. If this functionality is required, ensure it is only available to authenticated users. diff --git a/submissions/description/internal_infrastructure/simple_mail_transfer_protocol_user_enumeration/template.md b/submissions/description/internal_infrastructure/simple_mail_transfer_protocol_user_enumeration/template.md new file mode 100644 index 00000000..e24c2387 --- /dev/null +++ b/submissions/description/internal_infrastructure/simple_mail_transfer_protocol_user_enumeration/template.md @@ -0,0 +1,17 @@ +The Simple Mail Transfer Protocol (SMTP) server allowed unauthenticated users to enumerate valid users on the host. + +When connected to a mail server, common mail commands including EXPN, VRFY and RCPT TO can be used to infer the presence of valid users based on the responses returned by the server. When this functionality is available without authentication, it can be abused by an unauthenticated attacker to identify valid accounts on the system and leverage the discovered users in brute-force password guessing attacks. + +**Business Risk** + +This vulnerability may lead to indirect financial loss and reputational damage if an attacker is able to chain this vulnerability with another to achieve user account compromise and data exfiltration. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/simple_network_management_protocol_default_community_strings/guidance.md b/submissions/description/internal_infrastructure/simple_network_management_protocol_default_community_strings/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/simple_network_management_protocol_default_community_strings/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/internal_infrastructure/simple_network_management_protocol_default_community_strings/recommendations.md b/submissions/description/internal_infrastructure/simple_network_management_protocol_default_community_strings/recommendations.md new file mode 100644 index 00000000..01f4ec0f --- /dev/null +++ b/submissions/description/internal_infrastructure/simple_network_management_protocol_default_community_strings/recommendations.md @@ -0,0 +1,5 @@ +# recommendation(s) + +If possible, upgrade insecure SNMP versions (v1/2c) to SNMPv3, which provides more advanced security mechanisms, including encryption and password-based authentication. + +If it is not possible to upgrade the SNMP version, change all default community strings to suitably long, complex and unique values. diff --git a/submissions/description/internal_infrastructure/simple_network_management_protocol_default_community_strings/template.md b/submissions/description/internal_infrastructure/simple_network_management_protocol_default_community_strings/template.md new file mode 100644 index 00000000..e0874dc4 --- /dev/null +++ b/submissions/description/internal_infrastructure/simple_network_management_protocol_default_community_strings/template.md @@ -0,0 +1,21 @@ +The Simple Network Management Protocol (SNMP) server could be accessed using a default community string. + +SNMP provides monitoring capabilities to collect and poll information about devices (referred to as ‘agents’) on the network. In SNMP version 1 and 2c, access is commonly configured with default community strings to provide read-only and read-write access. + +If default community strings have not been updated to complex and secure values, an attacker located within the internal network could abuse this access to enumerate sensitive network configuration information. This may include; running processes, installed software, system info, hostnames, users, shares, services, listening ports, and any stored credentials. + +If write access is gained, an attacker could also modify configuration information. For example, it may be possible to change routing information, shutdown network interfaces, reboot systems, reset device passwords and more. In some cases, write access can also lead to remote code execution. + +**Business Risk** + +This vulnerability may lead to indirect financial loss and reputational damage if the information exposed by the service is leveraged in more advanced attacks or modified to compromise the system. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/ssh_server_password_authentication_supported/guidance.md b/submissions/description/internal_infrastructure/ssh_server_password_authentication_supported/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/ssh_server_password_authentication_supported/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/internal_infrastructure/ssh_server_password_authentication_supported/recommendations.md b/submissions/description/internal_infrastructure/ssh_server_password_authentication_supported/recommendations.md new file mode 100644 index 00000000..71d0af85 --- /dev/null +++ b/submissions/description/internal_infrastructure/ssh_server_password_authentication_supported/recommendations.md @@ -0,0 +1,3 @@ +# recommendation(s) + +Disable password-based authentication for SSH and enforce the use of public-key authentication. Disable direct root login via SSH; instead, use a non-privileged user and then sudo to root if necessary. Furthermore, consider setting a strong password on the authentication keys and the use of multi-factor authentication where possible. diff --git a/submissions/description/internal_infrastructure/ssh_server_password_authentication_supported/template.md b/submissions/description/internal_infrastructure/ssh_server_password_authentication_supported/template.md new file mode 100644 index 00000000..afcd9bb4 --- /dev/null +++ b/submissions/description/internal_infrastructure/ssh_server_password_authentication_supported/template.md @@ -0,0 +1,17 @@ +The SSH (Secure Shell) server was configured to accept password authentication and direct login by the root user. + +Password-based authentication is susceptible to brute-force attacks, especially when weak passwords are in use. This increases the likelihood of an attacker gaining unauthorised access to the host. Furthermore, if a brute-force attack is successful against the root user, this would grant the attacker administrator privileges over the vulnerable system. + +**Business Risk** + +Allowing weaker authentication mechanisms may lead to the system being compromised in the event that a brute-force password guessing attack is successful. Malicious actions such as data exfiltration, modification and service disruption from the compromised host may result in financial loss and reputation damage. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/ssh_server_weak_cipher_suites_supported/guidance.md b/submissions/description/internal_infrastructure/ssh_server_weak_cipher_suites_supported/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/ssh_server_weak_cipher_suites_supported/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/internal_infrastructure/ssh_server_weak_cipher_suites_supported/recommendations.md b/submissions/description/internal_infrastructure/ssh_server_weak_cipher_suites_supported/recommendations.md new file mode 100644 index 00000000..5a8dc4b5 --- /dev/null +++ b/submissions/description/internal_infrastructure/ssh_server_weak_cipher_suites_supported/recommendations.md @@ -0,0 +1,3 @@ +# recommendation(s) + +Configure SSH servers to use only strong and modern key-exchange, host-key, encryption, and MAC algorithms. Disable all deprecated and insecure algorithms. Regularly review and update the allowed algorithms based on current security best practices. diff --git a/submissions/description/internal_infrastructure/ssh_server_weak_cipher_suites_supported/template.md b/submissions/description/internal_infrastructure/ssh_server_weak_cipher_suites_supported/template.md new file mode 100644 index 00000000..225d29fe --- /dev/null +++ b/submissions/description/internal_infrastructure/ssh_server_weak_cipher_suites_supported/template.md @@ -0,0 +1,17 @@ +The SSH (Secure Shell) server supported key-exchange, host-key, encryption, or message authentication code (MAC) algorithms that are considered insecure. + +The use of these weak algorithms makes SSH communication vulnerable to various cryptographic attacks, potentially allowing attackers to decrypt sensitive data or tamper with communications. + +**Business Risk** + +This vulnerability negatively impacts the confidentiality and integrity of data. The severity of the impact to the business is dependent on the sensitivity of the data being stored and transmitted by the service. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/virtual_network_computing_sever_accessible_without_password/guidance.md b/submissions/description/internal_infrastructure/virtual_network_computing_sever_accessible_without_password/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/virtual_network_computing_sever_accessible_without_password/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/internal_infrastructure/virtual_network_computing_sever_accessible_without_password/recommendations.md b/submissions/description/internal_infrastructure/virtual_network_computing_sever_accessible_without_password/recommendations.md new file mode 100644 index 00000000..7ec27943 --- /dev/null +++ b/submissions/description/internal_infrastructure/virtual_network_computing_sever_accessible_without_password/recommendations.md @@ -0,0 +1,3 @@ +# recommendation(s) + +Disable the "None" authentication method on the VNC servers. Configure VNC servers to enforce strong authentication, ideally using a robust password or, where supported and feasible, integrate with existing authentication mechanisms like user accounts or multi-factor authentication. Restrict VNC access to authorized personnel and specific IP addresses or subnets through firewall rules and network segmentation. Regularly update VNC server software to the latest patched version to address any known vulnerabilities. diff --git a/submissions/description/internal_infrastructure/virtual_network_computing_sever_accessible_without_password/template.md b/submissions/description/internal_infrastructure/virtual_network_computing_sever_accessible_without_password/template.md new file mode 100644 index 00000000..24119e45 --- /dev/null +++ b/submissions/description/internal_infrastructure/virtual_network_computing_sever_accessible_without_password/template.md @@ -0,0 +1,17 @@ +The Virtual Network Computing (VNC) server had the "None" authentication method enabled. This configuration permits any client to connect to the VNC server and gain full graphical access to the remote desktop without requiring a valid password. + +An attacker situated in the local network may abuse this access to execute arbitrary commands on the host, install malicious software, read or exfiltrate sensitive data without leaving an authentication footprint, and leverage the system as a foothold from which target other internal network resources and/or pivot within the estate. + +**Business Risk** + +This vulnerability could lead to unauthorised system access, theft and manipulation of sensitive data. Such incidents can impact the organisation's operational security, result in financial losses, and damage the organisation's reputation, especially if customer data or critical business operations are compromised. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}} diff --git a/submissions/description/internal_infrastructure/x11_server_accessible_without_authentication/guidance.md b/submissions/description/internal_infrastructure/x11_server_accessible_without_authentication/guidance.md new file mode 100644 index 00000000..ee88d9d2 --- /dev/null +++ b/submissions/description/internal_infrastructure/x11_server_accessible_without_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/internal_infrastructure/x11_server_accessible_without_authentication/recommendations.md b/submissions/description/internal_infrastructure/x11_server_accessible_without_authentication/recommendations.md new file mode 100644 index 00000000..ad9a2193 --- /dev/null +++ b/submissions/description/internal_infrastructure/x11_server_accessible_without_authentication/recommendations.md @@ -0,0 +1,3 @@ +# recommendation(s) + +Disable unauthenticated access to X11 servers. Configure X11 to use secure authentication methods, or ideally, tunnel X11 connections over SSH using SSH X11 forwarding. Restrict X11 access to authorized users and IP addresses through proper configuration and firewall rules. diff --git a/submissions/description/internal_infrastructure/x11_server_accessible_without_authentication/template.md b/submissions/description/internal_infrastructure/x11_server_accessible_without_authentication/template.md new file mode 100644 index 00000000..cbabcb1e --- /dev/null +++ b/submissions/description/internal_infrastructure/x11_server_accessible_without_authentication/template.md @@ -0,0 +1,17 @@ +An X11 (X Windows) server was accessible without requiring authentication. This configuration, often referred to as "Open" access, allows any client on the network to connect to the X server and interact with the graphical display environment. + +An attacker with network access can leverage this configuration to perform various malicious actions, including: capturing screenshots of the graphical display, logging keystrokes, and executing arbitrary commands on the system in the context of the user running the X server. + +**Business Risk** + +This vulnerability could lead to unauthorised system access, theft and manipulation of sensitive data. Such incidents can impact the organisation's operational security, result in financial losses, and damage the organisation's reputation, especially if customer data or critical business operations are compromised. + +**Steps to Reproduce** + + + +**Proof of Concept (PoC)** + +The screenshot(s) below demonstrate(s) the vulnerability: +> +> {{screenshot}}