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

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

很多入侵事件里，真正高价值的目标不是 Web 服务器本身，而是它背后的数据库。攻击者拿下一台业务主机后，下一步往往就是寻找数据库连接信息、读取业务数据、导出敏感表，甚至把数据库服务直接变成新的持久化或横向落点。

在 0x02电子取证 里，服务信息检查、异常端口查询、系统用户审查 已经覆盖了数据库相关的基础入口，比如服务状态、监听端口、可疑进程、系统账号与共享情况。到了 0x03取证分析，重点就变成了如何回答：

• 数据库是否被攻击者真正接触过？
• 凭据是从哪里泄露的？
• 攻击者是本机访问、远程登录，还是通过应用中转？
• 是否发生了导库、打包、外传或权限升级？

0x01 数据库分析的核心问题

数据库取证可以围绕五个问题展开：

1. 数据库实例是否暴露？ 看监听地址、端口、账户与访问控制。
2. 凭据是如何获得的？ 看配置文件、源码、环境变量、客户端历史、备份文件。
3. 数据库是否被成功连接？ 看数据库日志、客户端工具痕迹、网络连接与进程链。
4. 攻击者做了什么？ 看查询日志、导出语句、权限变更、UDF 或作业创建。
5. 数据是否被带走？ 看导出文件、压缩包、临时目录、出站流量。

如果能把这五个问题闭环，数据库事件就能从“可能有风险”升级为“已确认被利用”。

0x02 从服务和端口判断数据库暴露面

数据库分析往往从最基础的“它是否在线、是否可达”开始。

1. 典型数据库监听端口

常见目标包括：

• 3306：MySQL / MariaDB
• 1433：MSSQL
• 5432：PostgreSQL
• 6379：Redis
• 27017：MongoDB
• 1521：Oracle

但真正要注意的不是端口号本身，而是：

• 监听在 127.0.0.1 还是 0.0.0.0
• 是否存在非标准端口伪装
• 谁在连接它
• 服务进程是否由异常父进程拉起

2. 与 0x02 证据项的衔接

这一步可直接承接：

• 服务信息检查
• 异常端口查询
• 系统共享检查

例如在 Windows 上，如果你看到：

• mysqld.exe 正在监听
• 同时存在 net share 暴露的备份目录
• 又有可疑进程频繁访问 3306

这就不再是“数据库存在”，而是“数据库可能已被当作攻击重点”。

0x03 数据库凭据最常从哪里泄露

大部分数据库失陷并不是因为攻击者先爆破了数据库，而是因为他们先拿到了数据库连接信息。

1. 应用配置文件

最常见泄露位置：

• Java 的 application.yml、application.properties
• PHP 的 config.php
• Python 的 .env、settings.py
• Node.js 的 .env、config.js
• 容器环境变量与启动参数

典型高风险特征：

• 明文账号密码
• root / sa / dba 高权限账号
• 多环境共用同一套连接串

2. 备份与导出文件

高频泄露位置：

• .sql 备份
• 运维文档
• 压缩包
• 自动化脚本
• Jenkins / GitLab / Ansible 配置

攻击者往往不需要真正理解业务代码，只要找到一个包含连接串的备份包就足够了。

3. 客户端工具与历史记录

这是最容易被忽视的一类凭据来源：

• mysql_history
• psql 历史
• Navicat 连接配置
• SQL Server Management Studio 配置
• DBeaver / DataGrip 连接信息

攻击者拿下开发机或运维机后，常常直接从这些工具里薅到数据库连接信息，而不是去猜密码。

0x04 如何判断数据库是否被真正访问过

拿到凭据不等于成功利用，下一步要判断是否真的连上了数据库。

1. 网络与进程侧证据

重点观察：

• 业务主机或办公终端是否对数据库端口建立连接
• 是否有命令行工具或客户端进程启动
• 连接时间是否与告警时间、文件落地时间一致

典型进程包括：

• mysql, mysqldump
• sqlcmd, osql
• psql
• redis-cli
• 各类 GUI 客户端

如果出现“攻击者落地 -> 读取配置文件 -> 随后立刻连接数据库”的顺序，利用链就非常清晰。

2. 数据库日志

不同数据库日志能力不同，但都应重点关注：

• 登录成功 / 失败
• 来自异常主机的连接
• 高危 SQL
• 用户创建与授权
• 导出和备份动作

高风险行为包括：

• SELECT ... INTO OUTFILE
• mysqldump
• xp_cmdshell
• Redis 的 CONFIG SET dir / dbfilename
• MongoDB 批量导出

这类动作基本上都具有极强的攻击语义。

0x05 四类高危数据库攻击行为

1. 读取敏感表

攻击者最先关注的通常是：

• 用户表
• 管理员表
• 凭据表
• 手机号 / 邮箱 / 身份证类业务表
• 支付、工单、订单、日志审计数据

如果数据库查询日志里出现大范围 select *、分页扫表、主键递增导出，往往说明攻击者已进入“取数阶段”。

2. 导出数据库

典型表现：

• 生成 .sql、.csv、.txt
• 临时目录出现转储文件
• 系统中出现压缩包或切片文件

数据库失陷真正的业务风险通常在这一阶段才发生实质扩大。

3. 提权或执行系统命令

不同数据库有不同危险点：

• MySQL：UDF、SELECT INTO OUTFILE
• MSSQL：xp_cmdshell、SQL Agent Job
• Redis：写 SSH 公钥、改持久化目录
• PostgreSQL：COPY TO PROGRAM

一旦攻击者把数据库能力转为系统命令执行，事件性质就会从“数据接触”升级为“主机控制”。

4. 建立长期访问

攻击者可能会：

• 创建隐藏数据库用户
• 授予远程访问权限
• 调整白名单或监听地址
• 留下自动备份导出脚本

这一步与 0x03 中已经补过的持久化分析天然相关。

0x06 凭据泄露链的典型路径

数据库事件非常适合按“凭据泄露链”来组织：

场景一：Web 应用源码泄露

1. 攻击者通过 WebShell 或代码仓库获得源码
2. 从配置文件中提取数据库连接串
3. 使用客户端工具或脚本连接数据库
4. 导出敏感表并打包外传

场景二：办公终端失陷

1. 攻击者控制开发 / 运维终端
2. 读取 Navicat、DBeaver、SSMS 配置
3. 复用保存的账号密码登录数据库
4. 进行批量查询与导出

场景三：Redis / MSSQL 被当作主机突破点

1. 数据库服务对外暴露
2. 凭据弱口令或匿名访问
3. 攻击者借数据库机制写文件、开命令执行
4. 主机被接管

这三类场景虽然入口不同，但分析方法一致：都要把“凭据来源、连接建立、危险操作、后续危害”串起来。

0x07 数据导出与外传的识别方法

数据库真正造成业务损失，往往不是“被看了一眼”，而是“被大量导出并带走”。

应重点关注以下信号：

• 临时目录出现新的 .sql、.csv、.gz、.7z
• mysqldump, pg_dump, bcp, expdp 等工具执行痕迹
• 数据库服务器或应用服务器对外传输大文件
• 出站流量在数据库访问后明显增加
• 共享目录、NFS、SMB 中出现转储文件

这也是为什么数据库分析必须与：

• 异常端口查询
• 系统共享检查
• 命令行历史取证
• 浏览器痕迹与下载执行链分析

一起看，而不能只停留在数据库本身。

0x08 实战中的三个误区

1. 看到数据库端口就等于被入侵

服务存在、端口开放，只能说明暴露面。是否真的被利用，还需要连接记录、日志和导出痕迹支撑。

2. 只看数据库日志，不看客户端与配置侧

很多数据库没有开启足够详细的审计，真正能说明“凭据是如何到攻击者手里的”，往往是源码、配置、客户端工具和终端日志。

3. 只关注数据，不关注数据库作为跳板的能力

Redis、MSSQL、MySQL 在某些场景下都可以被攻击者用来实现系统级动作。数据库事件既可能是数据窃取事件，也可能是主机接管事件。

0x09 建议的交付结构

数据库取证结果建议整理为如下表格：

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

0x0A 总结

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

• 攻击者如何获得了连接能力
• 是否真正建立了数据库访问
• 做了哪些查询、导出、提权或驻留动作
• 数据是否已经被带离现场

当你把服务、端口、配置文件、客户端历史、数据库日志与外传痕迹串成同一条链，数据库分析才真正从 0x02 的“证据入口”升级为 0x03 的“事件定性与影响评估”。