14号上午接到同事报告,某主机cpu占用至100%并出现可疑进程,安全部接手调查后结论如下:
分析过程如下:
登入主机后,找到可疑进程PID
进入proc/进程目录找到对应文件绝对路径在/usr/bin目录下,stat信息如下:
#!bash [[email protected]
13146]# stat /usr/bin/faksiubbri file: `/usr/bin/faksiubbri' Size: 610224 Blocks: 1200 IO Block: 4096 regular file Device: 802h/2050d Inode: 312739 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-01-14 10:33:13.000000000 +0800 Modify: 2015-01-14 10:29:06.000000000 +0800 Change: 2015-01-14 10:29:06.000000000 +0800 [ [email protected] 13862]# stat /usr/bin/ohzxttdhqk file: `/usr/bin/ohzxttdhqk Size: 625622 Blocks: 1232 IO Block: 4096 regular file Device: 802h/2050d Inode: 312741 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-01-14 10:32:59.000000000 +0800 Modify: 2015-01-14 10:29:26.000000000 +0800 Change: 2015-01-14 10:29:26.000000000 +0800
初步判断入侵时间在14号上午10:29分附近并且已有root权限
通过strings查看文件内容发现远程ip及其他信息
搜索ip发现为香港主机,并且在微博上发现如下信息
结合strings其他信息,确定该文件为恶意程序,目前首先要判断攻击者通过什么途径入侵进来,此处绕了一些弯路,原因如下几点:
后来有同事在网上查到该ddos后门通过ssh暴力破解方式传播,才重新把目光放到ssh。与相关人员确认得知,服务器由于特殊原因对外开放了22端口,并且机器为弱口令,结合此信息,推测服务器为暴力破解ssh入侵,故排查secure日志
6台外网主机有ssh验证成功记录,时间在13号21:12至23:59分之间,其中ip118.193.199.132与ip104.149.220.27在secure日志中无密码错误记录,推测为使用其它主机暴力破解,成功后返回密码使用其余主机登录
查看cron日志发现每3分钟会执行两个恶意脚本
/etc/cron.hourly/cron.sh /etc/cron.hourly/udev.sh
cron.sh文件内容如下
其中/lib/libgcc.so通过文件大小及strings部分内容基本确定与/usr/bin下的恶意程序ohzxttdhqk相同
udev.sh文件内容如下
其中/lib/libgcc4.so通过文件大小及strings部分内容基本确定与/usr/bin下的恶意程序faksiubbri相同
分别查看第一次执行计划任务时间如下
时间上与暴力破解成功时间吻合,基本可判断后门程序通过ssh途径被植入
查看secure日志,取之前发现ip成功验证ssh至断开连接时间差,结果如下
221.235.189.229
62.210.180.180
103.41.124.48
118.193.199.132
175.126.82.235Jan 13 23:22:23成功认证后无断开信息
104.149.220.27
通过成功验证ssh至断开连接时间差可看到221.235.189.229、62.210.180.180、103.41.124.48时间差为0,推测暴力破解成功后无其他举动,那么结合计划任务运行时间与时间差信息可判断种植后门的两个ip应该为118.193.199.132与175.126.82.235
但118.193.199.132时间差也仅有5秒钟时间,人工很难完成种植后门的操作,由此判断是自动化程序完成
目前疑点主要为不清楚后门通过什么方式被部署进来?
验证发现通过scp远程拷贝文件至主机与ssh登录后退出都会产生Received disconnect的日志,如果通过ssh自动化部署,last为何会看不到记录?是否单独清除了相关记录?如果是scp远程拷贝,是通过什么方式执行程序的?目前暂不知晓通过何种方式可以仅将文件放入机器后可以让程序自动执行,是否还有其他部署方式?
排查其他主机是否存在恶意文件,可注意以下几点:
修复主机bash漏洞
增加主机密码复杂度(包括重要端口不对外主机)
针对异常情况主机,安全人员排查前尽量不要有操作,如果需要对文件有操作,一定要先保存stat信息结果,备份文件内容,修改密码/新建账户/删除账户前一定要先 stat /etc/passwd
与 stat /etc/shadow
并保存执行结果
以上内容为之前对公司层面写的一份应急响应报告,大家可以参考下流程,有一点需要改正的是判断入侵途径这里因为主观判断认为不会是ssh入侵导致浪费了不少时间,在分析过程陷入瓶颈的时候,应该以多看日志为主,而非大脑空想,最后补充几个linux下应急响应中常用到的一些思路和命令,希望对大家有所帮助
web类入侵事件可结合以下几点排查:
查找一天内修改过的文件命令
#!bash find /home/work –mtime -1 –type f
查找系统中包含指定字符的所有文件(可以拿已知shell密码及特定字符作为关键字)
#!bash find /|xargs grep -ri "Bot1234" -l 2>/dev/null(执行后会改变所有文件的atime,请做完5中提到的点之后操作)
查看较大的日志文件时,可先通过fgrep指定字符筛选,比如已知shell文件为conf.php,可通过命令 fgrep –a ‘conf.php’ accesslog > conf_access
来筛选conf.php的访问记录,如果为一些高危漏洞,也可根据漏洞利用的关键字来筛选,通过第一步筛选结果后可找出入侵者ip等信息,可继续通过这些信息在accesslog中找到攻击者的所有访问记录以便进一步排查
判断影响时,当webshell操作为post且无流量镜像时,判断一些敏感文件如源码打包文件、包含密码信息文件是否被读取可通过文件atime信息来判断,此外对webshell的请求条数以及返回的字节数都可以作为定损的大概依据
主要通过其他高危服务,目前遇到的案例中大多属于ssh对外且弱口令的情况,主要结合syslog判断
此外,可结合以下几点排查:
netstat –an
查看是否已与外部可疑服务器建立连接,如已建立需及时断开 ls –al
查看exe对应值可得知文件路径,另外可查看计划任务,后门程序为保证自启动往往会添加新的计划任务