Sniffing out a Foothold
LLMNR/NBT-NS Poisoning - from Linux
LLMNR (5355 UDP) and NetBIOS (137 UDP) are legacy protocols used by Windows. These are used when DNS fails to resolve hostnames on the network. When a host is trying to resolve another host it will ask the DNS first, then if it fails, it will rely on the LLMNR protocol and then on the NetBIOS protocol as last resort.
The LLMNR protocols allows every hosts on the network to respond to a host making a name resolution query. In others words this is a multicast name resolution protocol.
This schema from Hacking Articles is a good illustration of how it works. When the DNS fails to respond to a requestor's resolving query, the requestor asks (sending multicast packets) all others machine on the networks for the answer. Then, the attacker machine plays as an authoritative server and pretend to know the answer to the request. The attacker then ask the requestor to authenticate itself to get access to the resource. This can grant the attacker with the NetNTLMv1/v2 hash of the requestor. This NTLM hash can be cracked offline or relayed to others domain-joined services or hosts.
The most known tool to perform LLMNR/Net Bios poisoning from a Linux attack box is Responder.
All captured hashes can be found in the /usr/share/responder/logs
folder.
Theses ports should be open on our attacker box for a more successful attack:
The NTLMv2 hashes captured can be cracked offline using hashcat (5600
). NTLMV1 hashes can be cracked using with crack.sh.
LLMNR/NBT-NS Poisoning - from Windows
LLMNR/Net-BIOS poisoning attacks can also be performed from a Windows attack box using Inveigh. Two versions of this tool exists, one is coded in C# and the others in PowerShell. The tool contains a lot of parameters. Those are listed here.
The PowerShell version is no longer supported
PowerShell version
Importing module and listing all parameters
LLMNR Poisoning attack
C# version
Can be compiled using the the .sln
file in the Github repo.
An advantage of the C# version is that we can enter an interactive console by pressing ESC while the tool is running. For example, this allows us to list all available options and list all NetNTLM hashes captured.
LLMNR/NetBIOS Mitigations
Disable LLMNR/NetBios protocol (make sure to test that disabling these protocols does not break the network).
Segmenting the network putting all assets togheter those who requires LLMNR/NetBios.
Disabling the LLMNR protocol
The LLMNR protocol can be disabled via Group Policy Editor. See here.
Disabling the NetBIOS protocol
Disabling the NetBIOS protocol for all hosts in a domain requires more steps as it can not be directly disabled via GPO. However, it is possible to add a script in the SYSVOL volume (shared between all domains computer) that will get executed once the hosts will reboot.
In the Groupe Policy Management Editor: Computer Configuration > Windows settings > Script (StartUp/Shutdown), we can specify the location of the script to get executed at startup. The value of the Script Name field should point to the location of the script containing the line of code below.
This script lists all interfaces of a host and aim to disable the NetBIOS protocol for each of them.
The script can thus be called on the DC by the UNC path that point to the script.
Detection Indicator
Defenders can send rogue LLMNR/NetBIOS requests and monitor if any machine is responding to them.
Monitor any changes to the
EnableMulticast
DWORD value for theHKLM\Software\Policies\Microsoft\Windows NT\DNSClient.
Password Spraying
While brute forcing involves attempting to identify the password for a user account using a long list of passwords, password spraying is using a single or a short list of passwords against multiple users accounts. Passwords spraying is a better approach to prevent the lock of productions accounts in the environment.
Make sure to enumerate the password policy before attempting a password spray attack. We do not want to lock account especially, when an admin needs to manually intervene to unlock the account.
Some elements are to consider before conducting a password spraying attack:
Examine the password policy of the organization. Details here.
Building a list of potential and valid usernames. Details here.
Choose a small list of potential valid passwords based on previous credentials identified or from a common password list (ex: Season, Organization name, common passwords such as Welcome1 or Password1, etc).
When our list of valid users and passwords are ready, we can perform the password spraying attempt using different tools depending if we have access to a Linux or Windows attack box. Details here.
Our methodology to enumerate valid users and conduct a password spray attempt will depend greatly on many elements:
Do we have a foothold to the internal network?
Do we already have credentials for a domain users?
Can we reach the DC?
Do we have access to a Linux or Windows Attack box?
Internet Facing Assets
It is also possible to identify valid set of credentials by conducting a password spraying attack against external facing services and web applications whose accounts are linked with AD such as:
Microsoft O365
Outlook Exchange
Skype
Lync server
RDS portals
Citrix
VDI
VPN
Finding a valid pair of credentials for one or many of those services could lead to a foothold within the internal network.
Password Spraying Mitigation
The impact of a successful password spraying attempt can be mitigated. Here are listed some best security practices to apply to an internal network environment and regarding Internet facing assets and services.
Enable Multi-Factor Authentication (OTP, RSA key, text message confirmation, push notification - keep in mind possible MFA fatigue).
Apply the least privilege principle which is granting to a user rights and access to only what is required for daily operations.
Separate regular users accounts from privileged accounts used to perform administrative tasks.
Ensure that the network is properly segmented to prevent lateral movement by an attacker and further compromise.
Educate users about the use of a secure password. Enabling password filter to avoid the most common passwords such as those based on the season or the company name.
Detection
There are different actions a company may perform to detect possible password spraying attacks attempt. To name a few:
Logs authentication attempts and trigger an alert if a large number of logon failure attempts are registered in a short laps of time. The ID event is 4625 when an account failed to logon.
Monitor failed Kerberos Pre-Authentication attempt. The event ID is 4771.
This article is about identifying Password Spraying attempts using Windows Security Event Logging. Here
Last updated