Grey Hat Developer performed testing under a “black box” approach Oct 13, 2022, to Oct 15, 2022, without credentials or any advance knowledge of Hacker High School’s internally facing environment with the goal of identifying unknown weaknesses. Testing was performed from a non-evasive standpoint with the goal of uncovering as many misconfigurations and vulnerabilities as possible. Testing was performed remotely via a host that was provisioned specifically for this assessment. Each weakness identified was documented and manually investigated to determine exploitation possibilities and escalation potential. Grey Hat Developer sought to demonstrate the full impact of every vulnerability, up to and including internal domain compromise. If Grey Hat Developer were able to gain a foothold in the internal network, Hacker High School allowed for further testing including lateral movement and horizontal/vertical privilege escalation to demonstrate the impact of an internal network compromise.

The scope of this assessment was one internal network range and the HACKERHIGH.LOCAL Active Directory domain.

In-Scope Assets

Table 1: Scope Details

During the internal penetration test against Hacker High School, Grey Hat Developer identified seven (7) findings that threaten the confidentiality, integrity, and availability of Hacker High School’s information systems. The findings were categorized by severity level, with five (6) of the findings being assigned a high-risk rating and one (1) medium-risk.

The tester found Hacker High School’s patch and vulnerability management to be well-maintained. None of the findings in this report were related to missing operating system or third-party patches of known vulnerabilities in services and applications that could result in unauthorized access and system compromise. Each flaw discovered during testing was related to a misconfiguration or lack of hardening.

One finding involved a network communication protocol that can be “spoofed” to retrieve passwords for internal users that can be used to gain unauthorized access if an attacker can gain unauthorized access to the network without credentials. In most corporate environments, this protocol is unnecessary and can be disabled.  It is enabled by default primarily for small and medium sized businesses that do not have the resources for a dedicated hostname resolution (the “phonebook” of your network) server.  During the assessment, the presence of these resources was observed on the network, so Hacker High School should begin formulating a test plan to disable the dangerous service.

The next issue was a weak configuration involving service accounts that allows any authenticated user to steal a component of the authentication process that can often be guessed offline (via password “cracking”) to reveal the human-readable form of the account’s password. These types of service accounts typically have more privileges than a standard user, so obtaining one of their passwords in clear text could result in lateral movement or privilege escalation and eventually in complete internal network compromise. Fortunately, this issue can be corrected without the need for third-party tools.  Microsoft’s Active Directory contains settings that can be used to minimize the risk of these resources being abused for the benefit of malicious users.

The tester also found shared folders with excessive permissions, meaning that all users in the internal network can access a considerable amount of data. While sharing files internally between departments and users is important to day-to-day business operations, wide open permissions on file shares may result in unintentional disclosure of confidential information. Even if a file share does not contain any sensitive information today, someone may unwittingly put such data there thinking it is protected when it isn’t. This configuration should be changed to ensure that users can access only what is necessary to perform their day-to-day duties.

Finally, the tester noticed that testing activities seemed to go mostly unnoticed, which may represent an opportunity to improve visibility into the internal network and indicates that a real-world attacker might remain undetected if internal access is achieved.  Hacker High School should create a remediation plan based on the Remediation Summary section of this report, addressing all high findings as soon as possible according to the needs of the business. Hacker High School should also consider performing periodic vulnerability assessments if they are not already being performed. Once the issues identified in this report have been addressed, a more collaborative, in-depth Active Directory security assessment may help identify additional opportunities to harden the Active Directory environment, making it more difficult for attackers to move around the network and increasing the likelihood that Hacker High School will be able to detect and respond to suspicious activity.

During testing, Grey Hat Developer uncovered a total of seven (7) findings that pose a material risk to Hacker High School’s information systems. Grey Hat Developer also identified one informational finding that, if addressed, could further strengthen Hacker High School’s overall security posture. Informational findings are observations for areas of improvement by the organization and do not represent security vulnerabilities on their own. The below table provides a summary of the findings by severity level.

Table 2: Severity Summary

Below is a high-level overview of each finding identified during testing. These findings are covered in depth in the Technical Findings Details section of this report.

Table 3: Findings List

1. Grey Hat Developer performed the following to fully compromise the HACKERHIGH.local domain.
2. The tester utilized the Responder tool to obtain an NTLMv2 password hash for a domain user,
3. This password hash was successfully cracked offline using the Hashcat tool to reveal the user’s clear text password which granted a foothold into the LOCAL domain, but with no more privileges than a standard domain user.
4. The tester ran the Impacket tool on the system with the obtained credentials and was able to discover that one of the shares was writable.
5. The tester then ran an Nmap script that checks for any hosts on the network that were running the SMB service and configured with signing disabled. This configuration was present on multiple systems. This allowed the tester to execute an SMB relay attack and obtain the SAM password hashes of both systems.
6. The tester then improved upon the SMB Relay attack, utilized the Responder tool to obtain an interactive shell on a remote host.
7. The tester used another tool, Secrets Dump, to be more stealthy  with the attack.
8. This password hash was successfully cracked offline using the Hashcat tool to reveal the clear text passwords which granted the password of another user account, bmonroe and an Administrator account which could potentially be used to elevate privileges on the system.
9. The tester found that one of the user’s passwords had local administrator privileges. With this knowledge the tester launched a Token-Impersonation attack with permitted the impersonation of a logged in domain administrator account.
10. From here, the tester used the GetUserSPNs.py tool to carry out a targeted Kerberoasting attack against the mssqlsvc account, having found that the mssqlsvc account had local administrator rights over the host SQLService.HACKERHIGH.LOCAL which was an interesting target in the domain.
11. The tester was able to crack this account’s password offline, revealing the clear text value.
12. The tester identified the Domain Controller had the IPv6 and LDAPS services enabled. The allowed the tester to execute a MiTM (Man-In-The-Middle) attack which subsequently revealed the cleartext password of a service account that someone had listed in the description of the account. The attack also created a new user on the domain controller.

Detailed reproduction steps for this attack chain are as follows:

Upon connecting to the network, the tester started the Responder tool and was able to capture a password hash for the pherzog user by spoofing NBT-NS/LLMNR traffic on the local network segment.

• [Finding 2] – Set strong (24+ character) passwords on all SPN accounts
• [Finding 5] – Enable SMB Signing on all devices
• [Finding 6] – Limit user/group token creation permissions
• Account tiering
• Local admin restriction

• [Finding 1] – Disable LLMNR and NBT-NS wherever possible
• [Finding 2] – Transition from SPNs to Group Managed Service Accounts (gMSA) wherever possible
• [Finding 3] – Implement a solution such as the Microsoft Local Administrator Password Solution” (LAPS)
• [Finding 4] – Enhance the domain password policy
• [Finding 5] – Disable NTLM authentication on network
• [Finding 7] – Perform a network file share audit

• Perform ongoing internal network vulnerability assessments and domain password audits
• Perform periodic Active Directory security assessments
• Educate systems and network administrators and developers on security hardening best practices compromise
• Enhance network segmentation to isolate critical hosts and limit the effects of an internal compromise

Finding Evidence:

Running the Responder tool to attempt to obtain user account password hashes.

Figure 1: Running Responder

Finding Evidence:

Retrieving a listing all SPN accounts in the HACKERHIGH.LOCAL domain using the GetUserSPNs.py tool from the Impacket toolkit.

Figure 2: Kerberoasting – Listing SPN Accounts

Targeted Kerberoasting against the mssqlsvc account using the GetUserSPNs.py tool.

Figure 3: Targeted Kerberoasting

• CWE	CWE-526
  CVSS 3.1 Score	9.5
  Description (Incl. Root Cause)	The person responsible for setting up service accounts sometimes put passwords in the description field to remember the password on the account. Storing a password in plaintext may result in a system compromise. Password management issues occur when a password is stored in plaintext in an application’s properties, configuration file, or memory. Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource. In some contexts, even storage of a plaintext password in memory is considered a security risk if the password is not cleared immediately after it is used.
  Security Impact	If external services are set up with Active Directory authentication (such as VPN, email, or remote application services) an attacker may be able to perform a targeted password
  Affected Domain	·         HACKERHIGH.LOCAL
  Remediation	·         Do not put passwords in places such as the description fields of accounts ·         Review the password policy and enforce a 12-character minimum password. Consider implementing an enterprise password manager to encourage the use of strong, randomized, passwords. Implement a password filter to restrict the use of common words such as variations on the words “welcome” and “password”, seasons, months, and variations on the company name. Network intrusion detection and prevention systems that can identify traffic patterns indicative of MiTM activity can be used to mitigate activity at the network level.
  External References	https://attack.mitre.org/mitigations/M1027/

  Finding Evidence:

  Running a MiTM attack on IPv6/LDAPS protocols to get domain information.

  $ mitm6-d HACKERHIGH.local $ ntmlrelayx.py -6 -t ldaps://domaincontroller -wh $ fakewpad.HACKERHIGH.local -l lootme (<- directory to save info on local machine)

  Figure 4: Dumping domain information

Finding Evidence:

Performing a ntlmrelay attack against all domain users and finding two valid passwords.

Figure 5: Finding valid user accounts 

Finding Evidence:

Performing a ntlmrelay attack against all domain users and finding two valid passwords.

Figure 6: Finding valid user accounts 

Finding Evidence:

Running a MiTM attack on IPv6/LDAPS protocols to get domain information.

Figure 7: Dumping domain information

Finding Evidence:

Viewing file shares accessible to a standard Domain user with the Impacket  tool.

Figure 8: Listing Accessible Shares

Each finding has been assigned a severity rating of high, medium, or low. The rating is based off of an assessment of the priority with which each finding should be viewed and the potential impact each has on the confidentiality, integrity, and availability of Hacker High School’s data.

Table 4: Severity Definitions

Table 5: Exploited Hosts

Table 6: User Accounts Compromised