How to extract hashes from IFM backup

Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed.
Methods exist to extract hashes directly for a live domain however this article describes a process to extract user data, including hashes from an IFM backup.

1) Overview

Overpermission and weak/reused passwords are probably the most common security issues found in Active Directory. To address the password issues, it is important to do regular password audits, to address over permissions, see my article about Active Directory delegation.

 

2) Password Hashes

Passwords are stored in Active Directory (NTDS.dit encrypted with a boot key) as an unsalted MD4 hash and as such, to check for password reuse it is a simple case of checking for duplicate hashes in the extracted hashes list.

 

Finding weak passwords are a little trickier. You need to lookup hashes against a rainbow table to ensure you do not have any weak/compromised hashes within your environment.

 

Both of these are out-of-scope for this article, this article focuses on extracting password hashes.

 

3) Extracting Password Hashes

a) On a Domain Controller

 

Start an elevated command prompt and run:

 

ntdsutil
activate instance ntds
ifm
create sysvol full C:\Temp\Backups\IFM\

 

Command Output

IFM Files

 

b) On Administrative Computer

 

Copy the IFM folder and run the following PowerShell script elevated (just copy and paste):

 

//Download DSInternals from PowerShell Gallery https://www.powershellgallery.com/packages/DSInternals
Save-Module -Name DSInternals -path 'C:\temp\DSInternals'


//Install DSInternals
Install-Module -Name DSInternals


//Import DSInternals Module
Import-Module DSInternals


//Get Boot Key from Registry section of the IFM. If Boot Key is blank, Get-ADDBAccount will still return usernames
$key = Get-BootKey -SystemHivePath 'C:\Temp\Backups\IFM\registry\SYSTEM'


//Store objects data
$hashes = Get-ADDBAccount -All -DBPath 'C:\Temp\Backups\IFM\Active Directory\ntds.dit' -BootKey $key


//Convert object data to the desired format
$hashes | Format-Custom -View Ophcrack | Out-File C:\Temp\Backups\Hashes.txt

 

Hashes.txt File

 

 

Weak Passwords Found (Getting password from hashes out-of-scope for this article)

 

 

Securing Active Directory Administrators Groups

A hard and fast method for reducing Active Directory Administrators members.

Introduction

Anyone that has gone through any security hardening process can confirm that simply saying something was done incorrectly does not mean that you can just apply suggested remediation steps, especially in a mature environment.

 

Take recommendation Appendix E, F and G from the AD DS Operations Best Practices for Securing Active Directory for example, even though I agree with all of the points, just removing user accounts from the Administrators groups (Enterprise Admins, Domain Admins or Administrators) without addressing the application requirement could have a significant impact on
daily operations.

 

Based on my experience, the biggest reason why user and service accounts were added to Domain Admins and the like was that default delegation model in Active Directory lacks an appropriate group that just gives server/workstation administrative rights.

 

This article describes the process of creating these delegation groups so that members of Domain Admins etc. can be removed without any impact, drastically increasing Active Directory overall security. It must be stressed that this is an intermediate
process, the lesser of two evils if you will and that these other issues will be addressed in future articles.

 

Creating Global Administrators Delegation

1) WMI Filters

Create WMI filter that will identify the three device types. In the article two of these, All Servers except Domain Controllers and All Workstations will be used. This allows
delegation policy to apply to the correct device type dynamically.

 

a) Create an All Workstations WMI filter according to company naming convention

Select * from WIN32_OperatingSystem where ProductType=1

 

 

b) Create an All Domain Controllers WMI filter according to company naming convention

Select * from WIN32_OperatingSystem where ProductType=2

 

 

c) Create an All Servers except Domain Controllers WMI filter according to company naming convention

Select * from WIN32_OperatingSystem where ProductType=3

 

 

2) Groups

Create a group for each device type and a group that will have rights to all device types. These will contain the administrators for each device type.

 

a) Create Global Server Administrators group, Global Workstations Administrators group and Global Administrators group according to company naming convention.

 

 

b) Add Global Administrators group as a member of both Global Server Administrators group and Global Workstations Administrators group.

 

 

3) Group Policies

Create a group policy for each device type. It should filter based on the device types and will contain the delegation settings.

 

3.1) Global Server Administrators Group Policy

 

a) Create new GPO and name it according to company naming convention. It will contain the configuration of the Global Server Administrators group.

 

 

b) Ensure group policy is linked from domain root and that it is enforced. Link the All Servers except Domain Controllers WMI filter to group policy.

 

 

c) Add Administrators group to Restricted Groups and add Global Server Administrators group as a member. This is mainly done for legacy devices.

 

 

d) Add Administrators (built-in) group to Local Users and Groups preference update item and add Global Server Administrators group as a member.

 

3.2) Global Workstations Administrators Group Policy

 

a) Create new GPO and name it according to company naming convention. It will contain the configuration of the Global Workstation Administrators group.

 

 

b) Ensure group policy is linked from domain root and that it is enforced. Link the All Workstations WMI filter to group policy.

 

 

c) Add Administrators group to Restricted Groups and add Global Workstation Administrators group as a member. This is mainly done for legacy devices.

 

 

d) Add Administrators (built-in) group to Local Users and Groups preference update item and add Global Workstation Administrators group as a member.

 

4) Remove User/Service Accounts

At this point, everything is ready to start removing accounts from Administrators groups by following the following logic:

 

Account Requirement Action
Account requires AD rights Remove from Administrators groups (Enterprise Admins, Domain Admins or Administrators) and temporarily into Account Operators group until correct rights can be determined
Account requires Administrators rights to all devices Remove from Administrators groups (Enterprise Admins, Domain Admins or Administrators) and add to Global Administrators group
Account requires Administrators rights to servers Remove from Administrators groups (Enterprise Admins, Domain Admins or Administrators) and add to Global Server Administrators group
Account requires Administrators rights to workstations Remove from Administrators groups (Enterprise Admins, Domain Admins or Administrators) and add to Global Workstation Administrators group

 

Please note: It is best to add these user/service accounts to role groups as explained in this article:

https://www.experts-exchange.com/articles/29366/Delegation-the-proper-way.html

 

Conclusion

Adding user accounts to Administrators groups (Enterprise Admins, Domain Admins or Administrators) puts the environment at a significant risk because these user accounts can dump all the Active Directory hashes, bypassing all security and auditing mechanisms.
The above process can be used to drastically reduce the number of Admin members.

 

The hash extraction process is explained d in this article:

 https://www.experts-exchange.com/articles/29569/How-to-extract-hashes-from-IFM-backup.html

 

 

 

 

How to restore Active Directory Group Policy with only SYSVOL data

Always backup Domain, SYSVOL etc.using processes according to Microsoft Best Practices. This is meant as a disaster recovery process for small environments that did not implement backup processes and did not run a secondary domain controller that need to recover Group Policies from files

1) Create new, blank Group Policy

Using GPMC.msc create a new, blank GPO with the same name as the original.

 

 

2) Overwrite Group Policy Data

a) Record the Unique ID that was assigned to GPO created in Step 1

 

 

b) Copy Machine, User and GPT data from original GPO

 

 

c) Paste data (overwrite) into the folder assigned to GPO created in Step 1. The folder is named the same as the Unique ID recorded in Step 2a

 

 

3) Fixing Group Policy Settings Preview

Note that after completing Step 1 and Step 2, even though the GPO settings are available within Edit, the Settings Preview shows No settings defined

 

 

a) Edit GPO, browse to any unconfigured setting and open it. Tick and untick Define this policy setting and click OK

 

 

b) If your GPO contains any Preferences browse to any one of them and simply open it and click OK

 

 

Settings Preview should show settings

 

4) Fixing Group Policy Permission

Unfortunately following this process does not restore the original permissions, this has to be added back manually.