diff --git a/data.json b/data.json index 73523437..86fc3e62 100644 --- a/data.json +++ b/data.json @@ -19799,5 +19799,9 @@ "https://mp.weixin.qq.com/s/DQX6I-a5-DvEQIOaDdRLFA": "【工业控制系统网络安全系列课程】第2课-工业控制系统的网络安全风险-过程控制漏洞利用（三）漏洞利用技术详解", "https://mp.weixin.qq.com/s/GfMl2I7h0Rgou8U1V2rzXw": "AI路由漏洞可被利用注入恶意代码并窃取敏感数据", "https://mp.weixin.qq.com/s/pgtf9R-smm085Jsi3BwbZA": "Storm-1175 高频勒索攻击全链路：从 N-day 漏洞到 Medusa 部署最快仅 24 小时", - "https://mp.weixin.qq.com/s/lV3b77o9XjT7PPADKpWy7A": "【工业控制系统网络安全系列课程】第2课-工业控制系统的网络安全风险-过程控制漏洞利用（四）真实案例分析" + "https://mp.weixin.qq.com/s/lV3b77o9XjT7PPADKpWy7A": "【工业控制系统网络安全系列课程】第2课-工业控制系统的网络安全风险-过程控制漏洞利用（四）真实案例分析", + "https://mp.weixin.qq.com/s/PD2sUcj3NQytfBpAdC67aA": "又一个Confluence倒下了：CVE-2023-22527漏洞导致ELPACO-team勒索软件入侵", + "https://mp.weixin.qq.com/s/z-475KDrSnw4tS1-ev7IFA": "工具推荐 | 快速探测可能存在SQL注入漏洞", + "https://mp.weixin.qq.com/s/7vwpX9F3fNcS8ux-JJ_cUA": "规模化 SAST & SCA 漏洞修复", + "https://mp.weixin.qq.com/s/UDf_TeEs0AhRbHzd2J6bDQ": "AI驱动漏洞海啸来袭：修复窗口从数周压缩到数小时" } \ No newline at end of file diff --git a/doc/2026-04/AI驱动漏洞海啸来袭：修复窗口从数周压缩到数小时.md b/doc/2026-04/AI驱动漏洞海啸来袭：修复窗口从数周压缩到数小时.md new file mode 100644 index 00000000..d6ee3bfc --- /dev/null +++ b/doc/2026-04/AI驱动漏洞海啸来袭：修复窗口从数周压缩到数小时.md @@ -0,0 +1,86 @@ +# AI驱动漏洞海啸来袭：修复窗口从数周压缩到数小时 +bitbot + bitbot Desync InfoSec 2026-04-12 15:51 + +2026年4月，Anthropic 发布了代号为 **Project Glasswing** 的前沿 AI 模型 **Mythos**——它能够以前所未有的深度和速度自主发现并利用生产软件中的漏洞，这种能力此前只有经验丰富的人类安全研究员才具备。这一突破意味着：一场漏洞披露的海啸即将到来，而修复窗口已被压缩到极致。 + +──────────────── + +新威胁格局：Mythos 改变了什么 + +Qualys 漏洞风险与修复管理领域的资深专家 Shailesh Athalye 指出，漏洞披露和修复周期的每个环节都在发生根本性变化。大型软件厂商现在已获得 Mythos 的访问权限，**结果是：在本已不堪重负的积压基础上，将涌现大量厂商安全公告、补丁和 CVE 披露。** + +漏洞管理的真正难题在于"发现之后"：在你的具体环境中，哪些发现代表了真正的、可被利用的风险——考虑到你的缓解控制措施以及最关键的业务服务——并在攻击者行动之前将其关闭。 + +**任何工具发现的漏洞并不自动等于你环境中的风险。**一个被 WAF 完全阻断攻击向量的关键漏洞不是你的紧急问题；而一个暴露在公网、未打补丁、且已有在野利用代码的中危漏洞才是。"漏洞被发现"与"环境中真实风险"之间的差距，正是大多数修复资源被浪费的地方。 + +──────────────── + +正在发生的变化：漏洞海啸与关闭的利用窗口 + +大多数安全团队已背负大量已知未修复暴露——不是因为疏忽，而是因为**漏洞数量一直远超修复能力**。现在叠加两个因素： + +**1. 利用时间线已提前至"负一天"：**Mandiant 2024 年数据显示，攻击者在补丁发布之前就已经完成武器化。攻击者部署 agentic AI 自动化侦察和漏洞利用开发，从披露到实际利用的窗口已从数周压缩到数小时。 + +**2. 修复窗口的残酷算术：** + +攻击者平均在 **17 天**内利用暴露的风险，且这个时间还在缩短。行业平均修复时间为 **37+ 天**。这意味着存在 **20+ 天**的已知、已确认、开放暴露窗口。AI 辅助发现只会加速新披露涌入队列，却无法从输出端缩小这个窗口。 + +──────────────── + +如何适应：告别"仪表盘旅游"，以机器速度运营 + +每个组织都有类似场景：安全仪表盘在各团队间分享、审查、交接。**当利用窗口压缩到以小时计，花在审查和讨论风险上的每一分钟，都是暴露仍然开放的时间。**检测工具、优先级工具、工单系统、IT 团队、变更管理之间的每一次交接都是延迟。工具孤岛之间的缝隙，就是风险栖身之所。 + +**残酷真相：如果一切都是"严重"，那就等于什么都不是！**唯一可行的响应是真正基于上下文的优先级排序——不是理论性的 CVSS 评分，而是你的环境中哪些是可被利用的、针对你的资产、考虑你的补偿控制措施。**业务上下文不是可选项，它是管理真实风险与统计理论漏洞之间的分界线。** + +**唯一重要的指标：平均暴露窗口（AWE）**不再是合规导向的 MTTR、30 天 SLA、补丁数量——这些是为"你有时间慢慢来"的世界设计的。在利用时间线以小时衡量的环境中，唯一映射到真实风险降低的指标是：**从一个已确认可利用的暴露进入环境到经过验证的关闭之间的时间。**这是大多数组织目前无法测量的。 + +──────────────── + +手动修复已死：构建信任基础设施 + +"自主修复"在安全运营中引发的怀疑几乎超过任何其他概念。安全团队被自动补丁搞崩过生产环境，被"自动部署"制造过比漏洞本身更严重的事故。这种怀疑是有道理的。 + +但另一面的事实同样残酷：**在当前环境下，手动修复的速度在运营上已不可持续。**每个修复步骤的人在环路——审批、排期、部署、验证——都是结构性瓶颈。答案不是消除人类判断，而是构建让自主操作足够安全的**信任基础设施**。 + +**需要三件事：** + +**① 先验证再修复：**在生产环境中用攻击者的真实手法验证漏洞可利用性——二元答案：可利用或不可利用，不是"可能"。Qualys 威胁研究单元（TRU）发现，**理论上存在风险的暴露中，经过确认验证的不到 1%**，这些才是 P0 级必须修复的。 + +**② 补丁之外的选择：**补丁并非总能立即部署——生产窗口、遗留系统、运营约束都是现实。关键是投资策略和控制改进：为 EDR、WAF、防火墙、CSPM 编写自定义规则，在补丁尚不可用时争取保护时间。从缓解到虚拟补丁、WAF 规则、主机隔离、服务禁用、补偿控制——全谱系适应性修复。 + +**③ 信任来自运营证据，而非承诺：**自主修复不是凭信心部署的功能。它需要通过累积证据来赢得——基于 AI 的补丁可靠性评分（训练数据来自 **1.5 亿+** 已部署补丁）、波次部署架构（每一轮建立信心后再推进下一步）、以及系统行为异常时触发的自动回滚。 + +**信任等式：**搞崩生产的自主修复不是修复，而是事故。通往机器速度修复的道路经过信任架构，而非单纯追求速度。你通过证明"可以安全运行"来赢得"更快运行"的权利。 + +──────────────── + +自研软件不豁免：将检测扩展到你的应用 + +大多数关注集中在第三方商业软件上。但每个企业还运行着自定义应用——内部工具、专有 API、关键业务服务——这些也将越来越多地通过 AI 辅助研究暴露漏洞。关键洞察很简单：**漏洞如何被发现不重要，重要的是你能否在运行环境中检测它、验证可利用性，并以与第三方 CVE 相同的速度关闭它。** + +这就是为什么需要**风险运营中心（ROC）**——以 AI 速度运营你的风险管理程序，停止"打地鼠"式的漏洞管理。 + +──────────────── + +关键数据一览 +
指标数值
攻击者利用平均时间17 天（且在缩短）
行业平均修复时间37+ 天
暴露窗口20+ 天
经确认验证的暴露比例<1%
自主补丁部署 + 回滚率40+ 次 / <0.1%
勒索软件/KEV 暴露修复时间<15 分钟
+──────────────── + +底线：未来 12 个月的决定性挑战 + +AI 辅助研究加速了漏洞发现，却对后续环节毫无帮助。成功穿越这个时代的组织做四件事： + +• **基于上下文而非评分排序：**CVSS 衡量理论全球严重性，有效排序意味着你的环境——你的资产、你行业的威胁行为者、暴露面的毒性组合、缓解控制和业务上下文 + +• **终结"仪表盘旅游"：**压缩从检测到确认关闭的循环，审查和协调的时间就是暴露仍然开放的时间 + +• **通过证据建立对自主修复的信任：**AI 可靠性评分、分阶段波次部署、自动回滚 + +• **证明风险已关闭，而非已打补丁：**用暴露前后的平均暴露窗口（AWE）取代补丁数量指标 + +**人类速度的漏洞管理时代已经结束。问题在于：你能多快采纳并信任自主修复？** + +来源：Qualys Security Blog | 作者：Shailesh Athalye原文：The Mythos Inflection Point: Dealing With the Upcoming Vulnerability Disclosure Avalanche and Compressed Exploitation Window发表日期：2026-04-10 + diff --git a/doc/2026-04/又一个Confluence倒下了：CVE-2023-22527漏洞导致ELPACO-team勒索软件入侵.md b/doc/2026-04/又一个Confluence倒下了：CVE-2023-22527漏洞导致ELPACO-team勒索软件入侵.md new file mode 100644 index 00000000..9136dbc2 --- /dev/null +++ b/doc/2026-04/又一个Confluence倒下了：CVE-2023-22527漏洞导致ELPACO-team勒索软件入侵.md @@ -0,0 +1,165 @@ +# 又一个Confluence倒下了：CVE-2023-22527漏洞导致ELPACO-team勒索软件入侵 +bitbot + bitbot Desync InfoSec 2026-04-12 15:51 + +又一个 Confluence 服务器倒下了：CVE-2023-22527 漏洞导致 ELPACO-team 勒索软件入侵 + +来源：The DFIR Report ｜ 编译：比特波特 + +──────────────── + +2024 年 6 月，一台未打补丁的 Atlassian Confluence 服务器通过 **CVE-2023-22527** 模板注入漏洞被攻破。攻击者从初始入侵到部署 **ELPACO-team** 勒索软件（Mimic 变种），整个过程仅耗时 **约 62 小时**。本文详细剖析了这条完整的攻击链。 + +**核心要点：** +• 初始入口：CVE-2023-22527 Confluence 模板注入漏洞 +• 攻击工具：Metasploit/Meterpreter、AnyDesk、Mimikatz、ProcessHacker、Impacket +• 横向移动：Impacket wmiexec + RDP +• 最终载荷：ELPACO-team.exe（Mimic 勒索软件变种） +• 攻击时长：约 62 小时完成完整入侵链 + + +──────────────── + +一、初始入口：CVE-2023-22527 漏洞利用 + +入侵始于 2024 年 6 月，攻击者利用 **CVE-2023-22527**（Atlassian Confluence 模板注入漏洞）攻击一台暴露在公网的 Confluence 服务器。该漏洞允许远程代码执行，Suricata 检测到以下告警规则： + + +ET EXPLOIT Atlassian Confluence RCE Attempt Observed (CVE-2023-22527) M2 (sid 2050543) + + +服务器日志显示，在数月内有大量来自不同 IP 地址的漏洞扫描尝试，最常见的命令是 **whoami**。真正的入侵从 IP 地址 **91.191.209[.]46** 开始，攻击者通过漏洞执行 curl 命令下载 Metasploit 载荷（Meterpreter），建立了与 C2 服务器的通信通道。 +![](https://mmbiz.qpic.cn/sz_mmbiz_png/PO9bjOzlHYCYE5OV6ia7jq96d1xccicCWpasicWbuvsMBOK4xQdmkYbia8z9OGhANYeH8Tc6Tha9npcxIhic5CTgslwMnUsqV5ricdFrIJQWBfPRk/640?wx_fmt=png "") + +图：PCAP 显示 CVE-2023-22527 漏洞利用的网络流量 + +下载的可执行文件 **HAHLGiDDb.exe** 被保存到可疑路径： +C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\ + +该文件仅导入了 **VirtualAlloc** 和 **ExitProcess** 两个 Windows API 函数，逆向分析确认它是一个 64 位 Metasploit shellcode 加载器，使用哈希混淆动态解析所需函数，并尝试将 Meterpreter DLL 注入其他进程。 +![](https://mmbiz.qpic.cn/mmbiz_png/PO9bjOzlHYD828FUOzVOqNcuxkxiaib2ibsiaGkyVZQ162XhrmAVOUVwVZX9gug2DF4MmfibZAyQ4DFeOUwhnZesbibyvGDLL9sOqYnibEu5Vwof60/640?wx_fmt=png "") + +图：HAHLGiDDb.exe 反汇编指令显示 Metasploit 加载器模式 + +──────────────── + +二、执行：Metasploit 载荷链 + +Metasploit 加载器 HAHLGiDDb.exe 连接到 **91.191.209[.]46:12385** 下载第二阶段载荷。下载的 PE 文件是一个 64 位 Windows DLL，只有 DllMain 导出函数（这对合法 DLL 来说极不寻常）。 + +在整个入侵过程中，攻击者 **三次** 通过 Confluence 漏洞投递 Metasploit 载荷，每次使用的 EXE 和 DLL 文件名都是随机生成的。加载器会释放随机命名的 DLL 文件到磁盘，同时创建同名管道（去掉 .dll 扩展名），这是一个非常鲜明的特征： +
DLL 文件路径管道名
nbjlop.dll\\nbjlop
npixmw.dll\\npixmw
cjlodi.dll\\cjlodi
wucnic.dll\\wucnic
+**检测提示：**可以通过威胁狩猎查询将 DLL 文件创建事件与管道创建事件关联——匹配去掉扩展名的 DLL 文件名和去掉反斜杠的管道名称，可以精准识别 Metasploit 活动。 + + +──────────────── + +三、持久化：AnyDesk 与用户账户 + +攻击者在入侵第一天就执行了一系列自动化操作，强烈暗示使用了 **自动化脚本或 Playbook**： + +**1. 创建本地管理员账户** +通过批处理文件 +u1.bat 创建用户 **"noname"**，密码 **"Slepoy_123"**，加入 Administrators 组，设置密码永不过期。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/PO9bjOzlHYDWQSTsaX2XUicwiaicXYrC1eHn38xPicsla0YMAZAbAFdsIryFuXOALINNxoA2CziasZqialNm4ykuIWgrNBQLVPkrk0JicEgFOE7jRo/640?wx_fmt=png "") + +图：u1.bat 批处理文件内容——创建用户并提权 + +**2. 安装 AnyDesk 服务** +攻击者将 AnyDesk.exe 下载到 Confluence 安装目录，然后以服务方式安装。设置无人值守访问密码为 **"P@ssword1"**，并通过 +ANYDESK.EXE --GET-ID 获取连接 ID。这一安装过程在入侵期间重复了三次。 + + +**3. Spider.dll — 与 BlackBasta/FIN7 的关联** +攻击者第三天通过 AnyDesk 会话传输了一个名为 "Attacker" 的文件夹，其中包含 **spider.dll** 和 spider_32.dll。逆向分析揭示 spider.dll 内嵌硬编码凭据 **"Crackenn"** / **"*aaa111Cracke"**，通过 NetUserAdd API 创建用户并加入管理员和远程桌面用户组。该凭据组合与 SentinelOne 此前披露的 **BlackBasta 勒索软件关联 FIN7 威胁组织** 的攻击工具一致。 + +![](https://mmbiz.qpic.cn/mmbiz_png/PO9bjOzlHYDQHc2rH4ZVdr800VgxHeCFSeSxuXibkic3p5icECNgBLzbLQm3hTZBxNkI7lEAgXgb91Kvmnib2C9bZhll9OibU5E5w2qS91chfibqI/640?wx_fmt=png "") + +图：spider.dll 的 DllMain 函数 + +──────────────── + +四、权限提升：从 NETWORK SERVICE 到 SYSTEM + +初始访问时，攻击者仅获得 **NETWORK SERVICE** 权限。Metasploit 的 getsystem 命令尝试了多种提权方法： + + +• **Named Pipe 冒充（DLL Dropper 变种）**——失败，因为需要初始管理员权限 +• **Token Duplication（令牌复制）**——失败，仅支持 x86 系统 +• **Named Pipe 冒充（RPCSS 变种）**——**成功**！利用 LSASS 对 NETWORK SERVICE 的特性，从 RPCSS 进程复制 SYSTEM 令牌 + + +提权成功后，攻击者还尝试利用 **Zerologon（CVE-2020-1472）** 攻击域控制器，但未成功。Suricata 的三条告警规则中仅触发了前两条，确认攻击失败。 +![](https://mmbiz.qpic.cn/sz_mmbiz_png/PO9bjOzlHYC3Ec7xf7HcHzuPduQicph6iaus9RJepfYk5ia8FCfBNX07yydiaK6j5sv7jjoiaWfCKSao7o7ZVFicaiax5wA6oqZcd7LtkMia2fW01h0/640?wx_fmt=png "") + +图：Zerologon 漏洞利用尝试（未成功） + +──────────────── + +五、凭据窃取：Mimikatz + Impacket 组合拳 + +第三天，攻击者通过 AnyDesk 会话投递了 **Mimikatz**（32 位和 64 位版本）及相关驱动文件，并执行以下命令： + + +mimikatz.exe "privilege::debug" "log .\!logs\Result.txt" "sekurlsa::logonPasswords" "token::elevate" "lsadump::sam" exit + + +Mimikatz 执行后，攻击者用 **notepad.exe** 查看转储结果文件。随后使用 **Impacket 的 secretsdump.exe**（PyInstaller 打包的 Python 2.7 脚本），在不到两分钟内执行了 8 次，使用 NTLM 哈希进行 Pass-the-Hash 攻击。 +![](https://mmbiz.qpic.cn/sz_mmbiz_png/PO9bjOzlHYAZYIQooaKDe3dO05EGzrfSetRYImAbHIART68MYicxw4gr77hwYtMRGBYAniaXibLpSeqm4kqCS7oM2BO3eHWZG37UfSOcSpklRk/640?wx_fmt=png "") + +图：Sysmon 进程访问事件显示 mimikatz.exe 访问 lsass.exe + +此外，攻击者还在备份服务器和文件服务器上安装并运行了 **ProcessHacker**，同样以 SYSTEM 身份访问 lsass.exe，进一步扩大凭据窃取范围。 +![](https://mmbiz.qpic.cn/sz_mmbiz_png/PO9bjOzlHYBFRhBwPPQqy0OsXFJMXtTzNHGRicRyM8aE9tD21kGnymjxgP76agTAPbAYbJZI3vDC01cSyksbcwIlMBmShygjwiaRhlXBkDJlY/640?wx_fmt=png "") + +图：从 secretsdump.exe 中提取并反编译的 Python 脚本 + +──────────────── + +六、横向移动与发现 + +获得域管理员凭据后，攻击者使用多种方式进行横向移动： + +**• NetScan 网络扫描：**扫描 Kerberos（88）、SMB（445）、RDP（3389）、Veeam Agent（6160）等端口**• Impacket wmiexec：**通过哈希传递在域控制器上远程执行命令，创建域用户 NONAME 并加入 Domain Admins 和 Enterprise Admins 组**• SMB 共享：**在 Confluence 服务器上创建 SMB 共享，存放后续攻击工具**• RDP：**通过 NetScan GUI 直接发起 RDP 连接到文件服务器和备份服务器**• PrintNightmare 探测：**使用 rpcdump.exe 检查 MS-RPRN 和 MS-PAR 端点（未成功） + + +──────────────── + +七、防御规避与最终载荷 + +攻击者使用 **Defender Control（DC.exe）** 禁用 Windows Defender，通过注册表设置 +DisableAntiSpyware = 1。同时配置防火墙规则放通 RDP（3389 端口），并启用 RDP 连接。 + +入侵约 **62 小时**后，攻击者通过 RDP 登录到多台服务器（包括备份服务器和文件服务器），将 **ELPACO-team.exe** 通过 SMB 复制过去并在本地执行。ELPACO-team 被识别为 **Mimic 勒索软件**的变种。虽然删除了部分事件日志，但未观察到大规模数据外泄行为。 + +**⚠ 警告：**spider.dll 中出现的 "Crackenn" 凭据此前仅在 SentinelOne 披露的 BlackBasta/FIN7 攻击中出现过，这可能暗示 ELPACO-team 勒索软件操作者与 FIN7 威胁组织之间存在关联，或共享了攻击工具。 + + +──────────────── + +八、IoC 情报指标 +
类型值
C2 IP91.191.209[.]46
AnyDesk 服务器 IP45.227.254[.]124
扫描 IP109.160.16.68
扫描 IP185.228.19[.]244
扫描 IP185.220.101[.]185
漏洞CVE-2023-22527（Confluence RCE）
漏洞CVE-2020-1472（Zerologon，尝试未成功）
载荷文件HAHLGiDDb.exe、ELPACO-team.exe、spider.dll
本地凭据noname / Slepoy_123
Spider.dll 凭据Crackenn / *aaa111Cracke
AnyDesk 密码P@ssword1
+──────────────── + +九、MITRE ATT&CK 映射 +
阶段技术
初始访问T1190 — 利用面向公众的应用程序（CVE-2023-22527）
执行T1059.003 — Windows Command Shell
持久化T1136.001 — 创建本地账户、T1219 — 远程访问软件（AnyDesk）
提权T1134 — 访问令牌操纵（Named Pipe 冒充）
防御规避T1562.001 — 禁用防护工具、T1070.001 — 清除事件日志
凭据访问T1003.001 — LSASS 内存转储、T1550.002 — Pass-the-Hash
发现T1018 — 远程系统发现、T1083 — 文件和目录发现
横向移动T1047 — WMI（wmiexec）、T1021.001 — RDP
C2T1219 — 远程访问软件（AnyDesk On-Prem、Metasploit）
影响T1486 — 数据加密（ELPACO-team / Mimic 勒索软件）
+──────────────── + +**防御建议：** +1. **立即修补** CVE-2023-22527 及所有已知 Confluence 漏洞 +2. 监控 Metasploit 特征：DLL 文件与同名管道创建事件的关联检测 +3. 加强 LSASS 保护：启用 Credential Guard，限制进程对 lsass.exe 的访问 +4. 监控 AnyDesk 等远程工具的异常安装行为 +5. 对域控环境实施 Zerologon 和 PrintNightmare 的纵深防御检测 +6. 定期审计域管理员组成员变更 + + +──────────────── + + +原文：Another Confluence Bites the Dust: Falling to ELPACO-team Ransomware +来源：The DFIR Report（原文链接） +发布时间：2025 年 5 月 19 日 + + diff --git a/doc/2026-04/工具推荐 快速探测可能存在SQL注入漏洞.md b/doc/2026-04/工具推荐 快速探测可能存在SQL注入漏洞.md new file mode 100644 index 00000000..571e4aa2 --- /dev/null +++ b/doc/2026-04/工具推荐 快速探测可能存在SQL注入漏洞.md @@ -0,0 +1,172 @@ +# 工具推荐 | 快速探测可能存在SQL注入漏洞 +saoshao + saoshao 星落安全团队 2026-04-12 16:02 + +![图片](https://mmbiz.qpic.cn/mmbiz_png/spc4mP9cfo75FXwfFhKxbGU93Z4H0tgt4O9libYH9mKfZdHgvke0CeibvXDtNcdaqamRk3dEEcRQiaWbGiacZ2waVw/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=0 "") + +点击上方 +蓝字 +关注我们 + +![图片](https://mmbiz.qpic.cn/mmbiz_png/WN0ZdfFXY80dA2Z4y8cq7zy2dicHmWOIib5sIn8xAxRIzJibo2fwVZ3aicVBM8RnAqRPH5Libr4f02Zs5YnMLBcREnA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=1 "") + + +现在只对常读和星标的公众号才展示大图推送，建议大家能把 +**星落安全团队** +“ +**设为星标** +”， +否则可能就看不到了啦 +！ + +【 +声明 +】本文所涉及的技术、思路和工具仅用于安全测试和防御研究，切勿将其用于非法入侵或攻击他人系统以及盈利等目的，一切后果由操作者自行承担！！！ + +![图片](https://mmbiz.qpic.cn/mmbiz_png/rlSBJ0flllmaRJibwmfdkAia0T0kARgPh113VfFDDPp7SgHllxtgT5I9kRAK2pibxCibvwDlN5K3b5TicENNHicniap8A/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&watermark=1&tp=webp#imgIndex=2 "") + +**工具介绍** + +DetSql +是基于 BurpSuite Java 插件 API 开发的 SQL 注入探测插件，主要作用为快速从 http 流量中筛选出可能存在 SQL 注入的请求，在尽可能减少拦截的情况下提高 SQL 注入测试效率。 + +注意：**DetSql** +采用 Montoya API 进行开发，BurpSuite 版本需满足（>=2023.12.1）。 + +**使用方法** + +插件装载: Extensions - Installed - Add - Select File - Next + +主面板（dashboard） + +![](https://mmbiz.qpic.cn/mmbiz_jpg/rlSBJ0flllkiaPPz0jSPmS5wTMoerk28FstcuE0zQBcFQAWibqBzzjkUt36XibeuyA1ZOqSf0Seryk1JiaB45p5ScQ/640?wx_fmt=other&from=appmsg#imgIndex=3 "") + +在Logger模块中查看扫描流量，选择Extensions类型如下 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/rlSBJ0flllkiaPPz0jSPmS5wTMoerk28FnIgU2mTghDEUWDa49NibaXkqctd0DOkEv0nHcZYIBgB5OrZQCpg2vkw/640?wx_fmt=other&from=appmsg#imgIndex=4 "") + +例子 + +报错类型页面 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/rlSBJ0flllkiaPPz0jSPmS5wTMoerk28F3cMl3WMhP4oaokicEuxJmaBrQrh1CzYTrNzgtyYfyiaib7fegJv1loAOg/640?wx_fmt=other&from=appmsg#imgIndex=5 "") + +order类型页面 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/rlSBJ0flllkiaPPz0jSPmS5wTMoerk28F6PLiaOZwIKnOyQbRbjTRZA9pFbL4xXM680LRQBARZ7udq9FJQDQQdjA/640?wx_fmt=other&from=appmsg#imgIndex=6 "") + +数字类型页面 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/rlSBJ0flllkiaPPz0jSPmS5wTMoerk28FXlfvyPfd5XAnFexRsLVA8q1VJic4cPCXw2US0HN8UUS4QIicNibYJethg/640?wx_fmt=other&from=appmsg#imgIndex=7 "") + +字符类型页面（包含多种类型） + +![](https://mmbiz.qpic.cn/mmbiz_jpg/rlSBJ0flllkiaPPz0jSPmS5wTMoerk28FYY2f5SISNkBZApqYEj52VrWSiaBmYL0ekuRlV53M1Ug2pzqjWSmvvag/640?wx_fmt=other&from=appmsg#imgIndex=8 "") + + +**双引号问题** + +由于双引号闭合的情况出现极少，此处仍在报错类型中保留了双引号的原因，经本人测试出现过双引号报错的情况，因此仍在报错类型保留了双引号，如想自行设置报错payload可在配置面板自行设置。 + + +**相关地址** + +**关注微信公众号后台回复“入群”，即可进入星落安全交流群！** + +关注微信公众号后台回复“ +20260413 +**”，即可获取项目下载地址！** + +**** + +**** +**圈子介绍** + +博主介绍 +： + + +目前工作在某安全公司攻防实验室，一线攻击队选手。自2022-2024年总计参加过30+次省/市级攻防演练，擅长工具开发、免杀、代码审计、信息收集、内网渗透等安全技术。 + + +目前已经更新的免杀内容： +- 部分免杀项目源代码 + +- 星落安全内部免杀工具箱1.0 + +- CobaltStrike4.9.1星落专版1.9 + +- 一键击溃windows defender + +- 一键击溃火绒进程 + +-   +CobaltStrike免杀加载器 + +- 数据库直连工具免杀版 + +- aspx文件自动上线cobaltbrike + +- jsp文件 +自动上线cobaltbrike + +- 哥斯拉免杀工具  +XlByPassGodzilla + +- 冰蝎免杀工具 XlByPassBehinder + +- 冰蝎星落专版 xlbehinder + +- 正向代理工具 xleoreg + +- 反向代理工具xlfrc + +- 内网扫描工具 xlscan + +- Todesk/向日葵密码读取工具 + +- 导出lsass内存工具 xlrls + +- 绕过WAF免杀工具 ByPassWAF + +- 等等... + + + +![图片](https://mmbiz.qpic.cn/mmbiz_png/DWntM1sE7icZvkNdicBYEs6uicWp0yXACpt25KZIiciaY7ceKVwuzibYLSoup8ib3Aghm4KviaLyknWsYwTHv3euItxyCQ/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=9 "") + + +目前星球已满1000人，价格由208元 +调整为 +218元( +交个朋友啦 +)，1100名以后涨价至268元。 + +![](https://mmbiz.qpic.cn/mmbiz_png/rlSBJ0flllk2esLaDRsI4yjB0HkCibHzia8jerjNSHxpsLG89WWYML55BMAUJAV8tkyzhXNYHssWed3icMXia9e3tQ/640?wx_fmt=png&from=appmsg "") + + +![图片](https://mmbiz.qpic.cn/mmbiz_png/MuoJjD4x9x3siaaGcOb598S56dSGAkNBwpF7IKjfj1vFmfagbF6iaiceKY4RGibdwBzJyeLS59NlowRF39EPwSCbeQ/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=11 "") + +    +往期推荐 +    + + +1.[加量不加价 | 星落免杀第二期，助你打造专属免杀武器库](https://mp.weixin.qq.com/s?__biz=MzkwNjczOTQwOA==&mid=2247495969&idx=1&sn=d3379e8f69c2cefb6d0564299e13d579&scene=21#wechat_redirect) + + + +2.[【干货】你不得不学习的内网渗透手法](https://mp.weixin.qq.com/s?__biz=MzkwNjczOTQwOA==&mid=2247489483&idx=1&sn=0cbeb449e56db1ae48abfb924ffd0b43&scene=21#wechat_redirect) + + + +3.[【免杀】CobaltStrike4.9.1二开 | 自破解 免杀 修复BUG](https://mp.weixin.qq.com/s?__biz=MzkwNjczOTQwOA==&mid=2247488486&idx=1&sn=683083d38a58de4a95750673d9cb725d&scene=21#wechat_redirect) + + + +4.[【免杀】原来SQL注入也可以绕过杀软执行shellcode上线CoblatStrike](http://mp.weixin.qq.com/s?__biz=MzkwNjczOTQwOA==&mid=2247489950&idx=1&sn=a54e05e31a2970950ad47800606c80ff&chksm=c0e2b221f7953b37b5d7b1a8e259a440c1ee7127d535b2c24a5c6c2f2e773ac2a4df43a55696&scene=21&token=458856676&lang=zh_CN#wechat_redirect) + + +![图片](https://mmbiz.qpic.cn/mmbiz_png/DWntM1sE7icZvkNdicBYEs6uicWp0yXACpt25KZIiciaY7ceKVwuzibYLSoup8ib3Aghm4KviaLyknWsYwTHv3euItxyCQ/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp#imgIndex=12 "") + + diff --git a/doc/2026-04/规模化 SAST & SCA 漏洞修复.md b/doc/2026-04/规模化 SAST & SCA 漏洞修复.md new file mode 100644 index 00000000..69c9e5cd --- /dev/null +++ b/doc/2026-04/规模化 SAST & SCA 漏洞修复.md @@ -0,0 +1,157 @@ +# 规模化 SAST & SCA 漏洞修复 +原创 tonghuaroot + tonghuaroot RedTeam 2026-04-12 14:49 + +原文：Remediation at Scale: What High-Performing AppSec Teams Do Differently +，Semgrep，2026 年。数据来自 2025 年全年，覆盖 50k+ 活跃 SAST 仓库、25k+ 活跃 SCA 仓库，400+ 组织。 +## 问题不在发现，在于修复 + +这份报告的起点很直接：现代工程团队已经普遍部署了扫描工具，发现漏洞不是难事。难的是修。修一个漏洞意味着开发者要停下手头的活，看懂问题，写代码，过 Review，可能花几小时也可能花几天，而这些时间直接从功能开发里扣。 + +Semgrep 把数据里的组织分成两组：修复率前 15% 叫 Leaders，其余 85% 叫 Field。 + +![image](https://mmbiz.qpic.cn/mmbiz_png/iatDdM4vSwrueIXprogfHvFM8HdjeX6H2TS8kIpgY0IPtuINsbDumRLpdSicFvG1mHPcsG1QFLR7XVGYjsb7Yy1QkVEFc9GgibUKm3kHcjRI0Q/640?wx_fmt=png&from=appmsg "") + +image +## 差距有多大 + +
指标
Leaders
Field
差距
SAST 漏洞修复率
74.4%
22.3%
3.3 倍
SCA 漏洞修复率
39.6%
16.8%
2.4 倍
SAST 平均修复时间
32.9 天
41.7 天
快 1.3 倍
SCA 平均修复时间
28.8 天
65.8 天
快 2.4 倍
+ +有一点反直觉：Leaders 修单个漏洞的速度其实跟 Field 差不多，差距在于他们修掉了更大比例的总量。不是更快，是更多。 + +![image](https://mmbiz.qpic.cn/mmbiz_png/iatDdM4vSwrt2EY30M1zPicJBy54nUDib8K5ricmHicicR5BozDyIWW8KTRCAwLTyZuZTn0VFIGOqo28Vsibicicf9F2dLQhuiaHsWtF7cLFu2KBVKF9s/640?wx_fmt=png&from=appmsg "") + +image + +各严重等级上，差距同样一致，Leaders 不是只修 Critical，是每个等级都修得更多： + +![image](https://mmbiz.qpic.cn/sz_mmbiz_png/iatDdM4vSwrsZobBTZooibLQnzuFw2hZRfvqib706PovsH2rbyWiaMha9a4aklXYMdlFFAVRn4EYVmOpjO9HTfYCAjHKlMWicSwkDhEu5OxqSptY/640?wx_fmt=png&from=appmsg "") + +image +## SAST 和 SCA 是两个不同的事 + +

SAST（自研代码漏洞）
SCA（第三方依赖漏洞）
来源
开发者自己写的代码
引入的第三方包/库
修复方式
改代码
升级依赖版本
主要障碍
理解漏洞、修代码
有没有补丁、升级会不会 break
PR 扫描效果
显著（代码刚写下）
有限（漏洞往往在加包之后才被披露）
+ +区别在于控制权：SAST 漏洞是你自己引入的，SCA 漏洞是上游某天突然披露的。 +## 什么时候检测，决定了修不修 + +这是报告里最值得停下来看的一组数据： + +
检测时机
Leaders MTTR
Field MTTR
PR 扫描（SAST）
4.8 天
18.2 天
全量扫描（SAST）
43.0 天
54.3 天
PR 扫描（SCA）
1.2 天
4.8 天
全量扫描（SCA）
76.1 天
36.4 天
+ +同一类漏洞，PR 里检测到的比全量扫描检测到的快 9 倍修完。原因很现实：开发者正在看那段代码，上下文在脑子里，顺手两行就解决了，不需要开 Ticket、不需要重新捡起旧包袱。Leaders 里有 63% 的 PR 发现当天就修完了。 + +全量扫描的结果要进 Backlog、等分配、重建上下文、和业务需求抢优先级，平均拖 43 天。 + +![image](https://mmbiz.qpic.cn/sz_mmbiz_png/iatDdM4vSwrstxicaE5MSh0YHcUpEYUIL0ica2WMtmUMibsicla5qQLc9Zml8icRYkKLjwsmBZBbRGOGl6YFab76qTmlJr0E2ibbyOYLr7syQ30iaYI/640?wx_fmt=png&from=appmsg "") + +image +## 同样的工具，不同的收益 + +Leaders 和 Field 用的功能基本一样，但 Leaders 从每个功能里拿到的提升明显更大。 +### Blocking Rules + +PR 里检测到高风险漏洞就阻止合并。Leaders 采用率比 Field 高 14 个百分点（45% vs 32%）。 + +
指标
Leaders
Field
有 Blocking Rule 的组织
45%
32%
开启后修复率提升
+12.3pp
+4.9pp
+ +为什么同一个功能 Leaders 拿到 2.5 倍的收益？因为他们只对高置信度漏洞启用阻断（硬编码密钥、SQL 注入这类），而且阻断发生时开发者知道怎么处理。工具没差，配套流程有差。 +### 跨文件分析（Cross-File Analysis） + +追踪数据从一个文件流到另一个文件再到危险调用的完整路径，确认漏洞是不是真的能被触达。 + +
发现类型
Leaders 修复率
Field 修复率
跨文件确认的漏洞
69.4%
40.1%
单文件漏洞
42.8%
18.1%
+ +开发者更愿意修"确认是真的"的漏洞，跨文件分析提供的就是这种确定性。 +### 可达性分析（Reachability，SCA） + +检查依赖包里的漏洞代码路径有没有被你的应用真正调用。 + +
可达性状态
Leaders 修复率
Field 修复率
可达
92.3%
30.5%
不可达/未知
66.9%
20.5%
+ +可达的漏洞，Leaders 修复率 92%，这个数字挺惊人的。这个信号能有效解决依赖告警太多看不过来的问题，可达的先修，不可达的批量处理。 +### AI Memories + +团队可以把安全判断记录下来，比如"所有路由都过了 AuthMiddleware，这类告警是误报"，让扫描引擎以后自动识别同类模式，不再重复弹。Leaders 平均创建 32 条这样的记忆，Field 平均 25 条。最常记录的是框架保护和非生产环境两类。道理是：这个判断人做一次，系统记住，不用每次都重来。 +### 自定义规则 + +通用规则集不认识你自己的代码库，不知道你的 sanitize_html() + 已经处理了 XSS、你的 @auth_required + 装饰器会做鉴权检查。Leaders 采用率比 Field 高 9pp（59% vs 50%），平均写 8.3 条，Field 写 6.4 条。 + +同一个功能在不同成熟度的团队里效果差距有多大： + +![image](https://mmbiz.qpic.cn/mmbiz_png/iatDdM4vSwrtSKH1N5O1v8QxXhns8Dy9SIDURRzW5vGf3ujvRqbgOicTiczEnJJDCVEneXozVx2iaBYB6h2owbOdHp2AUyUHwdmTE7icqumiaT0Ss/640?wx_fmt=png&from=appmsg "") + +image +## OWASP Top 10 各类别修复率 + +
OWASP 类别
Leaders
Field
差距
A07 身份验证失败
59.0%
~11%
+48pp
A02 加密失败
47.7%
~9%
+38pp
A03 注入
37.3%
14.5%
+23pp
A01 访问控制失效
43.6%
24.2%
+19pp
A10 SSRF
38.1%
40.4%
Field 反而更高
+ +身份验证和加密的差距最大，修这两类问题不是改一行代码的事，往往要动架构（Session 管理、加密算法迁移、跨服务协调），所以多数团队的应对是推进 Backlog。Leaders 会真的去做，Field 更多是拖着。 + +SSRF 的反例值得注意：Field 修复率反而比 Leaders 高，是因为 SSRF 的"修法"不确定，简单的 URL 白名单可以被 DNS Rebinding 绕过，很多"修了"只是制造了错误的安全感，所以高修复率不代表真的修好了。 + +![image](https://mmbiz.qpic.cn/mmbiz_jpg/iatDdM4vSwrtP3xm3yxoJPo6wJLUog90DgFYm9AGmPKg85PyuAP0L2mxtBz2bg5OnnWFibjLz9jT10bJibPF7yNI0yjPL7Rvks5EudibsbAA77o/640?wx_fmt=jpeg&from=appmsg "") + +image +## 90 天是个拐点 + +漏洞放超过 90 天，被修的概率急剧下降。 + +
指标
Leaders
Field
SAST 修复来自 90+ 天 backlog 的比例
9.4%
16%
SCA 修复来自 90+ 天 backlog 的比例
12.1%
19.9%
+ +最容易积压的漏洞（Field 数据） + +SAST 里，注入类有 31.9% 的漏洞积压超 90 天，平均躺了 218 天；加密失败 23.3%，平均 240 天；身份验证失败平均积压 262 天，是最长的。 + +SCA 里，ReDoS（正则 DoS）13% 超 90 天，平均 238 天；资源耗尽 11.5%，平均 215 天。 + +报告说得很直接：积压漏洞到期必须做决定，要么修，要么正式书面接受风险，要么确认是误报就关掉。什么都不做不是在管理风险，只是在表演管理风险。 + +![image](https://mmbiz.qpic.cn/sz_mmbiz_png/iatDdM4vSwrvnnm9ibRCsRu60xbrv1KMwl1ZCrAUPuW7lTsPbzh9w98zq6DWkIuQQNfC8hica2qqRibjYqDicWCTmD2pJziblRHd0VSEMSp7VyBEU/640?wx_fmt=png&from=appmsg "") + +image +## SCA 各生态修复情况 + +
生态系统
修复率
MTTR
Composer (PHP)
47.3%
101 天
PyPI (Python)
38.7%
31 天
Cargo (Rust)
33.6%
63 天
GoMod (Go)
31.4%
62 天
Maven (Java)
27.0%
30 天
NPM (JavaScript)
26.5%
42 天
NuGet (C#)
22.8%
33 天
+ +Composer 排第一，部分原因是 drupal/core 这类高频包升级路径清晰。NPM 在各严重级别上修复率都差不多是 26%，说明问题不在优先级，是生态整体的难度。 + +最难搞定的几个包：node-forge、Auth0 旧版 SDK、urllib3、commons-compress。这些包深埋在基础设施里，升级往往连着改一串东西。报告建议：如果一个依赖躺了半年以上，不如直接问自己：我们真的打算修吗？如果不打算，就正式接受这个风险，别装作在排队等修。 + +![image](https://mmbiz.qpic.cn/mmbiz_png/iatDdM4vSwrvruSK0EXzrGSHPf6kpWlc9NibIdbF16PmCiapPxrpnyMRD4ic4B17Ytu48Fvs4SnoOFEuzT0DhSYCWv13X40FCTEnB9DPpWMdCcY/640?wx_fmt=png&from=appmsg "") + +image +## 几条可以实际用的建议 + +**这周能做的：** + +先找出 5 条最高风险的 SAST 规则启用阻断。从硬编码密钥和 SQL 注入字符串拼接开始，确保修复路径明确，不要在修法不清楚的规则上阻断，那只会让开发者烦。 + +SCA Backlog 按可达性排序，可达的先处理，不可达的单独批量审。用可达性数据做过滤，而不是把所有告警当同等优先级，是目前最直接的降噪方法。 + +优先处理跨文件确认的漏洞。置信度高，修复率也高，拿来建立早期成果和开发者信任都合适。 + +**这个季度可以推进的：** + +建立 90 天 Escalation 机制：每条到期漏洞必须走三条路之一：修、书面接受风险、确认误报关掉。不允许第四条路（继续躺着）。 + +审计最近 50 条误报决策，找出高频模式，把它们编码成 AI Memories 或自定义规则，不要重复做同样的判断。 + +检查告警到达开发者的传导链：告警有没有真的到开发者那里？描述里有没有足够上下文（是哪个文件的哪个输入流到了哪个危险函数）？每条漏洞有没有明确的 Owner？这三个问题如果有一个答案是"不确定"，修复率上不去的原因就在这里。 + +**半年内的战略级决策：** + +身份验证和加密这两类问题，要么划专项时间修（这是项目，不是 Ticket），要么书面接受风险，不能继续在 Backlog 里挂着不管不问。字段平均积压 262 天，说明这种漠视已经是常态了。 + +不同包管理生态适用不同的 SLA，用自己的数据校准，而不是拍脑袋定个"所有高危 30 天内修复"。 + +为团队内部框架和 API 写自定义规则，通用规则集不知道你的 sanitize_html() + 安不安全、你的 @auth_required + 管不管用，不写自定义规则就是在接受误报率。 +## 最后一个值得记住的数字 + +如果 Critical SAST 修复率低于 50%，问题几乎不在扫描质量，而是告警到修复之间的流程断了。从这里查起。 + +