分享一次应急响应简述

一、背景

几周前接到某单位管理人员电话，说“您好，我单位某系统受到攻击，现系统已瘫痪（想到系统已瘫痪，心理特别慌张，要写溯源报告了），应用无法使用，需到现场进行排查”，随后简单问了一下网络情况，就匆匆赶往客户现场。

通过电话了解到的大致内容为：该系统已处于瘫痪状态、系统属于内网未对互联网开发端口、操作系统为Windows server 2008、已做断网处理。

二、现场排查

经过2小时后到达客户现场，再次与系统管理人员确认情况，得到的信息与电话沟通的内容差不多。原本想先进入系统看看情况，确认一下问题，可是有其他厂家的人员在看，也不好意思，就等着看他操作，一等就等了1个小时。这期间他主要操作还是在看系统安全日志，日志查看一直追溯到事发前1周时间，在日志的查看中并没有发现问题，如果是我在操作我也会先查看一下日志。

2.1、着手排查

通过之前的等待和其他人员的排查，在系统安全日志上并未发现存异常问题。到这里想到网络瘫痪于是有了以下想法：

想法1：系统遭受到类似于DOS或者DDOS之类的攻击； 想法2：系统存在web应用类漏洞，可能被上传了shell，系统被控制了。

但想到该系统未开发应用到互联网上，以上想法就不能成立，黔驴技穷了，一下子没思路了，不能刚刚接手鼠标和键盘就没有操作呀。顿时冷静了一下，想到既然是应用瘫痪了，那先看看网络活动的 TCP 连接情况。于是我用nestat -ano查看了tcp的连接情况，输入完netstat -ano回车后，我的妈呀！什么情况，为什么会有那么多tcp的连接，我倒是惊讶了，足足登录2分钟信息才刷新完，刷新完成后，发现有太多的TIME_WAIT等待了。

为了看的更清楚，我使用了netstat -ano | more命令，然后一页一页的翻，发现单位内部与该应用系统有通信IP的40000或50000以上的端口均处于TIME_WAIT状态。这让我想到了Windows 2008R2大量回话在TIME_WAIT状态的一个BUG，在系统启动时从 497 天后所有在TIME_WAIT状态的 TCP/IP 端口都不会被关闭。因此， TCP/IP 端口可能会被用光，并且可能不会创建新的 TCP/IP 会话。

到这里我将得到的信息反馈给管理人员，并询问了系统的开机时间，该系统已开启了500多天。管理人员并不是很接受，并说出了新的问题（这是我有开始有点慌了，难道不是这个问题嘛）“后台程序出现接口无法调用的问题”：

看到相关报错后，我更确认了我之前的想法。为了验证我的想法，我将之前看到的博客与微软的通告信息给管理人员看，最终确认问题。

相关连接如下：

https://support.microsoft.com/zh-cn/help/2553549/all-the-tcp-ip-ports-that-are-in-a-time-wait-status-are-not-closed-aft windows 2008 R2 大量会话在TIME_WAIT状态 socket-详细分析No buffer space available（转载）

该问题确认后，我又对系统进程和服务进行排查，发现该系存在WannaCry勒索病毒的服务，但未发现相关勒索病毒进程，并在杀毒软件的恢复区发现了WannaCry的文件。

通过询问后，发现该病毒在18年6月份已被删除过，但是由于系统未重启，该服务还存在，最后我清理注册表。

相关操作完成后，联系管理员重启系统，整个过程花费时间不到半个小时，最终解决问题。

三、总结

通过这次应急，我认为管理人员有时提供的信息与应急人员所需求的可能不同，很可能会误导应急人员。作为应急人员，应该有很强的逻辑能力和分析能力，另外还需要拥有自信。

新手上路，大佬勿喷，感谢。