1. 事件复盘一个端口引发的全盘危机1.1 攻击路径还原上周接到一个做制造业的朋友电话声音都是抖的公司ERP系统全部瘫痪所有业务部门停摆客户的订单数据、生产计划、财务对账表全被打不开了桌面上多了一堆勒索信被加密的文件后缀清一色变成了.weax。我到现场之后第一件事不是急着看病毒而是把网络拓扑、服务器清单、最近几天的登录记录全部拉出来。结果发现事情比想象中简单也正因为简单才让人脊背发凉攻击者没有用什么零日漏洞也没有搞什么复杂的社会工程学就是扫到了公网开放的一台SQL Server1433端口直接暴露在互联网上然后用sa账号弱口令爆破成功通过数据库自带的扩展存储过程执行系统命令把勒索payload下载下来运行前后不过十几分钟。整个攻击路径还原下来是这样的公网端口扫描识别1433 - 尝试SQL Server弱口令爆破 - 登录成功获得数据库权限 - 开启xp_cmdshell - 通过xp_cmdshell执行PowerShell脚本下载勒索程序 - 运行勒索程序加密全盘文件 - 写入勒索信 - 清理操作日志这年头像样的攻击者早就不跟你搞什么花活了。用最快的路径拿到服务器权限直接把核心业务文件一锁张嘴要钱。这一套玩法成熟得很几乎每天都有企业栽在上面。1.2 为什么偏偏是1433端口很多人不理解服务器上有那么多服务又不只有一个端口为什么攻击者偏偏盯上1433因为1433这个端口太“肥”了。它是什么是微软SQL Server数据库的默认监听端口。你能想象一个开放了web服务的端口背后可能是某个个人博客但开放了1433端口的机器背后大概率跑着的是企业里的核心业务数据库ERP、CRM、生产管理系统、报表系统全都在里面。数据库里存着的东西不是代码就是数据加密之后对企业来说是致命的。更要命的是1433端口极其容易被扫描发现。互联网上任何一个角落只要拿扫描工具对整个网段跑一圈所有公网IP上开放了1433的机器全都会被标记出来。扫描器根本不关心你公司叫什么、规模多大它只关心这个端口开着而且登录口令弱的话一台台试过去总有一台会破。我处理过好几起类似事件十有八九都是同一套剧本。所以在服务器上把1433端口暴露到公网跟把公司金库大门的钥匙挂在门外就差一个“欢迎光临”的牌子了。2. .weax勒索病毒与SQL Server弱口令一对“黄金搭档”2.1 .weax病毒是什么来头.weax这个后缀是近两年活跃度很高的一类勒索病毒变种的加密标记。这类病毒专门盯数据库服务器进入系统之后会遍历所有磁盘加密包括数据库文件.mdf、.ldf、备份文件.bak、文档、图片在内的几乎所有业务文件然后留下一个勒索说明文件告诉受害者“你的文件已经被加密请联系XXX邮箱”。为什么这类变种喜欢挑数据库下手因为数据库服务器的数据实时性太强了。个人电脑丢几个照片可能忍忍就过去了但企业数据库一旦加密等于整个业务停摆一天损失可能就比赎金还高。攻击者正是拿捏了这种心理才把矛头对准企业核心服务器。我在处置过程中特别注意到了一个细节被加密的文件列表里除了数据库文件还有放在同一台机器上的共享文件夹、临时导出报表、业务系统的配置文件。这说明勒索程序并不聪明它不会分辨哪些是系统文件哪些是业务文件它只会机械地遍历所有它能读到的目录能加密的全部加密。这也是为什么要把数据库服务器和文件服务器做物理隔离否则一个失守隔壁全遭殃。2.2 入侵链条拆解从爆破到加密只需几分钟我们详细拆一下这次攻击的每一步你就知道为什么我说“几分钟”不是在夸张。第一步扫描。攻击者用自动化工具扫描公网IP段识别出开放1433端口的主机批量记录IP地址。第二步爆破。拿一个装满常用密码的字典对着sa账号疯狂尝试。这里我要说一个扎心的事实很多企业DBA设置的数据库密码比如Admin123、Pssw0rd、123456、sa、sql2008几乎全在攻击者的字典里躺着。我这次遇到的案例密码是Qf2023这种看起来“挺复杂”的组合但依然被爆破了因为它是从历史泄露密码库中组合出来的攻击者用的字典足够大撞库成功率远比你想象的高。第三步登录并提权。拿到sa账号之后攻击者就有了这个数据库的最高权限。注意只拿到数据库权限还不够还差最后一脚——把系统命令跑起来。第四步开启xp_cmdshell。SQL Server里有个扩展存储过程叫xp_cmdshell可以执行Windows系统命令。微软默认它是关闭的但不少DBA为了方便做定期任务或者某些运维操作会把它打开。如果它开着攻击者等于直接拿到了Windows操作系统的shell权限。第五步下载payload并执行。通过xp_cmdshell执行一条PowerShell命令从攻击者控制的服务器上下载勒索程序然后静默运行。勒索程序开始遍历磁盘、加密文件、写入勒索信。第六步清理痕迹。攻击者会删除SQL Server错误日志、Windows事件日志把入侵痕迹掩盖掉让溯源难度大增。整个链条最可怕的地方在于它根本不需要什么高超的技术任何一个照着教程操作的人都能复现。这也是为什么弱口令高危端口是这么多年都排第一的安全风险组合。2.3 xp_cmdshell数据库失守的最后一道锁xp_cmdshell这个东西我这么多年见了太多因为它出事的案例了多到我觉得该单独拎出来骂一遍。它是微软SQL Server内置的一个扩展存储过程功能很简单在数据库里执行一条命令直接调用Windows操作系统的cmd.exe来解释执行。也就是说你在SQL Server里敲一句EXEC xp_cmdshell whoami;返回的居然是Windows系统当前的用户名。这就意味着数据库权限和操作系统权限之间的墙被一扇门打通了。攻击者拿到sa账号后只要有这扇门就能从数据库直接跳转到服务器系统层面。问题是这扇门默认是锁着的。微软从SQL Server 2005开始默认禁用xp_cmdshell但架不住很多DBA有业务需求比如要在数据库里跑批处理、调用外部程序图省事就执行一遍EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 1; RECONFIGURE;开完之后也没想着用完再关甚至完全忘了这回事。于是这台服务器的“数据库权限”就变成了“系统管理员权限”和林肯轿车一样脑门贴了个“请爆破我”的标签。我的建议很简单如果业务没有强需求xp_cmdshell永远保持关闭状态。如果确实需要也必须是专人审批、操作完成后立刻关闭并且数据库账号要使用强密码。别拿“业务需要”当挡箭牌出了事损失的可不是一个配置项能挽回的。3. 应急响应实战发现感染后我做了什么3.1 第一优先级断网隔离防止横向扩散很多管理员发现服务器中了勒索病毒之后的第一反应是“赶紧杀毒”这是最大的误区。你在这台机器上杀毒的同时勒索程序可能已经在局域网里横向扫描其他共享目录了晚隔离一分钟可能多加密十台机器。我当时到现场干的第一件事不是去看病毒而是拔网线。把受害服务器从网络里物理隔离出来交换机上直接shutdown对应端口同时把同一网段内的其他服务器、办公网做了临时访问控制。因为从经验上看这种入侵往往不是单点的攻击者可能已经通过这台数据库服务器作为跳板在内网里横向移动过了。断网隔离之后还要确认一件事攻击者有没有留下后门账号。我在检查时就发现这台Windows服务器上多了一个名为sqladmin的隐藏管理员账号。这种后门账号通常是通过xp_cmdshell创建的攻击者先建一个账号然后再用这个账号做后续操作。所以隔离之后我立刻把所有管理员组成员全部列出来逐一比对确认哪些是正常账号哪些是多出来的。3.2 取证留档给后续溯源留后路断网隔离之后不要急着重启机器、不要急着清理文件先把证据保留下来。因为重启会清空内存中的线索清理文件会丢失加密痕迹这些对后续溯源、甚至数据恢复都至关重要。我在现场按这个顺序做了留档对屏保、桌面、磁盘根目录的勒索信拍照记录勒索信里的联系方式通常是邮箱、比特币地址如果有、被加密文件的扩展名。在被加密目录执行dir命令把文件列表输出到文本保存记录被加密的文件类型分布。记录系统进程和网络连接。断网前如果来得及执行netstat -ano把当前活动连接导出来再配合tasklist /v保存进程快照这些信息能帮你判断是否有外部C2连接。保留SQL Server错误日志和Windows事件日志导出之后另存到移动硬盘上。特别是登录成功事件、进程创建事件、PowerShell执行事件。最关键的一步把整块硬盘做成镜像。有条件的用工具做磁盘镜像没条件的至少把重要的未加密文件和被加密文件复制一份出来然后原磁盘保持原状不要在上面再做任何写操作。之后数据恢复的时候这块原始镜像就是唯一的希望。留档这件事很多企业出事的时候根本没意识等到要找攻击者、要推断加密密钥规律的时候才发现啥都没留下那才是真的叫天天不应。3.3 排查失陷范围不只看数据库服务器很多人在应急响应的时候犯一个错误只盯着一台中毒的服务器看忽略了攻击者可能已经横向移动过。这次事件里除了数据库服务器我还检查了下面这些机器域控服务器攻击者会不会拿到这台机器之后直接dump域控hash然后登录域内所有机器所以域控是重点对象。备份服务器这是最容易被忽略的。攻击者进入内网后第一件事往往不是加密而是先找到备份服务器把备份干掉这样受害者才不得不掏赎金。我们检查时发现备份服务器的备份任务几天前就被禁用了日志里出现了异常登录。文件服务器共享文件如果被加密影响范围会扩大数倍需要确认它是否也被渗透。运维跳板机如果运维平时用某台机器管理所有服务器攻击者拿到这台机器就等于拿到了整个机房的控制权。排查方法不复杂重点看Windows事件日志里有没有异常登录记录、有没有非正常时间段的RDP登录以及各服务器上有没有新出现的计划任务、启动项、服务。横向移动的痕迹是藏不住的只是很多人不知道去哪看。4. 数据恢复与业务恢复没有备份怎么办4.1 勒索病毒加密机制简析要说数据恢复先得搞明白一件事勒索病毒到底是怎么加密文件的。目前主流的勒索病毒包括这次遇到的.weax变种采用的都是混合加密方案。简单说就是为每个文件生成一个随机的对称加密密钥用这个密钥和AES算法快速加密文件内容然后再用攻击者控制的RSA公钥把这个AES密钥加密打包存放在文件末尾或单独的文件里。这意味着什么意味着如果没有攻击者手里的RSA私钥理论上你不可能解密文件内容。AES密钥是随机生成的解密AES密钥需要RSA私钥而RSA私钥只有攻击者有。除非算法实现有漏洞、密钥派生有缺陷否则这就是一道数学难题不是靠几台服务器跑几天能暴力破解的。所以网上流传的那些“万能解密工具”绝大多数都是骗人的。只有安全厂商拿到某个已经倒闭或公开私钥的勒索家族的解密工具才有针对性效果。看到.weax后缀就急着去下载所谓“解密软件”的朋友我劝你冷静一下别没中勒索病毒先中了钓鱼软件的招。4.2 可行的恢复途径排序既然加密本身解不开恢复业务就得靠旁门左道了。我按优先级给大家排个序离线备份恢复这是唯一可靠的方案。如果备份在异地、离线存储或者云端对象存储里而且没有被攻击者删掉直接从备份恢复。注意恢复之前要检查备份服务器本身是否也被感染否则恢复完又被加密一遍心态直接崩掉。卷影副本恢复Windows自带的“以前的版本”功能VSS快照。很多勒索程序会执行vssadmin delete shadows来删除卷影副本但偶尔也有漏网之鱼。可以试试在文件所在目录上右键选择“以前的版本”或者在命令行执行vssadmin list shadows看看还有没有可用快照。已删除文件恢复勒索程序加密原文件后通常会把原文件删除。如果磁盘上那些被删除的文件块还没被覆盖用数据恢复软件比如R-Studio、WinHex这类扫描有机会找回零星的文件。但对大型数据库来说这种恢复方式成功率极低试过的人都知道。专用解密工具只有当你确认这个变种已经有公开私钥或安全厂商发布了有效解密工具才值得尝试。否则别浪费时间。支付赎金我这里要明确说强烈不建议支付。一方面这是助长犯罪行为另一方面根据国内外多家安全机构的统计支付赎金后真正成功恢复数据的比例并没有想象中那么高还有相当一部分人付完第一次钱之后又被二次勒索。把希望寄托在犯罪分子的“诚信”上本身就是个反讽。4.3 重建业务环境的详细步骤在无备份可用的前提下怎么让业务先跑起来这次事件里我采用了“翻箱底找副本 重建环境”的组合方案。第一步在中毒服务器上翻找没有被加密的数据副本。比如数据库的.bak备份文件如果存放在另一个目录、日志传送的备份目录、数据库快照文件只要没被加密就能用。我们运气不错在一台没有中毒的测试服上找到了上周的数据库全量备份。第二步把中毒服务器从网络彻底移除重装操作系统。重装不是简单地格式化建议重新分区把原来的磁盘做低格处理确保勒索程序没有任何残留。第三步安装SQL Server时的几个关键点不要使用默认实例名和默认端口1433换个非标准端口降低被自动扫描命中的概率。安装完成后立刻禁用sa账号或者给sa设置一个真正的强密码。不要一上来就开xp_cmdshell等到确实需要再开用完就关。将服务运行账号从管理员组降到普通账号限制数据库进程的最小权限。第四步从找到的备份文件恢复数据库。恢复之前先在新环境做一个病毒扫描确认备份文件没有被感染。恢复之后逐一核对数据完整性和相关业务系统能否正常连接。第五步修改所有相关系统的密码。数据库账号、Windows管理员、应用系统的连接字符串全部更换因为攻击者手里可能已经记录了内网一批账号密码。这次的恢复过程持续了一整夜好在业务数据保全了下来。但凡是备份也被一起清掉的情况那就不是熬夜的问题了而是业务可能直接伤筋动骨。5. 长期防护把1433端口的安全债补上5.1 端口层面的收敛策略事件平息之后我给这家企业做了一套完整的加固方案核心思路就是一条1433端口绝对不允许直接暴露在公网。这里给大家一套可以“抄作业”的收敛策略默认拒绝云安全组和防火墙的默认策略是拒绝所有入站规则谁需要访问就单独加白名单而不是先放通所有端口再一个个禁。数据库端口内网化1433端口只允许内网网段访问业务服务器通过内网IP连接数据库应用服务器到数据库之间不经过公网。白名单源IP如果确实有远程连接数据库的需求不是直接把端口映射到公网而是在防火墙层面把源IP限定为固定的办公网IP、公司出口IP。很多企业管理人员的移动办公IP经常变那就改用堡垒机统一访问堡垒机上做账号管理和操作审计数据库端口对运维人员的本机都不用直接放行。别用默认端口修改SQL Server默认端口配合上面几条能有效降低扫描器把你当靶子的概率。注意改端口不是“隐藏安全”只是减少无差别攻击命中的概率真正的安全还得靠认证和授权。别小看这几条能把大多数“脚本小子”挡在门外。真正有耐心盯着你们公司定向攻击的人也多半不会用爆破这种方式了。5.2 SQL Server自身加固清单端口问题解决之后数据库自身的安全配置也要补齐。我列一份加固清单照着做基本能挡住绝大多数自动化攻击禁用或重命名sa账号sa账号是攻击者字典里的“头号目标”最好的处理方式就是禁用。如果某些老系统必须用它至少改为极其复杂的密码并限制来源IP登录。启用密码策略SQL Server账号一律启用强制密码复杂度密码长度建议14位以上经常更换。关闭非必要组件除了xp_cmdshell还要检查Ole Automation Procedures、SQL Mail等容易被利用的功能是否开启不用的全关掉。登录审计开启“失败登录”和“成功登录”的审计至少要保留90天的日志方便日后溯源。权限最小化应用连接数据库不要用sa这种超级管理员单独创建数据库用户只授予该用户所需库的读写权限连ddl权限都不要给。补丁管理及时给SQL Server打安全补丁。很多攻击事件里都利用了SQL Server的已知漏洞而这些漏洞往往在一年前就有官方补丁了但企业就是没打。5.3 纵深防御体系搭建靠一个密码、一个端口收敛就想高枕无忧那是远远不够的。安全的核心思想是纵深防御就算某一层被突破后面还有第二层、第三层挡着。我建议企业至少要搭这么几层防线网络层防火墙/安全组收敛端口内网做VLAN隔离数据库服务器和应用服务器、办公网分段管理就算办公网中毒了数据库那一层还可以不受影响。主机层安装EDR或HIDS类防护软件设置进程白名单和敏感操作告警。勒索程序一旦运行EDR会在它加密大量文件之前就发出告警甚至自动阻断进程。数据库层数据库账号双因子认证、敏感操作审计、备份文件加密。SQL Server 2016以上版本支持Always Encrypted和透明数据加密TDE核心数据尽量加密存储。数据层严格执行“3-2-1”备份策略数据至少保留3份副本存放在2种不同介质上其中1份放在异地进行离线保存。然后定期做恢复演练别等到真出事了才发现备份是坏的。这里我要特别强调恢复演练。我见过太多企业备份确实做了但从来不去验证备份能不能恢复。等到出事了翻出备份一看有的是备份任务早就失败没发现有的是数据恢复到一半报错——这种情况比没有备份还让人崩溃。备份不是用来“交差”的是用来“救命”的请一定定期演练。6. 常见问题与排查技巧实录6.1 攻击溯源怎么看日志很多管理员问我服务器被入侵之后怎么揪出来攻击者是从哪个IP进来的、做了什么操作方法说难也不难关键是要知道去哪看。SQL Server层面打开SSMS在“SQL Server日志”里可以查看完整的登录记录。重点找登录成功但不是正常工作时间、来自异常IP的记录。尤其是sa账号登录成功的记录那是重大嫌疑。SQL Server错误日志文件默认在ERRORLOG1、ERRORLOG2这些滚动文件里里面记录了每次登录成功的来源IP。Windows层面查看事件查看器里的安全日志事件ID 4624是登录成功4625是登录失败。重点关注类型为3网络登录的4624事件以及紧接着出现的进程创建事件4688看看攻击者执行了哪些命令。PowerShell层面的日志也很关键。如果攻击者通过PowerShell下载和执行了payload那么在\Microsoft-Windows-PowerShell/Operational日志里能看到完整的执行记录命令内容都记录下来了。这次事件里我们就是从PowerShell日志中找到了攻击者执行的那条下载命令从而还原了他的C2服务器地址。实战排查顺序先用防火墙日志找出访问1433端口的源IP再拿这些IP去SQL Server日志里匹配登录记录最后看对应的Windows日志确认操作序列。有这几个维度交叉验证攻击路径基本能还原出来。6.2 数据库被加密后如何排查和恢复问得最多的问题永远是数据库文件被加密了有没有办法把数据捞出来。先说结论如果连备份都没有常规手段基本无解。但有一个很多人都忽略的“窗口期”如果数据库文件被加密时SQL Server服务进程还在运行那么内存中可能还有部分数据页的缓存。这时候进行内存转储有一定概率能提取出部分数据碎片。但对大部分企业来说这需要专业的数字取证设备和技术人员成本极高而且恢复出的数据也是不完整的拿来做临时应急还行指望它能还原整个业务库不现实。另一条路是检查数据库日志文件.ldf有没有被加密。有些场景下攻击者只加密了数据文件.mdf但事务日志文件可能逃过一劫。如果日志文件完好可以尝试从日志中重建一部分最新的事务数据。这个操作需要比较专业的数据库知识且恢复出来的也是部分数据。最靠谱的思路还是回到备份。如果你平时用“完整备份差异备份日志备份”的循环备份策略而且备份文件存放在异地或离线存储中那我们就可以把损失降到最低用最后一次完整备份恢复基础数据再用差异备份补上最近的变化最后用日志备份追补到出事前的时间点。这次事件之所以能在一夜之间恢复靠的就是这套备份策略。6.3 日常巡检的几个实用技巧经历了这么一遭我把这家企业的日常巡检机制也梳理了一遍分享几个不用花大钱就能落地的技巧第一定期自扫端口。拿扫描工具对你的公网IP做一次全端口扫描看看有没有不该出现的开放端口。别觉得“我们公司小没人攻击”扫描器不看公司大小只看端口开没开。建议每季度扫一次。第二密码“体检”。整理所有数据库、服务器、网络设备的账号台账定期检查有没有使用弱口令或默认口令。密码这种最容易忽视的安全点也是攻击者最爱用的突破口。第三做一次备份恢复演练。建议每半年做一次从备份介质恢复数据的完整演练记录恢复用时。如果发现恢复时间超过你的业务容忍度就要考虑优化备份策略了。第四配置告警。SQL Server启用“登录失败过多”告警Windows启用“新管理员账号创建”告警防火墙启用“异常端口访问”告警。宁可告警多到烦人也不要在沉默中被攻破。写在最后处理完这起事件后我连续几晚都在反复琢磨同一个问题如果这是一把能回到过去的钥匙在哪一个环节就能把攻击挡住答案其实很清晰1433端口不对公网开放攻击者的扫描器根本扫不到这台机器sa账号禁用或者用强密码爆破就无从谈起xp_cmdshell保持关闭数据库沦陷也上升不到服务器沦陷。这三道防线任何一道做好了这次事件都不会发生。可现实是这三道防线都失守了。它不是输在技术多高深而是输在侥幸心理和运维疏忽上。我写这篇文章不是想贩卖焦虑而是希望大家能从别人的惨痛教训里长记性。下次再有人跟你说“我们公司没价值不会有人盯着”你就把这篇转给他看看——这次被盯上的企业当初也是这么想的。