my personal blog about systemcenter

All posts tagged Security

Delegations Matter , Hunting mistakes with Bloodhound

Categories: Bloodhound
Comments Off on Delegations Matter , Hunting mistakes with Bloodhound

In this example i will use Bloodhound to show alternative path to Domain Admins

In the environment almost All Domain Admins have been removed , leaving DA-Alice as the sole enabled Domain Admin account

This makes a nice clean domains , does not give Alice much time off though so that will need to be fixes , but beats having 20+ Domain Admins running around , and Alice uses her Tier 0 Admin Workstation , so the users only logs on to the right security tiers

But we all know Alice and Bob is working together , Bob is helping out with password reset and a previous admin delegated rights to the Password-Reset Group

This is where the trouble start , Support-BOB is a member of Password-Reset , that group have been delegated full control over the Company OU to be able to reset passwords

First Mistake was to delegate full access and not only the password reset needed , but the 2nd and worse mistake was that someone placed the admin users under “Company” because it was the easy options , following bloodHound Shortest Path to Domain Admin

Gives us Support-BOB who have write permissions on all users in Admins that DA-Alice is a part off , this mean that no matter if Alice keeps doing everything right , Support-BOB can now reset DA-Alice password and start creating chaos.

In this case a Quick fix is to move the Admins outside of the Delegations so that Support-BOB rights that was on the “Company” OU does not apply anymore

This ends up giving us a single path to domain admin being DA-Alice

https://bloodhound.readthedocs.io/en/latest/data-analysis/bloodhound-gui.html

Check out BloodHound , ensure you have permission to run it as it will most likely will set off a alarm bell or two

Finding clients using insecure LDAP binds

Categories: Uncategorized
Comments Off on Finding clients using insecure LDAP binds

Microsoft announced in August 2019 that they will enforce the use of Secure LDAP binds from Marts 2020 Update

https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows

This means that applications that uses “classic” LDAP over 389 will fail after applying updates in the Marts 2020 Cycle


Take Action: Microsoft Security Advisory 
ADV190023 published to introduce LDAP channel binding and LDAP signing support. Administrators will need to test these settings in their environment after manually adjusting them on their servers.

First Call to Action was August 2019 , so if you missed this (like me) this is very late getting started to prevent possible outages pending Marts Update Cycle

Required: Security Update available on Windows Update for all supported Windows platforms that will enable LDAP channel binding and LDAP signing on Active Directory servers by default.

Second Call to Action is now , get searching in the logs

Event 2886,2889,2887,1220 from Directory Services are the ones to ensure are logged and searhable

Domain Controllers will pr default log a 2886 Every 24 hours with how many clients connected , this will see if there is a usage but not who/what

For detailed logging On your Domain Controllers enable LDAP Interface Events Logging to Level 2


Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

and to Disable Logging again

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v “16 LDAP Interface Events” /t REG_DWORD /d 0
With Logging set to level 2 , you will now see clients connection with insecure bind , source ip and username that authenticated with Event ID 2889

The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection. 

If you see 1220 a client tried to use LDAP/s but the domain controller didn’t have a certificate available

LDAP over Secure Sockets Layer (SSL) will be unavailable at this time because the server was unable to obtain a certificate. 

Dump AD user password hashes on-the-fly to a file of chosen format

Categories: Active Directory, AD
Comments Off on Dump AD user password hashes on-the-fly to a file of chosen format

So, you achieved Domain Admin permissions during a security assessment (penetration test) and you want to crack all of those nice password hashes from Active Directory, or you might have to perform a password audit, but you just hate exporting NTDS.DIT + SYSTEM and extracting the database afterwards…?

Instead you can now do live, in-memory on-the-fly Mimikatz-DCSync-style, synchronization of all those user password NT-hashes in PowerShell and write them to a pwddump format of your own choice, all ready for having lots of cracking fun!

Check out: https://github.com/ZilentJack/Get-ADHashDump

A few things to consider.

  1. Michael Grafnetter, who developed the DSInternals module, hasn’t released the source code yet. Therefore, you will have to trust his code (blindly) at the moment. However, Michael has told me that he will release the code later this year when he has had time to clean it up a bit. Thanks to Michael for his hard work and help.
  2. Be sure to have permissions to extract (and crack?) hashes from Active Directory 🙂

BTW. Have you seen this related tool and post: Crack and detect weak passwords in Active Directory on-the-fly

/Jakob H. Heidelberg
@JakobHeidelberg

Crack and detect weak passwords in Active Directory on-the-fly

Categories: Active Directory
Comments Off on Crack and detect weak passwords in Active Directory on-the-fly

A serious problem with Active Directory (AD) and built-in password policies is, that although password complexity is required, attackers (including penetration testers) can easily find weak user passwords during an engagement, that IT administrators or security officers do not have the means to discover “out -of-the-box”. There’s no visibility into how strong or weak user passwords really are.

Simple and very common passwords, such as “Summer2015”, “October2015”, “Password123”, “[company name] + [year]”,”[Well-known-shared-password-in-the-company]”, etc., all meet the regular requirements for password length and complexity, but in practice they are extremely weak passwords and probably among the first guesses an attacker will try out.

Brute-force and NTDS.DIT attacks

A so-called “brute-force” attack can be performed in two different ways. The most well-known method is the attack of one given user account, where the attacker tries out a whole lot different password combinations. In most environments this will lead to the user account being locked after a few guesses and the attack ends.

A better version of the “brute-force” attack is to try out one weak and widely used password, for example “Summer2015” against all user accounts in the environment (also called “password spraying”). This method will most often lead to a successful login without any account being locked – especially in environments where users are not properly trained in generating strong passwords.

Previously, obtaining insight into the password usage and strength in an AD environment, has been done by extracting data from the NTDS.DIT file of a Domain Controller, which is a rather tedious and manual process.

With a new PowerShell module, DSInternals, it is now possible to analyze passwords “on-the-fly”, in a live environment, assuming that you have (acquired) the proper rights (equivalent of ‘Domain Admin’ or ‘Domain Controller’). If you’ve ever looked at the DCSync tool, recently built into Mimikatz, this PS module offers the same functionality.

Get-bADpasswords to the rescue

I have developed a simple PowerShell script, Get-bADpasswords, which utilizes some of the functionality in the new PS module. My intention is to enable IT administrators and security officers to discover weak (or bad) user passwords active in AD – hopefully before attackers do it.

The drawing below illustrates the concept of the script.

Concept of Get-bADpasswords

A Domain Controller contacted and asked to hand over user names and password hash values ​​(NT hash) of all active users (under a given naming context).

The script retrieves, from one or more text files (word lists), poor or unacceptable (non-compliant) passwords in the environment and then hashes (NT hash) so that they can be compared with the output from the AD.

Here is an example of the contents of such a word list that should be adjusted each organization, language and so on.

Wordlist

Word list with weak passwords

The script is executed with “-Verbose” prints the current status to the console.

Get-bADpasswords -Verbose

The script can write user names for users who have weak passwords to a CSV file.

Get-bADpasswords CSV output

The script can write a log of current status, including detailed (verbose) information.

Get-bADpasswords log file

Note mentioned that my script assumes that DSInternals module is properly installed on the executing machine.

DSInternals module folder

A few things to consider.

  1. Michael Grafnetter, who developed the DSInternals module, hasn’t released the source code yet. Therefore, you will have to trust his code (blindly) at the moment. However, Michael has told me that he will release the code later this year when he has had time to clean it up a bit. Thanks to Michael for his hard work and help.
  2. It is probably a good idea to get an approval of HR and/or the legal department when running this regularly. There might be objections to administrators or security officers potentially gaining insight into user passwords (although we will only detect the weak ones).
  3. This script works “after the fact”, after users have actually created a weak password for their AD account. In Windows you can create custom Password Filters, which could prevent users from setting weak passwords in the first place, but that is quite another matter.

My PowerShell script can be downloaded here: Get-bADpasswords.

In the hope of more password-guessing-robust Active Directory environments out there!

/Jakob H. Heidelberg
@JakobHeidelberg