数据库痕迹与凭据泄露分析

数据库痕迹与凭据泄露分析

很多入侵事件里，真正高价值的目标不是 Web 服务器本身，而是它背后的数据库。攻击者拿下一台业务主机后，下一步通常不是“继续留一个 WebShell 就结束”，而是去寻找连接串、读取敏感表、导出业务数据，甚至把数据库服务当成继续控主机和横向扩散的支点。

0x02电子取证 已经覆盖了数据库相关证据入口，比如服务状态、监听端口、配置文件、客户端痕迹、系统账号与共享情况。到了 0x03取证分析，重点不再是“去哪里找”，而是“找到之后怎么判断”。本章真正要回答的是：

  • 凭据是怎样泄露到攻击者手里的
  • 攻击者是否真的建立了数据库访问，而不是仅仅看到了连接信息
  • 事件属于“数据接触”“批量取数”“主机接管”还是“长期驻留”
  • 数据库在这次事件里是目标、跳板，还是两者兼具

0x01 先把数据库事件分型

数据库痕迹很多，但分析时不能一上来就堆日志，而要先给事件分型。分型错了，后面的判断就容易失真。

1. 配置泄露型

这类事件的起点通常不是数据库本身，而是：

  • Web 目录泄露源码
  • Git、备份包、部署脚本泄露连接串
  • 运维终端中保存了数据库客户端配置

它的核心判断点不是“数据库端口是否开放”，而是“攻击者是否已经拿到了足以复用的连接能力”。

2. 数据库直连型

这类事件通常表现为：

  • 数据库服务直接对外或对办公区暴露
  • 弱口令、匿名访问、过宽白名单
  • 异常来源地址直接命中数据库端口

分析重点是区分“被扫到”“被探测到”和“已经登录并执行操作”。

3. 应用中转型

攻击者未必直接从自己主机连接数据库，而是：

  • 通过 WebShell 调用本机数据库客户端
  • 借助应用服务器已有连接能力读取数据
  • 通过脚本、计划任务、批处理在业务主机上执行导出

这类场景里，数据库日志看到的来源往往是“正常应用主机”，所以更要依赖进程链、时间线和文件痕迹来证明这是攻击行为而不是业务访问。

4. 数据库转主机控制型

数据库事件不一定终于数据，很多时候会升级成主机控制：

  • MSSQL xp_cmdshell
  • SQL Agent Job
  • MySQL UDF
  • Redis 改写目录、落公钥、写计划任务
  • PostgreSQL COPY TO PROGRAM

一旦出现这类语义，事件性质就已经从“数据库接触”升级为“数据库被当成执行器”。

0x02 判断凭据是“存在”还是“已泄露”

很多现场会卡在第一步: 明文连接串找到了，但到底能不能据此下结论说“数据库凭据已泄露”？

答案是不能直接下。要把“存在明文凭据”和“凭据进入攻击链”区分开。

1. 仅有静态存在，不足以下结论

例如你在 application.yml、.env、Navicat 配置里发现：

  • 明文用户名和密码
  • root、sa、dba 等高权限账号
  • 多套生产连接信息

这说明风险面存在，但还不能证明攻击者已经使用。

2. 具备以下关联时，才可提升为“已进入攻击链”

  • 同一时间段源码、配置或备份目录被访问
  • 随后出现数据库客户端进程、脚本或连接
  • 数据库端出现对应账号的成功登录
  • 登录之后出现敏感表查询、导出、权限变更

也就是说，凭据泄露分析不是“找到密码就结束”，而是要回答这组凭据是否从静态资产变成了被利用的能力。

3. 三类高频泄露源的分析差异

配置文件泄露

这类泄露更像“资产暴露”。通常说明应用安全和部署治理存在问题，但未必已经产生业务影响。必须继续追踪后续数据库接触行为。

终端客户端泄露

如果攻击者控制的是开发机、运维机、DBA 终端，那么从 DBeaver、Navicat、SSMS、mysql_history、psql 历史中拿到的凭据往往带有真实使用场景。这类线索比单纯源码中的老旧连接串更危险，因为它更可能是仍然有效、且带权限的。

备份包或脚本泄露

这类泄露最容易和批量取数串起来。因为备份目录、自动化脚本、转储文件常常本来就与导出流程、任务执行、压缩外传紧挨在一起，攻击者一旦触达，后续动作会更快。

0x03 如何证明数据库“被真正访问过”

数据库事件最常见的误判，就是把“看到了数据库相关痕迹”误认为“数据库已经被攻击者使用”。要避免这个问题，建议用四层证据闭环。

1. 第一层：连接能力存在

这层证据包括：

  • 连接串、账号密码、客户端保存会话
  • 数据库端口可达
  • 业务主机具备通向数据库的网络路径

这只能证明“攻击者有机会”，还不是“攻击者已经做了”。

2. 第二层：连接动作成立

这层证据才开始接近实锤：

  • 数据库登录成功
  • 业务主机或办公终端建立到数据库的连接
  • 数据库客户端工具或脚本被启动

如果这层缺失，结论最多只能是“高风险接触”。

3. 第三层：操作语义明确

这层要回答“攻击者进库以后做了什么”：

  • 查询敏感表
  • 批量枚举库表
  • 导出数据
  • 创建账号、授权、开危险组件
  • 执行系统命令或写文件

只有走到这一步，才能从“接触数据库”升级为“数据库被利用”。

4. 第四层：结果证据落地

最终还要看结果有没有外溢：

  • 生成导出文件、压缩包、切片
  • 共享目录或临时目录出现新转储
  • 出站流量上升
  • 后续主机出现凭据复用、横向和持久化

数据库分析的价值，恰恰在于把这四层串起来，而不是孤立地看某一条日志。

0x04 攻击者在数据库里的四种典型目的

1. 验证账户有效性

攻击者第一次进库，很多时候并不会立刻导出整库，而是先做小范围试探：

  • 列库、列表、看版本信息
  • 用少量查询确认权限范围
  • 观察是否能访问敏感业务表

这一步在日志上可能很轻，但意义很重，因为它说明攻击者已经完成从“拿到凭据”到“验证可用”的转换。

2. 批量取数

典型特征不是某一条危险 SQL，而是访问行为的形态：

  • 连续扫多个核心表
  • 同结构分页读取
  • 主键范围遍历
  • 在短时间内产生大量结果集

如果你看到的是这种“节奏型”访问，而不是一次两次查询，就更像批量取数而不是运维排错。

3. 借数据库做系统动作

这类行为有很强的升级意义：

  • 在 MSSQL 中启用 xp_cmdshell
  • 创建 SQL Agent Job
  • 在 MySQL 中尝试 UDF 或写文件
  • 在 Redis 中修改目录与持久化文件名

这说明攻击者不再把数据库当成纯数据源，而是试图把它转化成主机执行通道。

4. 建立长期访问

例如：

  • 新增数据库用户
  • 扩大远程来源范围
  • 保留转储脚本或自动化导出任务
  • 调整白名单、监听地址或客户端连接配置

这类行为意味着事件已从“机会性读取”演化为“持续控制和后续复用”。

0x05 两个最容易误判的边界

1. “数据库管理员行为”与“攻击者取数”如何区分

看表面动作，两者有时很像，都会：

  • 连库
  • 查表
  • 导出
  • 访问备份目录

真正的区分点在上下文：

  • 账号是否符合职责
  • 时间是否在变更、备份或发布窗口
  • 目标表是否超出平时职责范围
  • 是否伴随压缩、外联、清痕、代理或横向痕迹
  • 操作是否有稳定脚本、工单、审计留痕

分析时不要陷入“查了表就是攻击”的简单判断，而要看这个行为是否脱离了原有运维语境。

2. “应用正常访问”与“攻击者借应用中转”如何区分

很多数据库日志只能看到来源是应用服务器，并不能直接看到操作者是谁。这时要回到应用主机侧分析：

  • 访问数据库前，是否先出现 WebShell、异常命令执行或源码读取
  • 是否在业务低峰时段发生高密度查询
  • 是否伴随本地数据库客户端、导出工具、压缩命令
  • 导出文件是否出现在临时目录、站点目录、共享目录

数据库日志只能证明“从这台主机来了请求”，不能直接证明“是业务代码发起的”。这正是 0x03 分析与 0x02 采集的核心区别。

0x06 公开案例里最值得借鉴的分析思路

案例一：WebShell 之后并不是直接窃文件，而是继续打数据库

在 Unit 42 公开过的一些长期入侵分析中，攻击者在拿下对外应用节点后，并没有止步于 WebShell，而是继续通过站点主机上的数据库连接能力向后端 SQL 资产推进，常见工具包括 WebShell、数据库客户端和脚本化查询工具。对这类事件，现场最容易漏掉的不是 WebShell 本身，而是误把数据库访问当成“应用正常访问”。

这个案例给分析带来的启发是：

  • 如果攻击入口是 Web 层，就必须沿着应用配置、源码、连接串继续往后找
  • 数据库来源地址即便是“正常业务主机”，也不能因此排除恶意访问
  • 一旦出现查询、导出、压缩、外联的连续时间链，事件性质就会从“站点沦陷”升级为“后端数据失陷”

案例二：SQL Server 不是终点，而是继续控主机和扩大战果的中转点

公开威胁报告中反复出现一种模式：攻击者先拿到 SQL Server 访问能力，随后利用 xp_cmdshell、Agent Job 或系统命令调用能力继续下载工具、拉起脚本、触达更多资产。这类事件如果只盯着“数据库里查了哪些表”，就会低估影响面。

这个案例说明：

  • 看到危险 SQL，不要只按“数据库审计事件”处理
  • 要立即并行分析主机侧进程、落地文件、网络连接和后续横向
  • 数据库被滥用为执行器时，影响范围通常已经超出单一库表

案例三：Redis 被利用时，风险未必是“数据被读”，而可能是“主机被接管”

公开应急案例和多家安全厂商报告中，Redis 暴露后被修改持久化目录、写入 SSH 公钥或计划任务，是高频模式。这类事件在表面上看起来是“数据库配置被改”，但分析结论不能停在数据库层面，因为攻击者的真实目的常常是拿下操作系统权限。

这类事件提醒我们：

  • 不同数据库的分析目标不一样
  • MySQL/MSSQL 常兼具“数据目标”和“执行通道”双重属性
  • Redis 一旦出现目录、文件名、持久化路径异常，首先要怀疑主机侧后门和持久化

0x07 命令结果如何解释成分析结论

你真正要沉淀的，不是“会执行什么命令”，而是“看到什么结果，能判定什么问题”。下面这些经验更适合在应急现场直接复用。

1. sqlcmd 带查询与输出文件参数，不是普通探活，而是明显取数信号

如果在主机侧看到：

sqlcmd -S 127.0.0.1,1434 -U sa -P ****** -Q "select name from sys.databases" -o C:\Windows\Temp\db.txt

或 PowerShell 中出现：

Invoke-Sqlcmd -ServerInstance 127.0.0.1 -Query "select * from dbo.users" | Out-File C:\ProgramData\users.txt

优先不要只记“执行了 sqlcmd”，而要拆参数看语义：

  • 出现 -Q / -Query：说明不是交互式管理，而是一次性脚本化执行
  • 出现 -o / Out-File：说明查询结果被落盘，已经具备后续打包和外传条件
  • 目标是 127.0.0.1 或 localhost：说明攻击者常常是借已沦陷主机本地打库，而不是从自己机器直接远连
  • 查询内容如果是 sys.databases、sys.server_principals、fn_my_permissions：更偏权限试探和环境摸底
  • 查询内容如果直接指向业务表、账号表、订单表：更偏数据接触或批量取数

这类结论并不是空想。Unit 42 在 CL-STA-0048 公开分析里就提到攻击者滥用 sqlcmd 连接本地 SQL Server 并把结果输出后再外传，这种“本地连接 + 结果落盘”的组合，本身就是很强的取数语义。

2. 查询结果文件出现 .txt、.csv、.dat，说明事件已经接近“数据转储”

如果命令行、脚本块日志或 EDR 里看到：

sqlcmd.exe ... -o C:\inetpub\wwwroot\aspnet_client\result.txt
sqlcmd.exe ... -o C:\Windows\Temp\query.csv

分析重点不是“这个路径怪不怪”，而是：

  • 输出位置在 Web 根目录：更像准备通过 HTTP 直接下载
  • 输出位置在 %TEMP%、ProgramData：更像先暂存，再压缩或搬运
  • 输出文件扩展名是 .txt、.csv、.dat：通常不是 DB 管理控制台临时回显，而是为了后续被脚本消费或外带
  • 结果文件生成后很快出现 rar、7z、cab、makecab、curl、certutil、浏览器下载请求：可以上升为“导出后进入外传阶段”

Splunk 关于 sqlcmd.exe 和 Invoke-Sqlcmd 的检测经验也把“查询参数 + 输出重定向 + 可疑查询模式”视为高风险组合，这种思路很适合沉淀到应急判定中。

3. xp_cmdshell 返回的是操作系统文本输出，这不是普通 SQL 行为，而是“数据库已能执行系统命令”

如果现场命令或审计里出现：

EXEC xp_cmdshell 'whoami';
EXEC xp_cmdshell 'dir C:\Windows\Temp';

常见结果会是：

nt service\mssqlserver

或：

 Volume in drive C has no label.
 Directory of C:\Windows\Temp
 ...

看到这种返回结果时，结论不能只写“调用了 xp_cmdshell”，而应该直接写：

  • 已确认 SQL Server 具备系统命令执行能力
  • 返回文本说明命令已在宿主操作系统上真实执行，而不是 SQL 层失败回显
  • whoami 的输出可直接帮助判断执行上下文是 NT SERVICE\MSSQLSERVER、域服务账号还是更高权限账户
  • 如果 SQL Server 服务账号权限过高，这一步就意味着数据库事件已经升级为主机控制风险

微软文档明确说明 xp_cmdshell 启动的 Windows 进程默认继承 SQL Server 服务账户的安全上下文，因此 whoami、dir、ipconfig 这类返回文本，本质上就是“宿主主机权限边界”的现场证据。

4. 先 sp_configure 开启、后 xp_cmdshell 执行、再关闭，是典型短时滥用，不像遗留业务

如果日志里出现类似顺序：

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
EXEC xp_cmdshell 'powershell -enc ...';
EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;

那么分析时优先判定为：

  • 攻击者在临时打开危险能力，目的是降低暴露时间
  • 这比“长期启用 xp_cmdshell 的老系统”更接近实战入侵动作
  • 如果启用、执行、关闭集中出现在一个很短的时间窗内，且操作者账号平时不做 DBA 变更，恶意概率非常高

这类顺序也和微软对 xp_cmdshell 的安全建议形成反证。正常环境即便必须启用，也应有明确变更和审计；现场若看到无工单、无发布背景的瞬时开关，更应按入侵优先处理。

5. 查询内容命中系统表和危险存储过程，代表的不是同一种风险

例如命令里出现：

select name from sys.databases
select * from sys.server_principals
select * from fn_my_permissions(NULL, 'SERVER')

更像：

  • 库实例枚举
  • 登录用户枚举
  • 权限摸底

而如果出现：

exec xp_cmdshell 'whoami'
sp_configure 'xp_cmdshell', 1
sp_OACreate
OPENROWSET
BULK INSERT

更像：

  • 系统命令执行尝试
  • 组件启用与能力升级
  • 外部数据交互或批量导入导出

所以你在写分析结论时，不要笼统写成“执行了可疑 SQL”，而应区分为：

  • 环境枚举阶段
  • 权限确认阶段
  • 数据转储阶段
  • 系统执行阶段

这四种阶段对处置优先级完全不一样。

0x08 一条完整的数据库攻击链应该怎么写

数据库事件的结论最好不要写成“发现数据库端口开放”“发现账号密码明文”“发现若干 SQL”。更适合交付的写法是按攻击链展开：

  1. 入口阶段 攻击者通过 WebShell、源码泄露、办公终端失陷或暴露数据库获得初始接触面。
  2. 凭据阶段 从配置、终端客户端、备份包、脚本中获得可用凭据。
  3. 验证阶段 建立数据库连接，确认账号有效与权限范围。
  4. 利用阶段 查询敏感表、导出数据、开危险组件、执行系统动作。
  5. 结果阶段 形成导出文件、压缩包、外联流量、横向或持久化。

这样写的好处是，管理层可以清楚看到“哪里开始失守”，技术团队也能据此知道“封堵点应该落在哪一层”。

0x09 建议采用的分析结论模板

数据库类事件最终建议至少输出四个层面的结论：

1. 凭据来源结论

例如：

  • 凭据来源于站点配置文件
  • 凭据来源于运维终端客户端保存配置
  • 凭据来源于备份压缩包中的历史脚本

2. 利用成立结论

例如：

  • 已确认使用该凭据成功连接生产数据库
  • 暂仅确认凭据泄露，未确认成功连接
  • 已确认通过应用主机中转访问数据库

3. 行为定性结论

例如：

  • 仅发生库表枚举和权限试探
  • 已发生敏感数据批量查询
  • 已发生导出与打包
  • 已发生数据库到主机执行能力转换

4. 影响范围结论

例如：

  • 影响集中于单库单实例
  • 影响扩展到多业务库
  • 已扩展到数据库所在主机及内网其他节点

这样的交付方式，比单纯罗列日志更能支撑处置、汇报和后续追责。

0x0A 建议的交付表

数据库分析结果建议整理为如下表格：

时间证据源事件关联对象结论
01:22:11应用配置发现明文连接串application.yml凭据泄露源
01:24:03进程 / 网络mysql 连接建立10.0.0.12:3306攻击者成功访问数据库
01:25:19数据库日志执行批量查询user, order 表开始取数
01:27:41文件时间生成导出文件/tmp/db.sql.gz数据已转储
01:29:05外联流量对外发送大文件可疑 IP疑似数据外传

这种结构能很好支撑技术复盘、管理汇报与后续法证固定。

0x0B 总结

数据库分析的关键，不是单纯证明“这里有一个 MySQL/MSSQL/Redis 服务”，而是要完整回答：

  • 攻击者如何获得了连接能力
  • 是否真正建立了数据库访问
  • 做了哪些验证、查询、导出、提权或驻留动作
  • 数据是否已经被带离现场
  • 数据库在事件里究竟是数据目标、执行通道，还是长期据点

当你把配置文件、终端客户端、数据库日志、主机进程、文件转储和外联痕迹串成同一条链，数据库分析才真正从 0x02 的“证据入口”升级为 0x03 的“事件定性、影响评估与攻击链重建”。