chinemerem-nsv/Incident-response-threat-hunting-investigation

GitHub: chinemerem-nsv/Incident-response-threat-hunting-investigation

针对金融科技环境的多阶段入侵事件进行应急响应与威胁狩猎调查的完整案例分析项目。

Stars: 0 | Forks: 0

# 针对尼日利亚金融科技客户的应急响应与威胁狩猎调查 ![平台](https://img.shields.io/badge/Platform-Linux-blue?style=flat-square) ![领域](https://img.shields.io/badge/Discipline-Incident%20Response-red?style=flat-square) ![环境](https://img.shields.io/badge/Environment-SIEM%20%7C%20Threat%20Hunting%20%7C%20OSINT-darkgreen?style=flat-square) ![工具](https://img.shields.io/badge/Tools-SIEM%20%7C%20VirusTotal%20%7C%20Cisco%20Talos%20%7C%20urlscan.io-orange?style=flat-square) ![状态](https://img.shields.io/badge/Project-Completed-success?style=flat-square) ## 项目概述 本仓库记录了针对尼日利亚金融科技环境进行的一次应急响应与威胁狩猎调查。 本次调查的重点是通过安全遥测分析、SIEM 告警调查、威胁情报验证以及基于证据的事件报告,来重构攻击者的活动。 分析工作涉及将身份验证日志、安全工单历史记录、人事记录和系统构件进行关联,以识别多阶段入侵的演变过程,包括未经授权的访问、权限维持活动、数据暂存以及潜在的数据外发。 调查使用了威胁情报源来验证可疑的外部基础设施,并围绕攻击者的活动提供额外的背景信息。 ## 展示的技能 - 应急响应 - 威胁狩猎 - SIEM 分析 - 日志关联 - 威胁情报与 OSINT - 时间线重构 - MITRE ATT&CK 映射 - 根本原因分析 - 风险评估 - 安全报告 - 安全运营中心 (SOC) - 安全治理与合规 ## 调查目标 本次调查的主要目标是: - 验证安全告警时间线和监控有效性。 - 识别遭到入侵的账户和受影响的系统。 - 调查可疑的身份验证活动。 - 分析 SIEM 工作流中潜在的告警压制行为。 - 追踪未经授权的数据暂存和出站传输活动。 - 识别权限维持机制和访问控制弱点。 - 评估业务影响和安全控制失效情况。 - 提出遏制和修复建议。 ## 调查环境 | 类别 | 详情 | |-----------|---------| | 环境类型 | 生产服务器 (基于 Linux) | | 操作系统 | Ubuntu Server | | 系统角色 | 金融科技生产环境中的核心应用服务器 | | 调查类型 | 应急响应与威胁狩猎 | | 分析平台 | 安全信息与事件管理 (SIEM) | | 主要数据源 | 身份验证日志、安全工单系统、系统构件、人事记录 | | 威胁情报来源 | VirusTotal, Cisco Talos Intelligence, urlscan.io | | 网络关注区域 | SSH 身份验证活动、SCP 文件传输、进程执行监控、告警分诊日志 | ## 日志与遥测范围 本次调查使用了从生产基础设施聚合的集中式 SIEM 遥测数据。 关键的日志来源包括: - 身份验证事件 - 提权尝试 - 出站网络连接记录 - 进程执行活动 - 安全工单历史记录 我们还从系统级构件和操作记录中收集了额外的上下文信息,以重构攻击者在入侵多个阶段中的活动。 ## 证据来源 本次调查使用了多种证据来源,包括: - 身份验证和访问日志 - SIEM 告警历史 - 安全工单记录 - 人员排班和休假记录 - 系统配置构件 - 公开威胁情报库 根据项目共享指南,本仓库不包含原始的证据文件。 ## 威胁情报验证 在日志分析过程中识别出的可疑基础设施通过公开的威胁情报源进行了验证: - VirusTotal - Cisco Talos Intelligence - urlscan.io 使用这些资源旨在: - 评估 IP 信誉 - 识别网络所有者信息 - 验证可疑基础设施 - 为调查期间观察到的外部连接提供额外背景 ## 调查发现 ### 调查方法 本次调查通过关联多种安全证据来源进行,包括身份验证日志、SIEM 告警、安全工单记录、人事信息和系统构件。 分析的重点在于识别各个独立安全事件之间的关系,并确定它们是孤立的活动,还是协同攻击序列的一部分。 调查确定了以下演变过程: - 外部侦察和暴力破解身份验证尝试 - 使用受损凭证成功访问 - 未经授权的系统级活动 - 本地数据暂存 - 出站数据传输活动 我们对可疑基础设施进行了威胁情报验证,以提供额外的背景信息并确定外部指标的可信度。 ## 置信度级别定义 ### 高置信度 当多个独立的证据来源确认存在恶意或未经授权的活动时应用。 ### 中置信度 当活动高度可疑但需要进一步调查或支持性证据时应用。 ### 低置信度 当活动显得异常但可能有合理的正当解释时应用。 # 取证证据摘要 | # | 时间戳 (UTC) | 来源 | 用户 / 账户 | 事件类型 | 描述 | 证据参考 | 置信度 | |---|-----------------|--------|----------------|------------|-------------|--------------|------------| | 1 | 2024-06-01 11:14:00 | 45.95.147.12 | root | 身份验证失败 | 针对特权访问的多次 SSH 身份验证失败尝试。 | TICKET-A | 高 | | 2 | 2024-06-03 02:22:00 | 45.95.147.12 | admin / oracle / postgres | 身份验证尝试 | 针对多个服务账户的重复暴力破解活动。 | TICKET-B | 高 | | 3 | 2024-06-03 21:48:00 | 生产服务器 | 运维经理 | 身份验证事件 | 用户报告了不规则的 SSH 身份验证行为。 | TICKET-C | 中 | | 4 | 2024-06-04 02:07:00 | 185.220.101.9 | 运维经理 | 身份验证成功 | 观察到来自外部网络源的成功 SSH 身份验证。 | TICKET-D | 高 | | 5 | 2024-06-04 02:12:00 | 生产服务器 | 运维经理 | 系统活动 | 在预期维护窗口之外观察到手动重新加载 cron 守护进程。 | TICKET-E | 高 | | 6 | 2024-06-04 02:14:31 | 生产服务器 | 运维经理 | 文件系统活动 | 在临时目录中创建了包含敏感数据集的归档文件。 | TICKET-F | 高 | | 7 | 2024-06-04 02:31:51 | 生产服务器 | 运维经理 | 网络活动 | 向外部基础设施发起了出站 SCP 传输。 | TICKET-G | 高 | | 8 | 2024-06-05 03:14:00 | 185.220.101.9 | 运维经理 | 身份验证成功 | 使用相同的凭证配置文件进行重复的外部身份验证。 | TICKET-H | 高 | | 9 | 2024-06-05 23:45:00 | 网络网关 | 运维经理 | 进程执行 | 在生产服务器环境中观察到浏览器进程。 | TICKET-I | 高 | | 10 | 2024-06-06 11:31:00 | 网络网关 | 离职员工账户 | 身份验证事件 | 观察到目录服务中仍然存在的已停用账户有活动。 | TICKET-J | 高 | # 根本原因分析 ## 主要根本原因 事件的主要原因是访问控制执行不力,加之身份生命周期管理薄弱,使得有效但已遭泄露的凭证被用于对生产基础设施进行未经授权的访问。 ## 技术分解 攻击链经历了以下几个阶段: 1. 针对暴露的身份验证服务进行外部侦察和暴力破解尝试。 2. 使用有效凭证从外部网络源成功进行身份验证。 3. 在生产基础设施上执行未经授权的系统级命令。 4. 在临时文件系统目录中进行本地数据暂存。 5. 通过出站安全文件传输泄露敏感数据集。 ## 识别出的控制失效 ### 身份与访问管理 - 延迟停用非活动或过渡期的用户账户。 - 凭证轮换策略执行不力。 - 缺乏对异常登录上下文的实时验证。 ### 监控与检测 - 未能将多个日志来源中的相关告警进行关联。 - 对生产系统上异常进程执行的检测有限。 - 特权账户的会话级可见性不完整。 ### 运营安全 - 在告警分诊工作流程中缺乏严格的职责分离。 - 对反复出现的高置信度指标的上报不一致。 - 在非工作时间身份验证活动的验证方面存在漏洞。 ## 根本原因总结 此次事件的发生得益于身份治理薄弱与告警关联不足的结合,使得攻击者能够在不触发协同事件升级的情况下,在多阶段入侵中使用有效凭证。 # 告警压制分析 ## 概述 对 SIEM 工单活动的审查发现,在多个高危事件中存在告警处理不一致的情况。 几个与相同源指标相关的告警在没有进行全面调查或针对事件时间线进行关联的情况下,被关闭、降级或链接到了现有工单。 ## 观察到的行为模式 - 高危身份验证和网络告警经常作为重复项被关闭,而没有进行关联分析。 - 源自相同外部 IP 的多个事件被视为孤立事件处理。 - 几个告警在未验证权限维持或横向移动的情况下,使用自动防护参考进行了解决。 - 使用跨工单链接代替了完整的事件重构。 ## 对事件可见性的影响 这些处理模式导致整个攻击链的可见性变得碎片化。 构成更大规模入侵组成部分的独立事件被单独审查,阻碍了对协同恶意活动的检测。 身份验证、进程执行和数据传输事件之间缺乏关联,降低了 SIEM 的检测有效性。 ## 促成因素 - 缺乏强制执行的 SIEM 关联规则。 - 告警生成与关闭之间缺乏职责分离。 - 过度依赖自动压制和去重逻辑。 - 对反复出现的高置信度指标缺乏充分的上报触发机制。 ## 总结 告警管理过程允许将相关的安全事件视为独立事件处理,而不是协同入侵序列的组成部分,从而降低了整体的检测保真度。 ## 遏制事件 当安全领导层审查与生产环境相关的活动时,观察到短时间内出现了异常集中的安全事件,从而识别出了此次事件。 进一步的调查将这些事件与早期的暴力破解活动进行了关联,并确认这是一起多阶段入侵,涉及未经授权的访问、系统修改、数据暂存和出站传输活动。 受影响的系统被隔离,断绝了外部网络访问,受损的凭证被识别以进行修复,并启动了事件遏制程序。 # 业务影响评估 ## 确认的影响 ### 受影响的资产 分析发现,客户和交易数据集遭到了未经授权的访问,这些数据集已从生产服务器暂存并传输出去。 ### 对手活动 威胁情报分析将侦察活动与随后的访问(通过外部匿名网络发起)发生之前的出现的可疑扫描基础设施联系了起来。 ### 安全控制失效 调查发现了以下控制弱点: - 账户监控不足 - 访问审查程序薄弱 - 凭证吊销延迟 - 缺乏告警审查的职责分离 - 升级控制不足 # 框架对齐 ## NIST 网络安全框架 | 功能 | 类别 | |----------|----------| | PR.AC | 身份管理与访问控制 | | DE.CM | 安全持续监控 | | RS.AN | 事件分析 | ## ISO/IEC 27001 相关控制领域: - 用户访问管理 - 访问审查程序 - 特权访问控制 ## MITRE ATT&CK 映射 | 技术 | ID | |-----------|----| | 暴力破解 | T1110 | | 有效账户 | T1078.003 | | 削弱防御 | T1562.001 | # 关键要点 - 有效的应急响应依赖于跨多个数据源进行正确的告警关联,而不是孤立地审查事件。 - 薄弱的身份生命周期管理会显著增加基于凭证攻击的暴露面。 - 有效账户被盗用仍然是企业环境中最有效的初始访问媒介之一。 - 当告警分诊流程缺乏强制执行的职责分离时,SIEM 的有效性会降低。 - 威胁情报验证通过确认外部基础设施的信誉和背景,加强了内部调查。 - 多阶段攻击通常表现为低危、不相关的事件,除非随着时间的推移进行正确的关联。 - 及时的遏制和升级对于限制数据暴露和运营影响至关重要。 # 72 小时修复计划 ## 目标 遏制事件、消除权限维持机制、恢复安全的身份验证完整性,并加强整个生产基础设施的检测和响应能力。 ## 阶段 1:立即遏制(0–12 小时) ### 行动 - 隔离受影响的生产服务器,断绝外部网络访问。 - 在边界防火墙拦截已识别的恶意源 IP 地址。 - 禁用或挂起受影响的用户会话和凭证。 - 保留易失性和非易失性取证证据以供调查。 ### 负责人 基础设施与安全运营团队 ## 阶段 2:凭证与身份修复(12–24 小时) ### 行动 - 吊销并轮换所有特权账户凭证。 - 强制在生产系统中重新生成 SSH 密钥。 - 审计所有活动用户账户以查找未经授权的权限维持。 - 禁用非活动或过渡期账户,等待验证。 ### 负责人 身份与访问管理 (IAM) 团队 ## 阶段 3:系统强化与检测改进(24–72 小时) ### 行动 - 针对反复出现的身份验证失败实施自动拦截。 - 启用用于多阶段攻击检测的 SIEM 关联规则。 - 审查并更新高危事件的告警升级阈值。 - 强制执行告警检测与关闭之间的职责分离。 ### 负责人 安全工程与 SOC 团队 ## 阶段 4:事件后验证 ### 行动 - 对受影响的系统进行全面的取证审查。 - 验证没有存活的权限维持机制。 - 确认身份验证和日志系统的完整性。 - 出具最终的事件报告以供合规和审计审查。 ## 预期结果 成功执行此修复计划将恢复系统完整性,消除未经授权的访问媒介,并提高对未来入侵尝试的检测覆盖率。 # 职业道德与事件升级 ## 场景评估 在调查期间,在历史记录中识别出的与威胁行为者相关的指标在先前的安全事件中被发现,而这些事件此前并未得到充分的审查。 调查结果表明,在早期的调查中可能忽略了一些可疑活动,从而给组织带来了额外的风险。 ## 建议的应对措施 - 保留所有相关证据。 - 记录调查结果。 - 提交书面风险评估。 - 遵循既定的升级程序。 - 保持客观的、基于证据的报告。 ## 职业责任 这种方法支持保护组织资产、维护公众信任以及适当管理网络安全风险。 如果修复工作被延误或调查结果被忽视,应继续通过适当的管理和合规渠道进行升级上报。 # 改进建议 以下改进将加强检测、响应和整体的安全态势: - 实施自动化的 SIEM 关联规则,将相关的身份验证、进程和网络事件组合到统一的事件案例中。 - 在告警生成、分诊和关闭之间实施严格的职责分离,以防止对事件的压制或过早解决。 - 引入对特权账户活动的实时异常检测,特别是非工作时间的身份验证和不寻常的网络位置。 - 加强身份生命周期管理,立即停用非活动或过渡期的账户。 - 增强日志覆盖范围,以包含生产系统中特权用户的完整会话可见性。 - 针对源自相同基础设施的反复出现的高置信度指标,部署自动告警升级阈值。 - 将威胁情报源直接集成到 SIEM 关联逻辑中,以实现更快的富化和上下文感知告警。 ## 免责声明 本仓库包含的网络安全应急响应和威胁狩猎调查的净化版本,是出于培训和作品集演示目的而完成的。 根据项目共享指南,所有个人身份信息 (PII)、用户身份、工单参考、主机名和组织特定详细信息均已被删除或替换为通用标签。 保留技术发现、方法论和修复建议是为了展示在以下方面的实践技能: - 应急响应 - 威胁狩猎 - SIEM 分析 - 日志调查 - 威胁情报 - 安全报告 本仓库不包含任何机密数据集、平台截图、证据文件或标志 (flags)。 本仓库中展示的调查结果是通过对作为案例研究一部分提供的身份验证日志、SIEM 工单历史记录、人事记录和支持性系统构件进行分析而得出的。由于根据案例研究的共享指南未授权进行公开重新分发,因此已省略了原始的证据文件。
标签:SIEM分析, 威胁情报, 子域枚举, 安全运营, 库, 应急响应, 开发者工具, 扫描框架