Detecting Domain or Tenant Policy Modification (T1484)

Central identity systems are powerful because one change applies everywhere. That is also why adversaries want to change them. T1484, Domain or Tenant Policy Modification, covers modifying the configuration of a domain or identity tenant to evade defenses or escalate privileges. MITRE lists it under both defense impairment and privilege escalation, for Windows and identity providers.

How attackers use it

Central services manage identity resources such as devices and accounts. They often hold settings that apply between domains or tenants, including trust relationships, identity syncing and federation. With sufficient permissions, an adversary can alter those, and because the settings apply to many resources, the possible outcomes are broad.

MITRE gives four examples of abuse:

• modifying Group Policy Objects to push a malicious scheduled task to computers across the domain
• modifying domain trusts to include an adversary controlled domain, so forged access tokens are accepted by victim resources
• changing Active Directory configuration to implement a rogue domain controller
• adding a new adversary controlled federated identity provider to a tenant, allowing authentication as any user managed by that tenant

MITRE also notes that adversaries may change policy temporarily, carry out an action, and then revert the change to remove suspicious indicators. That makes point in time reviews weak and change logging essential.

How to detect it

MITRE's detection strategy has two analytics.

For Active Directory, look for creation or modification of GPOs, changes to delegation permissions, altered trust objects, and registration of a rogue domain controller. These may come through the GUI, command line or APIs.

For identity tenants, look for policy changes through the portal, PowerShell or the Graph API, such as altered federation or trust settings, newly added identity providers, a switch of authentication from managed to federated, and updates to federated domains.

MITRE does not name log sources or event IDs here, so decide what to collect:

1. Directory service change auditing on GPO and trust objects.
2. Admin audit logs from your identity provider, with alerts on any new identity provider or federation change.
3. File change monitoring on the policy store that holds GPO content.
4. A change record to match against. Any trust or federation change with no ticket is worth a call.

Because attackers may revert, retain these logs long enough to review after the fact.

How to reduce the risk

MITRE lists three mitigations.

1. Audit. Find and fix GPO permission abuse opportunities, for example who can modify GPOs, using auditing tools such as BloodHound version 1.5.1 and later.
2. Privileged account management. Use least privilege and protect administrative access to the domain controller and Active Directory Federation Services servers. Do not create service accounts with administrative privileges.
3. User account management. Use WMI and security filtering to tailor which users and computers a GPO applies to.

Add a process control to these: tenant federation changes should need a second person.

Check your own environment

• List who holds rights to edit GPOs and to create or modify trusts. Remove anyone who does not need it.
• List your federated domains and identity providers and confirm each has an owner.
• Confirm that admin audit logs from your identity provider flow to a place attackers with admin access cannot delete.
• Check that service accounts do not have domain admin rights.
• Run a test change in a lab and confirm an alert fires.

Quick check

Sources

• MITRE ATT&CK T1484: Domain or Tenant Policy Modification