2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
攻击者从账户中移除多因素认证（MFA）正是你希望捕获的行为。一旦移除了第二重验证因素，被盗的密码就成了全部问题所在。因此，你编写了这样一条规则：当有人调用 DeactivateMFADevice 或 DeleteVirtualMFADevice 时发出警报。
警报触发了。很好。接着它再次触发。然后，每次有员工离职时，它都会触发。
这是因为当你删除用户时，亚马逊云科技（AWS）会为你移除 MFA，而 CloudTrail 会将此清理操作记录为与攻击者生成的事件完全相同的事件。
看似正确的检测逻辑
移除 MFA 直接对应一种真实的技术手段——凭证访问、账户操纵（T1556）。对此发出警报是一个经得起推敲的决定，无需二次审查即可通过审核。这条规则简单得不能再简单：
index=aws sourcetype=aws:cloudtrail eventName IN (DeactivateMFADevice, DeleteVirtualMFADevice)
具体明确。理论上日志量很低。符合攻击矩阵映射。看起来没有任何问题，而这恰恰是问题所在。
AWS 的实际行为机制
你无法删除仍绑定有 MFA 设备的身份和访问管理（IAM）用户。在设备被移除之前，AWS 会拒绝 DeleteUser 调用。因此，删除操作有一个前提条件：先移除 MFA。
无论离职流程是通过控制台、命令行界面（CLI），还是某人两年前编写的 Lambda 函数执行，CloudTrail 记录的序列始终相同：
DeactivateMFADevice （执行者：离职处理角色，目标：jdoe）
DeleteVirtualMFADevice （执行者：离职处理角色，目标：jdoe）
DeleteUser （执行者：离职处理角色，目标：jdoe）
相同的执行者。相同的目标。间隔仅数秒。每一次合法的离职处理都会产生你的“攻击者移除 MFA”规则旨在捕获的确切事件。检测机制无法区分这两种情况，因为根本没有任何区别可言。它们是相同的应用程序接口（API）调用。没有任何阈值、严重性调整或被你忽略的字段能改变这一事实。
为何文档无法拯救你
AWS 逐一记录其 API 调用。DeactivateMFADevice 如其名所示执行操作。DeleteUser 也如其名所示执行操作。但文档并未告诉你的是，后者会作为前提条件触发前者——即删除用户会引发一系列连锁事件，而这些连锁事件中的成员与独立的恶意活动无法区分。
大多数 AWS 检测内容都存在同样的盲点。它们原子化地看待 CloudTrail 事件，针对每个 eventName 设置单一规则。但这里的真相并不存在于任何单个事件中。它存在于这三个事件之间的关系中，而这种关系恰恰是无人记录在案的。
这一点你无法通过阅读学到。只有当你对自己的误报进行分类处理，直到模式变得显而易见时，才能学会。
检测动作，而非副作用
良性案例有一个特征：移除 MFA 后总是紧接着对同一用户执行 DeleteUser。因此，进行关联分析，让良性模式自动抑制警报。
index=aws sourcetype=aws:cloudtrail eventName IN (DeactivateMFADevice, DeleteVirtualMFADevice)
| eval target_user=coalesce('requestParameters.userName', 'requestParameters.serialNumber')
| join type=left target_user
[ search index=aws sourcetype=aws:cloudtrail eventName=DeleteUser earliest=-60m latest=+60m
| eval target_user='requestParameters.userName'
| eval deleted=1
| fields target_user deleted ]
| where isnull(deleted)
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
