当MSSQL成为攻击跳板

一次真实入侵事件的技术复盘

0x01 来自日志的警告

2025年4月3日，我闲来无事看了一眼火绒的日志。两条告警记录赫然在目：

这两条告警让我感觉不太对劲，这显然是有人在尝试入侵我的数据库，并试图通过数据库创建系统账户，于是我立刻开始分析。

0x02 漏洞定位

软件排查

近期接了一个项目，要扩展生产环境中的一些功能，生产环境中使用的是Sql Server 2014，当时接下项目之后，为了在本地模拟生产环境，我从Msdn,I tell you 下载了Sql Server 2014的iso镜像并安装，一开始我在想会不会是MsdnItellyou上的iso镜像被篡改了？经过一系列文件对比和火绒的全盘查杀以后，没有发现任何异常，基本排除软件问题。

致命错误

当我打算登录SQL Server，点击Connect按键时，突然那个SQL Server Authentication的字样和sa账户让我意识到一个致命的错误，我开了混合模式的身份验证模式，而MSSQL默认会在所有IP上监听服务，最关键的是，密码是最常见的弱密码123456。

按下登陆后，返回密码错误提示，这意味着密码已被攻击者篡改，控制权彻底丢失。

路径重建

在大概弄懂攻击者是如何入侵的之后，我开始重建攻击路径：

攻击者通过扫描暴露在校园网的1433端口，然后针对sa账户进行暴力破解，登录成功后通过xp_cmdshell执行系统命令，创建系统账户后执行后续操作，根据火绒拦下来的日志，我上网查了下，这个k8h3d k8d3j9SjfS7这组账号密码可能和永恒之蓝漏洞有关，还好在第一步就被杀软拦下来了。

0x03 后续及反思

定位漏洞后，我立刻彻底重建了整个数据库服务器，并采取更为严格的访问控制措施，仅允许通过Windows身份验证的方式进行登录，以增强安全性。

之前98上就有帖子，说是校园网内网的网络环境并不太平，我的服务器上运行的fail2ban已经累计封禁了三十多个IP，经过这件事也让我更加意识到网络安全的问题，VPN等接入方式可能成为反向渗透通道，开发环境也应遵循最小权限原则。

此次事件中，攻击者在控制数据库后没有立即进行破坏，而是试图建立持久化通道。这提醒我们：现代攻击更多追求隐蔽性，安全防护必须形成身份验证、行为监控、网络隔离的闭环体系。