General Finding Name	Specific Finding Name	Description	Standard Remediation	References	Resources	Severity
Credential Management Weakness	Accounts Not Aligned with Password Policy	When password policies (e.g., those that define password lengths, complexity, and history) are not strictly enforced, some objects within the domain, such as service or user accounts, are not synced with the domain.	To ensure a high level of security for user accounts in Active Directory (AD), confirm that administrators configure the domain password policy in either Group Policy or fine-grained password policies. Ensure the policy is applied across all objects within the domain. Consider creating granular password policies that link with specific organizational units instead of editing Default Domain Policy settings.	https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-policy https://docs.microsoft.com/en-us/troubleshoot/windows-server/group-policy/password-policy-changes-not-applied	https://community.spiceworks.com/topic/1774907-creating-a-user-in-ad-that-goes-against-password-policy https://docs.microsoft.com/en-us/answers/questions/615313/active-directory-password-policy-complexity-enable.html https://docs.microsoft.com/en-us/answers/questions/118459/custom-change-in-39password-must-meet-complexity-r.html https://blog.netwrix.com/2021/07/14/active-directory-password-policy/#:~:text=NIST%20recommendations%20include%20the%20following,Unicode%20characters%20in%20their%20passwords. https://www.windows-active-directory.com/pso-ad-administrative-center.html http://woshub.com/password-policy-active-directory/ https://social.technet.microsoft.com/wiki/contents/articles/24159.active-directory-password-policies.aspx#Working_with_PSO_in_your_environment https://activedirectorypro.com/how-to-configure-a-domain-password-policy/	Medium
Credential Management Weakness	Password Reuse Across Privileged Accounts	An administrator may reuse their password across various privileged accounts or service accounts. This password reuse may be intentional for convenience or unintentional (e.g., an administrator installs a Microsoft Structured Query Language [MSSQL] server using their domain administrator account resulting in the MSSQL-Service account becoming an alias for their domain administrator account). Password reuse on administrative accounts risks lateral movement throughout the network and privilege escalation, which can allow attackers to access additional resources.	Enforce the password history and minimum/maximum password age settings to discourage users who want to reuse credentials after a period of time. Require that users change their password without reusing an old password to increase the effectiveness of a strong password policy. Implement multifactor authentication (MFA) for all user accounts.	https://docs.microsoft.com/en-us/answers/questions/615313/active-directory-password-policy-complexity-enable.html https://docs.microsoft.com/en-us/answers/questions/118459/custom-change-in-39password-must-meet-complexity-r.html	https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/enforce-password-history https://social.technet.microsoft.com/wiki/contents/articles/24159.active-directory-password-policies.aspx#Working_with_PSO_in_your_environment https://activedirectorypro.com/how-to-configure-a-domain-password-policy/	High
Credential Management Weakness	Password Reuse Across Standard and Privileged Accounts	Elevated password reuse is when an administrator uses the same password for their unprivileged and administrative accounts. If the unprivileged account’s password is compromised, it can be used to access the administrative account.	Do not allow those with administrative and unprivileged accounts to reuse or share their administrative credentials. Set and enforce secure password policies for accounts that conform to applicable federal standards, industry best practices, and/or agency-defined requirements (e.g., frequently change credentials to unique values across all workstations, use strong/complex passwords). Implement multifactor authentication (MFA) for all user accounts.	https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://attack.mitre.org/mitigations/M1027/	https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://attack.mitre.org/mitigations/M1027/	High
Credential Management Weakness	Insecure Group Policy Object Password Storage	Windows Server 2008 contains Group Policy Preferences that can manage and change passwords. While these passwords use Advanced Encryption Standard (AES) 256-bit encryption, an attacker can recover a plaintext password from affected policy files using the AES private key that is publicly available on the Microsoft Developer Network (MSDN).	Apply the Microsoft patch MS14-025. Manually remove all policy files that contain plaintext passwords.	https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://support.microsoft.com/en-us/topic/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevation-of-privilege-may-13-2014-60734e15-af79-26ca-ea53-8cd617073c30 https://adsecurity.org/?p=63	https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://adsecurity.org/?p=63 https://support.microsoft.com/en-us/topic/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevation-of-privilege-may-13-2014-60734e15-af79-26ca-ea53-8cd617073c30	Medium
Credential Management Weakness	NTLM Authentication Enabled	Windows New Technology LAN Manager (NTLM) authentication, introduced in Windows NT 3.1, validates whether a user is who they claim to be. A successor of LanMan (LM), NTLM authentication continues to use insecure methods through a hashing process of credentials. NTLM authentication also lacks effective support for smart cards and other multifactor authentication (MFA) solutions. If an attacker can obtain a username and a hash, they can conduct attacks such as Pass-the-Hash. On the client side, password hashes are stored in SYSTEM and Sequence Alignment Map (SAM) files, readable by anyone with administrator access. On the server side, password hashes are stored in the NTDS.dit file on the domain controller and are susceptible to DCSync attacks.	Since NTLM authentication has been replaced by Kerberos as the default authentication mechanism with the release of Windows 2000, organizations must disable NTLM authentication on systems that support it and modify the Group Policy settings to restrict NTLM. If necessary, create exception lists to allow specific servers access with NTLM authentication. Ensure that NTLMv1 is always disabled. Audit all NTLM traffic.	https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd560653(v=ws.10)https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj865676(v=ws.10)https://www.securew2.com/blog/why-ntlm-authentication-is-vulnerablehttps://securityboulevard.com/2018/10/the-security-risks-of-ntlm-proceed-with-caution/https://www.calcomsoftware.com/ntlm-security-weaknesses/		Medium
Credential Management Weakness	Weak Domain Account Password Usage	Without secure password configurations to enforce the creation of strong passwords, domain users and domain accounts can be created using weak passwords. If the network is compromised, user passwords can be easily cracked. Attackers can use automated tools to disguise their efforts as legitimate while taking control of the domain through privilege escalation, lateral movement, and persistence based on the accounts compromised. If a weak password is used with administrative accounts, compromise of the entire network can occur.	Implement strong password configurations and ensure that accounts created adhere to configuration settings. Configure security mechanisms, such as multifactor authentication (MFA), for all accounts. Reinforce strong cybersecurity awareness training for users within the domain to avoid password reuse across multiple accounts.	https://stealthbits.com/blog/attacking-weak-passwords-active-directory/		High
Credential Management Weakness	Weak Domain Password Policy	A weak domain password policy may not comply with applicable federal standards, industry best practices, and/or agency-defined requirements. That means that there might not be enforcement on password history, minimum/maximum password age, minimum password length, password complexity, or encryption protocols for password storage.	Implement a strong password policy across the domain according to national cybersecurity standards (e.g., National Institute of Standards and Technology [NIST] standards). Ensure that the password policy complies with applicable federal standards, industry best practices, and/or agency-defined requirements (e.g., use strong/complex passwords, prohibit the reuse of passwords, ensure all stored passwords are encrypted, and require administrators to use different passwords for their server accounts and other administrator accounts). Use multifactor authentication (MFA) for all administrative access, including domain administrative access.	https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-policy	https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-policy	High
Insecure Account Configuration	Excessive Group Permissions	Group accounts are used to collect user accounts, computer accounts, and other groups into manageable units. These accounts can assign user rights and permissions to security groups. When group permissions (explicit and inherited) are not managed properly, users of the group can be granted unintentional/excessive permissions, which, in turn, can be abused by an attacker. These abuses include adding users to groups, changing passwords without the current password, and Kerberoasting.	Ensure users are assigned to the appropriate groups and there are no unintended users. Periodically review group membership and remove unintended users. Ensure each group has the appropriate rights and permissions, and no extra permissions are granted to users. Allow personnel only with authorized accounts to handle permission delegation.	https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://cqureacademy.com/blog/hacks/active-directory-permissions https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups	https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://cqureacademy.com/blog/hacks/active-directory-permissions https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups	High
Insecure Account Configuration	Excessive Service Account Permissions	Applications use service accounts to run automated processes. For Windows, the types of service accounts are local user, LocalSystem, domain user, and NetworkService. Because service account lifecycles are linked to non-human privileged accounts that often run in the background, managing them is difficult. This lack of visibility can result in sprawling, forgotten, and obsolete service accounts that expose the organization to risk. Service accounts can be overprivileged and, if compromised, can be used to access off-system resources and cause system outages or failures.	Implement a service account lifecycle management program. Identify and audit existing service accounts to discover if they are still in use, and implement the principle of least privilege. Do not manually manage service accounts; implement an automated system for creating and managing new service accounts. Create a response plan for when service accounts are disrupted to minimize system outages.	https://www.beyondtrust.com/blog/entry/how-to-manage-and-secure-service-accounts-best-practices	https://www.beyondtrust.com/blog/entry/how-to-manage-and-secure-service-accounts-best-practices	High
Insecure Account Configuration	Excessive User Account Permissions	User account permissions control user access to host or application resources that can include sensitive information. When users are granted greater access than they need to perform their required duties, their permissions become excessive. These additional permissions can allow the user of the overprivileged account to perform unauthorized tasks, gain unauthorized access to restricted data, and compromise accounts.	Implement the principle of least privilege. Implement focused auditing on the use of administrative privileged functions. Monitor for organizational resources for anomalous behavior.	https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf	https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf	High
Insecure Account Configuration	Stale Domain Groups and Accounts	Active Directory (AD) environments contain an account for every user. When a user leaves an organization, their user account can be forgotten. Other accounts can be detected as stale or inactive based on the user's last password change or logon timestamp. Although these accounts are forgotten or stale, they are often not deleted or removed from privileged groups. Not deleting them allows former employees and attackers to use the accounts to facilitate privilege escalation within the domain, gaining unauthorized access to sensitive data. While more strict policies may be currently implemented, remnants of old domain configurations can be archived and pose a security risk to the organization.	Review privileged groups within the domain, and ensure only accounts that are necessary and active are present. Ensure administrators periodically perform access/account reviews to identify stale accounts within the domain. Ensure administrators use tools such as dsquery, dsmod, and dsrm to monitor, disable, and remove inactive user and group accounts.	https://docs.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/regularly-check-for-and-remove-inactive-user-accounts-in-active-directory	https://docs.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/regularly-check-for-and-remove-inactive-user-accounts-in-active-directory	Informational
Insecure Active Directory Configuration	Dangerous Object Configuration	Active Directory (AD) objects have Access Control Lists (ACLs), which explicitly define or inherit permissions from a parent object. Such permissions can be allowed or denied on the object and its properties. Poorly configured AD permissions can result in resource-based delegation (RBCD) attacks and unconstrained delegation attacks. RBCD is controlled by the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, which stores a descriptor for object access. An attacker can abuse this attribute if they have write permissions to the attribute on the target computer. Unconstrained delegation is an administrator privilege that can impersonate user credentials for resource access by caching authenticated user's Ticket Granting Ticket (TGT). If enabled, attackers can discover the cached credentials and export private certificates, reuse credentials, and obtain access to domain controllers and privileged users via privilege escalation and lateral movement.	Ensure the principle of least privilege applies to all objects and their descendants and that the inheritance of that access control is limited. Disable the unconstrained delegation property on servers and configure constrained delegation for those that require it. For privileged accounts, enable the "Account is sensitive and cannot be delegated" setting. Add necessary accounts to the Protected Users Security Group.	https://www.sentinelone.com/blog/detecting-unconstrained-delegation-exposures-in-ad-environment/ https://stealthbits.com/blog/resource-based-constrained-delegation-abuse/	https://blog.fox-it.com/2018/04/26/escalating-privileges-with-acls-in-active-directory/ https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/acl-persistence-abuse https://wald0.com/?p=112 https://msdn.microsoft.com/en-us/library/windows/desktop/aa379557(v=vs.85).aspx	Medium
Insecure Active Directory Configuration	Insecure AD CS Enrollment Service	Active Directory Certificate Services (AD CS) Enrollment Services with weak or default configurations can be abused by an attacker or domain user to request a certificate as a domain controller. Using the Microsoft Encrypting File System Remote (MS-EFSRPC) protocol, an attacker can target a domain controller to send Domain Controller (DC) New Technology LAN Manager (NTLM) credentials to the AD CS) Web Enrollment pages and enroll a domain controller certificate. This enrollment results in the attacker obtaining an authentication certificate that can be used to gain elevated domain service access and compromise the entire domain. Default configurations, such as Hypertext Transfer Protocol (HTTP) and New Technology NTLM authentication are found within the Certificate Authority (CA) Web Enrollment service and also pose a security risk to the domain. Such configurations may allow an attacker to create an NTLM authentication to themselves and relay the created authentication to web enrollment in the victim’s domain. This will enable the attacker to enroll for certificates and use them for authentication.	Disable AD CS enrollment services or restrict access only to those who need to access it. If the AD CS web enrollment service must remain enabled, ensure that NTLM authentication is disabled to protect against certain forms of Pass-the-Hash and relay attacks. If NTLM must be enabled, also enable Extended Protection for Authentication (EPA) and require Transport Layer Security (TLS). Block connections initiated by domain controllers or limit connections to tier 0 hosts and services. Use Remote Procedure Call (RPC) filters to block MS-EFSRPC.	https://www.paloaltonetworks.com/blog/security-operations/detecting-active-directory-certificate-services-abuse-with-cortex-xdr/ https://www.truesec.com/hub/blog/mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-adv210003-kb5005413-petitpotam	https://www.paloaltonetworks.com/blog/security-operations/detecting-active-directory-certificate-services-abuse-with-cortex-xdr/ https://www.truesec.com/hub/blog/mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-adv210003-kb5005413-petitpotam	High
Insecure Active Directory Configuration	Insecure KRBTGT Account Configuration	The Kerberos Ticket Granting Ticket (KRBTGT) account is a local default account that cannot be renamed or deleted and is the only account able to generate and sign every Kerberos ticket in the domain. The KRBTGT account is typically untouched by administrators and is not usually kept in a password rotation, unlike other accounts within a domain. Privileged users can obtain the hash of the KRBTGT account and potentially change the KRBTGT password. If an attacker can escalate privileges and obtain password hashes of the KRBTGT account, attacks such as Golden Ticket or a DCSync attack can occur. Persistence can be achieved if a user successfully controls a KRBTGT account.	Frequently reset any KRBTGT accounts rather than changing the password in case a newly restored domain controller replicates with a compromised domain controller. Monitor all privileged user access. When changing the password of the KRBTGT account, reset the password twice to remove old passwords from the password history, paying attention to replication within the Active Directory (AD) domain controllers.	https://blog.quest.com/what-is-krbtgt-and-why-should-you-change-the-password/ https://blog.quest.com/6-ad-security-public-service-announcements/ https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn745899(v=ws.11)?redirectedfrom=MSDN#Sec_KRBTGT https://www.alteredsecurity.com/post/resource-based-constrained-delegation-rbcd	https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#unconstrained-domain-persistence https://www.youtube.com/watch?v=1BU2BflUHxA	High
Insecure Active Directory Configuration	Vulnerable Certificate Templates	Active Directory Certificate Services (AD CS) provides templates for issuing and managing certificates. Such templates can include information about enrollment policies, predefined certificate settings, and other properties. Misconfiguring various elements of AD CS templates can result in domain escalation by unauthorized users (e.g., granting low-privileged users certificate enrollment rights, allowing requesters to specify a subjectAltName in the certificate signing request (CSR), not requiring authorized signatures for CSRs, granting FullControl or WriteDacl permissions to users).	Restrict enrollment rights to only those users or groups that require it. Disable the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag from templates to prevent users from supplying and editing sensitive security settings within these templates. Enforce manager approval for requested certificates. Remove FullControl, WriteDacl, and Write property permissions from low-privileged groups, such as domain users, to certificate template objects, where such permissions are not needed.	https://posts.specterops.io/certified-pre-owned-d95910965cd2	https://posts.specterops.io/certified-pre-owned-d95910965cd2	High
Insecure Active Directory Configuration	Weak Kerberos Encryption	Kerberos can use a variety of cipher algorithms to protect data. A Kerberos encryption type is a combination of a cipher algorithm and an integrity algorithm for confidentiality and integrity. The key distribution center (KDC) selects the encryption type of the session key, which should have the strongest encryption type available for itself and the service the ticket is granted for. Since the KDC uses only the first key in the list of long-term keys for encryption, weak encryption types, such as Data Encryption Standard (DES), DES3, hash-based message authentication code (HMAC), and Rivest Cipher 4 (RC4) may be enabled and used.	Ensure that newly created keys are not used with weak or deprecated encryption schemes or algorithms by excluding weak or deprecated encryption types under the supported_enctypes setting of the kdc.conf configuration file. Upgrade or migrate the krbtgt/REALM, kadmin/history, and other kadmin principals to ensure a single key entry has a supported and strong cipher algorithm. Use various methods supported by the Massachusetts Institute of Technology (MIT) to migrate user and service principles away from deprecated encryption types. Ensure the Group Policy does not default to weak encryption types within the adclient.krb5.permitted.encryption.types and adclient.krb5.tkt.encryption.types parameter values.		https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/kdc_conf.html#encryption-types https://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos https://docs.centrify.com/Content/config-gp/KerberosAuthAllowWeakEncryption.htm	High
Insecure Mobile Access Control	Insecure Authorization	Insecure authorization is a vulnerability that can allow an attacker to use installed malware or a botnet to bypass authentication and log in as a legitimate user. The attacker can then force-browse to a vulnerable endpoint and execute administrator functionality. Any improper authentication measures in place render authorization insecure. Examples of improper authentication measures are having insecure direct object reference vulnerabilities, assuming hidden endpoints will not be seen outside a certain role, and allowing the mobile application to transmit user permissions or roles as part of a backend request.	Do not use requests that contain permissions or roles that come from a mobile device. Authenticate only with backend information.	https://owasp.org/www-project-mobile-top-10/2016-risks/m6-insecure-authorization	https://owasp.org/www-project-mobile-top-10/2016-risks/m6-insecure-authorization https://www.computerworld.com/article/2701951/how-to-perform-basic-api-authorization-for-mobile-applications.html	High
Mobile Cryptographic Weakness	Insecure Data Storage	Insecurely storing data is a vulnerability that allows an attacker to obtain sensitive information, including obtaining a lost or stolen mobile device. With physical access to a device, an attacker can use readily available free software to search directories that likely contain personally identifiable information (PII) and other sensitive information. An attacker might also modify or inject malware into the device to obtain information and use that information to commit fraud or identity theft, violate privacy, damage reputations, violate external policies, or cause material loss. Susceptibility to insecure data storage is mostly associated with poor encryption on the device.	Avoid using jailbroken or rooted devices since they bypass encryption protections. Ensure that mobile devices have proper encryption protections for stored data since both users and malware can easily access filesystems. Understand how application program interfaces (APIs) and applications handle information. Analyze areas, including Uniform Resource Locator (URL) caching, logging, third-party analytics data sent, browser cookie objects, intermediate data, application backgrounding, copy/paste buffer caching, and keyboard press caching.	https://owasp.org/www-project-mobile-top-10/2016-risks/m2-insecure-data-storage		Medium
Mobile Cryptographic Weakness	Insecure Communication	Session identifiers (IDs) and data exchanged by mobile-to-mobile, app-to-server, server-to-app, or mobile-to-X are susceptible to being intercepted if communication channels are not secure. Wi-Fi, cellular, Transmission Control Protocol/Internet Protocol (TCP/IP), Bluetooth, Bluetooth Low Energy (LE), short message service (SMS), and other communication methods can be used insecurely and can tamper with data integrity, confidentiality, and origin integrity. If an attacker can intercept sensitive data, the user’s confidentiality might be violated and result in reputation damage, fraud, or identity theft. Devices using insecure communication also can be vulnerable to machine-in-the-middle (MITM) attacks, eavesdropping, and offline attacks. A poor Secure Sockets Layer (SSL) configuration facilitates MITM and phishing attacks.	Use strong SSL/TLS (Transport Layer Security) connections when transporting sensitive data and session tokens to a backend webservice or application programming interface (API). When possible, use another layer of encryption for sensitive data before it is sent through SSL channels. Use certificates that are signed by a trusted certificate authority (CA). Do not allow self-signed certificates, and notify the user through the user interface (UI) if an invalid certificate is detected.	https://owasp.org/www-project-mobile-top-10/2016-risks/m3-insecure-communication https://cwe.mitre.org/data/definitions/347.html https://owasp.org/www-community/attacks/Manipulator-in-the-middle_attack https://cwe.mitre.org/data/definitions/300.html	https://www.rapid7.com/fundamentals/man-in-the-middle-attacks/ https://www.netsparker.com/blog/web-security/man-in-the-middle-attack-how-avoid/ https://enterprise.verizon.com/resources/articles/s/what-are-eavesdropping-attacks/  https://www.trendmicro.com/vinfo/hk-en/security/news/cybercrime-and-digital-threats/security-101-protecting-wi-fi-networks-against-hacking-and-eavesdropping	Medium
Mobile Design Weakness	Extraneous Functionality	Excessive functionality on a device can lead to vulnerabilities. Attackers can exploit these vulnerabilities by finding functions and information that developers did not intend to leave behind. An attacker can download an application and examine configuration files, user acceptance testing (UAT) environments, staging, binaries, and log files to find hidden switches and test code not meant to be included. Attackers can then access information about backend servers, execute unauthorized privileged actions, steal intellectual property, and access sensitive functions.	Examine application configuration settings to discover hidden switches. Remove all test code from the production build. Ensure that logs do not contain descriptive information about the backend.	https://owasp.org/www-project-mobile-top-10/2016-risks/m10-extraneous-functionality	https://owasp.org/www-project-mobile-top-10/2016-risks/m10-extraneous-functionality	Medium
Mobile Design Weakness	Improper Platform Usage	An attacker can exploit an organization’s misuse or failure to follow published platform (e.g., Android, iOS) guidelines to extract information from a device. For example, application programming interfaces (APIs) or web services exposed to a device with unintentional vulnerabilities can be exploited.	Focus on server-side security controls to help protect mobile devices (e.g., Android, iOS). Maintain good configuration practices (e.g., removing unnecessary default content). Implement secure coding practices. Ensure there is strong authentication and session management, including input validation. Use proper access controls.	https://owasp.org/www-project-mobile-top-10/2016-risks/m1-improper-platform-usage	https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html https://wiki.owasp.org/index.php/Testing_for_authentication https://owasp.org/www-project-web-security-testing-guide/ https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html	Medium
Mobile Design Weakness	Lack of Binary Protections	Applications with missing or insufficient binary protections are vulnerable to reverse engineering. Using publicly available tools, an attacker can reverse engineer an application to understand the binaries by analyzing control flows, string tables, and source code. Such analyses can reveal ciphers, information about backend servers, and data that can be exploited to inject or modify code. An attacker can then steal sensitive information and intellectual property (IP), gain unauthorized access to data, and pirate the application, which can cause revenue and reputation loss.	Obfuscate applications to prevent easy reverse engineering. Test the obfuscation method by attempting to de-obfuscate code using publicly available tools. Implement secure coding techniques (e.g., jailbreak detection, checksum, certificate pinning, debugger-detection controls).	https://owasp.org/www-project-mobile-top-10/2016-risks/m9-reverse-engineering https://owasp.org/www-project-mobile-top-10/2014-risks/m10-lack-of-binary-protections	https://owasp.org/www-project-mobile-top-10/2016-risks/m9-reverse-engineering https://wiki.owasp.org/index.php/Architectural_Principles_That_Prevent_Code_Modification_or_Reverse_Engineering	High
Mobile Design Weakness	Modifiable Code	Modifiable code is a vulnerability that allows an attacker to modify application package core binaries and resource binaries, and replace or redirect application programming interfaces (APIs) to execute malicious code or intercept code. By gathering information in this way, an attacker can pirate the application, access new features, cause reputational damage, and commit identity theft and fraud.	Constantly monitor code throughout runtime to ensure it was not modified. Implement mechanisms for detecting whether a device has been rooted or jailbroken.	https://owasp.org/www-project-mobile-top-10/2016-risks/m8-code-tampering	https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project https://owasp.org/www-project-mobile-top-10/2016-risks/m8-code-tampering	High
Mobile Design Weakness	Poor Code Quality	Poor code quality can lead to vulnerabilities that attackers can exploit to compromise a system. Attackers can use fuzzing or static analysis tools to detect exploitable vulnerabilities in a mobile application (e.g., buffer overflows, format string vulnerabilities, and memory leaks) that can lead to data theft and reputational damage.	Write code that is easy to read and is well documented. Validate the length of buffer data against its target buffer length. Use third-party tools to detect memory leaks and buffer overflows. Prioritize third-party tools and buffer validation measures over issues with code quality.	https://owasp.org/www-project-mobile-top-10/2016-risks/m7-client-code-quality	https://owasp.org/www-project-mobile-top-10/2016-risks/m7-client-code-quality	Low
Email Spoofing Susceptibility	Missing DKIM Record	DomainKeys Identified Mail (DKIM) uses signatures to authenticate emails. DKIM adds an encrypted signature to each outgoing message's email header, which is signed with the sender’s private key. DKIM is used to validate the signature in the header of signed messages by using the sender’s public key.	Configure email servers to attach DKIM signatures to emails.	https://support.google.com/a/answer/174124?hl=en, http://www.dkim.org, https://dmarc.org/wiki/FAQ#How_does_DMARC_work.2C_briefly.2C_and_in_non-technical_terms.3F	https://support.detectify.com/support/solutions/articles/48001048962-missing-dkim-record, https://dkimcore.org/specification.html	Medium
Email Spoofing Susceptibility	Missing DMARC Record	Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication mechanism and addon to the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). Rules can be configured with DMARC for emails that fail authentication checks (e.g., report, reject). Since there are no defined filters when DMARC is missing, phishing emails can easily be sent.	Generate and publish a DMARC record in the Domain Name System (DNS). Verify that this record exists within the DNS and is accessible.	https://dmarc.org/wiki/FAQ#How_does_DMARC_work.2C_briefly.2C_and_in_non-technical_terms.3F	https://dmarcly.com/blog/how-to-fix-no-dmarc-record-found https://dmarcmonitor.net/fix-missing-dmarc-record-error/ https://support.detectify.com/support/solutions/articles/48001048963-missing-insufficient-dmarc-record	Medium
Email Spoofing Susceptibility	Missing SPF Record	The Sender Policy Framework (SPF) uses paths to authenticate emails. It prevents spoofed messages by verifying that a message claiming to have been sent by the organization actually came from the organization and was sent from a server authorized by the organization. If SPF records are not included for a domain, an attacker can use that domain in the sender's address in a phishing email.	Update or create a text (TXT) record for the SPF at the domain provider for the organization’s domain(s). Verify that it works properly by sending a spoofed email from outside the network.	https://support.google.com/a/answer/33786, https://dmarc.org/wiki/FAQ#How_does_DMARC_work.2C_briefly.2C_and_in_non-technical_terms.3F	https://geekflare.com/fix-email-spoofing-missing-spf-record-vulnerability/ https://support.google.com/a/answer/33786 https://support.detectify.com/support/solutions/articles/48001048956-missing-insufficient-spf-record	Medium
Email Spoofing Susceptibility	S/MIME Not Enabled	The Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol allows users to generate a certificate from a certificate authority (CA) that attaches their identity to a public key. The user can encrypt emails and digitally sign their emails using this certificate. Digital signatures use asymmetric cryptography to validate the identity of the email sender. This approach can distinguish spoofed emails since the attacker does not have access to the public/private key pair needed to digitally sign an email associated with the user’s identity.	Enable S/MIME to encrypt messages and authenticate via digital signatures. Establish a CA to issue S/MIME certificates for the organization. Train users on about generating certificates and using S/MIME to encrypt and digitally sign emails.			Medium
Social Engineering Susceptibility	Phishing Email Susceptibility	Email phishing is the most common type of phishing, where an adversary sends emails to target recipients that contain fake hyperlinks in an effort to trick the recipient into clicking on them and disclosing personal information or opening attachments containing malware. The senders of these emails frequently pose as important account providers, co-workers, financial organizations (i.e., banks), and others. If an organization does not have phishing prevention and detection measures in place, it is more vulnerable to phishing. Individuals are more vulnerable to phishing if they are easily persuaded and are not trained to identify phishing emails. Individuals may be targeted for spear phishing attacks if they have access to critical systems or important information.	Provide training about phishing, threat response, spam filtering, and phishing detection systems. If an individual is phished, test and audit the systems used to find the initial domain access point(s). Address and secure the results of these tests and audits to minimize the damage an attacker can cause if they gain access to the internal network.	https://www.microsoft.com/en-us/security/business/security-101/what-is-phishing?ef_id=b4f814899ed11b3c078676681374cbb9:G:s&OCID=AIDcmmdamuj0pc_SEM_b4f814899ed11b3c078676681374cbb9:G:s&msclkid=b4f814899ed11b3c078676681374cbb9 https://www.researchgate.net/publication/351945314_Testing_the_Susceptibility_of_Employees_to_Phishing_Emails		High
Social Engineering Susceptibility	Credential Harvesting Susceptibility	Credential harvesting (i.e., password harvesting or credential stuffing) is a process where attackers “harvest” or collect valid credentials (e.g., email addresses, usernames, and passwords) through planned breaches. Because it is likely that many users use the same credentials across multiple platforms, attackers are motivated to steal and sell these credentials on the dark web. One frequently cited source for this social engineering technique is the use of phishing emails. Credential harvesting is more likely to happen if both the organization and its users are not properly trained or equipped to deal with this threat.	Provide credential harvesting awareness training. Minimize external-facing services and/or restrict access based on endpoint checks. Implement user cybersecurity and awareness training. Update security software and patch it whenever prompted. Implement multifactor authentication (MFA) and/or secondary passwords, personal identification numbers (PINs), and security questions. Use Internet Protocol (IP) block-listing to prevent known malicious IP addresses from accessing the network. Apply credential policies (e.g., requiring unpredictable usernames and frequent password changes, disallowing password reuse).	https://www.mgocpa.com/article/credential-harvesting https://owasp.org/www-community/attacks/Credential_stuffing https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html	https://unit42.paloaltonetworks.com/credential-harvesting/ https://owasp.org/www-community/attacks/Credential_stuffing	High
Unblocked Malicious Code	Malicious File Download	A malicious payload is a payload that bypasses host protections and downloads successfully on a user’s system. Dangerous file types that are frequently sent by email include .exe, .doc, .xls, .xlsx, .pdf, .docx, .rtf, .xlsm, and .vbs. When delivering malicious payloads, these potentially malicious files can also be contained in other file types, such as compressed or archived files, disk images, and scripts.	Implement employee cybersecurity training; perform continuous virus scanning, file scanning, and inspection; continuously monitor the network; and implement spam filters/phishing detection systems, firewalls, and zero-trust policies.	https://www.certifiedcio.com/2021/04/22/malicious-downloads/ https://www.statista.com/statistics/1238996/top-malware-by-file-type/	https://www.file-extensions.org/filetype/extension/name/dangerous-malicious-files	High
Unblocked Malicious Code	Malicious File Execution	After downloading (through an email attachment or direct link), malicious files can be executed with or without user interaction. This malicious file execution can happen if the user’s system mistakenly believes the malicious payload to be legitimate, or the malicious file might successfully bypass any security measure(s) in place to detect and prevent it from running. The attacker might obfuscate these files to improve the chances of their successful execution, which may allow the attacker to gain a foothold in the organization’s system and carry out attacks that would compromise the confidentiality, integrity, and availability (CIA) of the system. Common malicious file types used are .exe, .hta, .js, .dll, and .cpl.	Use an antivirus program and set up a firewall to detect malware. Disable macro scripts in Microsoft Office files that are transmitted in email. Use a domain reputation service to detect and block suspicious or malicious domains. Use browser and application sandboxes or remote virtual environments to mitigate browser or other application exploitation.	https://www.cisa.gov/uscert/ncas/alerts/aa21-200b https://attack.mitre.org/techniques/T1204/002/		High
Unblocked Malicious Code	Malicious Code Execution Within Document	A user may download a document that contains malicious software from phishing email or an insecure website. The document might contain a malicious or embedded (and heavily obfuscated) macro, script, or Object Linking and Embedding (OLE). With OLE, the malicious code is installed from an external website after it is triggered. The execution of the malicious code can be with or without user interaction, depending on the type. Once the malware is installed, the attacker can gain a foothold on the user’s system.	Use a domain reputation service to detect and block suspicious or malicious domains. Enforce a Group Policy setting that disables macro from executing through protected view or protected editing, preventing macros from running automatically. Keep up to date with patches. Use file sanitization techniques (e.g., converting to another format, which can retain valuable information while eliminating embedded malware and stripping out embedded objects in document). Create blocklists. Perform static and dynamic analyses of downloaded documents.	https://blog.barracuda.com/2019/04/04/threat-spotlight-document-based-malware/ https://www.opswat.com/blog/using-data-sanitization-eliminate-malware-embedded-documents https://docs.microsoft.com/en-us/microsoft-365/security/intelligence/macro-malware?view=o365-worldwide		High
Unblocked Malicious Code	Mark-of-the-Web Bypass	Mark-of-the Web (MOTW) controls are used to protect files by preventing them from executing certain potentially malicious actions. Example controls are opening files in protected view or comparing them with an allow list of executables. These controls are automatically applied to files downloaded from the Internet in Windows. Attackers can bypass these controls to deliver malicious payloads by using compressed, archived, and/or disk image file types that are not supported by New Technology File System (NTFS), of which MOTW is a feature. The most common use case demonstrated is smuggling payloads by using optical disc image (ISO) files.	Disable or remove features or programs (e.g., automounting disk image files). If possible, block container file types (e.g., compressed or archived files, disk images) at web and/or email gateways and entry points.	https://attack.mitre.org/techniques/T1553/005/ https://outflank.nl/blog/2020/03/30/mark-of-the-web-from-a-red-teams-perspective/		High
Insecure Protocol Implementation	Insecure SMB Usage	Server Message Block (SMB) is an application layer protocol that allows computers on a network to connect to the SMB server to access shared files or perform network-based tasks (e.g., printing). An SMB server is known to have vulnerabilities if the most recent SMB version is not maintained or if it is configured incorrectly. An attacker who exploits these vulnerabilities can remotely execute code or gain unauthorized access to sensitive information.	Disable SMBv1 or update it to the most recent version. Update and patch all affected hosts on systems that use SMB. Restrict SMB access to only trusted users and networks using the principle of least privilege. Disable SMB on Windows platforms if it is not required.	https://cybersophia.net/articles/what-is/what-is-smb-protocol-and-why-is-it-a-security-concern/		Medium
Insecure Protocol Implementation	Insecure SNMP Usage	Network administrators use the Simple Network Management Protocol (SNMP) to monitor and configure devices on the network. If a network system uses SNMPv1 or SNMPv2, the information transmitted using the protocol is vulnerable to compromise. Because data passed using these protocols is not encrypted, an attacker on the network can gain access to this data using a protocol analyzer.	Ensure all affected hosts and servers on the system use SMNPv3 or higher. Ensure no SNMP agents use Dynamic Host Configuration Protocol (DHCP). Use Internet Protocol (IP) Security (IPsec) and the Transport Security Model (TSM) to secure traffic.	https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/spectrum/10-4/managing-network/secure-domain-manager-sdm/snmp-traffic-passing-across-insecure-networks.html	https://www.comparitech.com/net-admin/common-snmp-vulnerabilities/	Low
Insecure Protocol Implementation	LDAP Signing Not Required	Lightweight Directory Access Protocol (LDAP) signing is a feature of LDAP’s Simple Authentication and Security Layer (SASL), which is the communication protocol used to access Active Directory (AD). There are unsafe default LDAP signing configurations on Active Directory domain controllers that allow LDAP clients to communicate with them without requiring LDAP signing. These configurations can result in privilege escalation on AD domain controllers. Unsigned network traffic is also vulnerable to machine-in-the-middle (MITM) attacks or replay attacks when a ticket is issued.	Set LDAP signing to “Require Signing” in the Group Policy settings. Configure servers to reject SASL LDAP binds that do not request signing as integrity verification, and/or reject LDAP simple binds that are performed on a clear text channel (one that is not SSL/TLS [Secure Sockets Layer/Transport Layer Security] encrypted). Enforce validation of LDAP signing on servers within the domain.		https://msrc.microsoft.com/update-guide/en-us/vulnerability/ADV190023 https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/enable-ldap-signing-in-windows-server	Medium
Insecure Protocol Implementation	SMB Signing Not Required	Server Message Block (SMB) signing is a security mechanism built into the SMB protocol that generates signatures for all SMB messages sent over the network. Each signature field contains a hash of the SMB message to determine whether an attacker has tampered with the data. A remote network system that does not require SMB message signing can be used to launch machine-in-the-middle (MITM) and replay attacks against the network’s remote SMB server. When this vulnerability is exploited, a remote attacker can gain sensitive information, such as login credentials, which can lead to further exploits.	Enforce SMB message integrity checks on all systems and affected hosts within Group Policy Management. Restrict SMB login privileges to network users.	https://www.beyondsecurity.com/scan-pentest-network-vulnerabilities-smb-signing-disabled https://www.blackhillsinfosec.com/an-smb-relay-race-how-to-exploit-llmnr-and-smb-message-signing-for-fun-and-profit/  https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing		Medium
Insecure Protocol Implementation	Unencrypted Protocol Usage	Information is vulnerable to compromise when it is transmitted within a network using an unencrypted protocol (e.g., Telnet, Server Message Block [SMB], File Transfer Protocol [FTP]). This vulnerability can allow an attacker on the network to gain access or tamper with sensitive information by capturing and/or modifying traffic.	Do not rely on unencrypted protocols to relay information on networks. Switch to an encrypted version of the protocol or another encrypted protocol.	https://securityboulevard.com/2018/12/whats-the-problem-with-smb-1-and-should-you-worry-about-smb-2-and-3/		Medium
Insecure System or Service Configuration	Default Database Accounts or Tables	Attackers use default accounts or database tables to access systems. Default, blank, or weak accounts can allow an attacker to access an account and gain a foothold on systems.	Remove or disable default accounts and databases. If a default account is required, restrict access to it and change its name and password to comply with applicable federal standards, industry best practices, and/or agency-defined requirements.	https://nvd.nist.gov/vuln/search/results?adv_search=true&form_type=Advanced&query=cpe:/a:microsoft:sql_server:2016 https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html#mysql-and-mariadb https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-1209	https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials	Medium
Insecure System or Service Configuration	Excessive Database Permissions	Excessive permissions granted to database users creates opportunities for an attacker to abuse their access to those databases. Users that have excessive permissions can access information that they should not have permission to view, write, or execute. An attacker can abuse those permissions by querying, creating, or dropping tables, or inserting/modifying data.	Ensure that database users are granted permissions that follow the principle of least privilege. If administrative permissions are needed, grant local access rather than access to the entire database instance.	https://nvd.nist.gov/vuln/search/results?adv_search=true&form_type=Advanced&query=cpe:/a:microsoft:sql_server:2016 https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html#mysql-and-mariadb https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf	https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html	High
Insecure System or Service Configuration	Insecure Database Configuration	To protect the organization’s stored data and the database server, database applications must be properly configured and hardened. The database scan report can identify database misconfigurations and vulnerabilities. If the organization’s database configuration is compromised, data can be stolen, manipulated, or used for other cyber-attacks.	Keep up to date with any required security updates and patches. Consider configuring database services to run under a low-privileged user account. Remove any default accounts and databases. Store transaction logs on a separate disk from the database’s main files, and configure a regular backup of the database. Ensure that the backup and main databases are encrypted, protected with appropriate permissions, and that they follow industry best practices.	https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html https://1library.net/article/insecure-database-configuration-sql-injection-attacks-defense-pdf.oz1o0g3q	https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database	Informational
Insecure System or Service Configuration	Insecure Default System or Service Configuration	Default configurations of systems, services, accounts, and applications can permit unauthorized access. Many off-the-shelf applications are released with built-in administrative accounts that use predefined credentials that can often be found with a simple web search. As a result, an attacker—even one with minimal technical knowledge—can use these credentials to access related services.	Review all vendor applications and appliances to ensure that appropriate hardening measures are in place. Change, remove, or deactivate all default credentials. Before deploying new devices in a networked environment, change all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other services.	https://learning.oreilly.com/library/view/industrial-cybersecurity/9781788395151/88dfd411-5154-4e1f-8177-760f8d9242e1.xhtml https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration	https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/02-Test_Application_Platform_Configuration.html https://csrc.nist.gov/publications/detail/sp/800-123/final	Medium
Insecure System or Service Configuration	Unsafe Stored Procedures Enabled	When stored procedures are improperly implemented, they are susceptible to Structured Query Language (SQL) injection attacks. A stored procedure can be vulnerable when dynamic SQL inside the procedure is not handled properly. This vulnerability can occur because of a lack of user input sanitation or incorrect use of dynamic cursors. When a stored procedure is exploited, an attacker can access and manipulate information in the affected database or execute system-level commands.	Always validate user input. Avoid using dynamic SQL queries inside stored procedures. Ensure that a low-privileged account runs the database. Use procedures with embedded parameters.	https://www.paladion.net/blogs/are-stored-procedures-safe-against-sql-injection https://owasp.org/www-project-top-ten/2017/A1_2017-Injection, https://owasp.org/www-project-top-ten/ https://www.sqlinjection.net/advanced/stored-procedure/	https://solutioncenter.apexsql.com/secure-stored-procedures-against-sql-injection/ https://www.paladion.net/blogs/are-stored-procedures-safe-against-sql-injection https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html https://cwe.mitre.org/data/definitions/89.html	Medium
Insecure System or Service Configuration	Weak Local Account Password Usage	Weak local account passwords are used when authentication mechanisms that use a password to identify a user on a local machine use easily compromised or default passwords (e.g., using common, expected, or known compromised local account passwords). Without a strong password policy, attackers can compromise user accounts by guessing the password manually or using automated means (e.g., brute-force attack, dictionary attack). Failure to enforce secure password requirements makes local accounts more susceptible to compromise.	Enforce a strict and secure password policy. Ensure that all users who receive account access change the default passwords for their local accounts. Enforce a minimum password length. Restrict password reuse, common passwords, and using passwords with contextual strings (e.g., user id). Consider using randomly generated one-time passwords (OTPs), password expiration, and multifactor authentication (MFA).	https://cwe.mitre.org/data/definitions/521.html https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf		Medium
Insecure System or Service Configuration	Weak Local Password Policy	A weak password policy can enable an attacker to gain unauthorized access to a system or application; it may allow users to use weak passwords that lack length and complexity, never change their password, reuse old passwords. A weak password policy may also not require multifactor authentication (MFA).	Establish and enforce a strong password policy that includes requirements for password length, complexity, minimum password age, and password history. Ensure that the policy contains suggestions for enforcement and describes the consequences (e.g., lost system access) when the policy is not followed. Require multifactor authentication (MFA) for all user accounts that have access to sensitive data or systems. MFA can be achieved using smart cards, certificates, one-time password (OTP) tokens, or biometrics.	https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Password_Policy https://owasp.org/www-community/attacks/Brute_force_attack, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf	https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Password_Policy https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf	Medium
System Access Control Weakness	Insecure File Permissions	Giving a file or directory a permissions setting that allows access to a wider range of domain users than necessary could expose sensitive information or allow unauthorized users to modify the file. This level of access can result in additional exploits, particularly if the data in the file is related to program configuration, execution, or sensitive user data. An attacker can abuse these permissions to modify or misuse critical resource data, run executable files, and more.	Set the permissions of all files and directories to prevent unauthorized domain users from accessing critical resources. When using a critical resource, make sure it doesn’t have insecure permissions; if it does, generate an error or exit the software if the resource appears to have been modified by an unauthorized person. Explicitly set the default permissions or umask to the most restrictive setting possible during program startup. Ensure appropriate permissions are set during program installation.	https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/09-Test_File_Permission https://cwe.mitre.org/data/definitions/732.html		Medium
System Access Control Weakness	Unauthenticated File Share or Server Access	A server or resource that does not restrict access to explicitly authenticated users can allow attackers to probe for sensitive information. This access could include anonymous File Transfer Protocol (FTP) or null Server Message Block (SMB) access, both of which could allow an unknown attacker to gain information about the network and/or access to its resources. Some FTP server software is installed with anonymous access enabled by default, allowing attackers to access the FTP server with any password by using the feature’s default account. Access to the FTP server allows an unauthorized user to scan the network or download sensitive files. Using SMB null sessions, an attacker can gain access to the IPC$ share and interact with services exposed using named pipes. By using these sessions, Windows allows anonymous users to perform certain activities (e.g., enumerating the names of domain accounts and network shares).	Disable guest or anonymous access to resources like FTP and SMB. Ensure critical data and services are protected so that only authenticated users can access them.	https://dirteam.com/sander/2021/09/22/hardening-smb-on-domain-controllers-step-3-disabling-smb-null-sessions/https://support.skyvera.com/hc/en-us/articles/4411096503570-Security-Vulnerability-Accessible-Anonymous-FTP-Server https://book.hacktricks.xyz/network-services-pentesting/pentesting-smb#ipcusd-share https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/inter-process-communication-share-null-session		Medium
System Access Control Weakness	Insufficient Network Segmentation or Segregation	An unauthorized malicious actor can gain access to critical resources and sensitive information if networks are not segmented and segregated. When network segmentation is not properly implemented, an attacker can use their access to internal resources to avoid detection or perform lateral movement more easily.	To minimize the network’s attack surface, ensure that networks are not flat. Partition the network into smaller networks to restrict access to sensitive information and critical servers. Develop and enforce rules for controlling the communications between specific hosts. Implement server and domain isolation using Internet Protocol (IP) Security (IPsec).	https://deltarisk.com/blog/how-insufficient-network-segmentation-increases-your-security-risk/ https://www.cyber.gov.au/acsc/view-all-content/publications/implementing-network-segmentation-and-segregation		Medium
Unnecessary Network Services	Link-Local Multicast Name Resolution Enabled	The Link-Local Multicast Name Resolution (LLMNR) protocol is used for alternate host identification if the default host identification system is not working. However, LLMNR can allow an impersonator to respond to unqualified domain name system (DNS) requests (i.e., those that lack a fully qualified domain name) posing as various authenticated services (e.g., Server Message Block [SMB] servers, web proxies, Remote Desktop Protocol [RDP]). The victim computer and/or user would then respond to the impersonating system with username and password credentials that can be relayed to another valid service, which can be captured, brute-force cracked, or both.	Disable the LLMNR protocol.	https://kb.ndsu.edu/page.php?id=106754	https://kb.ndsu.edu/page.php?id=106754	High
Unnecessary Network Services	NetBIOS Name Service Enabled	The NetBIOS Name Service (NBT-NS) is a backup host-identification system. An impersonator can use NBT-NS to intercept Windows credentials.	Disable NBT-NS.	https://kb.ndsu.edu/page.php?id=106754	https://kb.ndsu.edu/page.php?id=106754	High
Unnecessary Network Services	Multicast Domain Name System Enabled	The Multicast Domain Name System (mDNS) protocol is designed to resolve hostnames to Internet Protocol (IP) addresses in small networks that do not include a local name server. If an mDNS service is exposed to the Internet, querying the service allows hackers to collect information about the server (e.g., the device’s media access control [MAC] address information or services). Attackers can then use this information to prepare an attack.	Disable the mDNS protocol. If mDNS must be used, configure the firewall to block incoming connections to User Datagram Protocol (UDP) 5353 and allow access to only trusted network IPs and hosts that need to contact the mDNS service.	https://kb.iweb.com/hc/en-us/articles/360005117952-Guide-to-Multicast-DNS-mDNS-security-issues	https://kb.iweb.com/hc/en-us/articles/360005117952-Guide-to-Multicast-DNS-mDNS-security-issues	High
Unnecessary Network Services	Print Spooler Service Enabled	Windows devices can carry out a print job in two ways: by opening the required port to send the information directly to the output device or by using the Print Spooler service. The latter is designed to be a general interface for print jobs and is responsible for managing all jobs sent to the printer or print server. This service contains a vulnerability that affects the print queue when enabled. The print queue, in particular, does not restrict access to the RpcAddPrinterDriverEx function, allowing an attacker to run malicious programs on a device and perform remote code execution. Successfully exploiting this vulnerability allows an attacker to escalate privileges and compromise the confidentiality, integrity, and availability (CIA) of the organization’s system and assets.	Apply security updates and patches to Windows devices. Review the Print Spooler registry settings and ensure that the applicable settings are set to zero or are undefined to disable the Windows Print Spooler service in domain controllers and systems that do not print. Disable inbound remote printing via Group Policy. Follow guidelines offered by Microsoft for the Windows Print Spooler Remote Code Execution Vulnerability.	https://msrc-blog.microsoft.com/2021/07/08/clarified-guidance-for-cve-2021-34527-windows-print-spooler-vulnerability/ https://touchstonesecurity.com/microsoft-print-spooler-patch/ https://www.cisa.gov/uscert/ncas/current-activity/2021/06/30/printnightmare-critical-windows-print-spooler-vulnerability	https://support.microsoft.com/en-us/topic/ms10-061-vulnerability-in-print-spooler-service-could-allow-remote-code-execution-5b97b890-c408-e75c-ed8b-71dcacc1a3ea https://nvd.nist.gov/vuln/detail/CVE-2021-34527 https://msrc-blog.microsoft.com/2021/07/08/clarified-guidance-for-cve-2021-34527-windows-print-spooler-vulnerability/ https://docs.microsoft.com/en-us/defender-for-identity/security-assessment-print-spooler https://www.windowscentral.com/how-mitigate-print-spooler-printnightmare-vulnerability-windows-10	High
Unnecessary Network Services	WebClient Service Enabled	The Windows WebClient service supports connections to a Web-Based Distributed Authoring and Versioning (WebDAV) server and its shares. WebDAV is a set of extensions to Hypertext Transfer Protocol (HTTP) that allows authorized users to edit and manage files collaboratively on remote web servers. To access the WebDAV server, the WebClient service must be enabled. When WebClient is enabled, the service contains a buffer overflow vulnerability that gives remote authenticated users or adversaries the ability to execute arbitrary code using crafted Remote Procedure Call (RPC) requests. Successfully exploiting this buffer overflow vulnerability allows an adversary to enter the organization’s system via WebDAV and take complete control of the affected system.	Disable the WebClient service if not needed (e.g., through Group Policy settings, command prompt, Windows Control Panel Settings). If the service is needed, apply the recommended workarounds from Microsoft, such as blocking Transmission Control Protocol (TCP) ports 139 and 445 at the firewall.			High
Unpatched System or Service	Unpatched BlueKeep Vulnerability	BlueKeep is a remote code execution vulnerability that exists in Remote Desktop Protocol (RDP). An unauthenticated attacker can use RDP to connect to the target system and send specially crafted requests. This pre-authentication vulnerability requires no user interaction. An attacker who exploits this vulnerability can execute arbitrary code on the target system and install programs; view, change, or delete data; or create new accounts with full user rights.	Update Windows on the affected hosts.	https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-0708 https://www.tenable.com/blog/cve-2019-0708-bluekeep-exploits-could-be-around-the-corner	https://www.tenable.com/plugins/nessus/125313	High
Unpatched System or Service	DD-WRT Router Information Disclosure	A vulnerability in the DresDren-Wireless RouTer (DD-WRT) firmware on a router allows information about the router to be disclosed that can lead to further compromise of a wireless network. An attacker can find the media access control (MAC) addresses of router interfaces, connected clients, and sometimes the Global Positioning System (GPS) coordinates, if the router is registered with Google location services.	Update the DD-WRT firmware on routers to the latest version.	https://www.tenable.com/plugins/nessus/51394, https://www.exploit-db.com/exploits/15842	http://www.devttys0.com/wp-content/uploads/2010/12/dd-wrt_info_disclosure.pdf	Medium
Unpatched System or Service	Unpatched Eternal Blue Vulnerability	Eternal Blue (i.e., MS17-010) is a remote code-execution vulnerability that affects Windows hosts. The vulnerability is caused by the improper handling of certain requests in Microsoft Server Message Block 1.0 (SMBv1). When exploited with a specially crafted packet, an unauthenticated attacker can execute arbitrary code.	Update Windows on the affected hosts.	https://www.tenable.com/cve/CVE-2017-0144	https://docs.microsoft.com/en-us/security-updates/securitybulletins/2017/ms17-010 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1472	High
Unpatched System or Service	Unpatched Heartbleed Vulnerability	Heartbleed is a vulnerability that affects outdated versions of the Open Secure Sockets (OpenSSL) cryptographic software library Transport Layer Security/Datagram Transport Layer Security (TLS/DTLS) protocols. When exploited, this vulnerability leaks memory content from the communication between the server and client, resulting in information disclosure and/or data exfiltration.	Update OpenSSL on the affected hosts.	https://heartbleed.com/	https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0160 https://www.tenable.com/plugins/lce/801617	High
Unpatched System or Service	Unpatched Log4Shell Vulnerability	Log4Shell is a remote code execution vulnerability of Apache Log4j V2, versions older than version 2.15.0 (excluding security releases) that do not protect JNDI features from attacker-controlled Lightweight directory access protocol (LDAP), and other Java Naming and Directory Interface-related (JNDI-related) endpoints. When message lookup substitution is enabled, an attacker with control over log messages or log message parameters can execute arbitrary code loaded from LDAP servers.	Upgrade to a version of Apache Log4j that is version 2.16.0 or higher.	https://cert-portal.siemens.com/productcert/pdf/ssa-397453.pdf	https://fossa.com/blog/quickly-find-remediate-log4j-vulnerabilities-log4shell/	High
Unpatched System or Service	Unpatched MS08-067 Vulnerability	MS08-067 is a remote code execution vulnerability that affects Windows hosts. The vulnerability is caused by the improper handling of remote procedure call (RPC) requests in the Server service. When exploited with a specially crafted RPC request, an unauthenticated attacker can execute arbitrary code with System privileges.	Update Windows on the affected hosts.	https://www.tenable.com/plugins/nessus/34476	https://docs.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-067	High
Unpatched System or Service	Unpatched PrintNightmare Vulnerability	PrintNightmare is a remote code execution vulnerability that occurs when the Windows Print Spooler service performs privileged file operations incorrectly. An attacker who exploits this vulnerability can execute arbitrary code on the target system and install programs; view, change, or delete data; or create new accounts with full user rights.	Update Windows on the affected hosts.	https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527		High
Unpatched System or Service	Unpatched ProxyLogon Vulnerability	ProxyLogon is a series of vulnerabilities in Microsoft Exchange Server that are caused by the improper validation of Uniform Resource Identifier (URI) requests to port 443, an inconsistency in backend and frontend handling of the msExchLogonMailbox header, and the improper validation of user filepath input from PowerShell to the DDIService. Attackers can exploit these vulnerabilities to perform remote code execution, bypass authentication, impersonate an administrator, upload arbitrary files, and execute arbitrary code with administrator privileges.	Update the affected installations of Microsoft Exchange Server.	https://devco.re/blog/2021/08/06/a-new-attack-surface-on-MS-exchange-part-1-ProxyLogon/	https://www.cpomagazine.com/cyber-security/understanding-proxylogon-vulnerabilities-and-how-to-secure-them/ https://devco.re/blog/2021/08/06/a-new-attack-surface-on-MS-exchange-part-1-ProxyLogon/; https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26855;  https://proxylogon.com/	High
Unpatched System or Service	Unpatched ProxyShell Vulnerability	ProxyShell is an attack chain that exploits three vulnerabilities in Microsoft Exchange Servers. The main remote code execution vulnerability exists in the handling of the mailbox export, which does not properly validate user-supplied data, allowing the upload of arbitrary files. Exploiting this main vulnerability requires authentication, but other vulnerabilities in the Autodiscover and PowerShell services allow an attacker to bypass authentication and elevate their user privileges. Specifically, the Autodiscover service does not properly validate Uniform Resource Identifiers (URIs) before accessing resources, and the PowerShell service does not properly validate an access token before executing the Exchange PowerShell command. When these vulnerabilities are exploited, an attacker can execute arbitrary code in the context of the system.	Update the affected installations of Microsoft Exchange Server.	https://www.zerodayinitiative.com/advisories/ZDI-21-819/ https://www.zerodayinitiative.com/advisories/ZDI-21-821/ https://www.zerodayinitiative.com/advisories/ZDI-21-822/	https://www.techtarget.com/whatis/feature/Everything-you-need-to-know-about-ProxyShell-vulnerabilities	High
Unpatched System or Service	Unpatched Shellshock Vulnerability	Shellshock is a remote code-execution vulnerability that affects hosts that run outdated versions of Bash that are also susceptible to command injection by manipulating environmental variables.	Update Bash on the affected hosts.	https://www.tenable.com/plugins/nessus/77823	https://www.tenable.com/plugins/nessus/77823 https://nvd.nist.gov/vuln/detail/CVE-2014-6271 https://nvd.nist.gov/vuln/detail/CVE-2014-7169	High
Unpatched System or Service	Unpatched Zerologon Vulnerability	The Zerologon vulnerability (i.e., Zerologon or Microsoft Windows Netlogon Remote Protocol [MS-NRPC]) uses an initialization vector (IV) of zero when the IV should be a random number. When exploited, an unauthenticated attacker can impersonate a domain-joined computer or domain controller and obtain domain administrator privileges.	Update Windows on the affected hosts.	https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-1472 https://www.trendmicro.com/en_us/what-is/zerologon.html https://www.kb.cert.org/vuls/id/490028 https://www.kb.cert.org/vuls/id/490028	https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-1472	Critical
Unsupported OS or Application	Unsupported Windows Version	A system that runs an unsupported Windows version can no longer receive software updates from Microsoft. These updates protect systems from malicious software and viruses. Publicly known, unpatched vulnerabilities are easy exploits for an attacker and can be used to compromise the organization’s system and assets.	Upgrade to a supported version of Windows. Keep track of the organization’s unsupported Windows machines by continually monitoring their use and applying access control to isolate them from primary networks.	https://support.microsoft.com/en-us/windows/what-does-it-mean-if-windows-isn-t-supported-08f3b92d-7539-671e-1452-2e71cdad18b5 https://perspectiverisk.com/top-5-most-common-network-vulnerabilities-unsupported-operating-systems-and-apps/		High
Unsupported OS or Application	Unsupported Unix Version	When an unsupported version of Unix is used, the application/OS vendor does not release new security patches, leaving it vulnerable to security risks. Unpatched, publicly known vulnerabilities are easy for an attacker to exploit and can be used to compromise the organization’s system and assets. Using an unsupported Unix version can also cause poor performance, increased downtime, software compatibility issues, and regulatory compliance failures.	Upgrade to a supported version of Unix. Keep track of the organization’s unsupported Unix machines by continually monitoring their use and applying access control to isolate them from primary networks.	https://perspectiverisk.com/top-5-most-common-network-vulnerabilities-unsupported-operating-systems-and-apps/ https://github.com/abelbrenes/Repositorio-experimental-documental/blob/master/2020-04-20%20page_%20indidente-01.md https://blog.cloudlinux.com/5-risks-of-using-end-of-life-operating-system		High
Unsupported OS or Application	Unsupported Software Version	Software has a lifecycle and will eventually become unsupported when a newer version is released. There are security risks to consider if an organization uses an unsupported version of the software. The software will no longer be updated or patched for security, functionality, or general maintenance; hardware may stop working; and the vendor will not resolve issues. An attacker can exploit these vulnerabilities to compromise the organization’s system or network and gain access to sensitive data.	Upgrade to a supported version of the software. Ensure that all software (including third-party software and external software) is up to date.	https://www.rccbusinessit.com/company/blog-news/risks-of-unsupported-software		High
Injection Weakness	Improper Input Handling	Improper input handling occurs when functions like validation, sanitization, filtering, encoding, and/or decoding of input data are not implemented correctly. This weakness is common in web applications and can make these applications vulnerable to attacks (e.g., buffer overflows, Structured Query Language [SQL] injections, and denial of service [DoS]).	Ensure the web application is performing server-side validation checks and client-side validation. Implement input sanitation and filtering mechanisms to allow acceptable input types and block unacceptable ones.	http://projects.webappsec.org/w/page/13246933/Improper%20Input%20Handling	http://projects.webappsec.org/w/page/13246933/Improper%20Input%20Handling	Medium
Injection Weakness	Improper Output Handling	Improper output handling can take various forms within an application (e.g., protocol errors, application errors, and data-consumer-related errors). Protocol errors include missing or improper output encoding. Or they can include escaping and outputting invalid data. Application errors include logic errors, such as outputting incorrect data or passing on unfiltered malicious content. Data-consumer-related errors occur if the application does not distinguish legitimate content from illegitimate content. An application that does not provide data in the correct context can allow an attacker to abuse the data consumer.	Ensure proper output handling to prevent the consumer from interpreting data in unexpected or unintended ways. Ensure that output filtering and sanitizing are consistent throughout the application. When choosing output-handling strategies, assume that all data in the application is untrusted.	http://projects.webappsec.org/w/page/13246934/Improper%20Output%20Handling	http://projects.webappsec.org/w/page/13246934/Improper%20Output%20Handling	Low
Insecure Web Application Configuration	Application Misconfiguration	Application misconfiguration can happen at any level of an application stack, including the network services; platform; web server; application server; database; frameworks; custom code; and pre-configured virtual machines, containers, or storage. Default configurations or misconfigurations typically result in insecure applications, which can leave an organization vulnerable to attack.	Review and apply the appropriate security configurations to applications. Minimize and remove unnecessary features and software to reduce possible attack vectors. Establish a repeatable automated hardening process that installs and validates the configurations and settings in all environments.	https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration		Medium
Insecure Web Application Configuration	Exposed Administrative Interface	Administrative interfaces in a web application or web server may allow users to perform privileged actions on the application, affecting site functionality. These administrative interfaces may be hidden and not directly linked to the main application or server; however, an attacker can still access its content through insufficient authentication mechanisms (e.g., brute forcing server contents), bypassing multifactor authentication (MFA) through session cookie stealing, directory and file enumeration, etc. An attacker who gains unauthorized access to the exposed application interfaces can make significant changes (e.g., provisioning user accounts, changing the site design or layout, manipulating data, and changing configurations). These changes can put the entire website or server at risk.	Ensure administrative interfaces and configuration management are accessible only by authorized users and administrators. Ensure that administrative interfaces use strong authentication mechanisms. Limit the use of encrypted communication channels for remote administration.	https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces	https://blog.securityinnovation.com/blog/2010/12/protect-your-administration-interfaces.html	Medium
Insecure Web Application Configuration	Insecure Default Web Application Configuration	Insecure default configurations on web applications and servers can be unsuitable for the tasks performed on them. Attackers can perform post-installation exploitation and compromise the security of the web application or server if insecure default configurations are not removed. After a default installation, an attacker can gain access to sensitive information using default credentials (e.g., admin, 1234), logs (e.g., debug information, stack traces, usernames, internal Internet Protocol [IP] addresses, personal data), application source code (e.g., informational inline comments), and more. An attacker can easily use these insecure default configurations to gain access to administrative or user accounts, introduce denial-of-service (DoS) attacks, wipe out logs, force log rotations, etc.	Disable all default credentials. Handle server errors using custom pages rather than default web server pages. Ensure that no sensitive information is stored in machine.config and root web.config files since by default all users can read these files. Maintain logs in a separate location rather than on the web server. Ensure that the directories where logs are stored are in separate partitions. Ensure that log information is never visible to users. Ensure that log statistics and/or analyses are not generated or stored on the same server where the logs were produced.	https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/02-Test_Application_Platform_Configuration https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/02-Testing_for_Default_Credentials#:~:text=%E2%80%9Cadmin%E2%80%9D%2C%20%E2%80%9Cpassword%E2%80%9D,An%20empty%20or%20blank%20password.		Medium
Insecure Web Application Configuration	Server Misconfiguration	Server misconfiguration attacks exploit configuration weaknesses. Many servers come with unnecessary defaults, including those for applications, configuration files, scripts, and webpages. Servers can also have unnecessary services enabled, such as content management and remote administration functionality. These features enable an attacker to bypass authentication methods and access sensitive information, perhaps with elevated privileges.	Review and apply appropriate security configurations to the affected server. Minimize and remove unnecessary features and software to reduce the number of possible attack vectors. Establish a repeatable automated hardening process that installs and validates the configurations and settings in all environments.	http://projects.webappsec.org/w/page/13246959/Server%20Misconfiguration	http://projects.webappsec.org/w/page/13246959/Server%20Misconfiguration	Medium
Insecure Web Application Configuration	XML External Entity Enabled	Many older or poorly configured Extensible Markup Language (XML) processors evaluate external entity references in XML documents. Attackers can use these external entities to disclose internal files using the file Uniform Resource Identifier (URI) handler, internal file shares, internal port scanning, remote code execution, and denial-of-service (DoS) attacks.	Whenever possible, use less complex data formats, such as JavaScript Object Notation (JSON), and avoid the serialization of sensitive data. Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system. Use dependency checkers. Update Simple Object Access Protocol (SOAP) to version 1.2 or higher. Disable XML external entity and document type definition (DTD) processing in all XML parsers in the application. Implement positive (allow list) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes. Verify that XML or Extensible Stylesheet Language (XSL) file-upload functionality validates incoming XML using XML Schema Definition (XSD) validation or similar.		https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html	Medium
Web Application Authentication Weakness	Insufficient Anti-Automation	Insufficient anti-automation occurs when a web application permits an attacker to automate a process that was originally designed to be performed manually by a human web user (e.g., application login forms).	Implement a Completely Automated Public Turing test to Tell Computers and Humans Apart (CAPTCHA) mechanism. There are multiple types of CAPTCHAs. One type might distort text inside images and ask the user to type the text. Another type might ask the user to answer simple math problems or common-sense questions. Yet another type might be an audio CAPTCHA that asks the user to type the word that is played.	http://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation	http://projects.webappsec.org/w/page/13246938/Insufficient%20Anti-automation	Medium
Web Application Authentication Weakness	Insecure Authentication Mechanism	Insecure authentication mechanisms allow an attacker to execute functionality or obtain sensitive information on an application without properly authenticating their identity. An example of insecure authentication is an application with administrative functionality but no validating authentication mechanisms. If authentication is insecure, an attacker can brute force password logins or bypass multifactor authentication (MFA) by stealing session cookies. If the attacker does not gain administrative access, the ability to view protected documents provides another attack layer. Even if these protected administrative resources are hidden and not directly linked to the main application, if secure authentication mechanisms are not in place, an attacker can still access their contents through enumeration (e.g., navigating to common file and directory locations such as /admin/, error messages, referrer logs, documentation, help files). Without proper authentication mechanisms, attackers can gain unauthorized administrative access to resources and compromise the web application.	Implement host-based and user-based access controls to Uniform Resource Locators (URLs), which can contain sensitive information. Enforce a strong password policy for all applications. Remove or change all default credentials. Use MFA. Ensure developers understand the business logic of the web application. Validate business processes and technical requirements throughout the stages of application development. Avoid making assumptions about user or application behavior.	http://projects.webappsec.org/w/page/13246939/Insufficient%20Authentication https://www.informit.com/articles/article.aspx?p=442984&seqNum=4 https://www.vaadata.com/blog/what-are-business-logic-flaws-on-web-applications/#:~:text=A%20logic%20flaw%20happens%20when,a%20technical%20mistake%20in%20itself. https://portswigger.net/web-security/authentication https://portswigger.net/web-security/logic-flaws	http://projects.webappsec.org/w/page/13246939/Insufficient%20Authentication https://www.informit.com/articles/article.aspx?p=442984&seqNum=4 https://www.vaadata.com/blog/what-are-business-logic-flaws-on-web-applications/#:~:text=A%20logic%20flaw%20happens%20when,a%20technical%20mistake%20in%20itself. https://portswigger.net/web-security/authentication https://portswigger.net/web-security/logic-flaws	Medium
Web Application Authentication Weakness	Insecure Password Recovery Mechanism	There are many insecure password recovery mechanisms, including not requiring the original password, sending a new password to a different email address than the user’s, sending the original password to the user, using common security questions, providing password hints, and sending non-expiring tokens by phone or via short message service (SMS). Attackers can exploit these insecure password recovery mechanisms to gain unauthorized access to legitimate user accounts and information.	Establish a secure password recovery mechanism (e.g., one that uses expiring tokens). Use strong security questions and limit the number of incorrect answers allowed. Disable password recovery after a certain number of incorrect guesses. If a user answers the security questions correctly, do not reveal the original password; provide a temporary password for the user to reset. Do not allow the user to control which email address the new password is sent to. Ensure SMS or phone call tokens expire and are invalidated after they are used.	https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities https://cwe.mitre.org/data/definitions/640.html https://www.informit.com/articles/article.aspx?p=442984&seqNum=4	https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities https://cwe.mitre.org/data/definitions/640.html https://www.informit.com/articles/article.aspx?p=442984&seqNum=5	Medium
Web Application Authentication Weakness	Insecure Session Management	Insufficient session management can cause vulnerabilities that allow an attacker to assume the identity of a valid user by targeting or stealing the user’s session identifier (ID) token. With insecure session management, an attacker can reuse a user’s session ID, predict it, or force it to an explicit value, allowing the attacker to bypass an application’s authentication mechanisms and impersonate a valid user or a valid session.	Use an encrypted Hypertext Transfer Protocol Secure (HTTPS) connection with the most recent version of Transport Layer Security (TLS) for the duration of the web session. Use the secure cookie attribute to ensure the session ID is exchanged only through an encrypted channel. Implement cookie attributes, such as HttpOnly and SameSite, to avoid accepting session IDs from malicious sources. Set an expiration date for sessions and credentials. Use up-to-date session-management implementations built into web development frameworks that avoid predictable session IDs and other implementation vulnerabilities.	https://www.acunetix.com/blog/web-security-zone/what-is-session-fixation/ http://projects.webappsec.org/w/page/13246960/Session%20Fixation https://owasp.org/www-community/attacks/Session_Prediction http://projects.webappsec.org/w/page/13246944/Insufficient%20Session%20Expiration https://cwe.mitre.org/data/definitions/613.html	https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-id-properties	Medium
Web Application Authentication Weakness	Weak Web Account Password Usage	When application users fail to create strong account passwords, the user accounts are vulnerable to attacks. An attacker may be able to guess or brute force the password through manual or automated means and gain access to sensitive information.	Use a strong password policy. Ensure that passwords adhere to the current password policy. Enforce using complex passwords. Prohibit password reuse. Ensure all stored passwords are encrypted. Configure security mechanisms (e.g., multifactor authentication [MFA]) for all web account access.	https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-policyhttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdfhttps://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-policy		Medium
Web Application Authentication Weakness	Weak Web Application Password Policy	Users are likely to use weak passwords when an application has a weak password policy, making the application vulnerable to password-guessing attacks. Signs of a weak password policy include the lack of a password encryption protocol and failure to enforce password history, minimum/maximum age, minimum length, and complexity.	Ensure that credential rotation is conducted periodically or when a password leak occurs. Set a password length requirement of at least eight characters. Include a password-strength meter to help users create a more complex password and block common and previously breached passwords. Use password history settings to prevent users from reusing past passwords. Ensure that password policy configurations comply with applicable federal standards, industry best practices, and/or agency-defined requirements (e.g., prohibit the reuse of passwords, ensure all stored passwords are encrypted). Configure security mechanisms (e.g., multifactor authentication [MFA]) for all web account access.	https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html  https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-policy https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-123.pdf https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/password-policy		Medium
Web Application Access Control Weakness	Improper Web Server Filesystem Permissions	Improper file system permissions threaten a web application's confidentiality, integrity, and availability (CIA). When incorrect file system permissions are set on files, directories, and symbolic links, an attacker can access restricted files or directories and modify or delete their contents.	Use the principle of least privilege. Review and change the permissions of files and symbolic links on the affected host.	http://projects.webappsec.org/w/page/13246932/Improper%20Filesystem%20Permissions	http://projects.webappsec.org/w/page/13246932/Improper%20Filesystem%20Permissions	High
Web Application Access Control Weakness	Excessive Data Disclosure	Excessive data disclosure is voluntarily sharing information about a web application that intentionally exposes excessive/unnecessary data (e.g., versions of software in use, images revealing sensitive information) to application users. This disclosure can result in undesirable data exposure in a built-in webpage or section of it. An attacker can use this information to compromise the confidentiality, integrity, and availability (CIA) of the organization's web application or server.	Enforce and review data-disclosure policies to ensure excessive/unnecessary data is not published to web applications. Ensure that services running on the application server’s open ports do not reveal sensitive information about its builds and versions.	https://www.dailyrazor.com/blog/10-web-application-security-best-practices-to-secure-your-data/ https://infosecwriteups.com/all-about-information-disclosure-5edb5459a514		Low
Web Application Access Control Weakness	Information Leakage	Information leakage occurs when an application reveals sensitive data (e.g., technical, environmental, or user-specific data) about the application. Information leakage can result from improper configurations of applications or servers, differences in page responses for valid versus invalid data, and/or Hypertext Markup Language (HTML) or script comments that contain sensitive information. An attacker can use the sensitive data to exploit the target web application, hosting network, or their users.	Disable Hypertext Transfer Protocol (HTTP) (and similar) headers. Use clean Uniform Resource Locators (URLs) and generic cookie parameters. Disable client-side error reporting in production environments. Sanitize template data and data passed to the client.	http://projects.webappsec.org/w/page/13246936/Information%20Leakage#:~:text=Information%20Leakage%20is%20an%20application,hosting%20network%2C%20or%20its%20users https://www.hacksplaining.com/prevention/information-leakage	http://projects.webappsec.org/w/page/13246936/Information%20Leakage#:~:text=Information%20Leakage%20is%20an%20application,hosting%20network%2C%20or%20its%20users.	Low
Web Application Access Control Weakness	Insufficient Authorization	Insufficient authorization occurs when an application does not perform adequate authorization checks, making it easier for attackers to access functions or data.	Ensure that authorization checks enforce a security policy that requires a user or application to perform a function or access data in a secure manner. Integrate standard authorization frameworks to determine which application resources users can access. Implement access control logic, and constantly check it throughout the development process. Implement secure coding practices. Maintain full control over third-party infrastructures.	http://projects.webappsec.org/w/page/13246940/Insufficient%20Authorization https://www.invicti.com/blog/web-security/how-to-avoid-authentication-and-authorization-vulnerabilities/	http://projects.webappsec.org/w/page/13246940/Insufficient%20Authorization https://www.invicti.com/blog/web-security/how-to-avoid-authentication-and-authorization-vulnerabilities/	Medium
Web Application Cryptographic Weakness	Insufficient Transport Layer Protection	Insufficient transport layer protection allows communication to be exposed to untrusted third parties, providing an attack vector that can be exploited to compromise a web application and/or steal sensitive information. When the transport layer is not encrypted, all communication between the website and client is sent in clear text, which leaves it open to interception, injection, and redirection. Secure Sockets Layer and Transport Layer Security (SSL/TLS) are typically used to provide encryption at the transport layer.	Implement proper transport layer protection in the affected application with secure protocols and strong ciphers with appropriate key lengths. Apply SSL/TLS to transport channels that the application uses to transmit sensitive information. Use certificates signed by a trusted certificate authority (CA) provider.	http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection https://owasp.org/www-project-mobile-top-10/2014-risks/m3-insufficient-transport-layer-protection	http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection  https://owasp.org/www-project-mobile-top-10/2014-risks/m3-insufficient-transport-layer-protection	Medium
Web Application Cryptographic Weakness	Insecure Usage of SSL/TLS	Insecure use of Secure Sockets Layer and Transport Layer Security (SSL/TLS) protocols is a vulnerability that can allow an attacker to exploit connections. All SSL versions and TLS versions 1.0 and 1.1 are weak and/or deprecated. Multiple SSL vulnerabilities (e.g., DROWN, POODLE, BEAST) have compromised many networks and applications. Insecure versions of TLS (i.e., TLS 1.0 and TLS 1.1) are obsolete and not in compliance with the Payment Card Industry Data Security Standard (PCI DSS). TLS 1.0 was also deemed insecure by the predefined security policy ELBSecurityPolicy-2016-08 and should not be used.	Disable SSL completely throughout the network and move all connections to TLS version 1.2 or later since they are proven to be secure. Follow compliance standards (e.g., National Institute of Standards and Technology [NIST] 800-53) that define how to configure and implement TLS protocols. Audit TLS protocol connections and update them as needed per system. For systems using TLS 1.0 or TLS 1.1, update and configure them to a more recent version (1.2 or 1.3). Implement intrusion prevention systems and detection systems (IPS/IDS).	https://cloudone.trendmicro.com/docs/network-security/insecure_SSL_TLS_NSoptomize/#:~:text=Insecure%20SSL%2FTLS%20Protocol%20Using%20insecure%20and%20deprecated%20protocols,and%20POODLE%20%28Padding%20Oracle%20On%20Downgraded%20Legacy%20Encryption%29.		Medium
Web Application Cryptographic Weakness	Weak SSL/TLS Encryption Cipher	This weakness refers to a Secure Sockets Layer/Transport Layer Security (SSL/TLS) implementation or a flaw in its algorithm. For SSL ciphers, this weakness includes any encryption cipher that uses the Triple Data Encryption Algorithm (3DES) or key lengths between 64 and 112 bits. The SSL/TLS encryption cipher Rivest Cipher 4 (RC4) allows an attacker to decrypt plaintext that has been encrypted repeatedly (e.g., Hypertext Transfer Protocol [HTTP] cookies). Using a weak SSL/TLS encryption cipher can allow an attacker to bypass or intercept the encryption of sensitive data in transit (DIT) to obtain ciphertext in plaintext. During configuration of TLS 1.2, the client and server can negotiate which algorithm to use; if the configuration is implemented incorrectly, attackers can exploit the TLS cryptographic protocol that allows backward compatibility. As a result, weak cyphers may be accepted or encrypted traffic may be downgraded to clear text. These vulnerabilities can affect the confidentiality of organizational data.	Reconfigure any application that uses insecure SSL/TLS encryption ciphers. Avoid using RC4 ciphers; instead, use the TLS 1.2 protocol with Advanced Encryption Standard Galois/Counter Mode (AES-GCM) suites. Disable weak ciphers when configuring TLS.	https://www.tenable.com/plugins/nessus/42873 https://www.tenable.com/plugins/nessus/65821 https://knowledge-base.secureflag.com/vulnerabilities/broken_cryptography/weak_cipher_vulnerability.html https://electricenergyonline.com/energy/magazine/779/article/Security-Sessions-Exploring-Weak-Ciphers.html		Medium
Web Application Cryptographic Weakness	Untrusted SSL Certificate	Secure Sockets Layer (SSL) certificates protect data security and ensure an encrypted channel exists for data to pass through. Often, the chain for SSL certificates can be broken because of various certificate issues: an unrecognized certificate authority (CA), an invalid expired certificate, and a certificate that may not be verified (e.g., self-signed certificates or those that match the issuer’s certificate). Self-signed certificates are issued by the users as opposed to a trusted authority. A visitor to a website that uses self-signed certificates might see a warning, which users typically ignore. Users can therefore be tricked into accepting an untrusted certificate and be susceptible to a machine-in-the-middle (MITM) attack. Attackers can exploit this weakness to intercept unencrypted network traffic and collect personal user information and login credentials from login pages.	Continuously monitor certificates to verify their validity and expiration status. For unrecognized certificates, purchase/generate a proper SSL certificate from a known public CA. Replace expired certificates with trusted ones. Avoid using self-signed certificates within a domain.	https://www.tenable.com/plugins/nessus/51192 https://www.tenable.com/plugins/nessus/57582 https://www.tenable.com/plugins/nessus/15901 https://www.namecheap.com/security/do-i-need-ssl-certificate/ https://www.kaspersky.com/resource-center/definitions/what-is-a-ssl-certificate		Medium
Web Application Design Weakness	Abusable Function	An attacker can exploit an application’s features for malicious uses (e.g., escalate privileges; upload files; compromise the confidentiality, availability, and integrity [CIA] of the application; inject malware; bypass security mechanisms). An attacker can exploit a weak implementation of an application’s hidden or third-party features if they are given access, higher level permissions, or the ability to upload malicious files.	Use fuzzing or manual analyses to thoroughly test a web application’s functionalities/features, including user functionality.	https://owasp.org/www-project-mobile-top-10/2014-risks/m8-security-decisions-via-untrusted-inputs https://cwe.mitre.org/data/definitions/829.html https://portswigger.net/kb/issues/00500980_file-upload-functionality		Medium
Web Application Design Weakness	Dynamic File Inclusion Weakness	A web application with a dynamic file inclusion weakness is vulnerable to an attacker inserting malicious files or malware from a remote web server. Since the attacker targets web applications that dynamically reference misconfigured external scripts, this weakness may result from the misconfiguration of a programming language used for the website or application.	Properly validate and sanitize user-supplied inputs in the web application (e.g., parameters for the Uniform Resource Locator (URL), GET, and POST). Sanitize cookie and Hypertext Transfer Protocol (HTTP) header values. Check the input parameters and values against an allow list. Restrict the execution of uploaded files and limit their sizes. Maintain an allow list of file types. Adhere to the Cross-Origin Resource Sharing (CORS) standard to prevent associated vulnerabilities from being exploited.	https://www.invicti.com/blog/web-security/remote-file-inclusion-vulnerability/#:~:text=Vulnerability%20classification%20and%20severity%20table%20%20%20,%20%2098%20%205%20more%20rows%20 https://www.imperva.com/learn/application-security/rfi-remote-file-inclusion/	https://book.hacktricks.xyz/pentesting-web/cors-bypass	High
Web Application Design Weakness	Improper Handling of XML Attributes	Extensible Markup Language (XML) parsers efficiently manage a web application’s attributes. Improperly inserted new attributes can cause a nonlinear overall runtime, which could exhaust server resources and make the application vulnerable to denial-of-service (DoS) attacks that could compromise its availability. An XML External Entity (XXE) attack exploits the vulnerability in an external entity with a weakly configured XML parser that the XML input references.	Limit the number of attributes per XML element and use a more efficient data container. Configure the XML processor to use a local static Document Type Definition (DTD). Disallow declared DTDs that are included in XML documents.	https://www.whitehatsec.com/glossary/content/xml-attribute-blowup https://resources.infosecinstitute.com/topic/xml-vulnerabilities/ https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2020-004_en.pdf https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing		Mediun
Web Application Design Weakness	Inconsistent Interpretation of HTTP Requests	Hypertext Transfer Protocol (HTTP) requests can be malformed when they are interpreted inconsistently between the frontend web servers or clients and the backend systems (e.g., application firewalls or load balancers). When this vulnerability is exploited, a website’s interpretation of HTTP requests from one or more users (i.e., server-client communication) is inconsistent with what the users intend. When these systems are unable to properly parse and interpret requests, an attacker can smuggle or split responses while the client and server are unaware. Request smuggling vulnerabilities are often critical because they enable an attacker to bypass security controls, gain unauthorized access to sensitive data, and directly compromise other application users. HTTP servers are vulnerable to request splitting when they use incompatible HTTP protocol versions, use outdated HTTP protocols, or when they do not validate user input.	Validate discrepancies in how a system’s backend and frontend interpret HTTP requests and data received by the application. Disable backend connection reuse so that each backend request is sent over a separate network connection. Use HTTP/2 for backend connections to prevent ambiguity between request boundaries. Use the same web server software in both the frontend and backend servers so their request boundaries agree. Confirm that HTTP servers have compatible HTTP protocol versions. Implement validation mechanisms to sanitize user input. Configure backend HTTP servers to reject ambiguous requests. Disable backend connection reuse. Use a Web Application Firewall (WAF) to detect abnormal HTTP requests. Validate that the Java Server Pages (JSPs) can check the HTTP headers. Assign a value for content length and return an error code if it is poisoned.	https://portswigger.net/web-security/request-smuggling https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24766		Medium
Web Application Design Weakness	Insecure HTTP Response Header Configuration	Although Hypertext Transfer Protocol (HTTP) response headers can be implemented to boost the security of a web application, vulnerabilities in its configuration can make an application more insecure. Improperly configured HTTP response headers can allow an attacker to enter data into the web application as an HTTP request through untrusted sources and include it in an HTTP response header sent to the web user. This data is sent without validation for malicious characters. The improper configuration can also allow an attacker to inject content into a server response that is interpreted differently by intermediaries than it is by the client browser. An attacker leverages various applications’ inconsistent or incorrect interpretations of the HTTP protocol in their attack. This attack can include response splitting, cross-site scripting (XSS), apparent defacement of targeted sites, and cache poisoning.	Properly sanitize and filter characters in the location header (e.g., /r and /n). Validate on the server side. Ensure that all data from the user is subject to strict validation. Disallow Carriage Return/Line Feed (CRLF) characters in all requests when the response header contains user input. Integrate a vulnerability management program that can detect and alert on potential vulnerabilities and is compatible with continuous integration and continuous delivery/deployment (CI/CD) channels. Do not rely on user-controllable input to form part of an output response stream to an HTTP request. Enforce strict adherence to interpretations of HTTP messages wherever possible (e.g., encode header information provided by user input so that its content is not interpreted by intermediaries).	Properly sanitize and filter characters such as “/r” and “/n” in the location header. Validate on the server side. Ensure that all data from the user is subjected to strict validation. Disallow CRLF characters in all requests where the response header reflects user input. Integrate a vulnerability management program that can alert potential vulnerabilities and can be integrated into CI/CD channels. Do not rely on user-controllable input to form part of the output response stream to an HTTP request. Require strict adherence to interpretations of HTTP messages wherever possible. For example, encode header information provided by user input so that user-supplied content is not interpreted by intermediaries.	https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html https://owasp.org/www-community/attacks/HTTP_Response_Splitting https://resources.infosecinstitute.com/topic/http-response-splitting-attack/ https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/	Low
Web Application Design Weakness	Insufficient Anti-CSRF Protection	Insufficient anti Cross-Site Request Forgery (CSRF) protection exposes a system to attackers performing functions without the user’s knowledge. When the attacker authenticates to the site (with all the cookies of the user), the site is unable to distinguish between legitimate and malicious (i.e., those using forged authenticated requests) users. CSRF forces the end user to execute actions that an application does not intend to perform with an authenticated session.	Confirm that the relevant framework has built-in CSRF protection (e.g., an anti-CSRF token), and use it. If it doesn’t have those protections, add CSRF tokens to all requests that change state and validate them on the server side. Refresh tokens after user authentication. Require anti-forgery validation for user actions, controller actions, and/or globally. Use the synchronizer token pattern for stateful software. Use double submit cookies for stateless software. Do not use GET requests for state-changing operations since they are insecure.	https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html https://owasp.org/www-community/attacks/csrf#:~:text=Cross%20Site%20Request%20Forgery%20%28CSRF%29%201%20Overview.%20Cross-Site,that%20do%20NOT%20work.%20...%205%20Examples.%20 https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-6.0	https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-6.0 https://www.invicti.com/blog/web-security/csrf-cross-site-request-forgery/	Low
Web Application Design Weakness	Insufficient Process Validation	Insufficient process validation occurs when an attacker circumvents the intended flow or business logic of an application. It can result in ineffective access controls and monetary loss for the organization.	Ensure that developers and testers understand the domain the application serves. Maintain clear design documents and data flows for all transactions and workflows. Do not make implicit assumptions about user or application behavior.	http://projects.webappsec.org/w/page/13246943/Insufficient%20Process%20Validation https://portswigger.net/web-security/logic-flaws	http://projects.webappsec.org/w/page/13246943/Insufficient%20Process%20Validation https://portswigger.net/web-security/logic-flaws	Medium
Web Application Design Weakness	URL Redirection to Untrusted Site	Uniform Resource Locator (URL) redirection is a vulnerability that forcibly forwards a website user to an untrusted external site. This problem is typically caused by a user who has implicit trust in a legitimate website/domain, receives and clicks a link from it, and is then redirected to a malicious website. Attackers use phishing and social engineering attacks to exploit this weakness.	Add trusted sites to the allow list of sites that users can be redirected to. Disable redirects to external untrusted sites on the server side. Filter based on a protocol handler. Use a regular expression (regex) to validate URL parameters.			Medium
Insecure Wireless Authentication	802.11r Fast Transition Roaming Enabled	The wireless standard 802.11r allows devices to roam to different access points within a wireless network without reauthenticating with Remote Authentication Dial-In User Service (RADIUS) servers every time. Standard 802.11r has known vulnerabilities (e.g., reinstallation of keys) that can allow attackers to replay, decrypt, and possibly spoof packets into the network.	Disable 802.11r on network devices. Install patches for network devices.	https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13082 https://blogs.cisco.com/networking/what-is-802-11r-why-is-this-important https://posts.specterops.io/modern-wireless-attacks-pt-i-basic-rogue-ap-theory-evil-twin-and-karma-attacks-35a8571550ee	https://www.cwnp.com/krack-s-not-bad-you-think/ https://www.krackattacks.com	Low
Insecure Wireless Authentication	Captive Portal MAC Address Unrestricted Access	The captive portal method authenticates users into wireless networks. This method differs from others because clients authenticate into the network after connecting to the access point, not before. Captive portals allow a valid client’s media access control (MAC) address to verify who has been authenticated and who has not. Attackers can abuse this method by spoofing the MAC address of a client who is already connected to the network, thereby bypassing the captive portal.	Update the wireless network to use an industry security standard. If that is not possible, ensure that the captive portal is being delivered through a secure standard.	https://kb.netgear.com/22006/What-is-the-captive-portal-and-how-does-it-work-with-my-managed-switch https://www.attilasec.com/blog/captive-portal-risk-remote-work-captive-vulnerability-zone	https://www.intraway.com/blog/captive-portals-security-challenge/	Low
Insecure Wireless Authentication	Certificate Validation Weakness	Wi-Fi Protected Access 2 (WPA2)-Enterprise Protected Extensible Authentication Protocol/Extensible Authentication Protocol-Transport Layer Security (PEAP/EAP-TLS) authenticates users into the network using valid Remote Authentication Dial-In User Service (RADIUS) servers. Attackers can use machine-in-the-middle (MITM) attacks to trick users into connecting to a malicious RADIUS server. If an organization does not force its endpoints to validate RADIUS server certificates, it is vulnerable to credential theft and MITM attacks.	Enforce server certificate validation on every network device by establishing a Group Policy Object (GPO) inside the domain.	https://www.securew2.com/blog/without-server-certificate-validation-wpa2-enterprise-isnt-secure https://www.securew2.com/solutions/wpa2-enterprise-and-802-1x-simplified	https://securityboulevard.com/2019/11/how-to-configure-wpa2-enterprise-on-each-operating-system/ https://dailysysadmin.com/KB/Article/714/create-a-group-policy-to-deploy-a-company-wireless-access-point/	Medium
Insecure Wireless Authentication	Generic Token Card (GTC) Downgrade Weakness	Extensible Authentication Protocol Generic Token Card (EAP-GTC) is an alternative to Protected Extensible Authentication Protocol with Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2). It allows authentication using a hardware security token or one-time password (OTP). Attackers can force a client machine to use a GTC instead of more secure methods. Since many client devices do not specify what password they want, a user is likely to enter network login credentials and accidentally send sensitive data in clear text.	Avoid using GTC authentication in the network. Use other authentication systems, such as OAuth (Open Authorization) and multifactor authentication (MFA).	https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol, https://networkradius.com/doc/3.0.10/raddb/mods-available/eap/gtc.html	Not really any resources. Just have to disable it.	Medium
Insecure Wireless Authentication	Wireless Network Does Not Require Authentication	Wireless networks enable users to access the Internet. Attackers can abuse this functionality to access resources and sniff the data of legitimate clients.	Configure the network to require password authentication for all clients that attempt to connect to it.	https://usa.kaspersky.com/blog/guest-wifi/16271/ https://www.pandasecurity.com/en/mediacenter/panda-security/guest-wifi/	https://www.al-enterprise.com/en/blog/5-best-practices-guest-wifi-access	Medium
Insecure Wireless Authentication	Wireless Network MAC Address Vulnerability	Wireless networks can authenticate clients using a media access control (MAC) address allow list to determine who is allowed on the network. Due to the weakness of MAC address allow lists, an attacker can determine it, spoof the MAC address of the valid client, and force the legitimate user to disconnect, taking their place on the network.	Configure the network to use an industry standard security protocol in place of a MAC allow list.	https://www.geeksforgeeks.org/mac-filtering-in-computer-network/ https://en.wikipedia.org/wiki/MAC_filtering	https://www.howtogeek.com/204458/why-you-shouldn’t-use-mac-address-filtering-on-your-wi-fi-router/	Medium
System Management Weakness	Rogue Wi-Fi Access Point	Client machines can broadcast the networks where they are known to connect. Typically, these clients connect to these previously known access points without user intervention. An attacker can use a rogue access point with the same name as the client to attempt to intercept users from legitimate access points. An attacker can then perform a machine-in-the-middle (MITM) attack and steal sensitive data.	Enforce certificate validation on all client machines to verify that access points are genuine. Avoid having open wireless networks. Disable the setting to remember wireless networks on client machines.	https://insights.sei.cmu.edu/blog/instant-karma-might-still-get-you/ https://en.wikipedia.org/wiki/KARMA_attack	https://insights.sei.cmu.edu/blog/instant-karma-might-still-get-you/ https://www.darkreading.com/attacks-breaches/understanding-evil-twin-ap-attacks-and-how-to-prevent-them-/a/d-id/1333240	Medium
Wireless Cryptographic Weakness	Weak WPA Pre-Shared Key	Many Wi-Fi standards rely on symmetric key encryption for the security of messages being exchanged inside a network. Symmetric key encryption uses pre-shared keys (PSKs). Wi-Fi networks that use weak PSKs to secure the network can put the network at risk. By intercepting enough handshakes, an attacker can crack the PSK used for the network. Attackers who know this PSK can access secure environments they are not authorized to access.	Configure PSK networks to have sufficiently long and complex encryption keys that can resist brute-force attacks for a reasonable amount of time.	https://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#WPA2 https://www.securew2.com/blog/wpa2-psk-is-not-enough	https://www.routersecurity.org/wepwpawpa2.php	Medium
Wireless Cryptographic Weakness	Wireless Encryption Weakness	Wired Equivalent Privacy (WEP) is a known weak wireless encryption standard due to its use of Rivest Cipher 4 (RC4) encryption and its insufficient initialization vectors (IVs) when encrypting traffic. Using WEP puts the network and users’ data at risk because the key can be cracked.	Update the network security standard to a better standard, such as Wi-Fi Protected Access 2 (WPA2) or Wi-Fi Protected Access 3 (WPA3).	https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy https://www.section.io/engineering-education/wep-encryption/	https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy	Medium
Wireless Cryptographic Weakness	Wireless Security Standard Weakness	Wi-Fi Protected Access 2 (WPA2)-Enterprise Protected Extensible Authentication Protocol with Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2) is a wireless security standard that allows the use of credentials to authenticate users on the network. The standard is vulnerable to machine-in-the-middle (MITM) attacks, and attackers can intercept credentials as they are being sent for authentication.	Enforce certificate validation of authentication protocols on the network.	https://www.securew2.com/blog/wpa2-enterprise-authentication-protocols-comparison https://securityboulevard.com/2020/01/eap-tls-vs-peap-mschapv2-which-authentication-protocol-is-superior/	https://www.securew2.com/blog/peap-mschapv2-vulnerability https://msrc-blog.microsoft.com/2012/08/20/weaknesses-in-ms-chapv2-authentication/	Medium
Wireless Network Design Weakness	Accessible Public Wi-Fi Network	A public Wi-Fi network has no security but is not designated as a guest network. Using public Wi-Fi networks can put users’ data at risk and allow unauthorized access.	Segment the public Wi-Fi network to exclude the parts where it is not publicly accessible. Use a guest network instead of a public Wi-Fi network, and implement security into that network.	https://usa.kaspersky.com/blog/guest-wifi/16271/ https://www.pandasecurity.com/en/mediacenter/panda-security/guest-wifi/08/20/weaknesses-in-ms-chapv2-authentication/	https://www.al-enterprise.com/en/blog/5-best-practices-guest-wifi-access	Low
Wireless Network Design Weakness	Non-Segmented Wireless Network	Network segmentation allows different types of network resources to be separated from other parts of the network through physical or logical segmentation. Non-segmented wireless networks decrease the security of a network by failing to limit how cyberattacks can spread to other systems. Failure to segment selected network resources can allow attackers to move laterally through an insecure network and, in the case of an intrusion, expose vulnerable resources to harmful traffic. If there is no segmentation on a network, an attacker only must penetrate the network’s perimeter to gain access to the entire wireless network.	Ensure wireless network segmentation is present when safeguarding a network’s critical and vulnerable resources/systems. Enforce a segmentation policy that restricts traffic between unrelated resources/systems.	https://www.cisco.com/c/en/us/products/security/what-is-network-segmentation.html https://www.paloaltonetworks.com/cyberpedia/what-is-network-segmentation	https://www.forescout.com/company/blog/network-segmentation/	High
Wireless Network Design Weakness	Use of Non-Broadcast SSID	An organization can obfuscate the existence of its wireless networks by not broadcasting its network service set identifier (SSID). Using SSIDs that are not broadcasted do not provide additional security to the organization. An attacker can easily sniff network traffic and look for connection requests over the air to identify hidden networks that do not broadcast their SSID.	Do not use non-broadcast SSID for security. Use a proper security standard, such as Wi-Fi Protected Access 2 (WPA2) or Wi-Fi Protected Access 3 (WPA3), to protect a network from attackers.	https://www.howtogeek.com/howto/28653/debunking-myths-is-hiding-your-wireless-ssid-really-more-secure/ https://en.wikipedia.org/wiki/Network_cloaking	https://www.lifewire.com/what-is-wpa2-818352	Medium
Wireless Network Design Weakness	Wireless Networks Accessible from Public Locations	Wi-Fi networks should be accessible only by users on the premises of an organization. Wi-Fi networks accessible from public locations allow attackers to conduct attacks without being on the organization’s premises.	Limit the strength of certain access points (APs) so they do not broadcast signals into public locations. Properly plan AP placement around the building to account for signal strength and potential outside connections.	https://www.metageek.com/training/resources/wifi-signal-strength-basics.html	https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Wi-Fi-Cloud/deploy/deployment_best-practices_device-channel.html	Low