攻击者靠规避你的EDR/XDR系统谋生，下文介绍了他们如何在三个关键点绕过或逃避你的防御。
最近的一项全球调查指出，CISO及其企业可能过于依赖端点检测与响应(EDR)和扩展检测与响应(XDR)系统，因为攻击者越来越多地规避了这些系统。
这部分是因为规避EDR/XDR系统一直以来并将继续是现代对手的基本要求。“规避”通常用来描述防御反应未被观察到的情况。虽然技术上准确，但这种缺乏具体性的描述阻碍了网络安全专业人士准确定位补救措施，例如，修复检测逻辑错误与XDR平台中缺少遥测数据的情况大不相同。
为了更好地理解攻击者如何规避EDR/XDR系统，以及更重要的，在发生规避后应该采取什么措施，我们需要了解规避发生的三个领域：观察、检测和响应与预防。
攻击者在观察阶段如何规避XDR
XDR系统的核心是从各种来源(如端点的操作系统或云提供商)获取事件，这些事件通常称为遥测数据，构成了检测的基础。XDR只能检测到系统能够提供和收集的数据，第一种规避类型发生在XDR未收到其需要的事件来检测恶意行为时。
这种规避有几个常见原因，首先，也是我认为最“纯粹”的技术规避，是对手的行动未生成相关的遥测数据，相关是指系统上每个动作都会生成一定量的遥测数据，但这些事件可能对创建有效检测没有用，可以将其视为系统中缺失的事件源，而不是XDR的缺陷。
接下来是系统生成了遥测数据但未被XDR接收的情况，XDR可以订阅数千个事件源，供应商的工作是决定哪些事件源是满足检测需求所必需的，例如，如果XDR供应商特别关注检测与Active Directory相关的行为，他们会优先收集来自AD的事件，而不是网络流量。不收集某些类型的事件，无论是有意为之还是无意为之，都会在XDR对某些技术的覆盖范围内产生可利用的漏洞。
最后，对手可能会主动干扰XDR代理，使事件无法发送到负责收集和关联的集中服务器，这种干扰有多种形式，包括停止或卸载代理、阻止与服务器的通信(例如，通过修改基于主机的防火墙)或篡改传感器(例如，禁用AMSI)。
总体而言，这些问题反映了XDR开发者的失败。如果由于代理程序未收集相关遥测数据而导致攻击被遗漏，供应商是唯一能够解决此问题的实体，因为这涉及添加新的遥测源或扩展/丰富现有的遥测源。在代理程序受到干扰的情况下，供应商应实施防篡改措施，以防止他们能防止的干扰，并检测无法合理防止的干扰。对于每个安全团队来说，这些问题是最难解决的，因为他们实际上除了求助于XDR供应商外别无他法。
攻击者如何在检测过程中规避XDR
当大多数人谈论规避XDR时，他们几乎总是指绕过XDR中的检测逻辑。检测本身只是评估一个事件或一组事件以确定是否存在某些可能表明恶意行为的条件的方式，这些检测查询或规则可以是精确的，意味着它们针对通常对某个恶意软件或攻击工具(例如Mimikatz的命令行参数)独有的特定属性，或者是鲁棒的，意味着它们针对的是多个恶意软件样本或工具共享的行为。
两种类型的检测都有其缺陷。精确检测易于被规避，因为它们通常过于具体，这意味着对目标样本的任何修改都会导致误报，例如，攻击者修改Mimikatz的参数字符串，将“sekurlsa::logonpasswords”变成“nothings::happening_here”，从而打破针对攻击者控制字符串的脆弱检测逻辑。
尽管鲁棒检测表面上看起来不那么容易被规避，但它们因误报而臭名昭著，这会导致规则中的排除项被攻击者利用。一个实际中的例子是，将Chrome更新进程“GoogleUpdate.exe”排除在凭证转储检测之外，因为其正常操作涉及打开本地安全机构子系统服务(LSASS)进程的特权句柄。此排除项允许攻击者冒充更新助手或注入其中以提取凭证而不被检测到，尽管XDR收集的事件中存在所有行为模式。
这些规避手段利用了EDR检测中的逻辑问题，无论这些检测是由供应商提供还是由内部检测工程师编写的。对技术或过程的理解不完善、检测瓶颈、为了使检测在生产环境中可行而做出的妥协以及XDR中次优的遥测数据导致的弱检测逻辑在端点保护领域是司空见惯的。
解决这些问题的方法是弥合这些逻辑差距，但不幸的是，在实际环境中，这并不总是可能的。有时我们必须接受某种程度的脆弱性，以快速生成针对新兴威胁的检测，但这些精确检测应辅以鲁棒检测，以捕捉不可避免的漏报。
鲁棒检测几乎总是需要一定程度的排除项，以避免安全团队被警报淹没，但这些排除项应尽可能少，并不断评估以确定它们是否需要继续存在于生产环境中。实际上，检测工程从检测进入生产环境的那一刻起，就进入了一个永无止境的调整和优化阶段，其唯一目标是使检测尽可能具有弹性，同时保持在团队可以容忍的误报和漏报范围内。
攻击者在响应和预防过程中如何规避XDR
最后一种规避类型集中在当发生真正的正面警报时应进行的调查过程中的漏洞。响应警报的过程因企业而异，但通常包括分诊、调查和响应阶段，这个过程的复杂性带来了许多不同的故障点。
在一个普通的SOC(安全运营中心)工作流程中，规避行为可能发生的第一个机会是在分诊阶段。在此阶段，一名一级分析师收到警报并错误地将其标记为误报，这导致尽管XDR发挥了作用，但该行为仍未被注意到，这种失败可能源于警报疲劳，导致分析师为了减少警报队列而错误地压制警报，或者是因为缺乏对检测目的和信息含义的理解。解决这一失败点通常涉及通过减少误报(如前文所述，减少误报本身也存在问题)来进行队列和疲劳管理，以及通过更好的文档和教育来提升分析师对检测的理解。
接下来是调查阶段，该阶段发生在确认真正的正面警报之后，涉及次级信息收集，以更具体地确定警报是否值得升级为全面事件，这个过程通常是手动的，需要熟练的分析师对相关系统进行质询并提取支持信息，例如文件系统上遗留的痕迹信息。
在这里，有很多与调查人员的技能和对手有关的失败点。如果分析师需要检查磁盘上的文件，但对手已预先将其删除怎么办?如果需要内存取证，但对手已重启系统怎么办?如果对手采用了调查人员不熟悉的技术，导致他们遗漏了攻击者留下的痕迹怎么办?解决这些失败点需要强有力的支持文档，例如在怀疑有真正正面警报时应收集什么信息以及这些信息的含义。
最后是响应阶段，这发生在警报被确认为真正正面并宣布为事件之后，涉及驱逐威胁行为者。在确定事件范围(涉及多少系统、用户等)之后，安全团队有多种清除攻击者的选项，从简单地重启主机以清除驻留在内存中的恶意软件，到像销毁整个环境这样极端的措施。在这个阶段，成功是二元的——要么完全驱逐对手，要么没有。
我在红队工作时遇到的这个阶段最大的错误是防御团队错误地确定了事件范围，导致驱逐不完全，使我们在环境中持续存在了近18个月(我们最终被踢出是因为我们驻留的服务器被他们的IT团队在技术生命周期升级过程中退役)。改进响应过程以减少对手规避驱逐的机会归结于拥有经过演练的可靠流程、识别妥协范围的能力以及验证对手完全根除的能力。
文档
详细描述XDR规避行为使我们能够更好地识别检测管道中的哪个组件失效，更重要的是，我们可以采取什么措施来修复它。大多数规避行为可以分为观察(XDR是否发现了恶意行为)、检测(XDR是否将行为正确识别为恶意)或响应(该行为是否导致安全团队采取了适当的响应)。在下次遇到规避行为时，推动使用更具描述性的语言，并看看可以对你的补救过程进行哪些改进。
