用 CodeQL 狩猎 Solorigate（SunBurst）后门：语法特征与语义模式两类查询的实战剖析

静态分析SAST应用安全漏洞扫描代码质量【免费下载链接】codeqlCodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security项目地址https://gitcode.com/gh_mirrors/co/codeql点击查看免费下载导读2020 年 12 月初被公开的 Solorigate又名 SunBurst供应链攻击是在 SolarWinds Orion 产品的构建服务器上植入恶意软件进行的。微软随后编写了一批 CodeQL 查询用于大规模扫描源代码中是否存在与植入代码共享特征的恶意修改。本篇文章以 CodeQL 仓库中csharp/ql/campaigns/Solorigate目录下的查询包为骨架逐条讲解其 4 个语法特征查询与 6 个语义模式查询的检测原理、阈值设计、误报分析与改造方向并介绍如何从生产构建服务器构建分析用数据库、以及用确定性构建与源哈希校验生产链路安全。读完本文你将掌握一套按 IoC 特征 按行为模式双层后门狩猎查询的完整设计方法并能够直接复用到未来的恶意活动分析中。一、背景为什么需要后门狩猎查询Solorigate 活动的核心特征是恶意软件植入物是在构建服务器上被注入 SolarWinds Orion 产品的而不是在普通开发者机器上。这意味着受害方的源代码仓库本身看起来正常真正被篡改的是最终编译出的二进制。为了识别这类代码看似无异常、但构建产物已被污染的情况微软将这些查询设计成在源代码上搜索与植入代码共享特征的模式作为大规模审计的第一步。这套查询在设计上有两个明确取向语法特征Syntactic瞄准植入物中的具体名称与特定字面量命令枚举名、进程哈希、字符串常量、方法名。这类查询执行极快、极易修改适合在未来的活动中做第一轮初筛。语义模式Semantic不依赖具体名称而是瞄准植入物所采用的功能与数据流模式FNV 风格哈希 XOR、进程名到哈希的流、时间炸弹逻辑、吞掉一切异常的 catch、危险原生 API 调用。这类查询更难被改名规避也能迁移到其他编程语言。无论哪类查询良性的代码都完全可能巧合命中因此所有结果都必须由人工复核以确认或排除被标记源码的出处/来源providence。文档在开源这些查询时刻意在检测能力与误报率之间取了平衡并且剔除了那些执行时资源开销巨大、却没有显著检测增值的查询。二、查询包的结构与如何运行整个 Solorigate 查询包位于仓库的 csharp/ql/campaigns/Solorigate 目录分为三个子目录目录内容关键文件lib/共享谓词库存放全部 IoC 数据lib/Solorigate.qllsrc/可执行的查询与套件定义各.ql、.qhelp、codeql-suites/solorigate.qlstest/QL 测试与预期结果test/Solorigate/test.cs 及各.expected查询包的元信息定义在 src/qlpack.ymlname: codeql/csharp-solorigate-queries groups: - csharp - solorigate defaultSuiteFile: codeql-suites/solorigate.qls dependencies: codeql/csharp-all: ${workspace} codeql/csharp-solorigate-all: ${workspace}默认套件 codeql-suites/solorigate.qls 非常简单——它按标签筛选出所有 Solorigate 相关查询- description: Queries related to Solorigate - queries: . - include: tags contain: solorigate因此使用 CodeQL CLI 对某个 C# 代码库运行这套查询时只需先codeql database create建立数据库再用codeql database analyze指定本查询包或直接指定solorigate.qls即可套件会自动收集所有带solorigate标签的查询。每个查询的 QL 元数据头id、precision、problem.severity都声明了自身的检测精度与告警级别方便在结果中排序处理。测试与验证方式仓库为这套查询提供了完整的 QL 测试在 test/Solorigate/test.cs 中构造了覆盖每个查询的正例与反例并用// $ Alert[...]注释标注期望告警配合.qlref指向查询路径与.expected预期输出进行回归验证。例如命令枚举查询的预期输出 NumberOfKnownCommandsAboveThreshold.expected 为| test.cs:42:7:42:15 | JobEngine | ... It matches 19 of the values used for commands in the enum. |这说明测试用例中的JobEngine枚举命中了全部 19 个已知命令名。这也是后续所有改动阈值调整、清单增删的回归安全网——改完查询必须保证测试仍然通过。三、语法特征查询Syntactic Queries语法查询的特点是精确但脆弱或不精确但耐久它们瞄准的是攻击者容易在多次行动间修改的具体名称与值或者极易巧合出现的通用符号。文档特别提示其中有几个查询使用了 CodeQL 1.26 引入的列表语法因此需要该版本或更新版本才能编译执行。3.1 cs/Solorigate/number-of-known-commands-in-enum-above-threshold实现文件src/NumberOfKnownCommandsAboveThreshold.ql元数据precision mediumproblem.severity warning该查询寻找看起来像是在定义命令与控制C2功能的枚举。原因很直接枚举是定义和引用这类功能的便捷方式其他植入物大概率也会沿用。查询基于 Solorigate 植入物中的命令枚举允许一定的模糊度——文档描述为默认只要枚举中出现 18 个已知命令中的至少 10 个即触发对照源码实际实现是total 10即命中 11 个及以上才会报警命令清单solorigateSuspiciousCommandsInEnum共列出 19 个命令名见 lib/Solorigate.qll。计数谓词countSolorigateCommandInEnum就在Solorigate.qll中定义int countSolorigateCommandInEnum(Enum e) { result count(string s, EnumConstant ec | e.getAnEnumConstant() ec and s ec.getName() and s solorigateSuspiciousCommandsInEnum() ) }命令之间存在若干簇例如操作文件系统的命令、操作注册表的命令、处理进程执行的命令等。如果某个 API 恰好同时实现文件系统与注册表交互可能巧合命中部分名称但要让一个枚举同时包含文件系统、程序集、进程执行等跨域命令就极不寻常了。调优建议若你知道自己的代码库确实实现了某子集功能例如只做文件系统操作从countSolorigateCommandInEnum中删除对应的命令、并降低查询阈值可显著降低误报但会增加漏报风险。想降低漏报降低阈值 把枚举值名称比较改成模糊匹配。代价是误报升高且模糊匹配计算开销更大、执行时间更长。3.2 cs/Solorigate/number-of-known-hashes-above-threshold实现文件src/NumberOfKnownHashesAboveThreshold.ql元数据precision mediumproblem.severity warningSolorigate 植入物会先枚举正在运行的进程用FNV-1A 哈希处理进程名再与魔数 6605813339339102567 做 XOR最后把结果与一张黑名单哈希表比对——这张表由它想规避的各种反恶意软件/安全检测进程名派生而来。对魔数做 XOR 的目的很可能是让比较值每个植入物唯一因此这些值几乎不可能被其他活动复用。该查询统计项目中出现的这些派生哈希字面量阈值默认是 5源码注释约 200 个已知字面量超过即报警。这些值出现在良性源码中的概率极低所以一旦命中结果极大概率就是恶意的。相关字面量定义在Solorigate.qll的solorigateSuspiciousHashes谓词中isSolorigateHash谓词负责匹配Literal的取值。复用方法如果未来出现类似活动只需把solorigateSuspiciousHashes中的值整体替换为新活动的哈希值即可。由于攻击者大概率会让这些值每个植入物唯一替换后很可能查不到东西但这本身是一个非常快的查询写与改的成本极低当作以防万一的例行检查很划算。需要强调的是该查询检测的是具体的值而cs/Solorigate/modified-fnv-function-detection与cs/backdoor/process-name-to-hash-function检测的是进程名哈希技术本身因此后两者对更换魔数的变体仍然有效。3.3 cs/Solorigate/number-of-known-literals-above-threshold实现文件src/NumberOfKnownLiteralsAboveThreshold.ql元数据precision mediumproblem.severity warning该查询寻找植入物中出现过的字面量。问题在于清单里大量字面量常见 IP 地址、主机名等会出现在海量正常代码中因此查询默认要求至少 30 个字面量同时存在才触发源码注释约 150 个已知字面量实现为total threshold且threshold 30。未来其他植入物若要实现类似功能多数字面量都得复用尽管也可以用可逆混淆技术藏起来。这个查询的关键设计点是它只统计语义字面量即通过 QL 的Literal元素匹配不会把注释、方法名、变量名中的相同文本误计为命中。这正体现了 CodeQL 相对纯文本正则扫描的优势——即使是这样一个简单检测也能做到语法感知。研判顺序建议由于这些字面量太过常见命中结果代表恶意修改的可能性低且人工研判该查询结果最费时文档建议优先处理其他查询的结果最后再处理本查询。调优建议若第一轮结果过多调高阈值如 30 → 更高只保留完整复刻 Solorigate 字面量集合的代码但漏报风险上升。若第一轮结果过少调低阈值以捕获只用了部分字面量的变体但误报显著上升。针对特定代码库运行时可以删掉该库中确属正常使用的方法与字面量来收缩结果集过度裁剪会增加漏报。未来活动的 IoC 字面量更多时把阈值从 30 调高可提升准确率且漏报增幅有限反之若 IoC 字面量大幅减少则需下调阈值。字面量清单定义在Solorigate.qll的solorigateSuspiciousLiterals中其中包含 WMI 查询串Select * From Win32_Process等、注册表路径HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography、IP 网段、域名avsvmcloud.com、字体资源路径等——从内容可看出植入物具备系统信息采集、网络通信与伪装 UI 资源等多重能力。3.4 cs/solorigate/number-of-known-method-names-above-threshold实现文件src/NumberOfKnownMethodNamesAboveThreshold.ql元数据precision mediumproblem.severity warning植入物刻意使用常见方法名来融入环境所以单个方法名几乎必然在大量代码库中巧合出现。因此该查询默认要求 50 个以上源码注释约 100 个已知名称的清单方法名同时出现才触发。与字面量查询对称它只统计真正作为方法名的使用不会把字面量、注释、变量名中的同名文本误计。清单定义在Solorigate.qll的solorigateSuspiciousMethodNames并由isSolorigateSuspiciousMethodName谓词限制m.fromSource()且名称精确匹配。文档的经验数据虽然在单项目内同时定义大量这些常见方法名并不寻常但确实可能发生微软在内部扫描时也遇到了不少误报。将类声明中的常见覆写如ToString从清单中剔除可以降低误报不过在 50 的阈值下微软发现不剔除也足够可控。语言可移植性说明枚举命令、派生进程哈希、字面量这三个查询的思路若移植到其他语言仍有价值但本查询的方法名清单是 C# 特有的移植无意义。不过如果未来发现针对其他语言的植入物本查询的方法名聚合计数基本方法仍然可复用只需替换名称清单。四、语义模式查询Semantic Queries语义查询不关心 IoC 中的具体名称或词项而是瞄准植入物功能所用的技术或模式。它们可以被用不同语义实现同样功能所规避但攻击者必须特意付出代价才能做到。这类查询可能顺带检测出无关的后门也可移植到其他语言检测同样的技术。4.1 cs/Solorigate/modified-fnv-function-detection实现文件src/ModifiedFnvFunctionDetection.ql元数据precision highproblem.severity errorSolorigate 植入物通过对进程名哈希并与内嵌值表比较来规避安全检测软件为了让内嵌表在每个植入物间唯一哈希结果又额外 XOR 了一个魔值。植入物内嵌的哈希函数是FNV-1A 的一个变体所以本查询寻找的是FNV 风格实现 额外 XOR的组合。什么算FNV 风格由共享库 csharp/ql/lib/experimental/code/csharp/Cryptography/NonCryptographicHashes.qll 中的谓词maybeUsedInFnvFunction判定。它的判定不依赖函数名而是看方法体的实现形态——在同一个循环LoopStmt内存在一个变量先参与 XOR 运算、随后参与乘法运算且控制流上 XOR 先于乘法predicate maybeUsedInFnvFunction(Variable v, Operation xor, Operation mul, LoopStmt loop) { exists(Expr e1, Expr e2 | e1.getAChild*() v.getAnAccess() and e2.getAChild*() v.getAnAccess() and e1 xor.getAnOperand() and e2 mul.getAnOperand() and xor.getControlFlowNode().getASuccessor*() mul.getControlFlowNode() and (xor instanceof AssignXorExpr or xor instanceof BitwiseXorExpr) and (mul instanceof AssignMulExpr or mul instanceof MulExpr) ) and loop.getAChild*() mul.getEnclosingStmt() and loop.getAChild*() xor.getEnclosingStmt() }查询本体则在循环退出之后追踪该变量是否又被一个含字面量的BitwiseXorOperation使用命中即报警参见 ModifiedFnvFunctionDetection.ql 中loopExitNode(loop).getASuccessor*() xor2.getControlFlowNode()的约束。这种看实现不看名字的策略可以规避纯靠函数改名逃脱检测的做法但刻意混淆函数实现仍可能绕过。另外文档指出maybeUsedInFnvFunction以及同库中寻找 Elfhash-like 的谓词maybeUsedInElfHashFunction同样是循环内先 XOR 后加法的模式与 Solorigate 无关可以结合控制流分析用于确认这些非加密哈希函数没有被用在密码学上下文那样会不安全。4.2 cs/backdoor/process-name-to-hash-function实现文件csharp/ql/src/experimental/Security Features/backdoor/ProcessNameToHashTaintFlow.ql元数据precision mediumproblem.severity warning与前两条查询不同这条查询不找FNV 风格方法 XOR的组合而是找从System.Diagnostics.Process.ProcessName到看起来像哈希函数的数据流。看起来像哈希函数由isGetHash谓词判定要么目标方法名匹配%Hash%或Md[4-5]|Sha[1-9]{1,3}要么其实现是 FNV-Like / Elf-Like复用上文的isCallableAPotentialNonCryptographicHashFunction见NonCryptographicHashes.qll——看实现的方法对简单改名是耐久的predicate isGetHash(Expr arg) { exists(MethodCall mc | ( mc.getTarget().getName().matches(%Hash%) or mc.getTarget().getName().regexpMatch(Md[4-5]|Sha[1-9]{1,3}) ) and mc.getAnArgument() arg ) or exists(Callable callable, Parameter param, Call call | isCallableAPotentialNonCryptographicHashFunction(callable, param) and call callable.getACall() and arg call.getArgumentForParameter(param) ) }数据流是跨过程的TaintTracking::Global因此即使攻击者把取进程名 → 哈希 → 比较的步骤拆散到多个方法中也能串起来。需要客观看待对进程名做哈希有正当理由例如做去重、统计、指纹所以即使流成立命中也不一定恶意。哈希函数的定义故意模糊%Hash%、MD/SHA 变体所以该查询精度为 medium——可能误捕并非在哈希进程名的代码。扩展方法想撒更大的网修改isGetHash增加更多哈希检测逻辑即可。测试用例位于 csharp/ql/test/experimental/Security Features/backdoor/ProcessNameToHashTaintFlow.qlref 对应目录。4.3 cs/backdoor/potential-time-bomb实现文件csharp/ql/src/experimental/Security Features/backdoor/PotentialTimeBomb.ql元数据precision Lowproblem.severity warningkind path-problem输出带路径的告警该查询针对 Solorigate 植入物的时间延迟激活功能植入物在 Orion 更新安装后的1214 天内不会激活而是先读取某个文件的最后写入时间、随机加上 288336 小时即 1214 天再与当前系统时间比较之后才首次回连 C2 服务器。查询检测的模式是从GetLastWriteTime到算术运算的流再到与当前时间比较的流。从源码看这是用三段式全局污点跟踪TaintTracking::Global串起来的FlowsFromGetLastWriteTimeConfigToTimeSpanArithmeticCallable源头为System.IO.File.GetLastWriteTime等GetFileCreationTime、GetCreationTimeUtc、GetLastAccessTimeUtc也被纳入汇点为System.DateTime的时间跨度算术调用Add、AddDays、AddHours、AddMinutes、、-等。FlowsFromTimeSpanArithmeticToTimeComparisonCallable从该算术运算流向比较调用Compare、CompareTo、Equals、、!、、、、。FlowsFromTimeComparisonCallableToSelectionStatementCondition从比较流向选择语句如if的条件。三段通过DataFlow::MergePathGraph3合并成一条完整路径kind path-problem最终由isPotentialTimeBomb谓词断言并输出告警路径。误报特征任何安装后一段时间才触发动作的软件都会被巧合命中——例如安装一段时间后提示用户注册或激活产品。文档给出的实战结论是该查询按原样在微软数千个数据库上运行时误报量是可管理的建议先原样运行仅在特定代码库中该模式确属常见时再做下述改造。可选增强会增大执行时间并增加漏报风险追加随后流向远程源的检查Solorigate 植入物正是回连 C2 的追加流向 shell 或进程执行的检查时间炸弹恶意代码的常见特征。通用化方向可以把数据源扩展到其他在系统中持久化初始数据的方式——读取注册表键、文件内容、系统重启时间等每加一个数据源误报都会上升。4.4 cs/Solorigate/swallow-everything-exception实现文件src/SwallowEverythingExceptionHandler.ql元数据precision highproblem.severity errorSolorigate 植入物用一段吞掉一切的异常处理包住被植入的代码避免运行时异常暴露自身try { // stuff } catch (Exception) { }查询逻辑源码中GenericCatchClause类覆盖两类 catchGeneralCatchClause不带异常类型的裸catch捕获SystemExceptionClass且没有过滤子句的SpecificCatchClause。然后要求gcc.getBlock().getNumberOfStmts() 0即catch 块为空命中即报警Empty Swallow Everything Exception.。精度评估检测是高精度的——凡是空的通用异常处理器都会被准确找出。但空 catch实在太常见网上有大量文章论证它是坏实践因此命中结果代表恶意植入的可能性低。文档建议逐一复核确认这个坏实践没有掩盖潜在或不那么潜在的 bug。规避与互补在 catch 块里放任意语句即可规避本查询但此时现有的cs/catch-of-all-exceptions查询可以兜住这种规避——它的结果是本查询的超集会覆盖异常已被预期、catch 可以安全处理并继续执行的大量正当场景。对比之下只看空 catch的本查询精确匹配植入物模式产生需要复核的结果更少。4.5 cs/backdoor/dangerous-native-functions实现文件csharp/ql/src/experimental/Security Features/backdoor/DangerousNativeFunctionCall.ql注ReadMe 中写作DangerousNativeFunctionCalls.ql仓库内实际文件名为单数DangerousNativeFunctionCall.ql元数据precision lowproblem.severity warning该查询列出多个可能出现在后门功能中的危险 Windows 原生 API包括若干 Solorigate 用到的。它的更广泛价值在于识别一种规避手段——攻击者通过直接调用原生平台库PInvoke来绕过查找恶意进程执行类查询而不是走 .NET 类库。isDangerousMethod谓词覆盖的名单包括OpenProcessToken、OpenThreadToken、DuplicateToken(Ex)、LogonUser%、WNetAddConnection%、DeviceIoControl、LoadLibrary%、GetProcAddress、CreateProcess%、InitiateSystemShutdown%、GetCurrentProcess(Token)、SetTokenInformation、LookupPrivilegeValue%、AdjustTokenPrivileges、SetProcessPrivilege、ImpersonateLoggedOnUser、Add%Ace%等——集中在令牌操作、权限提升、进程创建与库加载等敏感面。isExternMethod谓词判定方法是否为extern、带有DllImport特性、或声明类型带有ComImport特性。为何保留这个刻意简单的查询文档明确说明它故意保持简单、作为示例——告诉查询开发者不仅要查询后门模式还要思考如何查询攻击者对检测查询的规避尝试。它的直接价值有二撒大网找 PInvoke 规避技术以及审视良性代码中开发者为何选择了更容易出错的 PInvoke 实现。组合扩展把它接上数据流/污点流只需一步——在自定义isSink实现中加入对isExternMethod的调用。这样就能检测来自不可信源如 Web 请求的数据流入危险 API的路径即使不是 C2 实现也至少是一个值得复核的潜在安全漏洞。五、从生产构建服务器构建分析用数据库由于 SolarWinds 代码的恶意修改发生在构建服务器上用于分析的 CodeQL 数据库最好也由同一构建服务器构建。文档给出了两条关键论据CodeQL 与 MSBuild 使用同一个 Roslyn 编译器只要攻击者没有专门针对 CodeQL 的存在做检查其注入技术在 CodeQL 运行时大概率会复现——也就是说用构建服务器建的库最接近实际被编译进二进制的那份代码。如果只能在独立环境建库则需要用其他技术验证最终二进制里的代码 源仓库里的源代码。FYI两条独立验证技术确定性构建对比若构建环境配置了确定性构建并非所有编译器都支持支持的编译器也不一定默认开启可以把构建环境产出的二进制与另一独立环境用同一份源码编译出的二进制做对比。源哈希清单对比部分编译器可以配置为输出被编译源文件的哈希清单MSBuild 会把它们写进编译期间生成的 PDB 文件与独立环境生成的源哈希做对比。若上述任一对比不一致就是明确信号需要进一步调查。这两种技术都可以自动化形成对构建产物的持续校验。哈希强度建议做源哈希对比时强烈建议用SHA256而非更弱的哈希。下表是微软系编译器启用 SHA256 源哈希的具体开关编译器开关cl.exe/ZH:SHA_256ml.exe/ZH:SHA_256ml64.exe/ZH:SHA_256armasm.exe-gh:SHA_256armasm64.exe-gh:SHA_256csc.exe/checksumalgorithm:SHA256六、误报管理给读者的综合建议综合文档与源码把 10 条查询按命中即恶意概率排序研判优先级大致如下优先级查询命中含义原因最高number-of-known-hashes-above-threshold极可能恶意派生哈希值是每个植入物唯一的几乎不可能巧合出现高modified-fnv-function-detection值得深查FNV 风格 额外 XOR 是明确的规避手法信号中number-of-known-commands-in-enum-above-threshold值得深查单个枚举同时命中跨域命令簇极不寻常中potential-time-bomb需复核合法的安装后延时激活也会命中中process-name-to-hash-function需复核哈希进程名存在正当理由medium 精度中dangerous-native-functions需复核PInvoke 使用可能合法也可能是规避尝试较低swallow-everything-exception大概率是坏实践而非恶意空 catch 太常见最低number-of-known-method-names-above-threshold/number-of-known-literals-above-threshold多属巧合名称与字面量本就常见建议最后研判调优的共同原则每一项阈值或清单改动都在漏报与误报之间权衡任何改动都应回到 test/Solorigate/test.cs 的回归测试上验证防止检测能力意外退化。七、小结Solorigate 查询包展示了一套完整的供应链后门狩猎方法论先用基于 IoC 清单的语法查询做快速初筛快、易改、可复用再用基于行为模式的语义查询做纵深检测耐久、可跨语言最后以构建服务器建库 确定性构建/源哈希校验闭环验证产物真实性。对安全团队而言这批查询的价值不止于 Solorigate 本身——文档与源码刻意保留了清晰的扩展点替换Solorigate.qll中的清单、调整阈值、给isGetHash/isExternMethod增加规则、扩展时间炸弹的数据源使其能快速适配未来的任何恶意活动。对查询开发者而言DangerousNativeFunctionCall.ql等刻意简化的示例则示范了不仅查模式还要查对检测的规避这一更高级的狩猎思路。赞分享静态分析SAST应用安全漏洞扫描代码质量【免费下载链接】codeqlCodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security项目地址https://gitcode.com/gh_mirrors/co/codeql点击查看免费下载相关推荐对比评测NVIDIA-Nemotron-3-Ultra-550B-A55B-GenRM与传统Reward Model在RLHF训练中的性能差异对比评测NVIDIA Nemotron 3 Ultra 550B A55B GenRM与传统Reward Model在RLHF训练中的性能差异 NVIDIA人工智能大模型模型评测DeepSeek-V4-Flash-NVFP4高级配置指南温度参数调整与最大生成长度优化DeepSeek V4 Flash NVFP4高级配置指南温度参数调整与最大生成长度优化 DeepSeek V4 Flash NVFP4作为一款高效的AI模型Django-Rosetta测试策略确保翻译功能稳定的完整测试方案Django Rosetta测试策略确保翻译功能稳定的完整测试方案 Django Rosetta是一款专为Django项目设计的翻译管理工具它能帮助开发者轻上一篇如何利用Windows-Exploit-Suggester发现系统缺失补丁提升Windows安全防护能力下一篇BlinkMind Desktop 开源项目安装与使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考