The CredDefense Toolkit
Derek Banks, Beau Bullock, & Brian Fehrman //
Our clients often ask how they could have detected and prevented the post-exploitation activities we used in their environment to gain elevated privileges and ultimately access sensitive data. Most of the time, this is achieved through credential abuse.
As pentesters, the primary condition we take advantage of in credential abuse is poor passwords. In any given environment with more than a few hundred end-users, it is almost guaranteed that someone has chosen the season and year (e.g. Summer2017) as their password. This makes it pretty easy to guess using a technique known as password spraying.
One way to fix this is to change the minimum password length for accounts, but for reasons both technical and political, this is not always possible for every environment to do this.
There are also a number of additional credential abuse attacks that take advantage of flaws in protocol implementation or default environment configuration such as with Kerberoasting and LLMNR Poisoning.
Wouldn’t it be great if there was a free toolset to protect your credentials even when password length couldn’t be changed and to alert on other credential attacks being conducted in your network? That’s why we created The CredDefense Toolkit – to have a free way to detect and prevent credential abuse attacks.
Password Filter
Windows domains enforce a standard set of complexity requirements on user passwords. When a user attempts to set a new password, the new password is checked against the requirements. By default, the following requirements are in place:
- Eight-characters minimum
- Must contain three out of the four following
- Uppercase Letter
- Lowercase Letter
- Special Character
- Number
Additionally, users are required to set a new password every 90 days. So… what meets these requirements but is still easy for users to pick and remember? Let’s just say that most pentesters are very aware of the current season and the current year. Fall2017, for instance.
How can you prevent users from picking these types of passwords? Sure, you can increase the minimum number of characters and enforce additional complexity. We certainly have much less success password spraying in environments that require 15 characters or more. We do, however, still run into users picking things like SummerSummmer2017. Additionally, we understand the political backlash that can be associated with requiring that many characters. There has to be another way…and there is! Enter: Windows Password Filtering.
The Windows Password Filter feature allows you to add additional checks when a user attempts to pick a new password. The password first goes through the domain’s password complexity check. After passing the complexity check, it then gets passed through your custom check. You can have multiple checks if you’d like. The image below shows the process.
How is this implemented? The entire procedure is described here: https://msdn.microsoft.com/en-us/library/windows/desktop/ms721766(v=vs.85).aspx
This can seem a bit tedious and overwhelming to do manually…which is why we have incorporated it into the Cred Defense interface! Our work is based on this open-source project:
https://github.com/jephthai/OpenPasswordFilter
If you open the Cred Defense tool, select the Password Filter option. You will then be asked if you’d like to Install / Uninstall the feature or just update the password list that is used.
For Installing / Uninstall, you will be presented with two columns. The program will grab down a list of all domain controllers in your environment. It will then check each domain controller (DC) to see if it has the EasyPasswordFilter value in the HKLM\System\CurrentControlSet\Control\Lsa\Notifications registry key. If the key is not present, it indicates that the DC is likely not running the password filter and the names of those DCs will be placed in the Unconfigured DCs column. Selecting a DC name from the Unconfigured DCs list and clicking Install will:
- Deploy the EasyPasswordFilter DLL to the %SystemRoot%\Windows\System32 directory on the target DC
- Deploy the password list to %SystemRoot%\epf folder on the target DC
- Add the EasyPasswordFilter value to the HKLM\System\CurrentControlSet\Control\Lsa\Notifications registry key on the target DC
- Ask you if you’d like to reboot the DC and then instruct the DC to restart if you choose to do so
For uninstalling, the program simply removes the EasyPasswordFilter value from the registry on the target DC and asks if you’d like to reboot the machine.
Pretty simple, huh? A few clicks and you’re off and running!
How about updating the password list? If you choose this option, you will be shown a list of all of the DCs on which the password filter has been installed. Click the Edit Passwords button and the list of passwords will be opened in Notepad.exe for you to edit. Note that the password filter is set-up to be case-insensitive. Additionally, it will perform substring matching so that you don’t have to type Winter2017, Winter2018, WinterWinter2017, etc., and can instead just type winter. There is also a safety-check in place that does not allow you to specify words that are less than four characters. Once you’re done editing the password list, save the list and click the Deploy Updates button. The password list will then be deployed to all of the DCs that are shown in the DC’s Running Password Filter list. This does not require you to restart the domain controllers.
Password Auditing
Password filtering can be quite effective for preventing users from picking weak passwords. What about current passwords in the environment? How about Domain Admins reusing the same password for their normal user account? Do you have passwords that don’t expire? How about user accounts that don’t require a password? Is the same password used for multiple administrative accounts? All of these are very important questions that should be answered before threat actors find those answers.
The Password Auditing feature of the Cred Defense toolkit can make this process painless! The work is based on the DSInternals toolkit: https://github.com/MichaelGrafnetter/DSInternals
First, select the Password Auditing option from the main menu. You will then be presented with a list of Domains within the current forest.
After selecting the domain, you will be presented with a list of Domain Controllers within that domain.
After selecting a Domain Controller, you will be asked to select a password list to use for the password-cracking portion of the audit. You will also be asked to specify where you’d like the results to be saved.
After selecting the options, click the Run Audit button and the process will be kicked off. The program will leverage the AD Replication Sync feature to grab Active Directory information from the targeted DC. The information is kept in memory and is not written to disk. The program will perform multiple checks and output the results to the file specified. Some of the checks include:
- Password Reuse
- LanMan Hashes
- Admin Delegation
- No Password
- Password not Required
- Password doesn’t Expire
So how long does this take? We ran this from a VM that was allocated 8 GB of RAM and 2 Cores. It utilized the Human-Readable Crackstation password list. The environment contained 3 Domain Controllers and over 30,000 unique user hashes. The entire process completed in roughly 90 seconds!
Event Log Consolidation
There are generally two categories of environments that we encounter on our engagements when it comes to logging. The first is nothing is being logged and there is really no visibility into any information available that would help in detecting that malicious activity was occurring. The second is that every log event is going into a SEIM and no one can effectively use it to discover or alert on anything useful.
If you are in either scenario, setting up a more targeted approach to consolidating events from Windows Endpoints. As part of the CredDefense toolkit, we wrote this guide to setting up forwarding event logs to a central Windows Event Forwarding server.
Kerberoasting
One of the first attacks we try when gaining a foothold in an environment is known as Kerberoasting. The Microsoft implementation of Kerberos is complicated, but the gist of the attack is that it takes advantage of legacy Active Directory support for older Windows clients and the type of encryption used and the key material used to encrypt and sign Kerberos tickets. Essentially, when a domain account is configured to run a service in the environment, such as MS SQL, a Service Principal Name (SPN) is used in the domain to associate the service with a login account. When a user wishes to use the specific resource they receive a Kerberos ticket signed with NTLM hash of the account that is running the service. This effectively allows any domain user to obtain a crackable hash for a service account on the network – and often times a service account will have at least administrator on the local server where it runs.
The request for the Kerberos ticket generates Event 4769 on a domain controller in the environment. With Windows Event Forwarder configured to consolidate event logs, the Kerberos ticket requests are in one place to analyze.
An approach to detection is to create a HoneyAccount that will have a registered Service Principal Name and will not typically be requested by an end-user. The Set-ADUser commandlet can be used for this, just take care not to duplicate a valid SPN in your environment.
Set-ADUser honeytoken -ServicePrincipalNames @{Add=”MSSQLSvc/server161:1433″}
Once the HoneyAccount has been created, the CredDefenseEventParser PowerShell script can be used to parse the forwarded log to detect Event ID 4769 when the service account matches the HoneyToken value. This would indicate that it is likely someone is Kerberoasting in the environment.
ResponderGuard
One of the common attacks we as pentesters perform is to attempt NBNS or LLMNR spoofing attacks on a network in hopes of gaining hashed credentials of users. One popular tool for performing this attack is called “Responder” written by Laurent Gaffie. Another great tool for performing this attack is “Inveigh” by Kevin Robertson. These tools can do a lot of awesome things but one of the primary functionalities is to function effectively as an NBNS or LLMNR spoofer.
It is common for us to be successful at obtaining hashed user credentials by using these tools. So how does a defender go about detecting Responder-like activity on a large network? There are a few tools that do detection of Responder on a LAN already out there. But, from what I can tell most are only able to check a single subnet due to how they are broadcasting an NBNS packet used. Another option would be to send honey tokens to every system over SMB on the network but this method would require an attacker to actively crack an NTLMv2 hash and attempt to login prior to receiving an alert that Responder is on the network.
ResponderGuard is a PowerShell tool that should allow for the detection of Responder-like activity on a larger scale across networks. It has the ability to locate Responder listeners on foreign subnets by sending targeted NBNS requests to every host in a list of CIDR ranges. With each NBNS request, a random hostname is requested for each IP address. If a host responds that it is the correct host then it is likely that host is an NBNS spoofer.
To assist with alerting for this activity ResponderGuard writes a Windows event log immediately upon detecting a Responder-like listener on the network. This can be utilized in association with CredDefense or any SIEM of your choice to alert you whenever a Responder-like system is discovered. Just look for event ID 8415.
In addition to alerting for Responder activity immediately, ResponderGuard also has the ability to serve up honey credentials to the Responder listener. This provides an additional detection mechanism if the attacker attempts to log in to a designated account. In the screenshot below a defender has launched ResponderGuard and it is currently scanning the provided CIDR ranges. It detected an NBNS response from the IP address at 192.168.0.18 for a random hostname. An event was written to the event log and then a set of honey credentials (HoneyDomain\HoneyUser : Summer2017) were submitted over SMB to the listener.
The screenshot below shows what the attacker would see in their Responder output. First, Responder reports that a poisoned answer was sent to 192.168.0.12 (Our Windows server running ResponderGuard, which is actually on a completely different subnet being NAT’d). Next, Responder received an SMB authentication request along with NTLMv2 hashed user credentials of our honey user. How you set up these honey tokens could be done in a number of ways. Some options will be discussed later on in this post.
To run ResponderGuard as a standalone script first download it from here. Then, start a new PowerShell process as an Administrator.
C:> powershell.exe -exec bypass
Next, import the ResponderGuard PowerShell script.
PS C:> Import-Module ResponderGuard.ps1
ResponderGuard can be run with or without generating event logs. To write to the Windows Event log each time Responder is detected add the -LoggingEnabled flag to Invoke-ResponderGuard. A list of CIDR ranges can be passed to Invoke-ReponderGuard with the -CidrList option. If you would like to additionally submit a HoneyToken to Responder add the -HoneyTokenSeed option. Make sure you manually change the honey token credentials in the script otherwise HoneyDomain\HoneyToken will be submitted to Responder.
PS C:> Invoke-ResponderGuard -CidrList C:\temp\cidr-list.txt -LoggingEnabled -HoneyTokenSeed
This tool is very much still in development and more features are being worked on. If you want to help out check out the open issues on the CredDefense repo.
Password Spraying
Password spraying is an attack we use on almost every pentest due to how effective it can be in gathering credentials. We’ve written about it a number of times. Password spraying is an attack where basically the attacker generates a large list of usernames and submits one authentication attempt for each of them to avoid account lockout. The password chosen is typically something commonly found to be used by users like ‘SeasonYear’ (for example: ‘Fall2017’) or ‘Companyname123’.
Password spraying can be performed against pretty much any authentication mechanism but we commonly target Active Directory related services. It can be performed both internally and externally to most networks due to externally exposed web portals tied to Active Directory. Some examples we commonly password spray externally are Outlook Web Access (OWA), ADFS, Exchange Web Services (EWS), Office 365, or even VPN portals.
Internally, a PowerShell tool we at Black Hills InfoSec wrote called DomainPasswordSpray works well for password spraying. It generates a list of user accounts from the domain and attempts to remove anyone close to lockout already. Additionally, it enumerates Fine-Grained Password policies in order to avoid lockouts for accounts under different password policy restrictions.
Regardless of how password spraying is performed, it will generate a large number of failed login events. Many SIEM’s and products alert for brute-forcing of account credentials on a network but most are just looking at a single user account’s failed login attempts and missing password spraying due to the fact that it is one attempt for each account. In order to help alert for password spraying CredDefense parses event logs looking for any individual IP address that generates more than ten failed login attempts in an hour.
The CredDefenseEventParser.ps1 script included in the repo can be run standalone or from CredDefense. In addition to running in a loop looking at a given Windows Event log fil, it can be directed at a specific event file (evtx) to perform analysis to “hunt” for password spraying events. When run in a loop it will continually evaluate a given log file for events. This could be your forwarded events log file where you are collecting the forwarded Windows Event logs from each system in your environment.
Conclusion
The CredDefense Toolkit is meant to be a collection of tools and techniques that can be used to prevent and/or detect many of the common attacks both pentesters and truly malicious individuals have success with. The three of us working on this are red teamers at heart. With CredDefense we are trying to make our lives harder by making it easier for organizations to detect the common attacks we have success with. Oh… and it is 100% free and open source!
Some things we’ve already included in CredDefense and discussed in this post are the following:
- Domain Password Filter (to hopefully prevent users from creating bad passwords in the first place)
- Password doesn’t Expire
- Kerberoast Detection
- Event Log Consolidation (Using built-in Windows Event tools)
- NBNS Spoofing Detection & Honey Token Submission Responder-like systems
- Password Spraying Detection
If you would like to hear more about CredDefense the video from our talk at DerbyCon 7.0 is available here: https://www.youtube.com/watch?v=4u5gCoCu88Q. We still have a number of other items we want to add in and are hopeful that we can get some community involvement in this project as well. ___ Like what you see? Check back soon for the webcast we’ll be posting soon!
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
