Privileged Access Breach

A privileged access breach occurs when an attacker gains control of an account with administrative rights to systems, applications, or infrastructure. The elevated permissions of these accounts mean that compromise enables lateral movement, persistence establishment, and access to sensitive data that standard user accounts cannot reach. This playbook applies when administrative accounts, service accounts, or any identity with elevated privileges shows signs of unauthorised use.

Activation criteria

Invoke this playbook when any of these conditions are confirmed or strongly suspected:

Standard user account compromise follows the Account Compromise playbook. Escalate to this playbook if investigation reveals the compromised account has privileged access or if the attacker has elevated privileges during the incident.

Roles

For organisations with a single IT person, that individual assumes all technical roles. The incident commander role should transfer to a senior manager or director to maintain decision authority separation during containment actions that affect operations.

Severity assessment

Before proceeding with containment, assess breach severity to determine response scope. Severity drives the breadth of containment actions and the extent of credential rotation required.

                              +-------------------------+
                              | Privileged Account      |
                              | Compromise Detected     |
                              +------------+------------+
                                           |
                              +------------v------------+
                              | What account type?      |
                              +------------+------------+
                                           |
              +----------------------------+----------------------------+
              |                            |                            |
              v                            v                            v
    +---------+---------+        +---------+---------+        +---------+---------+
    | Domain Admin /    |        | Application Admin |        | Service Account   |
    | Global Admin      |        | (single system)   |        |                   |
    +---------+---------+        +---------+---------+        +---------+---------+
              |                            |                            |
              v                            v                            v
    +---------+---------+        +---------+---------+        +---------+---------+
    | SEVERITY 1        |        | SEVERITY 2        |        | Check scope       |
    | Full cascade      |        | System-specific   |        | of service        |
    | All credentials   |        | rotation          |        | account access    |
    +---------+---------+        +---------+---------+        +---------+---------+
              |                            |                            |
              |                            |               +------------+------------+
              |                            |               |                         |
              |                            |               v                         v
              |                            |     +---------+---------+     +---------+---------+
              |                            |     | Cross-system      |     | Single-system     |
              |                            |     | (AD, Azure AD,    |     | service account   |
              |                            |     | multiple apps)    |     |                   |
              |                            |     +---------+---------+     +---------+---------+
              |                            |               |                         |
              |                            |               v                         v
              |                            |     +---------+---------+     +---------+---------+
              |                            |     | SEVERITY 1        |     | SEVERITY 2        |
              |                            |     | Full cascade      |     | System-specific   |
              |                            |     +-----------------+       +-----------------+
              |                            |
              v                            v
    +---------+----------------------------+---------+
    |                                                |
    |            PROCEED TO PHASE 1                  |
    |            with severity level                 |
    |                                                |
    +------------------------------------------------+

Figure 1: Severity assessment decision flow for privileged access breach

Severity 1

Domain-wide or tenant-wide administrative access compromised. Requires full credential rotation cascade, infrastructure integrity verification, and potential directory rebuild assessment.

Severity 2

Administrative access to specific systems or applications compromised. Requires targeted credential rotation for affected systems and their downstream dependencies.

Phase 1: Immediate containment

Objective: Stop attacker access and prevent further lateral movement within 30 minutes of playbook activation.

Timeframe: 0 to 30 minutes

1. Capture current session state for the compromised account. Record all active sessions, authentication tokens, and recent activity before any containment action.

   For Microsoft Entra ID (Azure AD):

   # Get sign-in logs for last 24 hours
   Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'admin@example.org'" -Top 100 |
     Select-Object CreatedDateTime, IpAddress, Location, AppDisplayName, Status |
     Export-Csv -Path "C:\Evidence\signin_logs_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv"

   # Get current sessions
   Get-MgUserAuthenticationMethod -UserId "admin@example.org"

For on-premises Active Directory:

   # Get recent authentication events
   Get-WinEvent -FilterHashtable @{
     LogName='Security'
     Id=4624,4625,4768,4769
     StartTime=(Get-Date).AddHours(-24)
   } | Where-Object { $_.Properties[5].Value -eq 'compromised_admin' } |
     Export-Csv -Path "C:\Evidence\ad_auth_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv"

2. Disable the compromised account in all identity systems. Perform this action simultaneously across systems if the account exists in multiple directories.

   Microsoft Entra ID:

   # Disable account
   Update-MgUser -UserId "admin@example.org" -AccountEnabled:$false

   # Revoke all refresh tokens (forces re-authentication)
   Revoke-MgUserSignInSession -UserId "admin@example.org"

On-premises Active Directory:

   # Disable account
   Disable-ADAccount -Identity "compromised_admin"

   # Force immediate replication to all DCs
   repadmin /syncall /AdeP

Linux systems (if local account):

   # Lock account
   usermod -L compromised_admin

   # Expire account immediately
   chage -E 0 compromised_admin

   # Kill all user processes
   pkill -u compromised_admin

3. Terminate all active sessions for the compromised account. Cached tokens and existing sessions can persist after account disablement.

   For cloud applications with OAuth/OIDC:

   # Revoke OAuth tokens for all enterprise applications
   Get-MgUserOAuth2PermissionGrant -UserId "admin@example.org" |
     ForEach-Object { Remove-MgOAuth2PermissionGrant -OAuth2PermissionGrantId $_.Id }

For Windows Remote Desktop sessions:

   # Query sessions on critical servers
   $servers = @("DC01", "DC02", "FILESERVER01", "SQL01")
   foreach ($server in $servers) {
     query session /server:$server | Select-String "compromised_admin"
   }

   # Forcibly log off if found (replace SESSION_ID with actual ID)
   # logoff SESSION_ID /server:SERVER_NAME

4. Block the compromised account at network level if immediate session termination is not possible or verifiable.

   Firewall rule (example for pfSense/OPNsense):

   Block all traffic from IP addresses associated with compromised sessions
   Source: [attacker IP addresses from sign-in logs]
   Destination: any
   Action: Block
   Log: enabled

Conditional Access emergency policy (Microsoft Entra ID):

   Name: EMERGENCY - Block Compromised Admin
   Users: compromised_admin@example.org
   Cloud apps: All cloud apps
   Conditions: Any location, any device, any client app
   Grant: Block access
   Enable policy: On

5. Notify the incident commander that Phase 1 containment is complete and provide the following information:
   • Account disabled: Yes/No and timestamp
   • Sessions terminated: Yes/No and count
   • Evidence captured: Yes/No and location
   • Any issues encountered

Decision point: If the compromised account shows signs of creating new accounts, modifying group memberships, or disabling security controls, escalate immediately to Severity 1 regardless of initial assessment. Proceed to Phase 2 with elevated urgency.

Checkpoint: Account disabled across all directories. All active sessions terminated or blocked. Evidence captured and secured. Proceed to Phase 2 only after confirming these conditions.

Phase 2: Scope determination

Objective: Identify what the attacker accessed, modified, or exfiltrated during the compromise period.

Timeframe: 30 minutes to 4 hours (parallel with Phase 3 for Severity 1)

The scope determination phase establishes the timeline and extent of compromise. The compromise window spans from the earliest suspected unauthorised access to the moment of containment. For breaches detected through breach database monitoring, assume the compromise window extends to the password’s last change date. For impossible travel detections, the window begins at the anomalous authentication.

1. Establish the compromise timeline by analysing authentication logs to identify the first unauthorised access.

   Query for first anomalous access (Microsoft Entra ID):

   # Get all sign-ins for the account, sorted by date
   Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'admin@example.org'" -All |
     Sort-Object CreatedDateTime |
     Select-Object CreatedDateTime, IpAddress, Location, AppDisplayName,
                   @{N='Status';E={$_.Status.ErrorCode}},
                   @{N='Risk';E={$_.RiskLevelDuringSignIn}} |
     Export-Csv -Path "C:\Evidence\full_signin_history.csv"

Look for these indicators to establish compromise start:

• First authentication from an IP address not previously associated with the account
• First authentication from a geographic location inconsistent with user’s normal pattern
• First authentication using a device not registered to the user
• Authentication immediately following password reset not initiated by user

2. Document all systems the compromised account accessed during the compromise window.

   Microsoft 365 unified audit log:

   # Search unified audit log for all activity by compromised account
   Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
     -UserIds "admin@example.org" -ResultSize 5000 |
     Select-Object CreationDate, Operations, AuditData |
     Export-Csv -Path "C:\Evidence\m365_audit.csv"

Windows Security Event Log (aggregate from all servers):

   # Events indicating privileged activity
   $eventIds = @(
     4624,  # Successful logon
     4672,  # Special privileges assigned
     4728,  # Member added to security-enabled global group
     4732,  # Member added to security-enabled local group
     4756,  # Member added to security-enabled universal group
     4738,  # User account changed
     4720,  # User account created
     4726   # User account deleted
   )

   Get-WinEvent -FilterHashtable @{
     LogName='Security'
     Id=$eventIds
     StartTime=[compromise_window_start]
   } | Export-Csv -Path "C:\Evidence\windows_security_events.csv"

3. Identify data access during the compromise window. Query file access logs, database audit logs, and application logs to determine what information the attacker could have accessed.

   SharePoint/OneDrive file access (Microsoft 365):

   Search-UnifiedAuditLog -StartDate [compromise_start] -EndDate [compromise_end] `
     -UserIds "admin@example.org" `
     -Operations FileAccessed,FileDownloaded,FileModified,FileCopied |
     Select-Object CreationDate, Operations,
                   @{N='File';E={(ConvertFrom-Json $_.AuditData).ObjectId}} |
     Export-Csv -Path "C:\Evidence\file_access.csv"

SQL Server audit (if database admin account):

   SELECT event_time, action_id, succeeded,
          server_principal_name, database_name,
          object_name, statement
   FROM sys.fn_get_audit_file('C:\SQLAudit\*.sqlaudit', DEFAULT, DEFAULT)
   WHERE server_principal_name = 'compromised_admin'
     AND event_time >= '[compromise_window_start]'
   ORDER BY event_time;

4. Check for privilege escalation and lateral movement. The attacker may have used the compromised account to gain access to additional accounts or elevate privileges on other systems.

   New privileged group memberships:

   # Check who was added to privileged groups during compromise window
   Get-WinEvent -FilterHashtable @{
     LogName='Security'
     Id=4728,4732,4756
     StartTime=[compromise_window_start]
   } | ForEach-Object {
     [PSCustomObject]@{
       Time = $_.TimeCreated
       Group = $_.Properties[2].Value
       MemberAdded = $_.Properties[0].Value
       AddedBy = $_.Properties[6].Value
     }
   }

New accounts created:

   # Check for accounts created during compromise window
   Get-ADUser -Filter {Created -ge [compromise_window_start]} -Properties Created,Enabled |
     Select-Object Name, SamAccountName, Created, Enabled

5. Document scope findings in the incident record. Create a clear summary for the incident commander:

   SCOPE DETERMINATION SUMMARY

   Compromise Window: [start_datetime] to [end_datetime]
   Duration: [X] hours/days

   Systems Accessed:
   - [System 1]: [access type, data exposed]
   - [System 2]: [access type, data exposed]

   Accounts Created/Modified:
   - [List any new accounts or privilege changes]

   Data Exposure:
   - File servers: [Yes/No, scope]
   - Databases: [Yes/No, scope]
   - Email: [Yes/No, scope]
   - Cloud storage: [Yes/No, scope]

   Evidence of Exfiltration: [Yes/No/Unknown, details]

   Persistence Mechanisms Found: [Yes/No, details - see Phase 3]

Decision point: If scope determination reveals access to personal data of more than 100 individuals, or any access to protection/safeguarding case data, notify the incident commander immediately. Data breach notification timelines begin from this determination. Coordinate with the Data Breach Response or Protection Data Breach Response playbook as appropriate.

Checkpoint: Compromise window established. All accessed systems documented. Data exposure assessment complete. Findings documented in incident record.

Phase 3: Persistence detection

Objective: Identify and remove mechanisms the attacker may have established to maintain access after the compromised account is disabled.

Timeframe: 1 to 8 hours (run in parallel with Phase 2 for Severity 1 incidents)

Attackers with privileged access typically establish persistence mechanisms to survive credential rotation. These mechanisms operate independently of the original compromised account and will allow continued access unless specifically identified and removed.

+-------------------------------------------------------------------------+
|                    PERSISTENCE MECHANISM DETECTION                       |
+-------------------------------------------------------------------------+
|                                                                          |
|  +-------------------+     +-------------------+     +-------------------+|
|  | ACCOUNT-BASED     |     | CREDENTIAL-BASED  |     | CODE-BASED       ||
|  +-------------------+     +-------------------+     +-------------------+|
|  |                   |     |                   |     |                   ||
|  | - New admin       |     | - Additional      |     | - Scheduled tasks ||
|  |   accounts        |     |   passwords       |     | - Services        ||
|  | - Reactivated     |     | - SSH keys added  |     | - Startup scripts ||
|  |   disabled accts  |     | - API keys        |     | - Web shells      ||
|  | - Service accts   |     | - App passwords   |     | - Cron jobs       ||
|  |   created         |     | - Certificates    |     | - Registry keys   ||
|  | - Guest accounts  |     | - OAuth grants    |     | - GPO scripts     ||
|  |   elevated        |     | - SAML tokens     |     | - WMI subscriptions|
|  |                   |     |                   |     |                   ||
|  +--------+----------+     +--------+----------+     +--------+----------+|
|           |                         |                         |          |
|           v                         v                         v          |
|  +--------+----------+     +--------+----------+     +--------+----------+|
|  | CHECK: Directory  |     | CHECK: Credential |     | CHECK: System    ||
|  | enumeration       |     | stores, key vaults|     | task enumeration ||
|  | Account audit     |     | Certificate stores|     | Service audit    ||
|  +-------------------+     +-------------------+     +-------------------+|
|                                                                          |
+-------------------------------------------------------------------------+

Figure 2: Persistence mechanism categories and detection approaches

1. Enumerate all accounts created or modified during the compromise window. Each must be verified as legitimate or disabled.

   Active Directory account audit:

   # Accounts created during compromise window
   Get-ADUser -Filter {Created -ge [compromise_start]} -Properties * |
     Select-Object Name, SamAccountName, Created, Enabled,
                   PasswordLastSet, MemberOf, Description |
     Export-Csv -Path "C:\Evidence\new_accounts.csv"

   # Accounts modified during compromise window
   Get-ADUser -Filter {Modified -ge [compromise_start]} -Properties * |
     Select-Object Name, SamAccountName, Modified, Enabled,
                   PasswordLastSet, MemberOf, Description |
     Export-Csv -Path "C:\Evidence\modified_accounts.csv"

   # Check for disabled accounts that were re-enabled
   Get-WinEvent -FilterHashtable @{
     LogName='Security'
     Id=4722  # Account enabled
     StartTime=[compromise_start]
   } | ForEach-Object {
     [PSCustomObject]@{
       Time = $_.TimeCreated
       Account = $_.Properties[0].Value
       EnabledBy = $_.Properties[4].Value
     }
   }

Microsoft Entra ID account audit:

   # Get directory audit logs for user management
   Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge [compromise_start]" |
     Where-Object { $_.Category -eq 'UserManagement' } |
     Select-Object ActivityDateTime, ActivityDisplayName,
                   @{N='Target';E={$_.TargetResources[0].UserPrincipalName}},
                   @{N='Actor';E={$_.InitiatedBy.User.UserPrincipalName}} |
     Export-Csv -Path "C:\Evidence\aad_user_changes.csv"

2. Check for additional authentication methods added to existing accounts. Attackers add secondary credentials to accounts they do not control to maintain access.

   Microsoft Entra ID authentication methods:

   # Check all admin accounts for authentication method changes
   $admins = Get-MgDirectoryRoleMember -DirectoryRoleId [global_admin_role_id]

   foreach ($admin in $admins) {
     $methods = Get-MgUserAuthenticationMethod -UserId $admin.Id
     [PSCustomObject]@{
       User = $admin.AdditionalProperties.userPrincipalName
       MethodCount = $methods.Count
       Methods = ($methods | ForEach-Object { $_.AdditionalProperties.'@odata.type' }) -join ','
     }
   }

SSH authorized_keys on Linux systems:

   # Check for recently modified authorized_keys files
   find /home -name "authorized_keys" -mtime -30 -exec ls -la {} \; -exec cat {} \;

   # Check root authorized_keys
   ls -la /root/.ssh/authorized_keys
   cat /root/.ssh/authorized_keys

3. Examine OAuth application consents and enterprise application permissions. Attackers grant permissions to applications they control to maintain API access.

   # List all OAuth2 permission grants created during compromise window
   Get-MgOAuth2PermissionGrant -All |
     Where-Object { $_.StartTime -ge [compromise_start] } |
     Select-Object ClientId, ConsentType, PrincipalId, Scope |
     Export-Csv -Path "C:\Evidence\oauth_grants.csv"

   # List enterprise applications with recent permission changes
   Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge [compromise_start]" |
     Where-Object { $_.Category -eq 'ApplicationManagement' } |
     Select-Object ActivityDateTime, ActivityDisplayName, TargetResources |
     Export-Csv -Path "C:\Evidence\app_changes.csv"

4. Check scheduled tasks, services, and startup items on systems the compromised account accessed.

   Windows scheduled task audit:

   # List tasks created during compromise window
   Get-ScheduledTask | Where-Object {
     $_.Date -ge [compromise_start]
   } | Select-Object TaskName, TaskPath, Date, Author,
                     @{N='Action';E={$_.Actions.Execute}}

   # Check for tasks running as SYSTEM or with stored credentials
   Get-ScheduledTask | Where-Object {
     $_.Principal.RunLevel -eq 'Highest' -or
     $_.Principal.LogonType -eq 'Password'
   } | Select-Object TaskName, TaskPath,
                     @{N='RunAs';E={$_.Principal.UserId}},
                     @{N='Action';E={$_.Actions.Execute}}

Windows service audit:

   # Services created during compromise window
   Get-WinEvent -FilterHashtable @{
     LogName='System'
     Id=7045  # Service installed
     StartTime=[compromise_start]
   } | ForEach-Object {
     [PSCustomObject]@{
       Time = $_.TimeCreated
       ServiceName = $_.Properties[0].Value
       ImagePath = $_.Properties[1].Value
       ServiceType = $_.Properties[2].Value
       StartType = $_.Properties[3].Value
       AccountName = $_.Properties[4].Value
     }
   }

Linux cron and systemd audit:

   # Check for recently modified cron jobs
   find /etc/cron* /var/spool/cron -mtime -30 -type f -exec ls -la {} \; -exec cat {} \;

   # Check for recently created systemd services
   find /etc/systemd/system -mtime -30 -type f -name "*.service" -exec ls -la {} \; -exec cat {} \;

   # Check systemd timers
   systemctl list-timers --all

5. Examine Group Policy Objects for script-based persistence (Windows domain environments).

   # List GPOs modified during compromise window
   Get-GPO -All | Where-Object { $_.ModificationTime -ge [compromise_start] } |
     Select-Object DisplayName, ModificationTime, GpoStatus

   # Check for scripts in GPOs
   $gpos = Get-GPO -All
   foreach ($gpo in $gpos) {
     $gpoPath = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies\{$($gpo.Id)}"
     $scripts = Get-ChildItem -Path "$gpoPath\*\Scripts" -Recurse -ErrorAction SilentlyContinue
     if ($scripts) {
       Write-Output "GPO: $($gpo.DisplayName)"
       $scripts | Select-Object FullName, LastWriteTime
     }
   }

6. Document all persistence mechanisms found and removal status.

   PERSISTENCE DETECTION SUMMARY

   Account-Based:
   - New accounts found: [count]
   - Accounts requiring removal: [list]
   - Removal status: [Pending/Complete]

   Credential-Based:
   - Additional auth methods found: [count]
   - OAuth grants requiring revocation: [count]
   - Removal status: [Pending/Complete]

   Code-Based:
   - Scheduled tasks found: [count]
   - Services found: [count]
   - Startup scripts found: [count]
   - Removal status: [Pending/Complete]

   GPO-Based:
   - Modified GPOs found: [count]
   - Remediation status: [Pending/Complete]

Decision point: If persistence mechanisms are found in domain controllers, certificate authorities, or identity providers, escalate to Severity 1 if not already classified as such. Consider engaging external forensics support before removing persistence if legal proceedings are anticipated.

Checkpoint: All persistence categories examined. Findings documented. Persistence mechanisms removed or queued for removal with appropriate approvals.

Phase 4: Credential rotation cascade

Objective: Rotate all credentials that the compromised account could access or that may have been exposed during the breach.

Timeframe: 4 to 48 hours depending on severity and credential count

Credential rotation follows dependency order. Rotating a downstream credential before its upstream dependency may result in service outages or incomplete rotation. The cascade begins with infrastructure credentials and proceeds through application and service account credentials.

+------------------------------------------------------------------+
|                 CREDENTIAL ROTATION CASCADE                      |
+------------------------------------------------------------------+
|                                                                  |
|  TIER 1: Directory & Infrastructure (rotate first)               |
|  +------------------------------------------------------------+  |
|  | - KRBTGT (requires two rotations, 10+ hours apart)         |  |
|  | - Directory service accounts                               |  |
|  | - Domain admin accounts (all)                              |  |
|  | - Certificate authority private keys                       |  |
|  | - Azure AD Connect / sync service accounts                 |  |
|  +------------------------------------------------------------+  |
|                              |                                   |
|                              v                                   |
|  TIER 2: Platform & Service Accounts                             |
|  +------------------------------------------------------------+  |
|  | - Cloud platform service principals                        |  |
|  | - Database service accounts                                |  |
|  | - Application pool identities                              |  |
|  | - Backup service accounts                                  |  |
|  | - Monitoring service accounts                              |  |
|  +------------------------------------------------------------+  |
|                              |                                   |
|                              v                                   |
|  TIER 3: Application & Integration                               |
|  +------------------------------------------------------------+  |
|  | - API keys and secrets                                     |  |
|  | - Integration credentials                                  |  |
|  | - Third-party service credentials                          |  |
|  | - Certificate-based authentication                         |  |
|  +------------------------------------------------------------+  |
|                              |                                   |
|                              v                                   |
|  TIER 4: User Credentials (if warranted)                         |
|  +------------------------------------------------------------+  |
|  | - All admin user passwords                                 |  |
|  | - Admin MFA re-enrollment                                  |  |
|  | - Standard users (if lateral movement confirmed)           |  |
|  +------------------------------------------------------------+  |
|                                                                  |
+------------------------------------------------------------------+

Figure 3: Credential rotation cascade tiers

1. Inventory all credentials requiring rotation based on compromise scope. Create a tracking spreadsheet with status for each credential.

   Credential	System	Owner	Rotation method	Status	Verified
   KRBTGT	AD	Infrastructure	Script	Pending	No
   svc_backup	AD	Backup team	Manual	Pending	No
   SQL_admin	SQL01	DBA	Manual	Pending	No

2. Execute Tier 1 rotation for directory and infrastructure credentials.

   KRBTGT rotation (requires two executions):

   # First rotation
   # Download and run Microsoft KRBTGT reset script
   # https://www.microsoft.com/en-us/download/details.aspx?id=53430

   # Verify current KRBTGT password age
   Get-ADUser krbtgt -Properties PasswordLastSet |
     Select-Object PasswordLastSet

   # Force replication after rotation
   repadmin /syncall /AdeP

   # Schedule second rotation for 10+ hours later

Directory service account rotation:

   # Rotate Azure AD Connect service account
   # This requires coordination with identity team
   # Document current account: AAD_[guid]

   # For managed service accounts, trigger password rotation:
   Reset-ADServiceAccountPassword -Identity "svc_account_name"

3. Execute Tier 2 rotation for platform and service accounts. Coordinate with application owners for each service account to minimize disruption.

   # Generate service account credential inventory
   Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties * |
     Select-Object Name, SamAccountName, PasswordLastSet,
                   ServicePrincipalName, Enabled |
     Export-Csv -Path "C:\Evidence\service_accounts.csv"

   # For each service account, follow rotation procedure:
   # 1. Notify application owner
   # 2. Create new password
   # 3. Update password in application configuration
   # 4. Restart service
   # 5. Verify functionality
   # 6. Update documentation

4. Execute Tier 3 rotation for application and integration credentials.

   Azure Key Vault secrets:

   # List secrets that may need rotation
   Get-AzKeyVaultSecret -VaultName "vault-name" |
     Select-Object Name, Created, Updated, Enabled

   # Rotate individual secrets
   # (generate new value and update in Key Vault)
   $newSecret = ConvertTo-SecureString "[new_value]" -AsPlainText -Force
   Set-AzKeyVaultSecret -VaultName "vault-name" -Name "secret-name" -SecretValue $newSecret

API keys in environment configurations:

   # Inventory API keys in use
   grep -r "API_KEY\|APIKEY\|api_key" /etc/ /opt/apps/ --include="*.env" --include="*.conf"

   # Document each key and its regeneration process
   # Regenerate through respective service provider
   # Update configuration files
   # Restart dependent services

5. Execute Tier 4 rotation for user credentials if lateral movement was confirmed.

   Force password reset for all admin accounts:

   # Get all members of privileged groups
   $privilegedGroups = @("Domain Admins", "Enterprise Admins", "Administrators")
   $admins = foreach ($group in $privilegedGroups) {
     Get-ADGroupMember -Identity $group -Recursive
   }
   $admins = $admins | Sort-Object -Unique

   # Force password change at next logon
   foreach ($admin in $admins) {
     Set-ADUser -Identity $admin -ChangePasswordAtLogon $true
   }

   # Communicate to affected users

MFA re-enrollment for admin accounts (Microsoft Entra ID):

   # Require MFA re-registration
   foreach ($admin in $admins) {
     # Revoke existing MFA methods
     $methods = Get-MgUserAuthenticationMethod -UserId $admin.UserPrincipalName
     # Remove and require re-registration based on organisational policy
   }

6. Verify credential rotation effectiveness by testing authentication with old credentials fails and new credentials succeed.

   # Test that old credential no longer works
   # (use test script or manual verification)

   # Test that service functions with new credential
   # (verify application functionality)

   # Update rotation tracking spreadsheet with verification status

Decision point: If credential rotation causes service outages exceeding 2 hours, invoke Major Service Outage playbook in parallel. Maintain focus on security rotation while managing service restoration.

Checkpoint: All identified credentials rotated. Rotation verified for each credential. Tracking spreadsheet complete with verification status for all items.

Phase 5: Infrastructure integrity verification

Objective: Confirm infrastructure components have not been modified and can be trusted.

Timeframe: 4 to 24 hours (may extend for Severity 1)

For Severity 1 breaches where domain controller or identity provider compromise is suspected, infrastructure integrity verification determines whether rebuild is required.

1. Verify domain controller integrity by comparing against known-good baselines.

   # Check for unauthorized modifications to AD schema
   Get-ADObject -SearchBase "CN=Schema,CN=Configuration,DC=domain,DC=org" `
     -Filter {Modified -ge [compromise_start]} -Properties Modified

   # Check for modifications to AdminSDHolder
   Get-ADObject "CN=AdminSDHolder,CN=System,DC=domain,DC=org" -Properties *

   # Verify Group Policy template integrity
   # Compare SYSVOL contents against backup

2. Verify certificate authority integrity if the compromised account had CA admin rights.

   # List certificates issued during compromise window
   certutil -view -restrict "NotBefore>=[compromise_start]" -out "RequestID,RequesterName,CommonName,NotBefore,NotAfter"

   # Check for certificate template modifications
   # Compare against documented templates

3. Check for Golden Ticket and Silver Ticket attack indicators.

   Golden Ticket indicators (Kerberos TGT manipulation):

   • TGT tickets with lifetimes exceeding policy maximum
   • TGT tickets issued by non-DC systems
   • Authentication events without corresponding TGT requests

   # Look for anomalous Kerberos events
   Get-WinEvent -FilterHashtable @{
     LogName='Security'
     Id=4769  # Kerberos Service Ticket Operations
     StartTime=[compromise_start]
   } | Where-Object {
     $_.Properties[8].Value -ne '0x0'  # Failure code
   }

4. Verify backup integrity. Confirm backups taken before and during the compromise window are clean before relying on them for recovery.

   BACKUP INTEGRITY VERIFICATION

   Backup Date: [date]
   Backup Type: [full/incremental]
   Systems Included: [list]

   Verification Method:
   [ ] Restore to isolated environment
   [ ] Malware scan of restored data
   [ ] Integrity check of restored systems
   [ ] Comparison against known-good baseline

   Status: [Clean / Compromised / Unknown]

5. Document infrastructure integrity findings and rebuild recommendations.

   INFRASTRUCTURE INTEGRITY SUMMARY

   Domain Controllers:
   - DC01: [Verified clean / Requires rebuild / Under investigation]
   - DC02: [Verified clean / Requires rebuild / Under investigation]

   Certificate Authority:
   - Status: [Verified clean / Requires rebuild]
   - Certificates to revoke: [count]

   Identity Provider:
   - Status: [Verified clean / Configuration requires review]

   Backup Integrity:
   - Most recent clean backup: [date]
   - Backup systems affected: [Yes/No]

   Rebuild Recommendation: [Yes/No]
   - If Yes, scope: [Full domain / Specific DCs / CA only]

Decision point: If integrity verification indicates domain controller or certificate authority compromise that cannot be verified as clean, recommend infrastructure rebuild to incident commander. This is a business continuity decision that requires executive approval due to operational impact.

Checkpoint: All infrastructure components assessed. Integrity status documented. Rebuild recommendation made if applicable.

Phase 6: Post-incident

Objective: Complete documentation, conduct review, and implement improvements.

Timeframe: 24 hours to 2 weeks after containment

1. Complete incident documentation including timeline, actions taken, and findings.

   Incident record must include:

   • Incident timeline with timestamps
   • Scope determination findings
   • Persistence mechanisms found and remediated
   • Credential rotation inventory with verification
   • Infrastructure integrity assessment
   • Data exposure assessment (for breach notification)
   • Total response costs and resource utilisation

2. Conduct post-incident review within 5 business days of containment.

   Review agenda:

   • Timeline walkthrough
   • Detection effectiveness (how was this found?)
   • Containment speed (where were delays?)
   • Scope determination accuracy
   • Persistence detection completeness
   • Communication effectiveness
   • What should change

3. Initiate access review for all privileged accounts within 10 business days.

   Review scope:

   • Current membership of all privileged groups
   • Justification for each privileged access grant
   • Removal of unnecessary privileges
   • Documentation update for approved access

   See Access Recertification for access review procedures.

4. Implement detection improvements based on lessons learned.

   Common improvements after privileged access breach:

   • Enhanced monitoring for privileged account activity
   • Alerting for after-hours privileged authentication
   • Alerting for privileged group membership changes
   • Alerting for service account interactive logons
   • Integration of breach monitoring for privileged accounts

5. Update playbook based on lessons learned.

   Document any gaps or improvements needed in this playbook for future incidents.

Checkpoint: Incident fully documented. Post-incident review complete. Improvements identified and assigned. Playbook updated if needed.

Communications

Communication templates

Executive notification (Severity 1):

Subject: SECURITY INCIDENT - Privileged Access Breach - Immediate Notification

[Executive name],

We are responding to a confirmed privileged access security incident.

CURRENT STATUS
- Incident type: Privileged account compromise
- Severity: [1 or 2]
- Containment status: [In progress / Complete]
- Affected account: [account type, not specific name in this communication]

IMMEDIATE ACTIONS TAKEN
- Compromised account disabled
- Active sessions terminated
- Investigation underway

KNOWN IMPACT
- Systems accessed: [number/scope]
- Data exposure assessment: [In progress / Complete - summary]

CURRENT PHASE: [Phase name]

NEXT UPDATE: [Time]

Incident Commander: [Name]
Contact: [Phone number]

IT staff notification:

Subject: Security Incident - Privileged Account - Action Required

Team,

We are responding to a security incident involving a privileged account.

WHAT THIS MEANS FOR YOU
- Some administrative actions may be temporarily restricted
- You may be asked to verify recent activities
- Credential rotation may affect system access

IMMEDIATE ACTIONS
- Do not share details of this incident outside IT
- Report any unusual system behaviour immediately
- Respond promptly to any verification requests

STATUS UPDATES: [Channel/location]

Questions: Contact [Incident Commander name]

User notification (after containment):

Subject: Security Incident Notification and Required Actions

Dear [User],

We are writing to inform you of a security incident that may affect
your account.

WHAT HAPPENED
On [date], we detected unauthorised access to an administrative
account on our systems. We immediately contained the incident and
conducted a thorough investigation.

WHAT INFORMATION WAS INVOLVED
[Specific description of data types potentially accessed]

WHAT WE ARE DOING
- The compromised account has been disabled
- We have rotated credentials across affected systems
- We have implemented additional monitoring

WHAT YOU SHOULD DO
- Change your password at your next login
- Re-enroll your MFA device when prompted
- Report any suspicious activity to IT

QUESTIONS
Contact the IT Service Desk at [contact details]

Evidence preservation

Preserve the following evidence throughout the incident response, maintaining chain of custody documentation for each item.

Chain of custody documentation for each evidence item:

EVIDENCE CHAIN OF CUSTODY

Evidence ID: [unique identifier]
Description: [what this evidence is]
Collection date/time: [timestamp]
Collected by: [name]
Collection method: [tool and process]
Original location: [where collected from]
Hash (SHA-256): [hash value]

Custody transfers:
Date/Time | From | To | Purpose
[entry]   | [name] | [name] | [reason]

See Evidence Collection for detailed evidence collection procedures.

See also

• Account Compromise for standard user account compromise
• Evidence Collection for evidence procedures
• Privileged Access Management for PAM concepts
• Break-Glass Access for emergency access during response
• Data Breach Response if regulated data was accessed
• Incident Triage Matrix for severity classification
• Access Recertification for post-incident access review