尊敬的读者

这是一篇基于91数据恢复工程师真实上门处置记录整理的手记。接到求助时，对方只说"电脑打不开文件，后缀多了个.ths"。企业不幸遭遇勒索病毒袭击，大量文件被加密手足无措？您可第一时间添加我们专业技术人员技术服务号（help5522）凭借大量实战经验，快速输出切实可行的处置方案。到现场后才发现，问题远不止一两台主机——整条办公内网的多台工作站、NAS共享存储陆续被加密，源头指向一个已经离职三个月的业务账号。处置团队从系统日志、安全日志、进程日志入手，逐层回溯，才把完整攻击链路还原出来。整场抢修的关键，不是病毒本身有多难缠，而是大量取证和止损要在"不破坏现场"的前提下完成，每一步都受制于之前留下的日志留存习惯。本文以现场手记形式，还原这次.ths事件的完整时间线、现场见闻和处置难点，供同样依赖共享盘协作的中小团队对照参考。

一、接到求助：现场初判，问题比描述严重得多

上午九点多接到电话，对方是本地一家做广告物料的小公司，说财务电脑里的台账打不开，文件名后面多了.ths。电话里先让现场人员做了一件事：拔掉那台财务电脑的网线，不要关机，不要打开杀毒软件扫描。随后安排91数据恢复工程师带干净设备上门。 到场后的第一眼，就确认了问题规模。财务电脑、前台接单电脑、设计工作站的桌面文件、项目源文件、共享NAS里的客户报价资料，均已出现批量加密文件，后缀统一为.ths。多个目录下散落着命名相近的提示文档。加密不是今天才发生，通过文件修改时间初步判断，最早一批文件在前一天夜间被处理。 现场第一个难点浮现：NAS共享存储仍处于挂载在线状态，多台工作站的网络映射盘还没有断开。这意味着攻击载荷仍可能在内网横向移动。优先动作是先切断共享访问通道，而不是急着看日志。

二、阻断与固定现场：先保住剩余数据，再做取证

按照处置优先级，第一件事不是查病毒源头，而是冻结传播链路。逐一断开所有工作站的网线、关闭Wi-Fi，通知现场人员停止访问NAS共享盘。随后断开NAS的对外共享权限，保留NAS本机运行状态不动。 在隔离完成之前，全程禁止在中毒主机上执行任何写入动作：不截图、不复制文件、不运行磁盘修复工具。现场使用另一台干净离线设备拍照留存勒索文档内容、加密文件完整名称、异常进程列表。这一步能保留下来的原始数据碎片，直接决定后续恢复的空间。 确认传播链路冻结之后，才开始系统性地导出日志。这里踩到一个现场常见难点：多家终端此前没有开启足够长度的日志留存，部分系统日志在事件后已被自动滚动覆盖。这也为后续溯源增加了难度。

遭遇勒索病毒加密文件，业务停滞损失惨重？专业应急处置不可或缺。联系我们技术团队（help5522）服务号，快速处理数据加密危机。

三、日志还原第一步：安全登录日志，锁定最早的入侵入口

溯源的核心，是从日志里找出攻击者最早进入内网的时间点与账号。首选调取Windows安全日志中的登录事件记录。 通过安全日志筛选，发现一个可疑账号在三个月前仍存在有效登录，该账号对应的离职员工已离开公司，但账号未被注销、密码未重置。日志显示，这个账号近期出现了多次非工作时段的远程登录记录，来源IP指向外部地址。这些登录动作，是整条攻击链最早的开端。 登录成功之后，攻击者通过该账号建立了远程桌面会话，期间执行了多次系统命令，为后续载荷落地做准备。这个账号原本被分配了普通业务权限，但由于离职交接不彻底，账号仍保留着访问共享文件夹、读取NAS映射目录的权限，正好被攻击者利用。 现场核对了离职员工账号的权限清单：该账号仍可访问销售合同目录、客户信息台账、NAS共享存储，这为攻击者在内网横向移动提供了入口。

四、日志还原第二步：进程日志，追踪载荷落地与驻留痕迹

锁定入口账号后，下一步通过进程日志，还原恶意载荷的落地路径与驻留机制。 查看系统进程创建记录，发现该离职账号在登录后，曾通过远程会话下载并运行了一个未签名程序，程序存放路径位于临时目录。进程执行后，逐步释放了加密模块，并写入多个持久化点位：注册表启动项、计划任务、服务项。 计划任务日志显示，恶意载荷被设置为固定周期自启动，这一机制解释了为什么加密动作在夜间触发——病毒潜伏等待，直到完成内网扫描和凭据收集之后，再统一启动加密。 进程日志中还记录到，恶意程序尝试连接外部控制地址，用于接收指令。在隔离断网之前，这些连接已经持续了一段时间，说明攻击者在这段潜伏期内完成了内网测绘，摸清了共享盘和NAS的位置。

五、日志还原第三步：文件与共享访问日志，还原横向扩散轨迹

横向扩散的还原，依靠共享访问日志和文件系统审计记录完成。 共享访问日志显示，在加密触发前的一段时间内，离职账号曾短时间大量访问共享目录，读取多份客户资料、项目源文件。这一行为与正常业务操作的访问频率存在明显差异，属于典型的恶意遍历。 文件系统审计记录则还原了加密的执行顺序：病毒优先处理共享NAS内的高价值目录，随后扩展到各工作站的本地项目文件夹。这也是现场看到NAS资料最先出现异常的原因——.ths变种会优先锁定共享存储这类集中存放业务数据的位置。 通过日志串联，完整攻击链路被还原：离职账号被外部扫描命中 → 远程登录进入内网 → 下载投放.ths载荷 → 潜伏期间完成内网测绘与凭据收集 → 优先加密共享NAS → 横向扩散到各工作站。整个过程没有借助高深的0day漏洞，核心就是那一个未注销的离职账号。

六、现场处置难点复盘：日志缺失、权限不清带来的阻力

这次处置过程中，有三个现场难点值得单独记录。 第一个难点，日志留存不足。多台终端的安全日志、登录日志，默认保留周期过短，事件发生前一段时间的关键记录已被滚动覆盖，导致无法完整还原每一步动作。事后如果想要精确锁定全部受影响文件，只能依赖文件系统层面的审计记录补全。 第二个难点，账号权限梳理困难。公司此前没有建立统一的账号台账，离职员工账号是否残留权限、是否仍被使用，长期无人核查。排查时只能逐台比对账号、逐一核对共享权限，耗费大量现场工时。 第三个难点，共享盘权限过宽。多个共享目录对所有员工开放完全控制权限，无法快速判断攻击者通过离职账号到底读取、修改了哪些目录，扩大了需要重点排查的范围。

七、现场处置后的建议：从日志和账号源头补漏洞

处置完成后，给现场留下了几条可直接落地的整改建议。 第一，离职账号立即注销并重置所有关联权限。员工离职当天，应完成账号注销、密码回收、共享权限清除、远程访问入口关闭，杜绝残留账号成为入侵跳板。建议建立离职账号清理清单，作为人事流程的一部分执行。 第二，提升日志留存标准。开启并适当延长安全日志、登录日志、共享访问日志的留存周期，配置告警规则，对非工作时段登录、短时间大量访问共享目录等异常行为及时提醒。 第三，收紧共享权限。取消"所有人完全控制"，按岗位分配只读、读写权限，关闭闲置共享目录，共享盘不再默认对所有工作站开放访问。 第四，内网账号建立台账。统一登记账号、权限、有效期，定期核查是否存在离职、调岗未清理的残留账号。 第五，延续离线轮换备份。备份介质平时脱离内网，定时接入同步，同步完成后抽样校验，避免备份随主数据一并被加密。

八、结语

这次.ths事件，从日志还原的角度看，核心突破口并不是多么复杂的技术攻击，而是一个长期无人处理的离职账号。攻击者顺着这个残留账号，远程登录进入内网，投放.ths载荷，潜伏测绘后批量加密共享资料，横向扩散到多台工作站。整条链路在系统日志、进程日志、共享访问日志里都有迹可循，只是因为平时日志留存和账号管理习惯不到位，导致溯源和处置都变得更加困难。 对于依赖共享盘协作的中小团队而言，这次处置带来的提醒很直接：安全不只在防护设备上，也藏在账号生命周期、日志留存、权限管理这些日常细节里。一个没有及时注销的账号，就可能是病毒进入内网的那扇后门。把账号管住、日志留够、权限收紧、备份离线，才是在.ths这类勒索变种面前，真正能守住底线的做法。