Surviving and Passing SOC Audits – Part Two

Return to Part One

In part two and three of the “Surviving and Passing SOC Audits”, we are going to discuss the most common findings that come up in a penetration test, and ways that you can remediate those findings through configuration changes or controls. First, lets discuss Severity ratings and CVSS Scores, below is a table that shows the common scoring for vulnerabilities.

Vulnerability Scoring

In a network penetration test, you’re likely to come across a range of findings. Some can be rectified swiftly, while others demand greater time and resources. We’ll delve into each to deepen your understanding of what they entail and how to address them. Although I may offer PowerShell code for quick fixes, it’s advisable to implement remediation through Group Policy whenever feasible. This ensures a uniform application of changes across all current and future Windows systems.

Part One

• Local Network Poisoning – LLMNR, NBT-NS, mDNS (High)
• Unmanaged IPv6 Man in the middle (High)
• Outdated Software and Services (Critical or High)
• WPAD Man-in-the-middle
• Weak SSH configuration
• Deprecated TLS Protocol Support – TLS 1.0 or 1.1 (Medium)
• ARP Poisoning (High)

Part Two

• Accessible Network Shares (High)
• Default Credentials on Devices (Medium)
• SMB Signing Disabled (Medium)
• Weak TLS/SSL configuration (Medium)
• Weak RDP configuration (Medium)
• HTTPS not required (Medium)
• Weak SSH configuration (Medium)

Local Network Poisoning

Finding: Local Network Poisoning is a frequent and troublesome issue that persistently emerges in various forms such as LLMNR, NBT-NS, or mDNS. Each variant requires a unique approach to remediation. LLMNR, NBT-NS, and mDNS are integral to contemporary Microsoft Windows operating systems. LLMNR, which debuted with Windows Vista, was designed to supplant NBT-NS. By default, both LLMNR and NBT-NS are active. On the latest Windows 10, Windows 11, and Server 2022 versions, as well as on Mac and iOS devices, mDNS is also enabled by default. Windows further permits applications to employ mDNS for specialized broadcasts, a functionality utilized by browsers such as Google Chrome and Microsoft Edge. Moreover, devices like printers, projectors, and screen-casting tools commonly utilize mDNS for device detection.

Impact: Attackers may exploit LLMNR, NBT-NS, and mDNS protocols to conduct man-in-the-middle attacks. They do this by monitoring for LLMNR (5355/UDP), NBT-NS (137/UDP), and mDNS (5353/UDP) broadcasts or multicast requests for host resolution within a local network. An intercepted request can be manipulated to reroute the user to a machine under the attacker’s control. This misuse of protocols can lead to authentication requests being mistakenly sent to the attacker, which were meant for legitimate hosts. Attackers might leverage these requests to launch further attacks on the network. Should the intercepted credentials be plaintext, they can be directly used for authentication on other systems and services. Alternatively, if the credentials are hashed, they can be retained for future cracking attempts or used in relay attacks targeting other systems in the network.

NBT-NS/LLMNR Remediation: To mitigate this issue, a few adjustments are necessary, and consistency is key across all Windows systems, encompassing servers and end-user laptops/workstations. Within the settings of each network card, you must deselect the “Enable LMHOSTS Lookup” option and choose to disable “Netbios over TCP/IP”.

Here is a powershell script that can be used to disable both settings:

# Disable LMHOSTS lookup on all network adapters
$adapters = Get-WmiObject Win32_NetworkAdapterConfiguration
foreach ($adapter in $adapters) {
    if ($adapter.IPEnabled -eq $true) {
        $null = $adapter.SetWINSEnableLMHostsLookup($false)
    }
}

# Disable NetBIOS over TCP/IP on all network adapters
$regkey = "HKLM:SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey | ForEach-Object {
    Set-ItemProperty -Path "$regkey\$($_.PSChildName)" -Name NetbiosOptions -Value 2
}

mDNS Remediation: To mitigate this issue you can use the following powershell code, or create a GPO with the same registry update.

# Disable "Automatically detect settings" in Internet Options
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\" -Name EnableMDNS -Value 0 -Type DWord

Unmanaged IPv6 Man in the middle (High)

Finding: This one can be a real headache if you do not have infrastructure in place to handle IPv6 traffic. Most auditing companies will recommend that you enable RA Guard or DHCP guard on all your switches, or on your VMware virtual switches (which requires NSX) to prevent DHCP spoofing. However, you may not have that capability on your switches, I have been in that position before, or maybe you don’t use NSX in your virtual environment.

Impact: Operating systems’ favoring of IPv6 allows attackers to establish unauthorized services and interact with unmanaged hosts. They can set up a rogue DHCPv6 server that, once operational, enables IPv6-capable hosts and devices to obtain IPv6 addresses. This rogue server can also distribute DNS addresses, causing hosts to route DNS requests through the attacker’s system.

# Disable "Automatically detect settings" in Internet Options
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name AutoDetect -Value 0