谁能想到，一家航空公司赖以运转的数据库服务器，会在神不知鬼不觉中沦为攻击者的"遥控器"？更令人啼笑皆非的是，这场精心策划的入侵，最终竟然栽在攻击者自己手里——他们用来存放战利品的公开服务器，忘了上锁。

2026年9月下旬，网络安全研究团队在例行威胁狩猎中，意外发现了一台暴露在互联网上的服务器。顺藤摸瓜之后，一个与墨西哥廉价航空公司 Viva Aerobus 环境密切相关的入侵事件浮出水面。9月25日至29日之间，攻击者完成了一系列教科书式的渗透动作：窃取凭证、收集源代码、为横向移动铺路。而让整件事显得既专业又荒诞的，是他们选择了一条极不寻常的作案通道——把微软 SQL Server 变成执行命令和搬运文件的工具。

一条藏在数据库会话里的"隐形通道"

攻击者的核心手法，是滥用 SQL Server 内置的 xp_cmdshell 功能。这项功能的本意是给数据库管理员提供便利，启用后可以直接在操作系统层面运行命令。可在攻击者手里，它成了一把打开 Windows 系统大门的万能钥匙：通过普通的数据库会话提交 Windows 命令，再对 PowerShell 脚本进行编码混淆，数据库连接瞬间摇身一变，成为控制底层操作系统的秘密通道。

这种"数据库当跳板"的思路并不新鲜，历史上针对 SQL Server 的多起攻击都走过同样的路径——只要拿到数据库访问权限，就能绕到数据库之外执行系统命令。但这次调查恢复的证据，描绘的是入侵得手之后的操作过程，并不能证明具体的初始入侵方式。究竟是漏洞利用、弱口令爆破还是其他手法，至今仍是个谜。研究人员也未能识别出特定的恶意软件家族，因为在现场发现的更像是一套完整的工具箱，而非某个单一植入程序。

文件不走寻常路，Base64 借壳数据库回传

如果说命令执行只是开胃菜，那接下来的文件窃取手段堪称"巧思"。攻击者没有架设传统的恶意软件控制服务器，而是复用同一条数据库连接完成数据外传：工具读取目标文件内容，将其切割成若干小片段，逐片转换成 Base64 文本，再通过 SQL 查询的返回结果带出去。

Base64 本质上只是一种文本编码方式，谈不上加密，但它完美地利用了数据库响应通道作为掩护。命令从这条路进来，数据从这条路出去，全程没有任何可疑的新连接建立，防火墙和流量审计设备很难察觉异常。没有 C2 服务器、没有新增通信信道，一次干净利落的渗透窃密就这样在数据库会话的掩护下完成。

类似的"数据库功能滥用"在 Mjobtime 应用程序漏洞利用事件中也曾出现，二者异曲同工：都是借数据库的合法外衣，行操作系统命令执行之实。不过研究团队明确表示，并未将本次入侵与 Mjobtime 软件关联起来。

HTTP 日志还原出的时间线耐人寻味：9月25日16时20分，受害环境首次拉取攻击载荷；仅仅一分钟后，一台无关的主机开始"围观"这台暴露的服务器，并在两三分钟内完成了探查；到了18时04分至05分，更多外部主机前来下载工具、收集遗留工件。也就是说，从攻击者部署基础设施的那一刻起，这台"秘密仓库"就已经对全网敞开了大门。

十七件兵器悉数亮相，凭证收集成为重头戏

在攻击者遗留的公开服务器上，研究人员清点出17个命名工具，几乎完整还原了入侵后作业的每一步。其中最扎眼的，是围绕凭证展开的一系列操作。

Mimikatz 的使用痕迹赫然在目，表明攻击者曾进行凭证转储。这种手法在 HiddenGh0st 凭证窃取活动中也曾出现，尽管目前尚无证据将两起事件关联。除了内存抓取，攻击者还盯上了 Windows DPAPI 保护机制下的 SQL Server Management Studio 连接历史——那些保存着数据库用户名和密码的连接配置文件，同样被整套打包带走。

这些记录即便受 DPAPI 加密保护，依然极具价值：它们能帮攻击者快速锁定下一个目标，梳理出企业内部数据库的连接图谱。当然，文件到手不等于密码全解，但防守方绝不能抱侥幸心理。

源代码和配置文件也没能幸免。攻击者收集了大量涉及数据库连接、OAuth 认证、电子邮件、SFTP 乃至支付与报表集成的代码与配置。值得肯定的是，研究团队公开发布时做了脱敏处理，敏感值、受害主机名、用户名等私密信息一律隐去，避免这些秘密被二次利用。

其余工具则暴露出更清晰的横向移动意图：有的脚本专门对其他 SQL 系统批量测试凭据组合，有的则探测 SMB 管理共享的访问权限。种种迹象表明，攻击者在为深入内网积极铺路，只不过现有证据无法证实他们是否真的成功突入了其他系统。

比入侵更尴尬的，是黑客自己"公开了罪证"

这场事件最富戏剧性的一幕在于：攻击者存放工具与窃得资料的 loot、loot2 两个目录，居然对互联网完全公开。换句话说，最初的受害者还没发现自己被入侵，攻击者的"赃物仓库"就先被无关的路人甲逛了个遍。

安全研究团队正是通过这台疏于防护的公开服务器，才得以完整还原整个工具链。攻击工具和窃取资料被双重曝光——原始攻击者或许根本没意识到，他们费心收集的成果，早已落入其他不速之客之手。这也给事件定性带来一个新维度：就算最初的黑客没有滥用这些数据，拿到副本的第三方也未必守规矩。ThreatMon 在报告中措辞严厉地警告：只要凭证或密钥曾抵达过这台暴露的服务器，就必须视同已泄露处理，因为最初的攻击者很可能根本不是唯一的接收者。

企业该如何亡羊补牢？

对于防守方而言，这次事件敲响了多层警钟。数据库服务器绝不是"只管数据"的孤岛，任何在 SQL Server 服务账户下出现的异常行为都值得高度警惕：xp_cmdshell 被意外调用、编码后的 PowerShell 被执行、临时目录里出现可疑的文件操作，这些都应触发即时调查而非例行忽略。

已经保存的数据库连接记录和密码资料，必须按敏感资产对待。历史网络连接需要对照公开的入侵指标逐一回溯排查，端点上也该检索匹配的哈希值和已知工作目录。值得庆幸的是，截至目前调查尚未发现乘客数据、支付数据或核心商业数据失窃的证据，但这并不能成为放松警惕的理由——凭证一旦外泄，后续连锁反应可能滞后数月才显现。

从 SQL Server 到 PowerShell，从 Mimikatz 到 SMB 探测，攻击者留下的每一件工具都在提醒企业：现代渗透早已不依赖"惊世骇俗的零日漏洞"，而是把企业环境里被忽视、被默认放行的合法功能，一件件变成手里的武器。堵住这些"合法通道"的滥用，或许比追逐漏洞补丁更为紧迫。

附：公开入侵指标（IoCs）速查

此次事件披露的服务器地址为 151.243.232.123，用于部署攻击工具并存放窃得材料。关键文件哈希包括 exfil.py（c38f49ba68b891bb476510704cddf080798f3c70075e2a517e98e04e833f64fa）、upload.py（33aeaaa3d57b7785ef2be5b8ccd39d534b8af50e0cd32a5036fdb64601a52fc9）与 sqlspray.ps1（8b6c53e3d57b4c3049f3d0765a44d9a52feb6af78f1eaa5aff19daf1b9665998）。攻击者在端点上使用的工作目录为 C:\Windows\Temp\artex，公开赃物目录包括 loot 与 loot2。涉及的脚本文件涵盖 chrome_dump.ps1、cred_dump.ps1、cred_enum.ps1、sqlspray.ps1、mssqltest.ps1、vault.cmd、vtest.ps1 等，另有 exfil.py、upload.py 两件文件传输工具，以及从暴露服务器上恢复的 cred_dec.txt、mdump.txt、httpd.log 等工件。cmd.exe 与 powershell.exe 作为合法系统进程被滥用执行可疑命令，同样列入排查清单。

安全团队提醒，以上 IP 与域名信息已做脱敏处理，企业应在 MISP、VirusTotal 或自有 SIEM 等受控威胁情报平台中完成解析与比对，切勿直接访问。