Internal Pentest.yml

- cvssv3: 'CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L'
  priority: 2
  remediationComplexity: 1
  category: Internal Pentest
  details:
    - locale: EN
      title: Shared platform usage
      vulnType: Pentest
      description: >-
        <p>Running services with shared resources carries the risk that if one
        of the apps is vulnerable or exploitable, all others are at risk as
        well. More services most likely means that more users have access to the
        system, but these user don't necessary have the rights to access the
        other solutions running on that system. However, the compromise of the
        user of another service, might give an attacker a first foothold on the
        shared system, which later might result in a full compromise of all
        hosted services.</p><p>For critical service like e.g. a Certificate
        Authority, Domain Services, Backup solutions, it is best practice to
        have them running on dedicated systems.</p>
      remediation: <p>Migrate the affected service to a dedicated platform.</p>
      references: []
      customFields: []

- cvssv3: 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'
  priority: 3
  remediationComplexity: 3
  category: Internal Pentest
  details:
    - references:
        - >-
          https://learn.microsoft.com/en-us/security/compass/privileged-access-access-model
      locale: EN
      title: Missing Network Seperation
      vulnType: Pentest
      description: >-
        <p>Using network segmentation and separation together offers an
        additional level of security to systems and data. <br>A robust ‘defense
        in depth’ network enhances security by physically and virtually ensuring
        data flow and connectivity within networks is for known and approved
        connections only. It controls who can access which resource from
        where.</p><ul><li><p>Network segmentation involves breaking down an
        organization's network into smaller networks, using DMZ’s and other
        logical segmentation (like Production/Test) to logically segment
        processing activity.</p></li><li><p>Network separation means using
        different access controls to allow connections across these smaller
        networks. This can be by employing different technologies and filters to
        further control data flow.</p></li></ul><p>These measures make it harder
        for an attacker to move laterally and access unwanted and critical
        resources, once he gained an initial foothold in the internal
        network.<br><br>Access to critical infrastructure like Domain
        Controllers, Certificate Authorities, Backup solutions and alike, should
        be secured as much as possible.</p>
      remediation: >-
        <p>Systems that can be accessed from the Internet should always be
        placed in a demilitarized zone (DMZ), as these systems are exposed to an
        increased risk.</p><p>It is recommended to divide the systems into
        different TIER levels, in which the sensitivity and criticality of the
        servers is differentiated. Direct access by clients to services is
        enabled in a specific TIER level, the other TIER levels can only be
        accessed from the next lower level and are separated in each
        case.</p><p>The bare minimum that should be implemented is a network
        separation between the client and server networks. This will better
        protect the server network from automated attacks by executed malware
        (for example, ransomware) on clients, as well as from network
        attacks.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L'
  priority: 3
  remediationComplexity: 1
  category: Internal Pentest
  details:
    - locale: EN
      title: SMB Signing not activated
      vulnType: Vulnerability Scan
      description: >-
        <p>SMB (Server Message Block) signing is a security feature that is used
        to digitally sign SMB packets to ensure their authenticity and
        integrity. <br>This helps to prevent man-in-the-middle (MitM) attacks,
        where an attacker intercepts and modifies SMB packets in transit, by
        allowing the recipient to verify that the packets were sent by an
        authenticated sender and have not been tampered with. <br>The most
        widely known attack that abuses the lack of SMB signing is
        relaying.<br>SMB signing can be enabled or disabled on both the client
        and server side and is supported on Windows Server and Windows client
        operating systems. It is typically used in enterprise environments to
        secure file sharing and other types of data transfer over the
        network.</p>
      observation: <p>CME Screenshot or Nessus output</p>
      remediation: >-
        <p>SMB signing should be enabled and enforced on both the client and
        server side.</p>
      references:
        - 'https://luemmelsec.github.io/Relaying-101/'
        - >-
          https://techcommunity.microsoft.com/t5/storage-at-microsoft/configure-smb-signing-with-confidence/ba-p/2418102
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N'
  priority: 1
  remediationComplexity: 1
  category: Internal Pentest
  details:
    - references: []
      locale: EN
      title: Usage of untrusted Certificates
      vulnType: Vulnerability Scan
      description: >-
        <p>The reason that a certificate is considered untrustworthy can have
        different causes. In the following scenarios, a certificate might be
        detected as not valid:</p><ul><li><p>The server's certificate does not
        have a valid certificate chain to a trusted root certificate authority.
        This happens if the certificate was issued by an unrecognized
        certificate authority, if the certificate is a self-signed certificate,
        or if an intermediate certificate is missing from the certificate
        chain.</p></li><li><p>The commonName (CN) parameter of the certificate
        does not match the domain name of the server. This might happen if the
        IP is used instead for the DNS name.</p></li><li><p>The signature of the
        certificate could not be verified.</p></li><li><p>A certificate is
        invalid if the server's certificate has expired, i.e. during
        verification the certificate's valid date range does not match the
        current date.</p></li></ul><p>These issues make it difficult for users
        to verify the certificate and increase the risk of Man-in-the-Middle
        attacks.</p>
      remediation: >-
        <p>Create and apply trusted certificates.<br>Internet facing systems
        should have a certificate signed by a 3rd party trusted public CA.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N'
  priority: 2
  remediationComplexity: 2
  category: Internal Pentest
  details:
    - references:
        - 'https://nvd.nist.gov/vuln/detail/CVE-2000-1200'
      locale: EN
      title: Unauthenticated User Enumeration over SMB - CVE-2000-1200
      vulnType: Vulnerability Scan
      description: >-
        <p>Windows NT allows remote attackers to list all users in a domain by
        obtaining the domain SID with the <em>LsaQueryInformationPolicy</em>
        policy function via a null session and using the SID to list the
        users.</p>
      remediation: >-
        <p>Contact the vendor to see if appropriate settings, updates or fixes
        are available.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'
  priority: 4
  remediationComplexity: 1
  category: Internal Pentest
  details:
    - references: []
      locale: EN
      title: Extremely weak Admin Credentials
      vulnType: Pentest
      description: >-
        <p>Accounts with critical privileges like Domain Admins, Firewall
        Admins, Backup Admins and alike should always be handled with care and
        secured accordingly.<br>People using these accounts need to be aware of
        the potential risks that arise when their accounts get
        compromised:</p><ul><li><p>Data breaches and theft of sensitive
        information: If a hacker gains access to an administrative account, they
        may be able to view, steal or manipulate confidential data stored on the
        system, such as personal information, financial records, or trade
        secrets.</p></li><li><p>System damage and disruption of services: The
        attacker may use the administrative privileges to cause harm to the
        system, for example, by deleting critical files, modifying system
        settings, or shutting down servers. This could result in significant
        downtime and disruption of services for the organization and its
        customers.</p></li><li><p>Spread of malware and further compromise: The
        attacker may use the compromised administrative account to install
        malware, such as viruses, Trojans, or ransomware, which can spread to
        other systems and devices on the network, leading to additional security
        breaches and compromise. This could result in significant damage to the
        organization's reputation and financial loss.</p></li></ul><p>In this
        case the password complexity of these administrative accounts must be
        rated as extremely weak. <br>The password is either guessable or if an
        attacker gets a hold on hashed material easily recoverable.</p>
      remediation: >-
        <p>Privileged accounts should have extremely strong passwords. They
        should be at least 20 characters long, and comply to complexity with
        uppercase, lowercase, numbers and special characters. The passwords
        should be randomly generated, no words! Password blacklisting can be
        issued to help here.<br>Password reusage should be avoided at all
        costs.<br>Personal holding higher privileges needs to be trained and
        made aware of the possible risks. <br>Saving credentials in a Web
        Browser should also be avoided.<br>Additionally these accounts should be
        hardened via Multi Factor Authentication where possible.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'
  priority: 3
  remediationComplexity: 3
  category: Internal Pentest
  details:
    - references:
        - >-
          https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-access-model
      locale: EN
      title: Deficient Roles and Authorization Concept
      vulnType: Pentest
      description: >-
        <p>A Roles and Authorization Concept purpose is to restrict access to
        sensitive resources as much as possible.<br>This can be achieved through
        appropriate measures like e.g.:</p><ul><li><p>Limiting the number of
        users that have access to the resource</p></li><li><p>Limiting the
        access rights to the absolute minimum each user needs - concept of least
        privilege</p></li><li><p>Limiting the sources which have access - e.g.
        from where can a valid user access an
        application</p></li><li><p>Defining a password policy and MFA
        requirements</p></li></ul><p></p>
      remediation: >-
        <p>Implement a sufficient and secure Roles and Authorization
        concept.<br>Review the access rights to the systems.<br>Change
        passwords.<br>Follow best practices like the TIER model from
        Microsoft.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N'
  priority: 3
  remediationComplexity: 1
  category: Internal Pentest
  details:
    - locale: EN
      title: Outdated Software
      vulnType: Pentest
      description: >-
        <p>Used soft- and firmware as well as operating systems should always be
        kept to the most current versions.</p><p>Using outdated versions poses
        several direct and indirect security risks like:<br>- Security
        vulnerabilities: outdated software may have unpatched security holes
        that can be exploited by attackers.<br>- Compatibility issues: new
        hardware or software may not be compatible with old systems.<br>-
        Performance degradation: outdated software may run slower, become less
        responsive, or crash more often.<br>- Lack of features: newer software
        may have additional features or improvements that are not available in
        older versions.<br>- Compliance problems: outdated software may not meet
        industry regulations or standards.<br><br>Staying up to date is a
        mandatory requirement to a matured security culture and should be part
        of the patch management process.<br></p>
      observation: >-
        <p><br>Criticality depending on what could be achieved due to systems
        and software being outdated.</p>
      remediation: >-
        <p>Check if any of the mentioned software components can be upgraded /
        updated and if important security updates are missing.<br>Implement a
        patch management strategy and process that ensures that all your systems
        are up to date and that updates are applied timely according to their
        criticality.<br>Apply workarounds when no patches are available when
        tackling critical flaws.</p>
      references:
        - ''
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
  priority: 3
  remediationComplexity: 2
  category: Internal Pentest
  details:
    - locale: EN
      title: Password Requirements
      vulnType: Pentest
      description: >-
        <p>Using weak passwords has several security implications and is posing
        one of the biggest risks in the IT security threat landscape with the
        following impacts:<br></p><ul><li><p>Easy to guess: Bad passwords are
        often easily predictable, making it easier for hackers to guess or crack
        them.</p></li><li><p>Dictionary attacks: Poor passwords are susceptible
        to dictionary attacks, where a hacker uses a list of commonly used
        passwords to gain access to an account.</p></li><li><p>Brute force
        attacks: In a brute force attack, a hacker tries every possible
        combination of characters to crack a password, making a weak password
        easier to crack.</p></li><li><p>Reuse: People often reuse the same
        password across multiple accounts, putting all their information at risk
        if a single password is compromised.</p></li><li><p>...</p><p></p><p>If
        the passwords used by the users are not complex enough they can easily
        be guessed or the clear text passwords can trivially be recovered if an
        attacker gets access to their hashed values.</p></li></ul>
      remediation: >-
        <p>The following settings and measures can help to harden access to
        users and their credentials:</p><ul><li><p>Implementing multi-factor
        authentication.</p></li><li><p>Implementing a secure domain wide
        password policy in case of Active Directory. At least 12 characters for
        low privileged and 14 characters for high privileged accounts. For
        service accounts at least 20 characters should be
        used.</p></li><li><p>Using a password manager. Best in combination with
        the possibility for fine granular rights management and MFA
        authentication.</p></li><li><p>Password blacklisting. Ban passwords with
        the company name, seasons, passwords on leaked lists
        etc.</p></li><li><p>Implementing password policies based on the access
        rights of the accounts affected.</p></li><li><p>Regular password
        audits.</p></li><li><p>User awareness campaigns. Especially security
        related trainings for technical staff.</p><p></p></li></ul><p>Best
        practices for the Domain Password
        Policy:</p><ul><li><p>ComplexityEnabled =
        True</p></li><li><p>LockoutDuration &gt;= 15
        Minutes</p></li><li><p>LockoutObservationWindow &gt;= 15
        Minutes</p></li><li><p>LockoutThreshold &lt;= 10
        Minutes</p></li><li><p>MinPasswordLength &gt;=
        12</p></li><li><p>ReversibleEncryptionEnabled =
        False</p></li></ul><p><br></p>
      references: []
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L'
  priority: 2
  remediationComplexity: 2
  category: Internal Pentest
  details:
    - references:
        - >-
          [1]
          https://learn.microsoft.com/en-us/windows/win32/winrm/authentication-for-remote-connections
        - >-
          [2]
          https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management
      locale: EN
      title: Management Service Misconfiguration
      vulnType: Pentest
      description: >-
        <p>Management services like SSH, RDP, Telnet, WinRM etc. are meant for
        administrative purposes of systems and applications.<br>Access to those
        services should be restricted as much as possible to follow the
        defense-in-depth approach as well as the least privilege
        principle.<br>Even if not currently affected by a directly exploitable
        vulnerability, they at least pose the risk of being accessed with stolen
        / impersonated identities.</p>
      remediation: >-
        <p>Access to management services and their according ports should be
        restricted by means of network separation or (local) firewalls. <br>Most
        of these services offer hardened authentication methods and settings
        like certificate based authentication for SSH or restricted host polices
        for access to WinRM [1][2].<br>Systems ideally reside in a dedicated
        management VLAN to which only the needed systems and people can connect
        to.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N'
  priority: 2
  remediationComplexity: 2
  category: Internal Pentest
  details:
    - references: []
      locale: EN
      title: Servers with Internet Access
      vulnType: Pentest
      description: >-
        <p>Not restricting internet access to systems poses several potential
        security risks like:</p><ul><li><p>Malware can be downloaded directly
        onto the system's disk</p></li><li><p>Malware can be downloaded directly
        into the system's memory</p></li><li><p>The system can be connected and
        controlled via an internet hosted Command &amp; Control server or a
        Botnet</p></li></ul><p>Especially servers that don't necessarily need
        access to the internet should not be given these possibilities.<br></p>
      remediation: >-
        <p>If really needed, the internet traffic should be routed through a
        firewall or proxy that analyzes the dataflow and connections made.
        <br>It should be able to block access and isolate the host in case
        something suspicious pops up.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L'
  priority: 3
  remediationComplexity: 1
  category: Internal Pentest
  details:
    - references: []
      locale: EN
      title: General Observations Work Ethics
      vulnType: Pentest
      description: >-
        <p>Sensitive files should always be handled with care. Cleaning up when
        files are no longer used is an essential part of work ethics.</p><p>For
        attackers, valuable information residing inside such files comes in
        handy and can drastically expose further services and systems, allowing
        for privilege escalation or lateral movement.</p>
      observation: >-
        <p>Critically dependant on the info found and according
        possibilities</p>
      remediation: >-
        <p>Technical staff should be trained and forced to clean up after their
        work is done.<br>Leaving sensitive info exposed on systems is bad
        practice and should be avoided at all costs.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N'
  priority: 3
  remediationComplexity: 2
  category: Internal Pentest
  details:
    - references: []
      locale: EN
      title: General Observations in regard to Alerts
      vulnType: Pentest
      description: >-
        <p>Critical systems and events should be monitored closely to be able to
        react on a shorthand if something bad happens.</p><p>Having visibility
        inside the whole network is a crucial fundamental of a matured
        IT-Security strategy.</p>
      observation: <p></p><p></p>
      remediation: >-
        <p>Logs and events need to be monitored closely. If critical alerts show
        up, according investigations and countermeasures need to take place.</p>
      customFields: []

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'
  priority: 4
  remediationComplexity: 3
  details:
    - locale: EN
      title: MSSQL Features xp_*** available to low privileged Users
      vulnType: Pentest
      description: >-
        <p><em>xp_cmdshell</em>, <em>xp_dirtree</em> and<em> xp_fileexist</em>
        are MSSQL native extended stored procedures. While <em>xp_cmdshell</em>
        allows for executing shell commands, the latter ones are aimed at file
        and directory operations.</p><p><em>xp_cmdshel</em>l: This extended
        stored procedure enables the execution of operating system commands from
        within SQL Server. If accessible to low privilege users, it poses
        significant security risks. Exploiting <em>xp_cmdshel</em>l, an attacker
        can execute arbitrary commands on the server's operating system with the
        permissions of the SQL Server service account. This can lead to
        unauthorized actions, such as accessing or modifying sensitive files,
        compromising the system, or even gaining full control over the
        server.</p><p><em>xp_dirtree </em>and <em>xp_filexist</em> can be
        executed by members of the Public role by default in SQL Server
        2000-2014. The public role is essentially a group that includes all
        database users by default. Both can be used to force the SQL Server
        service account to authenticate to a remote attacker.&nbsp; The service
        account password hash can then be captured + cracked or relayed to gain
        unauthorized access to systems. This also means they can be used to
        escalate a lower privileged user to sysadmin when a machine or managed
        account isn't being used.&nbsp;That's because the SQL Server service
        account is a member of the sysadmin role in SQL Server 2000-2014, by
        default. Also, if the service accounts happen to be local administrators
        on the servers themselves, an attacker can takeover those as well.</p>
      remediation: >-
        <p>There are several points to take into consideration
        here:</p><ul><li><p>It must URGENTLY be avoided to reuse service
        accounts. If really needed, there should be a dedicated service account
        per SQL server. If possible the computeraccount should be used.
        Alternateively managed service accounts per instance.</p></li><li><p>It
        must URGENTLY be avoided that (MSSQL) service accounts also hold local
        admin rights on servers. This needs to be checked on ALL (not only the
        ones listed) servers.</p></li><li><p>ALL (not only the ones listed)
        instances where the xp_ procedures are available to low privileged users
        have to be identified and the permissions need to be adjusted according
        to the principle of least privilege.</p></li><li><p>ALL (not only the
        ones listed) instances where ALL domain users have access to have to be
        identified and evaluated if those broadly applied rights are really
        needed. Adjustment has to be made according to the principle of least
        privilege.</p></li><li><p>SMB Signing MUST be enabled on ALL servers,
        not only MSSQL servers. Best would be to do it domain wide, also on
        clients.</p></li><li><p>Robust AV MUST be in place that prevents attacks
        via malware.</p></li><li><p>Monitoring for critical events MUST be in
        place and reactions and countermeasures MUST take place
        immediately.</p></li><li><p>TIERing MUST be implemented. Access to
        servers is to be applied according to the principle of least
        privilege.</p></li></ul>
      references:
        - 'https://www.offsec-journey.com/post/attacking-ms-sql-servers'
        - >-
          https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/abusing-ad-mssql
      customFields: []
  category: Internal Pentest

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
  priority: 4
  remediationComplexity: 3
  details:
    - locale: EN
      title: Shared Service Accounts
      vulnType: Pentest
      description: >-
        <p>Using shared service accounts can pose security risks due to the
        following reasons:</p><ul><li><p>Lack of Accountability: When multiple
        services or applications use the same service account, it becomes
        difficult to determine which service or application performed a
        particular action. This lack of accountability can hinder incident
        response and make it challenging to identify the source of unauthorized
        or malicious activities.</p></li><li><p>Overprivileged Access: Shared
        service accounts often have elevated privileges to perform various tasks
        across different systems or applications. If an attacker gains access to
        a shared service account, they inherit all the privileges associated
        with it, potentially granting them widespread access to sensitive data
        or critical systems. The principle of least privilege is compromised
        when using shared service accounts, as multiple services may have more
        access than they actually require.</p></li><li><p>Password Management
        Challenges: Shared service accounts typically have long lifetimes and
        are seldom changed or updated, which increases the risk of password
        compromise. If the password for a shared service account is compromised,
        all the services using that account are also compromised. Additionally,
        updating the password for a shared service account can be challenging
        due to its wide usage, leading to delayed or neglected password
        changes.</p></li><li><p>Difficulty in Monitoring and Auditing:
        Monitoring and auditing become more challenging when multiple services
        share the same account. It becomes difficult to attribute specific
        actions to individual services or track activities associated with the
        account. This can impede security investigations, compliance audits, and
        the ability to detect and respond to security incidents
        effectively.</p></li><li><p>Dependency Risks: When multiple services
        rely on a shared service account, any disruption or compromise of the
        account can have a cascading effect on all the dependent services. A
        single security incident or misconfiguration can result in widespread
        service disruptions or unauthorized access to critical
        systems.</p></li></ul>
      remediation: >-
        <p>To mitigate these risks, it is generally recommended to use
        individual service accounts with unique credentials for each service or
        application. This allows for better accountability, enables fine-grained
        access control, simplifies auditing and monitoring, and reduces the
        impact of a compromised account to a single service or application.</p>
      references: []
      customFields: []
  category: Internal Pentest

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N'
  priority: 2
  remediationComplexity: 1
  details:
    - locale: EN
      title: SPN Remnants
      vulnType: Pentest
      description: >-
        <p>SPN stands for Service Principal Name, and it is a concept in a
        Windows environment, particularly within Active Directory (AD). An SPN
        is a unique identifier for a service instance that runs under a specific
        user account. It is used by clients to identify and authenticate the
        service they are trying to access.</p><p>Here are some key points about
        SPNs in a Windows environment/AD:</p><ul><li><p>Purpose: The primary
        purpose of an SPN is to associate a service with a specific account in
        order to facilitate mutual authentication. When a client wants to
        communicate with a service, it can use the SPN to locate and
        authenticate the service.</p></li><li><p>Format: An SPN is composed of
        two parts: the service class and the service name, separated by a
        forward slash (/). The service class identifies the type of service,
        such as "HTTP" for a web service or "MSSQLSvc" for a SQL Server service.
        The service name is the fully qualified domain name (FQDN) or the
        NetBIOS name of the server hosting the service.</p></li><li><p>Unique
        Identifiers: Each service instance running under a specific user account
        should have a unique SPN associated with it. This allows clients to
        differentiate between different instances of the same service running on
        different servers.</p></li><li><p>Kerberos Authentication: SPNs are
        primarily used with Kerberos authentication in a Windows environment.
        When a client needs to authenticate to a service using Kerberos, it
        requests a ticket-granting ticket (TGT) from the Key Distribution Center
        (KDC) using the SPN associated with the service. The SPN helps the KDC
        locate the appropriate service account to authenticate the client
        against.</p></li><li><p>Registering SPNs: Service accounts can register
        their SPNs automatically or manually. Automatic registration occurs when
        services start up and utilize the Network Service or Local System
        accounts. Manual registration is required when using custom service
        accounts.</p></li><li><p>Duplicate SPNs: Each SPN must be unique within
        a domain to avoid conflicts. Duplicate SPNs can cause authentication
        failures or unpredictable behavior. It's important to ensure that
        different services or instances use distinct
        SPNs.</p></li><li><p>Delegation: SPNs also play a role in delegation
        scenarios, where a service needs to forward a client's credentials to
        another service on behalf of the client. Service accounts require proper
        configuration, including the appropriate SPNs and delegation settings,
        to enable secure delegation.</p></li></ul><p>In summary, SPNs in a
        Windows environment/AD are unique identifiers used to associate services
        with specific user accounts for authentication purposes, primarily in
        the context of Kerberos authentication. They help clients locate and
        authenticate the services they want to access while ensuring secure and
        accurate identification of the service instances.<br><br>In some
        circumstances, mainly when SPNs get registered manually with the help of
        the <a target="_blank" rel="noopener noreferrer nofollow"
        href="https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731241(v=ws.11)">setspn</a>
        tool, or when the machine is not able to unregister SPNs for several
        reasons while being decommissioned, you might have dead SPNs in your
        environment.<br><br>These dead SPNs can still be used to conduct
        Kerberoasting attacks. When SPNs are tied to use accounts rather than to
        computer objects, it might be the case that the password is weak. With
        the Kerberoasting attack the cleartext credentials can then be
        retrieved.</p>
      observation: >-
        <p>Criticality depends on what is possible.<br>If we can kerberoast
        accounts where no actual service is running but which still have an SPN
        and are admin or sth, this would be high/critical.<br>If they have
        strong passwords and nothing can be done, medium to low.</p>
      remediation: >-
        <p>Remove ALL SPNs that are pointing to systems that no longer exist.
        This has do be done for ALL domains.<br>This can either be done by
        directly changing the <em>servicePrincipalName</em> value of the AD
        objects or by using the <em>setspn</em> command:</p><pre><code>setspn -d
        &lt;SPN&gt; &lt;accountname&gt;  

        setspn -d MSSQL/SQLSERVER1 sqlservice </code></pre>
      references:
        - 'https://luemmelsec.github.io/Kerberoasting-VS-AS-REP-Roasting/'
      customFields: []
  category: Internal Pentest

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'
  priority: null
  remediationComplexity: null
  details:
    - locale: EN
      title: SAP Gateway ACL Misconfiguration
      vulnType: Vulnerability Scan
      description: >-
        <p>A remote code execution vulnerability exists in the remote SAP
        Gateway as a result of allowing non-SAP applications to communicate
        with, and potentially run OS commands on SAP applications. An
        unauthenticated attacker can run the arbitrary commands on remote server
        to gain access to the system or to read/write sensitive information.</p>
      remediation: >-
        <ul><li><p>Secure your Gateway ACL pointed by profile parameter
        gw/sec_info with help of SAP note 1408081</p></li><li><p>Filter out
        access from untrusted sources to the Gateway (port
        tcp/33NN)</p></li></ul>
      references:
        - 'https://github.com/chipik/SAP_GW_RCE_exploit'
        - 'https://github.com/gelim/sap_ms'
        - >-
          https://blogs.sap.com/2019/05/02/10kblaze-exploit-can-potentially-impact-most-sap-customers/
        - 'https://www.tenable.com/plugins/nessus/126003'
      customFields: []
  category: Internal Pentest

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
  priority: 4
  remediationComplexity: 1
  details:
    - locale: EN
      title: Password Reusage for Highly Privileged Accounts
      vulnType: Pentest
      description: >-
        <p>Password reuse refers to the practice of using the same password for
        multiple accounts or systems. This is considered a bad security practice
        because it significantly increases the risk of unauthorized access and
        security breaches.</p><p>When password reuse occurs, several security
        vulnerabilities arise:</p><ul><li><p><strong>Single Point of
        Failure:</strong> If a password is compromised for one account, all
        accounts using the same password become vulnerable. This means that an
        attacker who gains access to one account could potentially gain access
        to other accounts, including highly privileged
        ones.</p></li><li><p><strong>Amplified Impact:</strong> If an attacker
        gains access to a highly privileged account with broad system access
        (like an administrator account), they could potentially wreak havoc
        across the entire system or network.</p></li><li><p><strong>Limited
        Password Strength:</strong> People tend to use simpler passwords when
        they have to remember them for multiple accounts. This increases the
        chances of a password being easily guessed or cracked using brute-force
        attacks.</p></li><li><p><strong>Difficulty in Tracking and
        Management:</strong> Keeping track of multiple passwords can lead to
        poor password management practices, like writing passwords down or
        storing them in unsecured digital formats, further compromising
        security.</p></li><li><p><strong>Delayed Detection:</strong> Detecting
        unauthorized access becomes more challenging since a compromised account
        might not raise suspicion if the account holder also uses the same
        password for legitimate access.</p></li><li><p><strong>Social
        Engineering Exploits:</strong> If an attacker discovers a password from
        one account, they might use that information to impersonate the
        legitimate user and attempt to gain access to other accounts by
        exploiting trust relationships.</p></li></ul><p>For highly privileged
        accounts like administrators, the risks are even more severe. These
        accounts have access to critical systems, sensitive data, and the
        ability to make system-wide changes. If such an account is compromised
        due to password reuse, the potential damage and data breaches could be
        catastrophic.</p>
      remediation: >-
        <p>In no case should passwords be reused.</p><p>Choose unique and strong
        passwords for each user.</p><p>For highly privileged accounts use MFA
        where possible.</p>
      references:
        - ''
      customFields: []
  category: Internal Pentest

- cvssv3: 'CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H'
  priority: 2
  remediationComplexity: 1
  details:
    - locale: EN
      title: SCCM Usage of Network Access Account for Deployment
      vulnType: Pentest
      description: >-
        <p>The Network Access Account (NAA) is a manually assigned (domain)
        account which can be utilized by SCCM clients. This account enables
        content downloads from an SCCM Distribution Point (DP) in cases where
        the client cannot use its own computer account for DP access. Typically,
        an SCCM client uses its computer account for server communication,
        except for scenarios like non-domain-joined clients. <br>SCCM
        administrators often create NAAs for such cases. However, according to
        Microsoft [1] this is not best practice and should be avoided where
        possible. Instead Enhanced HTTP should be used.</p>
      remediation: >-
        <p>Transition to Enhanced HTTP.</p><p>After transitioning away from
        NAAs, disable or remove the NAA accounts in Active Directory.</p>
      references:
        - >-
          [1]
          https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/enhanced-http
        - >-
          [2]
          https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/accounts#network-access-account
        - >-
          https://www.securesystems.de/blog/active-directory-spotlight-attacking-the-microsoft-configuration-manager/
        - >-
          https://posts.specterops.io/the-phantom-credentials-of-sccm-why-the-naa-wont-die-332ac7aa1ab9
      customFields: []
  category: Internal Pentest

- cvssv3: 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L'
  priority: 3
  remediationComplexity: 2
  details:
    - locale: EN
      title: SCCM Client Push Installation
      vulnType: Pentest
      description: >-
        <p>SCCM (System Center Configuration Manager) client push installation
        is a method used to deploy the SCCM client software to computers in a
        networked environment. Instead of manually installing the SCCM client on
        each individual computer, client push installation automates the
        process.</p><p>Here's how it
        works:</p><ul><li><p><strong>Configuration</strong>: Administrators
        configure the SCCM server with the necessary settings for client push
        installation. This includes specifying credentials and authentication
        methods.</p></li><li><p><strong>Discovery</strong>: SCCM actively scans
        the network to identify computers that need the client software
        installed. It can also use predefined discovery methods to identify
        potential target
        computers.</p></li><li><p><strong>Installation</strong>: Once target
        computers are identified, the SCCM server attempts to remotely install
        the SCCM client software on those computers using the configured
        authentication credentials.</p></li><li><p><strong>Status
        Reporting</strong>: The SCCM server monitors the installation process
        and reports back on whether the installation was successful or
        encountered any issues.</p></li><li><p><strong>Client
        Communication</strong>: After successful installation, the SCCM client
        on each computer establishes communication with the SCCM server. This
        allows the server to manage the computer, deploy software, updates, and
        perform other configuration tasks.</p></li></ul><p>Client push
        installation simplifies the task of deploying the SCCM client to a large
        number of computers across the network, ensuring that they are properly
        configured and ready to be managed through SCCM.</p><p>The step
        <em>Installation</em> can be abused by an adversary who either
        compromised a client that already is configured inside SCCM or from any
        system if he gained access to credentials of a member of the <em>Full
        Administrators</em> role inside SCCM. Starting from there coercion of
        all push install accounts can be triggered and from the fetched
        information they can either try to crack the passwords or relay the
        credentials.<br>The prerequisites are:</p><ul><li><p>Automatic site
        assignment for a boundary group, automatic site-wide client push
        installation, and “Allow connection fallback to NTLM” are
        enabled.</p></li><li><p>The site server must be able to reach the
        capture/relay server via SMB on port 445 or if WebClient is enabled, via
        HTTP on any port.</p></li><li><p>HTTPS Only with PKI certificates must
        not be required for client authentication to management points for this
        attack to be executed as a low-privileged user.</p></li></ul>
      remediation: >-
        <p>Microsoft states that the least secure way to deploy the SCCM client
        is client push [1].</p><p>If it is the only option you can stick to the
        following recommendations:</p><ul><li><p>Disable the <em>Allow
        connection fallback to NTLM</em> setting</p></li><li><p>Use long and
        complex passwords for all push accounts.</p></li><li><p>Use software
        update-based client installation [2] instead of automatic site-wide
        client push installation</p></li><li><p>Lock down client push accounts
        by denying local logon and marking them as “account is sensitive and
        cannot be delegated”.</p></li><li><p>Do not use the client push
        installation method for Domain Controllers or sensitive
        servers/workstations. Push accounts should not be added to the local
        administrator’s group on these systems. Manual installation of the
        client is preferred. Ideally, critical assets should not be managed by
        the same SCCM at all (or leverage a separate system entirely dedicated
        to “Tier 0” assets).</p></li><li><p>Evaluate the use of NTLM across the
        enterprise. At a minimum, the authentication level for Domain
        Controllers should be set to “Send NTLMv2 response only\refuse LM &amp;
        NTLM”, and efforts should be made toward fully eliminating NTLM
        traffic.</p></li><li><p>Starting in version 1806, Microsoft implemented
        the checkbox to “allow connection fallback to NTLM”. They recommend
        unchecking this setting to enforce Kerberos authentication. Note that
        clients must be in a trusted Active Directory to use this feature.
        Careful testing may be required to ensure there is no service disruption
        when disabling this setting.</p></li><li><p>Never use members of highly
        privileged groups (e.g., Domain Admins) for client push installation.
        Instead, create an account for each site specifically for this purpose
        that doesn’t have interactive logon rights and add it to the local
        Administrators group. Monitor for suspicious use of this
        account.</p></li><li><p>Require SMB signing, LDAP signing/channel
        binding, and MSSQL extended protection for authentication to prevent
        relayed credentials from being used to against other
        systems.</p></li><li><p>Requiring PKI certificates for SCCM client
        authentication also prevents this attack from being conducted as a
        low-privileged user, even if NTLM authentication is allowed.
        </p></li></ul>
      references:
        - >-
          [1]
          https://learn.microsoft.com/en-us/mem/configmgr/core/clients/deploy/plan/security-and-privacy-for-clients#use-the-most-secure-client-installation-methods-that-are-practical-for-your-environment
        - >-
          [2]
          https://docs.microsoft.com/en-us/mem/configmgr/core/clients/deploy/deploy-clients-to-windows-computers
        - >-
          https://posts.specterops.io/coercing-ntlm-authentication-from-sccm-e6e23ea8260a
        - >-
          https://posts.specterops.io/relaying-ntlm-authentication-from-sccm-clients-7dccb8f92867
        - >-
          https://posts.specterops.io/sccm-site-takeover-via-automatic-client-push-installation-f567ec80d5b1
        - 'https://github.com/Mayyhem/SharpSCCM/wiki/invoke#invoke-client-push'
        - >-
          https://www.hub.trimarcsecurity.com/post/push-comes-to-shove-exploring-the-attack-surface-of-sccm-client-push-accounts
      customFields: []
  category: Internal Pentest