Category: Active Directory


Hacking techniques for AD: “state of the art” (but scary!) with possible mitigation (when possible) + a few new methods…

https://adsecurity.org/wp-content/uploads/2015/08/DEFCON23-2015-Metcalf-RedvsBlue-ADAttackAndDefense-Final.pdf

https://github.com/infosecn1nja/AD-Attack-Defense

https://specterops.io/resources/research-and-development

https://github.com/wavestone-cdt/AD-security-workshop

https://www.labofapenetrationtester.com/

https://github.com/fireeye/commando-vm

For GPO Audit : https://github.com/l0ss/Grouper2

Spraykatz:

https://www.slideshare.net/sylvaincortes/spraykatz-installation-basic-usage

https://github.com/aas-n/spraykatz

ReverseTCP shell:

https://www.youtube.com/watch?v=T9qb4DIAXTg&feature=youtu.be

https://github.com/ZHacker13/ReverseTCPShell

Securing AD:

https://digital-forensics.sans.org/blog/2013/06/20/overview-of-microsofts-best-practices-for-securing-active-directory

http://video.ch9.ms/sessions/teched/na/2014/DCIM-B213.pptx

https://www.pingcastle.com/

AD Authentication silos and more: https://www.sstic.org/user/abordes

MS white-paper best practices to secure AD: http://aka.ms/bpsadtrd

Authentication mechanism assurance: https://technet.microsoft.com/en-us/library/dd378897.aspx

 

Reference article:

https://docs.microsoft.com/en-us/azure/security/fundamentals/steps-secure-identity

Doc to disable the user consent:

https://docs.microsoft.com/en-us/azure/security/fundamentals/steps-secure-identity#restrict-user-consent-operations

Best practices:

There are many aspects to a secure Identity infrastructure, but this five-step checklist will help you quickly accomplish a safer and secure identity infrastructure:

  • Strengthen your credentials.
  • Reduce your attack surface area.
  • Automate threat response.
  • Increase your awareness of auditing and monitoring.
  • Enable more predictable and complete end-user security with self-help.

Details action plan:

  • Make sure your organization uses strong authentication
  • Start banning commonly attacked passwords and turn off traditional complexity, and expiration rules
  • Protect against leaked credentials and add resilience against outages
  • Implement AD FS extranet smart lockout
  • Block legacy authentication
  • Block invalid authentication entry points
  • Implement Azure AD Privileged Identity Management (PIM)
  • Implement user risk security policy using Azure AD Identity Protection
  • Implement sign-in risk policy using Azure AD Identity Protection
  • Monitor Azure AD
  • Monitor Azure AD Connect Health in hybrid environments
  • Monitor Azure AD Identity Protection events
  • Audit apps and consented permissions
  • Implement self-service password reset
  • Implement self-service group and application access
  • Implement Azure AD access reviews

Reference:

To use Authenticated silos, you need a 2012 R2 Domain functional level on the forest.

Their are part of the configuration partition (so, at the forest level), replicated on all domain controllers

https://www.sstic.org/2017/presentation/administration_en_silo/

https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos.md

https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos#BKMK_HowKerbUsed

 

Videos:

How to:

before to configure ADFS smart lockout, remove your account from AD protected users group, else you can get access denied

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-smart-lockout-protection

Articles:

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-soft-lockout-protection

https://blog.dacimm.com/audit-adfs-extranet-lockout-protection-81620ec055df

https://community.spiceworks.com/topic/673038-continuous-account-lockouts-from-adfs

https://blogs.technet.microsoft.com/pie/2016/02/02/ad-fun-services-track-down-the-source-of-adfs-lockouts/

https://blogs.msdn.microsoft.com/luzhao1/2015/06/24/demystify-extranet-lockout-feature-in-ad-fs-3-0/

https://s4erka.wordpress.com/2018/11/02/ad-fs-2016-extranet-smart-lockout-eventids-1203-and-1210-clarification/

https://s4erka.wordpress.com/2018/11/09/powershell-script-to-collect-adfs-extranet-smart-lockout-events-sequence/

 

Primary Domain Controller Requirement

AD FS 2016 offers a parameter that allows fallback to another domain controller when the PDC is unavailable.

  • ExtranetLockoutRequirePDC <Boolean> When enabled, extranet lockout requires a primary domain controller (PDC). When disabled, extranet lockout will fallback to another domain controller in case the PDC is unavailable.The following example shows the cmdlet to enable lockout with the PDC requirement disabled:
    Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 8 -ExtranetObservationWindow (new-timespan -Minutes 30) -ExtranetLockoutRequirePDC $false

PS C:\WINDOWS\system32> get-adfsproperties | select *extra*

ExtranetLockoutThreshold  : 8
ExtranetLockoutMode       : ADPasswordCounter
ExtranetLockoutEnabled    : True
ExtranetObservationWindow : 00:30:00
ExtranetLockoutRequirePDC : True

PS C:\WINDOWS\system32> $cred = Get-Credential

cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential
PS C:\WINDOWS\system32> Update-AdfsArtifactDatabasePermission -Credential $cred
PS C:\WINDOWS\system32> Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly

Confirm
This command will set the extranet lockout mode to AdfsSmartLockout.  Verify all nodes have up to date patches and appropriate database permissions have been assigned by
running Update-AdfsArtifactDatabasePermission.  See https://go.microsoft.com/fwlink/?linkid=864556 for more information.
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is “Y”): Y
WARNING: PS0038: This action requires a restart of the AD FS Windows Service. If you have deployed a federation server farm, restart the service on every server in the farm.
PS C:\WINDOWS\system32> restart-service adfssrv
WARNING: Waiting for service ‘Active Directory Federation Services (adfssrv)’ to stop…
WARNING: Waiting for service ‘Active Directory Federation Services (adfssrv)’ to stop…
WARNING: Waiting for service ‘Active Directory Federation Services (adfssrv)’ to stop…
WARNING: Waiting for service ‘Active Directory Federation Services (adfssrv)’ to stop…
WARNING: Waiting for service ‘Active Directory Federation Services (adfssrv)’ to start…
WARNING: Waiting for service ‘Active Directory Federation Services (adfssrv)’ to start…

 

Observing Audit Events

AD FS will write extranet lockout events to the security audit log:

  • When a user is locked out (reaches the lockout threshold for unsuccessful login attempts)
  • When AD FS receives a login attempt for a user who is already in lockout state

While in log only mode, you can check the security audit log for lockout events. For any events found, you can check the user state using the Get-ADFSAccountActivity cmdlet to determine if the lockout occurred from familiar or unfamiliar IP addresses, and to double check the list of familiar IP addresses for that user.

 

Enable enforce mode

Once you have been running in log only mode for sufficient time for AD FS to learn login locations and to observe any lockout activity, and once you are comfortable with the lockout threshold and observation window, smart lockout can be moved to “enforce” mode using the PSH cmdlet below:

PS C:\>Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce

For the new mode to take effect, restart the AD FS service on all nodes in the farm

PS C:\>Restart-service adfssrv

How to choose between authn methods:

https://docs.microsoft.com/en-us/azure/security/fundamentals/choose-ad-authn#comparing-methods

 

 

 

This feature allows you to migrate from federated authentication to cloud authentication by using a staged approach:

Moving away from federated authentication has implications. For example, if you have any of the following:

  • an on-premises MFA server => you must be moved to Azure MFA first
  • are using smart cards for authentication
  • other federation only features

These features should be taken into consideration prior to switching to cloud authentication. Before trying this feature, we suggest you review our guide on choosing the right authentication method. See this table for more details.

  • You have an Azure AD tenant with federated domains.
  • You have decided to move to either Password Hash Sync + Seamless SSO (Option A), or Pass-through Authentication + Seamless SSO (Option B). Although seamless SSO is optional, we recommend enabling seamless SSO to achieve a silent sign-in experience for users using domain joined machines from inside corporate network.
  • You have configured all the appropriate tenant branding and Conditional Access policies you need for users who are being migrated over to cloud authentication.
  • If you plan to use Azure Multi-Factor Authentication, we recommend you use converged registration for Self-service Password Reset (SSPR) and Azure MFA to get your users to register their authentication methods once.
  • To use this feature, you need to be Global Administrator on your tenant.

To enable Seamless SSO on a specific AD forest, you need to be Domain Administrator.

Articles:

https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Staged-rollout-to-cloud-authentication-now-in-public-preview/ba-p/827830

 

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-staged-rollout

Note:

  1. Removing the user from the group disables staged rollout for the user.
  2. If you wish to disable staged rollout feature, please slide the feature back to ‘OFF’ state to turn off staged rollout.

 

 

Reference articles to secure a Windows domain:

https://github.com/PaulSec/awesome-windows-domain-hardening

Microsoft audit Policy settings and recommendations:

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations

Sysinternals sysmon:

https://onedrive.live.com/view.aspx?resid=D026B4699190F1E6!2843&ithint=file%2cpptx&app=PowerPoint&authkey=!AMvCRTKB_V1J5ow

On ADsecurity.org:

Beyond domain admins: https://adsecurity.org/?p=3700

Gathering AD data with PowerShell: https://adsecurity.org/?p=3719

Hardening Windows computers, secure Baseline check list: https://adsecurity.org/?p=3299

Hardening Windows domain, secure Baseline check list:

Securing Domain Controllers to Improve Active Directory Security

Domain hardening in general:

  • Implement 2 or 3 tier model against Pass the Hash threat
  • FGPP implementation
  • LAPS Implementation
  • Process for proper cleanup of unused AD accounts
  • Reset of krbtgt account,domain admins account,IT administrators account
  • Setting Up Jump servers for Tier0,1,2 users
  • Domain joining of all windows boxes
  • Proper account Management Based on privileges
  • Usage of service accounts to run application instead of local system accounts
  • Review of existing AD accounts/Deletion of Unnecessary Accounts/ Review Ou structuring/GPO etc
  • HoneyToken Account Creation in Local boxes as well domain
  • GPO changes for disabling guest accounts across system,restricted RDP mode,Password Policy changes,disabling internet in member servers
  • GPO for Jump server implementation based on PAW GPO settings
  • Rename existing builtin Administrator account and lockdown
  • Sysmon deployment and WEF setup (WEC for symon events)
  • Use Pingcastle www.pingcastle.com  review to assess the AD security
  • Use Bloodhound (https://github.com/BloodHoundAD/BloodHound) to assess the AD security
  • Use ADTimeline to assess the AD security

 

Some interesting sites:

Windows hardening: https://wp.me/p15Zft-Mr

Privilege admin workstation: https://wp.me/p15Zft-Mr

Delegate WMI access to domain controllers:

This post originally came about after several customers asked how to remove users accounts from Domain Admins and the Administrators group in the domain. These accounts are needed to monitor the systems, so we needed to find a way to get them to read the instrumentation of the system with non-elevated privilege.

https://blogs.technet.microsoft.com/askpfeplat/2018/04/30/delegate-wmi-access-to-domain-controllers/

 

Troubleshooting Account Lockouts has become an IT admin routine nowadays;

You can find more possible root causes in our Account Lockout Troubleshooting Guide – https://community.spiceworks.com/how_to/113387-account-lockout-troubleshooting.

Possible root causes:

Persistent drive mappings with expired credentials
Mobile devices using domain services like Exchange mailbox
Service Accounts using cached passwords
Scheduled tasks with expired credentials
Programs using stored credentials
Misconfigured domain policy settings issues
Dsconnected Terminal Server sessions
Unix programs
Kerberos pre-authentication failures

Event IDs used to troubleshoot account locked out: 4740, 4625, 4771 (kerberos pre-authentication failure)

List of free tools to help the community with Account lockout root cause investigation and here it is:

1) Netwrix Account Lockout Examiner. As a disclaimer, this is our free tool and you probably know it very well, I want to keep your eye on its main features, may be you didn’t know something about it:

a. Account lockout investigation – It is the main feature that helps you to find out the account lockout root cause, it scans the logs related to locked accounts and gives you the info about IP address or computer name from which failed logons came from, it also examines mapped drives, services, RDP sessions or scheduled tasks for bad credentials.

b. E-mail alerts – You can alert your IT admins or help-desk staff with e-mail received after an account lockout happens so even before end users pick up the phone, help desk personnel already have all the details they need to quickly troubleshoot account lockouts.

c. Helps you to unlock accounts faster through a web-based console or even via email sent from your mobile device.

2) Account Lockout Status Tools. This is a pack of tools from Microsoft that consists of several separate ones, that will help you with Account Lockout troubleshooting.

a. EventCombMT.exe collects and filters events from the event logs of domain controllers. This tool has a built-in search for account lockouts, it gathers the event IDs related to a certain account lockouts in a separate text file.

b. LockoutStatus.exe examines all DCs in a domain, letting you know when the target account last locked out and from which DC. In addition, it provides the locked-out account’s current status and the number of bad password attempts that have been made.

c. Netlogon logging is used for tracking Netlogon and NT LAN Manager (NTLM) events. Enabling Netlogon logging on all DCs is an effective way to isolate a locked-out account and see where the account is being locked out. Although Netlogon logging isn’t part of the Account Lockout and Management Tools, NLParse.exe is used to parse the Netlogon logs—and NLParse.exe is one of the account lockout tools.

d. Acctinfo exposes more properties in ADUC (Active Directory Users and Computers), for example lastLogon and Password Expires.  Specifically, with this add-on you get an extra tab in ADUC called Additional Account Info it helps isolate and troubleshoot account lockouts and to change a user’s password on a domain controller in that user’s site.

3) ADLockouts. This simple utility tries to track the origin of Active Directory bad password attempts and lockout. It can search each domain/domain controller for failed logons, then parse any related events and work out where the origin of the lockout came from. After that it analyzes each machine and outputs what common causes of account lockouts are present, for example mapped drives, old rdp sessions, scheduled tasks and so on.

4) Powershell. Using powershell you can easily filter the event log for events that are related to a certain account and try to figure out what caused the its lockout.

a. Here is the powershell code with Get-EventLog cmdlet:

Get-EventLog -LogName Security | ?{$_.message -like "*locked*USERNAME*"} | fl -property * 

You can also use Get-UserLockoutStatus function for troubleshooting persistent account lockout problems. The function searches all domain controllers for a user in a domain for account lockout status, Bad Password Count, Last bad password time, and When password was set last, you can find the full code here – https://gallery.technet.microsoft.com/scriptcenter/PowerShell-function-for-bc5f8b56

https://adsecurity.org/wp-content/uploads/2019/08/2019-BlackHat-US-Metcalf-Morowczynski-AttackingAndDefendingTheMicrosoftCloud.pdf