ANAVEM
Languagefr
Windows security monitoring dashboard showing Event Viewer with security audit logs for group management events
Event ID 4734InformationMicrosoft-Windows-Security-AuditingWindows

Windows Event ID 4734 – Microsoft-Windows-Security-Auditing: Security-Enabled Local Group Member Removed

Event ID 4734 fires when a member is removed from a security-enabled local group. This security audit event tracks group membership changes for compliance and security monitoring purposes.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 202612 min read 0
Event ID 4734Microsoft-Windows-Security-Auditing 5 methods 12 min
Event Reference

What This Event Means

Windows Event ID 4734 represents a fundamental security auditing mechanism that tracks the removal of members from security-enabled local groups. When this event fires, it indicates that the group membership database has been modified, specifically that a security principal (user account, computer account, or another group) has been removed from a local group's membership list.

The event provides comprehensive details including the subject who performed the action (with their Security ID, account name, and domain), the target group that was modified (including its Security ID, name, and domain), and the member that was removed (with complete identification details). This granular logging enables administrators to maintain detailed audit trails of privilege changes and group modifications.

In Active Directory environments, this event fires on domain controllers when domain local groups are modified. On standalone systems or member servers, it fires when local groups are changed. The event is generated regardless of whether the removal was performed through GUI tools like Computer Management, command-line utilities like net localgroup, or programmatic methods through Windows APIs.

The timing and frequency of these events can indicate normal administrative activities, automated processes, or potentially suspicious behavior. Mass removals or removals performed by unexpected accounts may warrant investigation, making this event valuable for security monitoring and incident response activities.

Applies to

Windows 10Windows 11Windows Server 2019/2022/2025
Analysis

Possible Causes

  • Administrator manually removing a user from a local group through Computer Management console
  • Command-line operations using net localgroup or PowerShell cmdlets like Remove-LocalGroupMember
  • Group Policy processing that modifies restricted groups membership
  • Automated scripts or applications removing users from groups programmatically
  • Active Directory replication removing members from domain local groups
  • Security software or identity management systems performing group cleanup operations
  • System account changes during software installation or uninstallation processes
Resolution Methods

Troubleshooting Steps

01

Review Event Details in Event Viewer

Start by examining the specific details of the Event ID 4734 occurrence to understand what happened.

  1. Open Event Viewer by pressing Win + R, typing eventvwr.msc, and pressing Enter
  2. Navigate to Windows LogsSecurity
  3. Filter the log by clicking Filter Current Log in the right pane
  4. Enter 4734 in the Event IDs field and click OK
  5. Double-click on a recent Event ID 4734 entry to view details
  6. Review the following key fields in the event description:
    • Subject: Who performed the removal (Account Name, Account Domain, Logon ID)
    • Group: Which group was modified (Group Name, Group Domain, Group SID)
    • Member: Which account was removed (Member Name, Member SID)
  7. Note the timestamp and correlate with any known administrative activities
Pro tip: Use the Details tab in Event Viewer to see the raw XML data, which can be helpful for automated parsing or detailed analysis.
02

Query Events with PowerShell

Use PowerShell to programmatically query and analyze Event ID 4734 occurrences across multiple systems or time periods.

  1. Open PowerShell as Administrator
  2. Query recent Event ID 4734 entries:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4734} -MaxEvents 50 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
  3. For more detailed analysis, extract specific fields:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4734} -MaxEvents 20 | ForEach-Object {
        $xml = [xml]$_.ToXml()
        $eventData = $xml.Event.EventData.Data
        [PSCustomObject]@{
            TimeCreated = $_.TimeCreated
            SubjectUserName = ($eventData | Where-Object {$_.Name -eq 'SubjectUserName'}).'#text'
            GroupName = ($eventData | Where-Object {$_.Name -eq 'TargetUserName'}).'#text'
            MemberName = ($eventData | Where-Object {$_.Name -eq 'MemberName'}).'#text'
            MemberSid = ($eventData | Where-Object {$_.Name -eq 'MemberSid'}).'#text'
        }
    }
  4. Filter events by specific time range:
    $StartTime = (Get-Date).AddDays(-7)
    $EndTime = Get-Date
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4734; StartTime=$StartTime; EndTime=$EndTime}
  5. Export results to CSV for further analysis:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4734} -MaxEvents 100 | Export-Csv -Path "C:\Temp\GroupRemovals.csv" -NoTypeInformation
03

Investigate Group Membership Changes

Verify current group membership and investigate whether the removal was authorized and expected.

  1. Check current membership of the affected group using PowerShell:
    Get-LocalGroupMember -Group "GroupName"
  2. For domain groups, use Active Directory cmdlets:
    Get-ADGroupMember -Identity "GroupName" | Select-Object Name, SamAccountName, ObjectClass
  3. Review group membership history by querying related events:
    # Look for both additions (4732) and removals (4734)
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4732,4734} -MaxEvents 100 | Where-Object {$_.Message -like "*GroupName*"} | Sort-Object TimeCreated
  4. Check if the removal was part of a larger administrative action by examining events around the same time:
    $EventTime = (Get-Date "2026-03-18 10:30:00")
    $TimeWindow = 300 # 5 minutes
    Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime=$EventTime.AddSeconds(-$TimeWindow); EndTime=$EventTime.AddSeconds($TimeWindow)} | Where-Object {$_.Id -in @(4732,4733,4734,4735)}
  5. Verify the subject account that performed the removal has appropriate permissions
  6. Document findings and determine if the change was authorized
Warning: Unexpected removals from privileged groups like Administrators or Domain Admins should be investigated immediately as potential security incidents.
04

Configure Advanced Auditing and Monitoring

Set up comprehensive monitoring to track future group membership changes and establish baselines for normal activity.

  1. Verify that Object Access auditing is enabled through Group Policy:
    • Open Group Policy Management Console
    • Navigate to Computer ConfigurationPoliciesWindows SettingsSecurity SettingsAdvanced Audit Policy Configuration
    • Expand Account Management and ensure Audit Security Group Management is set to Success and Failure
  2. Configure advanced audit settings via command line:
    auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
  3. Create a scheduled task to monitor for suspicious group changes:
    # Create a PowerShell script that runs every 15 minutes
    $ScriptBlock = {
        $Events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4734; StartTime=(Get-Date).AddMinutes(-15)} -ErrorAction SilentlyContinue
        if ($Events) {
            $Events | ForEach-Object {
                # Add your alerting logic here
                Write-EventLog -LogName Application -Source "GroupMonitor" -EventId 1001 -Message "Group member removal detected: $($_.Message)"
            }
        }
    }
    # Register the scheduled task
    Register-ScheduledTask -TaskName "MonitorGroupRemovals" -Trigger (New-ScheduledTaskTrigger -RepetitionInterval (New-TimeSpan -Minutes 15) -Once -At (Get-Date)) -Action (New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-WindowStyle Hidden -Command $ScriptBlock")
  4. Set up Windows Event Forwarding (WEF) to centralize security logs from multiple systems
  5. Configure SIEM integration if available to correlate group changes with other security events
05

Forensic Analysis and Incident Response

Perform detailed forensic analysis when Event ID 4734 indicates potential security incidents or unauthorized changes.

  1. Create a forensic timeline of all related events:
    # Collect comprehensive event data
    $StartDate = (Get-Date).AddDays(-30)
    $Events = @()
    $Events += Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625,4648,4672,4732,4733,4734,4735; StartTime=$StartDate} -ErrorAction SilentlyContinue
    $Events += Get-WinEvent -FilterHashtable @{LogName='System'; Id=7034,7035,7036; StartTime=$StartDate} -ErrorAction SilentlyContinue
    $Events | Sort-Object TimeCreated | Export-Csv -Path "C:\Forensics\SecurityTimeline.csv" -NoTypeInformation
  2. Analyze logon sessions associated with the subject account:
    # Find logon events for the account that made the change
    $SubjectAccount = "DOMAIN\Username" # Replace with actual account
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625} | Where-Object {$_.Message -like "*$SubjectAccount*"} | Select-Object TimeCreated, Id, Message
  3. Check for privilege escalation events (Event ID 4672) around the time of group changes:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4672} | Where-Object {$_.TimeCreated -gt (Get-Date).AddHours(-24)} | Format-Table TimeCreated, Message -Wrap
  4. Examine process creation events if Process Tracking is enabled:
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -like "*net.exe*" -or $_.Message -like "*powershell*"} | Select-Object TimeCreated, Message
  5. Document all findings and create an incident report including:
    • Timeline of events leading to the group change
    • Source of the change (user, process, system)
    • Impact assessment of the removed member
    • Recommendations for remediation or policy changes
  6. If malicious activity is suspected, preserve evidence and consider isolating affected systems
Warning: During forensic analysis, avoid making changes to the system that could alter evidence. Work with copies of logs when possible.

Overview

Event ID 4734 is a security audit event that fires whenever a member is removed from a security-enabled local group on a Windows system. This event is part of the Object Access audit category and provides detailed information about group membership changes, including who performed the action, which account was removed, and from which group.

The event appears in the Security log and is crucial for security monitoring, compliance auditing, and forensic investigations. It fires on domain controllers when domain local groups are modified, and on member servers and workstations when local groups are changed. The event captures both successful removals and provides context about the security principal that initiated the change.

This event is particularly important in environments where group membership changes need to be tracked for regulatory compliance, security investigations, or administrative oversight. It works in conjunction with Event ID 4732 (member added to group) to provide a complete audit trail of group membership modifications.

Frequently Asked Questions

What does Event ID 4734 mean and when should I be concerned?+
Event ID 4734 indicates that a member was removed from a security-enabled local group. You should be concerned when: removals happen from privileged groups like Administrators without authorization, removals occur outside normal business hours, the subject account performing the removal is unexpected or compromised, or there are mass removals from multiple groups simultaneously. Normal administrative activities will generate this event regularly, so establish baselines to identify anomalous patterns.
How can I tell if an Event ID 4734 was caused by legitimate administrative action?+
Check several factors: verify the subject account has appropriate permissions and is a known administrator, confirm the timing aligns with scheduled maintenance or known administrative tasks, review change management records for authorized group modifications, examine the member being removed to ensure it's appropriate, and look for related events like successful logons (4624) from the administrator's workstation. Legitimate actions typically have documentation, occur during business hours, and involve authorized personnel.
Why am I seeing multiple Event ID 4734 entries for the same group change?+
Multiple entries can occur due to: nested group memberships where removing a user from one group affects their membership in parent groups, replication in Active Directory environments where the change is recorded on multiple domain controllers, Group Policy processing that enforces restricted groups settings, or automated systems that verify and re-apply group memberships. Each occurrence represents a separate security audit record, which is normal behavior for comprehensive auditing.
Can Event ID 4734 help me track who removed a user from the Administrators group?+
Yes, Event ID 4734 provides detailed information about group membership removals including the subject (who performed the action) with their account name, domain, and Security ID, the target group that was modified, and the member that was removed. The event also includes timestamps and logon session information. Cross-reference this with Event ID 4624 (successful logon) to trace the administrator's session and determine the source workstation or method used.
How long are Event ID 4734 records retained and how can I archive them?+
Retention depends on your Security log configuration, typically 20MB with overwrite as needed by default. For compliance or forensic purposes, configure larger log sizes or enable archiving. Use PowerShell to export events: Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4734} | Export-Csv. Consider Windows Event Forwarding (WEF) to centralize logs, implement SIEM solutions for long-term storage, or use scheduled tasks to regularly archive security events. Many compliance frameworks require 90 days to 7 years of audit log retention.
Documentation

References (2)

Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...