DC0094: Group Modification
Changes made to a group, such as membership, name, or permissions (ex: Windows EID 4728 or 4732, AWS IAM UpdateGroup). Examples:
- Active Directory: - Event ID 4728: Member added to a global group. - Event ID 4732: Member added to a local group. - Azure AD: `Set-AzureADGroup -ObjectId
*Data Collection Measures:*
- Directory Logging: - Windows: Log EIDs 4728 (add), 4729 (remove). - Azure AD: Enable "Audit logs." - Google Workspace: Enable Admin Activity logs. - Office 365: Use Unified Audit Logs. - Cloud Monitoring: - AWS: Log `UpdateGroup`, `AttachGroupPolicy`, `RemoveUserFromGroup`. - Azure: Track modifications via Audit logs. - API Monitoring: Log Google Admin SDK and Microsoft Graph API calls. - SIEM Integration: Centralize and monitor group modification logs.
Analyst context for executives and security teams
Group Modification is a high-value audit signal because changes to group membership, names, or permissions can quickly alter who has access to business-critical systems and cloud resources. For leaders, the practical question is not just whether groups exist, but whether the organization can prove when sensitive groups changed, who made the change, through which directory or cloud service, and whether that change was expected.
Executive priority
Prioritize this data component where group membership or permissions influence privileged access, production administration, financial systems, cloud administration, or regulated data access. It supports incident response scoping, access governance evidence, compliance reviews, and operational resilience by helping teams reconstruct authorization changes across directory and cloud identity services. Budget and control decisions should focus on whether group modification events are consistently logged, centralized, retained, and reviewed across Active Directory, Azure AD, AWS IAM, Google Workspace, and Office 365 where those services are in use.
Technical view
SOC and IR teams should validate collection of group change records such as Windows Event IDs 4728, 4729, and 4732; Azure AD audit logs; AWS IAM events including UpdateGroup, AttachGroupPolicy, and RemoveUserFromGroup; Google Workspace Admin Activity logs and Admin SDK activity; Office 365 Unified Audit Logs; and Microsoft Graph group modification activity. Because ATT&CK provides no detection logic for this data component, teams should build local analytics around sensitive group changes, unexpected permission changes, high-risk administrative groups, unusual source accounts, and changes occurring outside approved change windows.
Likely telemetry
- Directory service audit logs for group membership, name, and permission changes
- Windows security events including EID 4728, 4729, and 4732 where Active Directory is used
- Azure AD audit logs for group modifications
- AWS IAM logs for UpdateGroup, AttachGroupPolicy, and RemoveUserFromGroup
- Google Workspace Admin Activity logs and Admin SDK API activity
Detection direction
- Confirm that group modification logging is enabled in each relevant identity, directory, SaaS, and cloud environment listed in the ATT&CK description.
- Tune alerts around changes to privileged or business-critical groups rather than treating all group changes equally.
- Correlate group changes with the actor account, target group, affected member or permission, source service/API, timestamp, and change-management context.
- Expect legitimate administrative activity to create false positives; use approved change windows, ticket references, and known identity administration processes to reduce noise.
- Look for blind spots where SaaS API activity, cloud IAM events, or directory logs are not forwarded to the SIEM or are retained for too short a period.
Mitigation priorities
- Enable and retain directory, cloud, SaaS, and API audit logs for group modifications where those services are used.
- Centralize group modification telemetry in the SIEM or equivalent monitoring platform.
- Define and inventory sensitive groups whose changes require heightened monitoring and review.
- Align group changes with access governance and change-management workflows so expected activity can be distinguished from suspicious activity.
- Review logging coverage and retention as part of compliance readiness and incident response preparedness.
Analyst notes and limits
This is a data component, not a technique, so its value is primarily in coverage validation and evidence quality. It is especially relevant to identity and cloud security because group changes often determine effective access. The supplied object provides collection examples but no ATT&CK detection text or relationship context, so local group criticality, administrative workflows, and logging architecture are required to turn it into reliable detections.
Platforms and tactics are not specified for the object, and no official detection logic or relationships were supplied. The examples reference multiple directory, cloud, and SaaS services, but applicability depends on which of those services exist in the local environment. This take does not imply active exploitation, attribution, impact, or existing detection coverage.
Group Modification
Changes made to a group, such as membership, name, or permissions (ex: Windows EID 4728 or 4732, AWS IAM UpdateGroup). Examples:
- Active Directory: - Event ID 4728: Member added to a global group. - Event ID 4732: Member added to a local group. - Azure AD: `Set-AzureADGroup -ObjectId
*Data Collection Measures:*
- Directory Logging: - Windows: Log EIDs 4728 (add), 4729 (remove). - Azure AD: Enable "Audit logs." - Google Workspace: Enable Admin Activity logs. - Office 365: Use Unified Audit Logs. - Cloud Monitoring: - AWS: Log `UpdateGroup`, `AttachGroupPolicy`, `RemoveUserFromGroup`. - Azure: Track modifications via Audit logs. - API Monitoring: Log Google Admin SDK and Microsoft Graph API calls. - SIEM Integration: Centralize and monitor group modification logs.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | ee080e9b3db0… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0094Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.