‹ 首页

respond-compromised-account

@dandye · 收录于 5 天前 · 上游提交 3 个月前

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.

适合你,如果发现用户账号有异常活动需要立即处理

/ 通过 npx 安装 校验哈希
npx oh-my-skill add dandye/ai-runbooks/respond-compromised-account
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- dandye/ai-runbooks/respond-compromised-account
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify dandye/ai-runbooks/respond-compromised-account
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
119GitHub stars
~1.4K上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 086cbf6 · 表述以原文为准
它做什么

安装后,Claude 会按照 PICERL 模型处理用户账户泄露事件:调查可疑活动、遏制账户、移除攻击者留下的持久化机制,最后恢复账户安全。

什么时候触发

当用户报告账户可能被盗,或出现异常登录、撞库攻击、钓鱼成功等迹象时触发。

装好后可以这样说
启动完整的泄露响应流程。
执行识别与清除阶段。
技能原文 SKILL.md作者撰写 · Apache-2.0 · 086cbf6

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

| Output | Description | |--------|-------------| | AFFECTED_ACCOUNTS | User accounts confirmed or suspected compromised | | SUSPICIOUS_ACTIVITY | Summary of anomalous activity detected | | ACCESS_SCOPE | Systems/data the account had access to | | COMPROMISE_LIKELIHOOD | Assessment level: Low, Medium, High, Confirmed |

Containment Phase

| Output | Description | |--------|-------------| | DISABLED_ACCOUNTS | Accounts that were disabled | | RESET_PASSWORDS | Accounts with passwords reset | | REVOKED_SESSIONS | Sessions terminated |

Eradication Phase

| Output | Description | |--------|-------------| | REMOVED_PERSISTENCE | Persistence mechanisms removed (forwarding rules, OAuth apps, etc.) | | CLEANED_ENDPOINTS | Associated endpoints verified clean |

Recovery Phase

| Output | Description | |--------|-------------| | RESTORED_ACCOUNTS | Accounts re-enabled with new security controls | | USER_NOTIFICATIONS | Users notified of incident and required actions |

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

| Level | Indicators | |-------|------------| | Low | Single anomalous event, user confirms legitimate | | Medium | Multiple anomalies, unverified | | High | Clear malicious activity patterns | | Confirmed | Known credential theft, attacker actions visible |

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

| Likelihood | Disable Account | Reset Password | Terminate Sessions | |------------|-----------------|----------------|-------------------| | Confirmed | ✅ Immediate | ✅ | ✅ | | High | ✅ Recommended | ✅ | ✅ | | Medium | Consider | ✅ | ✅ | | Low | No | Consider | Consider |

Common Persistence Mechanisms

| Mechanism | Where to Check | |-----------|----------------| | Email forwarding | Mail rules | | Delegate access | Mailbox permissions | | OAuth apps | Connected applications | | Inbox rules | Mail filters | | Recovery options | Account settings | | API tokens | Developer settings |

按 Apache-2.0 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。