Notes from the field – Penetration tests

This blog post is by no means a comprehensive guide from an expert in the cyber security area. However my previous role meant I had the pleasure of reviewing a number of customer penetration tests and from this, pretty much all of them were all exploited in the same way. So I put together some basic information for any of my customers to review and think about before they had a penetration booked.

After all, might as well make it a challenge for the people you are hiring to hack your network 😉

Methodology

Ok, so I’m only going to cover the basics, as there are far better articles out there on this.

  • Reconnaissance
    • Information gathering before attending the targets site
      • IP addresses of websites and MX record details
      • Details of email addresses (shared mailboxes, employees direct)
      • Social networks (details shared on LinkedIn by Employees, the companies twitter posts etc)
        • Consider the below twitter post by a company, what information can you glean from seeing a picture of their racks and other equipment.
        • If we know the company name, we can enumerate the various domain names they own to public IP addresses, and just plug that into a website like http://shodan.io and maybe look for that Sonicwall and find out if its running the latest firmware.
        • Below when zooming in on the image, we can find details of an ADSL line
      • Job websites; are they hiring, especially in IT, what skills do they want? Looking for an engineer that knows a particular accountancy package?
  • Enumeration/Identification
    • Assessment of devices found and the search for vulnerabilities
      • Tools in use such as, but not limited to; nmap, Nessus, Metasploit, unicornscan, nikto, dotdotpwn, gobuster.
  • Exploitation
    • Create a plan of action/attack based on the information gathered.
    • Perform the attack/exploitation itself to achieve the end goal, usually access to systems from zero, escalation with the end goal being access to private/sensitive/restricted systems and data.
    • Tools in use such as, but not limited to; Kali Linux (OS and contains a lot of tooling), Nmap, Metasploit, BurpSuite, SQLMap, padbuster, custom exploit scripts
Common exploits to gain access

Ok so first, lets review how multiple networks were exploited or hacked.

Below is the common summary of issues found at many sites I reviewed, and this is what I will cover in this blog post ;

  • Null session authentication on Domain Controllers
  • Devices configured to use NBT-NS / LLMNR
  • SMB Signing
  • NTLMv1 in use for network authentication
  • Domain Users have Local Admin permissions to their machines
  • Poor password policy
  • No split accounts for Domain Admins
  • Poor patching on systems
Null Session Authentication

By default null sessions (unauthenticated) are enabled on Windows 2000 & 2003 servers. Therefore anyone can use these NULL connections to enumerate potentially sensitive information from the servers, read this as information from your Active Directory.

Therefore anyone with a legacy domain which has been upgraded through the years, will find that Null Session Authentication is enabled on their environments.

Seeing it in action

I won’t recreate, as a quick google will find you numerous articles on the subject. However this YouTube video shows you a tool to undertake this exploit.

Resolution

Step 1 : Apply below group policy settings to Default Domain Controller policy object or to the GPO object that is applied to your domain controllers.

Edit GPO- Go to Computer configuration\Policies\Windows settings\Security Settings\Local Policies\SecurityOptions

Enable:
Network access: Restrict Anonymous access to Named Pipes and Shares
Network access: Do not allow anonymous enumeration of SAM accounts
Network access: Do not allow anonymous enumeration of SAM accounts and shares
Network access: Shares that can be accessed anonymously
Disable:
Network access: Let Everyone permissions apply to anonymous users
Network access: Allow anonymous SID/Name translation

Step 2 : Update the registry key values to restrict null session as below:

HKEY\SYSTEM\CurrentControlSet\Control\Lsa:
RestrictAnonymous = 1
Restrict AnonymousSAM = 1
EveryoneIncludesAnonymous = 0

(source)

Devices configured to use NBT-NS / LLMNR

LLMNR (Link-Local Multicast Name Resolution) is a protocol that was first part of the Windows Vista OS. It is usually found to be used by network connected devices to identify hosts on a local subnet when DNS fails, i.e a fallback system when a name cannot be found by contacting the DNS server.

NBT-NS (NetBIOS Name Service) the precursor protocol to LLMNR and operates similarly to ARP (Address Resolution Protocol) broadcasts.

LLMNR is enabled by default in Windows Vista and later Windows OS releases (which includes Server editions), with NBT-NS available on all Windows OS releases.

Although it can be argued the two protocols have their uses in the network, they suffer inherently vulnerabilities which can be attacked. The outcome of attacking these protocols are the result in the disclosure of Domain User names and credentials, either as hashed format (challenge/response such as NTLMv1 & NTLMv2) or worse, in clear text.

NTLMv1 & NTLMv2 hashes can be cracked reasonably quickly using brute-force and/or dictionary-based password attacks, if weak passwords have been set by the users.

Therefore its a no brainer and recommended LLMNR and NBT-NS protocols are disabled where there is no business case for their use.

Seeing it in action

A common tool used to exploit this vulnerability is called Responder (built into Kali Linux).

You can poison network traffic and responses using the below;

./Responder -I eth0 -r -d -w

In response to this, you would will see responses such as below, these password hashes can be used in a pass-the-hash attack, simply using this hash to authenticate to other systems. Or running the hash through a password cracking tool to uncover the victims password.

You can find a brilliant write-up of the tool in action here.

Resolution

  • Disable via GPO
  1. Open up gpedit.msc on your domain controller (or jump box which can edit GPOs used on the domain)
  2. Navigate to Local Computer Policy -> Computer Configuration -> Administrative Templates -> Network -> DNS Client
  3. In the DNS Client Folder, double-click on “Turn Off Multicast Name Resolution” and set it to “Enabled

The following registry key is set on computers when LLMNR is disabled:

HKLM\Software\Policies\Microsoft\Windows NT\DNSClient
"EnableMulticast" DWORD 0

  • To disable NetBIOS Name Service on a single machine:
  1. Open Control Panel
  2. Under “Network and Internet”, click “View network status and tasks”
  3. Click “Change adapter settings”
  4. Right-click “Local area connection” and then click “Properties”
  5. Double-click on “Internet Protocol Version 4 (TCP/IPv4)”, click “Advanced” then click on the “WINS” (Windows Internet Name Service) tab
  6. Click on “Disable NetBIOS over TCP/IP”

  • To disable NetBIOS Name Service across a domain with DHCP clients:
  1. Go to the DHCP Snap-In
  2. Go to “scope options” for the network you are changing
  3. Right click and Configure Options
  4. Select Advanced tab and change “Vendor class” to “Microsoft Windows 2000 Options”.
  5. In the “Available Options” frame, select and check the box “001 Microsoft Disable Netbios Option”
  6. In the “Data Entry” dialog box, change the data entry to 0x2
  7. Click “OK”.  The new settings will take effect when the clients renew their addresses.

SMB Signing

SMB (Service Message Block) is a protocol used for accessing shared resources, in most environments, a Windows OS device accessing file shares and printers.

SMB has the digital signing feature, which is designed to allow a recipient to confirm the authenticity of SMB packets, providing a way to prevent tampering during packets transiting the network. By default, only DCs (Domain Controllers) require packets to be signed.

SMB Relaying attacks this exploit/weakness, by modifying and relaying packets between a client and server in order to establish an authenticated connection.

Again, the earlier article shows this in action.

Resolution

You can force signing by creating a GPO applied to all devices.

Set the following GPO settings to enabled.

  • Microsoft network server: Digitally sign communications (if client agrees)
  • Microsoft network server: Digitally sign communication (always)
  • Microsoft network client: Digitally sign communication (always)
NTLMv1 in use for network authentication

NT LAN Manager (NTLM) is Microsoft’s original authentication protocol, which was replaced with Kerberos starting Windows 2000.

Implementation was for the authentication of Active Directory (AD) accounts between Microsoft workstations and servers. Even though it has not been the default for Windows deployments for a long time, it is still very much found active in a lost of customer networks, helped by the fact it is also still supported by the current versions of AD.

Resolution

It is recommended that anyone looking at these settings, first audit their connectivity and before increasing the security levels. During the audit if any devices are using the lower authentication methods, remediate them where possible, once happy increase the authentication level by one, and re-audit. The steps would follow the below;

  • Sent NTLMv2 response only. Refuse LM

And then after a further period of auditing to ensure remediation any devices using NTLMv1, finally change the security setting to;

  • Send NTLMv2 response only. Refuse LM & NTLM

To audit the devices;

  1. Collect Audit Logs from all Domain Controllers in a central log collection.
  2. Filter for Event Logs with the Event ID 4624 – An Account was successfully logged on.
  3. In this event you will find the section “Detailed Authentication Information
    1. If the “Authentication Package” was NTLM, NTLM was used as authentication method
    2. Now have a look at “Package Name (NTLM only)“, if LM or NTLM v1 is the value of this attribute, LAN Manager or NTLMv1 was used
  4. Investigate all clients/servers where LAN Manager or NTLMv1 was used.

Source: https://blogs.technet.microsoft.com/miriamxyra/2017/11/07/stop-using-lan-manager-and-ntlmv1/

Domain Users have Local Admin permissions to their machines

I think this common security failure for most companies is self explanatory. It’s always best practice to have separation of roles between accounts.

Users access to their local devices should be restricted, and where elevated privileges are needed, these requirements should be evaluated. Then is if needed an exception provided, and another separate account with a secure password provided.

Poor password policy

Another self explanatory item.

The current NIST guidance recommends the following for passwords:

  • An eight character minimum and 64 character maximum length
  • The ability to use all special characters but no special requirement to use them
  • Restrict sequential and repetitive characters (e.g. 12345 or aaaaaa)
  • Restrict context specific passwords (e.g. the name of the site, etc.)
  • Restrict commonly used passwords (e.g. [email protected], etc.)
  • Restrict passwords obtained from previous breach corpuses

In regards to the last point, you can see this blog post which has a way of using the “Have I been pwned” hash lists, to ensure users do not set a password which has already been exploited. I have personally not tried out this setup, and recommend it is tested in a lab environment first.

The issue with password complexity, is usually passwords end up being easy for hackers to guess/crack etc, but hard for actual end-users to remember.

So part of the overall NIST guidance (blog post covering this information) is using memorable phrases or collections of words, that mean something to the end-user but nothing to someone else. For example, “Golb3rg!Ghost5£Treasure”

No split accounts for Domain Admins

Yet another self explanatory item. How many of us have worked somewhere were our normal AD accounts have had elevated permissions on the domain.

This is a big no! I don’t think I have to list the reasons why.

Any admin users should have a separate administrator account, with the correct privileges applied, be subject to a strict password policy and change of password policy.

The use of password vaults, such as those provided by CyberArk, should be used where possible to provide an additional layer of security and auditing.

Poor patching on systems

This is the biggest downfall of most systems, poor patching, leaving systems full of vulnerabilities to be exploited. Most hacking stories which involve major companies, when the details are released, are due to unpatched vulnerabilities in systems. Usually ones which have been patched over 12 months before the exploit took place.

Most penetration testers will fallback to Nessus to scan a system for exploits, and its definitely what I’d advise you to do.

It will pick up some false positives, and some systems where you can just do nothing about the version of software running on that system, however that’s when an alternative security guard rail is needed (move the system to a secure ACL controlled VLAN for example).

You can apply for a licence for Nessus Home edition here, which will allow you to scan 16 IP addresses. A great way to get to grips with the tool.

In terms of “how the hell do I patch everything in time”, that’s a long answer which can be complex. The true answer is, its depends, most companies try to operate to a 30 day patch cycle for all systems. You can automate this in many different ways, or use a 3rd party tool to automate this for you.

Finally, think about your baseline templates for deploying systems, have something in place to keep those up to date as well. Whether is a virtual machine template for server deployments, or your WIM capture used for deploying new desktops over PXE boot.

Regards

Dean

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.