Top 5 Critical Network Pentest Findings

01. NetBIOS NAME SERVICE (NBNS) SPOOFING

NetBIOS (Network Basic Input/Output System) is a protocol used for file sharing, printer sharing, and other network services in older versions of the Windows operating system. NBNS serves the same purpose as DNS: translate human-readable names to IP addresses. The NBNS protocol is used within an internal network environment to resolve a domain name system (DNS) name when a DNS server doesn’t exist or can’t be helpful.

NetBIOS Name Service (NBNS) spoofing is a type of cyber-attack that involves manipulating or impersonating the NetBIOS Name Service to redirect network traffic or gain unauthorized access to resources.

Here’s a brief overview of how NBNS spoofing works:

NetBIOS Name Resolution:

1. The system checks its local host file to determine if an entry exists to match the DNS name with an IP address.

2. If the system does not have an entry in its local hosts file, it sends a DNS query to its configured DNS server(s) to attempt retrieving an IP address that matches the DNS name in question.

3. If the configured DNS server(s) cannot resolve the DNS name to an IP address, the system sends an NBNS broadcast packet on the local network to seek assistance from other systems.

Attack Scenario:

In an NBNS spoofing attack, an attacker can send malicious packets to the target network, claiming to be a legitimate NBNS server.

Spoofing Responses:

The attacker responds to NetBIOS name resolution requests, providing false information. For example, the attacker might respond to a request for the legitimate server’s NetBIOS name with its IP address.

Redirected Traffic:

The requesting device receives the spoofed NBNS response and believes it has obtained the correct IP address for the desired NetBIOS name. Consequently, all subsequent network traffic intended for that NetBIOS name will be sent to the attacker’s IP address. Instead of redirection, an attacker can flood the listening NetBIOS ports with requests. This can cause the system to become unresponsive or crash.

Man-in-the-Middle (MITM) Attacks:

With the network traffic redirected, the attacker can exploit the situation in various ways. They may perform a Man-in-the-Middle (MITM) attack, intercepting and manipulating the network traffic for malicious purposes. This can include capturing sensitive information, injecting malware, modifying or redirecting traffic, or launching attacks on the compromised devices.

Security Impact:

Since the NBNS queries are broadcast across the network, any system can respond to these queries with the IP address of the DNS name in question. Malicious attackers can abuse this since an attacker can respond to all these queries with the IP address of the attacker’s system. Depending on the service the victim was attempting to communicate with (e.g., SMB, MSSQL, HTTP, etc.), an attacker may be able to capture sensitive cleartext and hashed account credentials. Hashed credentials can often be recovered in a matter of time using modern-day computing power and brute force techniques.

Recommendation to fix:

Implement the following strategy for preventing the use of NBNS in a Windows environment or reducing the impact of NBNS Spoofing attacks:

Disable NetBIOS (manually)

• Click Start, point to Settings, and then click Network Connections.
• Right-click the local area connection that you want to be statically configured, and then click Properties.
• Click Internet Protocol (TCP/IP) > Properties > Advanced, and then click the WINS tab.
• Click Disable NetBIOS over TCP/IP.

Disable NetBIOS (automatically)

# disable NetBIOS over TCP/IP (legacy protocol not required)

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\netbt\Parameters\interfaces\tcpip_*’ -name NetBiosOptions -value 2 -Verbose

Audit:

02. LINK-LOCAL MULTICAST NAME RESOLUTION (LLMNR) SPOOFING

Like NetBIOS, the Link-Local Multicast Name Resolution (LLMNR) is a broadcast protocol used in Windows systems to support legacy systems and resolve computer names for clients that cannot be resolved through DNS queries. Having LLMNR protocol enabled exposes systems on the internal network to potential poisoning attacks. A successful poisoning attack may allow a malicious user to perform man-in-the-middle attacks on communication destined for another host and potentially intercept sensitive authentication data, which can then be taken offline for password attacks and brute forcing.

When a system attempts to resolve a DNS name, the system proceeds with the following steps:

1. The system checks its local host file to determine if an entry exists to match the DNS name with an IP address.

2. If the system does not have an entry in its local hosts file, it sends a DNS query to its configured DNS server(s) to attempt retrieving an IP address that matches the DNS name in question.

3. If the configured DNS server(s) cannot resolve the DNS name to an IP address, the system sends an LLMNR broadcast packet on the local network to seek assistance from other systems.

Security Impact:

Since the LLMNR queries are broadcast across the network, any system can respond to these queries with the IP address of the DNS name in question. Malicious attackers can abuse this since an attacker can respond to all these queries with the IP address of the attacker’s system. Depending on the service the victim was attempting to communicate with (e.g., SMB, MSSQL, HTTP, etc.), an attacker may be able to capture sensitive cleartext and/or hashed account credentials. Hashed credentials can often be recovered in a matter of time using modern-day computing power and brute-force techniques.

Recommendation to fix:

1. Open the group policy editor by typing “gpedit.msc“
2. In the Local Group Policy Editor, navigate to the following path:
3. Computer Configuration à Administrative Templates à Network à DNS Client à  locate the policy named “Turn off multicast name resolution.”
4. Double-click on the policy to open its properties.
5. Select the “Enabled” option.
6. Click the “Apply” button and then “OK” to save the changes.

Audit:

From the command prompt, type the following command:

netstat -a -n

Look for port numbers 137, 138, and 139 in the output. These are the default ports used by NetBIOS. If you see these ports listed as “Listening” or “Established,” it indicates that NetBIOS is active and potentially exposed to attacks.

03. IPV6 DNS SPOOFING

All operating systems support IPv6 communication by default, but organizations aren’t focused yet on IPv6. By default, on Windows environments, IPv6 is enabled and has priority over IPv4. Usually, IPv6 is neither used nor configured. When a Windows machine boots or gets plugged into the network, it asks for an IPv6 configuration through a DHCPv6 request. The attacker brings a rough DHCPv6 server on the same network and then forces clients to update their DNS server information into a rough DNSv6. Spoofing DNS responses can lead to various security threats, including redirecting users to malicious websites, intercepting communication, or performing Man-in-the-Middle (MitM) attacks.

Here’s a general overview of how IPv6 DNS spoofing might occur:

DNS Query Process:

When a device needs to resolve a domain name to an IP address, it sends a DNS query to a DNS server.

IPv6 DNS Spoofing Scenario:

In an IPv6 DNS spoofing attack, an attacker might intercept DNS queries or proactively send malicious DNS responses to the target network.

Spoofing Responses:

The attacker can craft DNS responses with false information, providing incorrect IP addresses for requested domain names.

Redirecting Traffic:

The attacker can redirect traffic to a server under their control by manipulating DNS responses. This can be used to impersonate legitimate websites, eavesdrop on communication, or launch other attacks.

Recommendation to fix:

# Prefer IPv4 over IPv6

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters” /v DisabledComponents /t REG_DWORD /d 0x20/f

Audit:

netsh interface ipv6 show prefixpolicies

04. ACCOUNTS VULNERABLE T0 KERBEROASTING

Kerberoasting is a post-compromise attack technique for cracking passwords associated with service accounts in Microsoft Active Directory. The attacker impersonates an account user with a service principal name (SPN) and requests a service-related ticket. They then crack the password hash linked to that service account, log in with the plaintext credentials, and advance the attack.

A user can request a ticket-granting service (TGS) ticket for any SPN, and parts of the TGS may be encrypted with RC4 using the password hash of the service account assigned the requested SPN as the key. Therefore, an adversary who can steal TGS tickets (either from memory or by capturing them by sniffing network traffic) can extract the service account’s password hash and attempt an offline brute force attack to obtain the plaintext password.

The root causes of the Kerberoasting attack are listed below:

1. Most service accounts are over-permission and are often members of domain admins or local admins providing full admin rights to Active Directory or member servers.

2. In many scenarios, the same service accounts with the same password are the local admins for multiple servers.

3. In many scenarios, the services account password is configured as “password never expires,” or the password hasn’t changed in over a year.

Recommendation to fix:

1. Ensure service accounts are granted following the principle of least privilege and segregation of duties.
2. Configure service accounts so they cannot log in interactively to a system (“Deny Interactive Logon”).
3. Ensure strong password policies for service accounts (e.g., minimum 25+ characters) and that passwords are changed regularly.
4. Ensure the use of multifactor authentication (MFA).
5. Ensure strong encryption for Kerberos tickets, such as AES256 instead of RC4. No RC4 encryption is allowed.
6. Implement Kerberoasting detection mechanisms. This can be done by performing the following:

• Configure “Audit Kerberos Service Ticket Operations” (Success) on Domain Controllers. This will generate two Event IDs:

o 4769: A Kerberos service ticket (TGS) was requested

o 4770: A Kerberos service ticket was renewed

• Ensure these logs are forwarded to a central store (e.g., Security Information and Event Management platform)

• Regularly Rotate Service Account Passwords.

Consider implementing Microsoft “Managed Service Accounts” (MSA) (Windows Server 2008R2 and later) or “Grouped Manage Service Accounts” (gMSA) (Windows Server 2012 and later).

05. WEAK PASSWORD POLICY

Ensuring a strong password policy is a fundamental aspect of overall cybersecurity hygiene, and organizations should regularly review and update their policies to adapt to evolving threats. One of the root causes of compromising a privileged server is the weakness of the password policy. Often, organizations fail to implement an effective password policy.  Weaknesses in password complexity are usually abused via password guessing attacks or if an attacker could gather password hashes for offline cracking and retrieval. An attacker would need to gain elevated privileges on a system within the internal network to obtain user NTLM hashes.

Recommendation to fix:

Strengthen Password Policies

• Regular user accounts:

o All passwords should be created with these three guiding principles in mind:

• Password must be strong:
• Password must be long (At least 12 or more characters).
• Password must be unique (Never re-use passwords).
• Password must be complex (Each unique password should combine upper-case letters, lower-case letters, numbers, and special characters).
• Make your password a sentence:
• Example: I love country music à Il@vec@ountrymus1c
  • Ensure the use of a unique account and password; having separate passwords for every account helps thwart cybercriminals. At a minimum, separate your work and personal accounts and ensure that your critical accounts have the strongest passwords.

• Privileged domain user accounts:

o Require a minimum of 20-character passwords.

• Other requirements are listed for regular user accounts.

• Service and application accounts:

o Require a minimum of 30-character passwords.

o Other requirements listed for regular user accounts, except the accounts should not be set to

automatically lockout.

Password Requirements:

1. Ensure service accounts are granted following the principle of least privilege and segregation of duties.

2. Configure service accounts so they cannot log in interactively to a system (“Deny Interactive Logon”).

3. Ensure strong password policies for service accounts (e.g., minimum 25+ characters) and that passwords are changed regularly.

4. Ensure the use of multifactor authentication (MFA).

5. Ensure strong encryption for Kerberos tickets, such as AES256 instead of RC4. No RC4 encryption is allowed.

6. Implement Kerberoasting detection mechanisms. This can be done by performing the following:

• Configure “Audit Kerberos Service Ticket Operations” (Success) on Domain Controllers. This will generate two Event IDs:

o 4769: A Kerberos service ticket (TGS) was requested

o 4770: A Kerberos service ticket was renewed

• Ensure these logs are forwarded to a central store (e.g., Security Information and Event Management platform)

7. Regularly Rotate Service Account Passwords.

8. Consider implementing Microsoft “Managed Service Accounts” (MSA) (Windows Server 2008R2 and later) or “Grouped Manage Service Accounts” (gMSA) (Windows Server 2012 and later).