freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

分享一次应急响应简述
2019-09-26 13:20:06

一、背景

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

通过电话了解到的大致内容为:该系统已处于瘫痪状态、系统属于内网未对互联网开发端口、操作系统为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月份已被删除过,但是由于系统未重启,该服务还存在,最后我清理注册表。

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

三、总结

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

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

*本文原创作者:bbbbbbig,本文属于FreeBuf原创奖励计划,未经许可禁止转载

# 应急响应 # 排查
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者