respond-compromised-account

name: respond-compromised-account description: "Respond to a potentially compromised user account. Use when impossible travel, credential stuffing, successful phishing, or suspicious activity indicates account compromise. Investigates activity, contains the account, removes persistence, and restores access." required_roles: chronicle: roles/chronicle.editor soar: roles/chronicle.soarAdmin gti: GTI Standard personas: [incident-responder]

Compromised User Account Response Skill

Structured workflow for responding to potentially compromised user accounts using the PICERL model.

Inputs

• USER_ID - Username or email of the potentially compromised user
• CASE_ID - SOAR case ID for documentation
• ALERT_GROUP_IDENTIFIERS - Alert group identifiers from SOAR
• (Optional) INITIAL_ALERT_DETAILS - Summary of triggering alert

Required Outputs

After completing each phase, you MUST report these outputs:

Identification Phase

Containment Phase

Eradication Phase

Recovery Phase

PICERL Phases

Phase 2: Identification

Step 2.1: Get Context

secops-soar.get_case_full_details(case_id=CASE_ID)

Use /check-duplicates.

Step 2.2: Gather Initial Context

SIEM entity lookup:

secops-mcp.lookup_entity(entity_value=USER_ID)

(If IDP tools available):

• Account status
• Recent logins
• MFA configuration
• Password last changed

Step 2.3: Analyze User Activity

Search SIEM for last 96 hours:

secops-mcp.search_security_events(
    text="All activity for USER_ID",
    hours_back=96
)

Look for:

• Anomalous logins: Unusual locations, times, IPs, user agents
• Suspicious commands: On associated endpoints
• Sensitive access: Files, applications, databases
• Lateral movement: Logins to other systems
• Data exfiltration: Large transfers, unusual destinations
• Account changes: MFA, recovery email, forwarding rules
• OAuth grants: New application authorizations

Step 2.4: Check Related Cases

Use /find-relevant-case with [USER_ID].

Step 2.5: Assess Compromise Likelihood

Document: COMPROMISE_LIKELIHOOD

Step 2.6: Document Identification

Use /document-in-case with findings and assessment.

Phase 3: Containment

Step 3.1: Confirm Containment Actions

Based on COMPROMISE_LIKELIHOOD, use /confirm-action:

High/Confirmed:

"Disable account [USER_ID] immediately?"

Medium:

"Reset password and terminate sessions for [USER_ID]?"

Low:

"Force MFA re-enrollment for [USER_ID]?"

Step 3.2: Execute Containment

(Requires Identity Provider tools)

Actions by severity:

• Disable account: Immediate lockout
• Reset password: Force change on next login
• Terminate sessions: Invalidate all active sessions
• Revoke tokens: OAuth and API tokens

Step 3.3: Verify Containment

Monitor for continued activity:

secops-mcp.search_security_events(
    text="Activity from USER_ID after containment",
    hours_back=1
)

Use /document-in-case with containment status.

Phase 4: Eradication

Step 4.1: Investigate Attacker Actions

Thoroughly review what the attacker did while in the account:

secops-mcp.search_security_events(
    text="All actions by USER_ID during compromise window",
    hours_back=96
)

Focus on:

• Emails: Sent, received, forwarding rules created
• Data access: Files downloaded, shared externally
• Configuration: Account settings changed
• OAuth apps: New authorizations
• Lateral movement: Other systems accessed

Step 4.2: Check for Persistence

(Requires email/cloud platform tools)

Look for:

• Email forwarding rules to external addresses
• Delegate access grants
• Malicious OAuth applications
• Inbox rules that hide attacker activity
• Recovery email/phone changes

Step 4.3: Remove Persistence

Delete/revoke all identified persistence:

• Remove forwarding rules
• Revoke OAuth apps
• Remove delegate access
• Reset recovery options

Step 4.4: Endpoint Investigation

If account accessed specific endpoints:

Trigger endpoint triage to check for:

• Malware dropped
• Persistence mechanisms
• Credential caching

Use /document-in-case with eradication findings.

Phase 5: Recovery

Step 5.1: Ensure Threat Removed

Verify:

• All persistence removed
• Associated endpoints clean
• No ongoing attacker access

Step 5.2: Secure Account

• Strong password set
• MFA properly configured (hardware key preferred)
• Recovery options secured
• Review account permissions

Step 5.3: Re-enable Account

(If disabled during containment)

Re-enable with:

• Password change required on first login
• MFA verification required

Step 5.4: Communicate with User

Inform the user:

• What happened (appropriate level of detail)
• Actions taken on their account
• Steps they need to take
• Warning signs to watch for
• How to report suspicious activity

Step 5.5: Monitor Account

Enhanced monitoring for 30 days:

• Watch for anomalous activity
• Alert on unusual logins
• Track sensitive data access

Use /document-in-case with recovery status.

Phase 6: Lessons Learned

Use /generate-report with:

• Initial access vector (if determined)
• Attacker actions during compromise
• Data potentially exposed
• Response timeline
• Recommendations

Review:

• How was compromise detected?
• Was MFA bypassed? How?
• What data was at risk?
• What detections should be added/tuned?

Critical Warnings

• DO NOT execute containment without analyst confirmation
• DO NOT re-enable without checking for persistence
• MUST document all findings in SOAR
• ALWAYS check for forwarding rules and OAuth apps

Containment Decision Matrix

Common Persistence Mechanisms