金融企业网络安全应急响应之技术篇

admin 2022年1月22日01:54:19评论70 views字数 6174阅读20分34秒阅读模式

金融企业网络安全应急响应之技术篇


上篇文章讲了网络安全应急响应的一些基础理论和常规套路,这篇主要就其中的技术部分进行阐述。


一、工具包准备


如果应急响应的对象是某台可能被攻陷的主机,那在登录上去之前需要先有一些工具事先准备好才行。因为目标机器上的文件可能早就被黑客进行了篡改或替换,所以我们不能依靠目标系统的本地程序、依赖文件和系统文件去展开调查。推荐的做法是事先准备好静态编译的常用工具是很有必要的,特别是恶意软件常常为了更好隐藏自己,对文件遍历、进程列表、网络连接方面做相应的处理,所以在应急响应过程中需要重点关注,比如ls、lsof、ps、netstat等,而windows下的工具可能还涉及到依赖一些dll文件,需要提前分析依赖关系(PEview工具查看即可),将所需要的关键文件统一放到一个目录,以备不时之需。


为了提升工作效率,可以考虑做成脚本,一键运行即可开始收集,在一些不方便的场合也可以让系统管理员代为运行,只需将收集的结果回传即可进行初步分析。上个针对Windows的效果图:

 

金融企业网络安全应急响应之技术篇


这里需要说明一下,应急响应不完全等同于取证(取证严格意义上讲更专业也更严格,毕竟你在登录机器执行命令的时候从某种程度上讲就已经破坏了现场),只是利用了取证过程中常用的工具或技术提取一些信息便于分析或溯源。


二、Windows通用工具包


如果目标是Windows,需要收集的信息建议包括以下内容:


  • 系统日期和时间(date /t、time /t)

  • 主机名(hostname)、当前用户(whoami)、操作系统版本(ver)、运行时间

  • ARP记录(arp –a)、路由信息(rotue print)、DNS缓存信息(ipconfig /displaydns)

  • 用户信息(net user、net localgroup、net localgroup administrators)

  • 登录信息(psloggedon.exe)

  • 文件共享信息(net share)

  • NetBios连接信息(nbtstat -S、nbtstat –c、net session、net file)

  • 网络连接和开放端口(netstat –ano、cports.exe /scomma xxx.txt)

  • 进程信息(tasklist、pslist、pv -e、CProcess.exe /stab xxx.txt查看进程详细信息)

  • 服务相关信息(net start、tasklist /svc、serviwin.exe /scomma servicesservice.csv)

  • 系统已安装的驱动(serviwin.exe /scomma driversxxx.csv)

  • 获取主动加载DLL信息(InjectedDLL.exe /stab injectdll.txt)

  • 获取动态链接库调用信息(Listdlls.exe  > dllcall.txt)

  • 已打开的文件(OpenedFilesView.exe /scomma file.csv)

  • 文件句柄信息(handle -a >fhandle.txt)

  • 运行的历史命令(doskey /history)

  • 启动项(autorunsc.exe -a -m -v -c >autorun.csv,过滤了微软签名)

  • IE代理设置(看注册表项

  • HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings下面关于ProxyEnable、ProxyServer的内容)

  • IE浏览器历史访问记录(iehv.exe /stab iehistory.txt)

  • Firefox浏览历史记录(MozillaHistoryView.exe /scomma ffhistroy.csv)

  • Chrome浏览历史记录(ChromeHistoryView.exe /scommachromehistory.csv)

  • 最近打开的文件记录(RecentFilesView.exe /scomma recentfile.csv)

  • 最近运行的程序(WinPrefetchView.exe /scomma prefetch.cvs)


另外就是收集系统的一些文件内容和日志如hosts文件,日志可以用DUMPEVT.exe导出


  • DUMPEVT.exe /logfile=app /outfile=%ReportPath%app_log.csv /all

  • DUMPEVT.exe /logfile=sec /outfile=%ReportPath%sec_log.csv /all

  • DUMPEVT.exe /logfile=sys /outfile=%ReportPath%sys_log.csv /all


微软提供的Logparser也很方便,可以将常用语法做成脚本,需要的时候可快速运行,如下图:

 

金融企业网络安全应急响应之技术篇


还有一些关于隐藏文件、交换数据流文件及文件权限的(sfind、cacls)

有些程序输出的txt建议转换为csv方便分析(CSVFileView.exe /load xxx.txt /scomma xxx.csv)


上面介绍的工具较多,基本来源于系统自带。


微软SysinternalsSuite系列及www.nirsoft.net提供的各种小工具,平时多关注这些会很有帮助。大部分工具都有GUI界面方便查看,但如果只是方便自动化采集的话,需要用到我上面的一些参数,大家自行研究。需要注意的是,随着系统和软件的更新,有些工具可能不再适用(如WinPrefetchView)或需要适当做出调整(如firefox历史记录库文件路径)。上面列出的工具有点杂而多,有条件的企业,也可以考虑使用商业的取证工具(如Encase等),不再多说。某日,我们SOC报警发现有个外包网段的机器尝试nmap扫描触发报警,但一线人员反馈说目标机器使用者只是一个华为的销售人员根本不懂啥叫nmap,于是让一线人员在该外包机器上运行相应的程序,nmap.exe –O赫然在列,后面经过了解原来是华为在每台终端上做了这样的一个动作,当机器有连接外部时会主动触发nmap探测对方,汗!


如果机器已经被人拿到管理员权限,那可能还需要关注一下是否被安装各种后门或远控程序,有时候看看机器上的防病毒查杀日志会发现一些黑客不小心的尝试动作,如下图:

 

金融企业网络安全应急响应之技术篇


结合文件修改时间可以找到与此次事件有关的文件。还有一个场景是明确机器被黑了,怀疑中了rookit之类的怕机器不干净,一般都会拿出类似冰刃、syscheck、、PC Hunter(以前叫XueTr)的工具看看是否有隐藏进程,有哪些钩子(inline hook、SSDT hook各种),最后还不放心那就放出大招,建议重装系统算了。


三、Linux通用工具包


Linux与Windows有个显著的不同是Linux下所有对象都被当做文件来操作,当然这里的文件会比我们上面的文件更加广泛一些,不仅普通的文件,还有目录、字符设备、块设备、 套接字等在Linux中都被当做文件对待,比如进程相关的信息我们知道在/proc虚拟文件系统里能找到。客观来讲,在Linux下各种命令被恶意软件替换的概率比Windows要更大一些,跟文件(ls、find)、进程(ps、lsof)、网络(netstat)、模块(lsmod)相关的尤其需要重点关注。Linux下通常需要收集的信息建议如下:


  • 系统日期和时间(date)

  • 主机名(uname -a)、当前用户(whoami、who)、操作系统版本(lsb_release -a、cat /etc/redhat-release 、cat /etc/issue、cat /proc/version)、运行时间(uptime)、IP地址配置(ifconfig -a)

  • ARP记录(arp)、路由信息(rotue -n)

  • 用户信息(cut -d: -f1 /etc/passwd)

  • 组信息(cut -d: -f1 /etc/group)

  • 防火墙信息(iptables -nvL)

  • Tcp_Wrapper配置文件(/etc/hosts.allow、/etc/hosts.deny)

  • 计划任务(cat /etc/crontab、及各用户的var/spool/cron/USERNAME

  • 文件)

  • 登录信息(w、who、lastlog、last)

  • 历史命令记录(history、cat .bash_history)

  • 进程信息(ps aux、ps -ef、ps -eFH、ps -ealf、top、htop)

  • 查看网络连接与开放端口(netstat –anop、ss –anp 、netstat –nlp,如果只看TCP相关则加t)

  • 启动的服务(chkconfig --list或者 systemctl list-units --type=service)

  • 查看进程打开的文件(lsof -p PID)

  • 跟踪进程的库调用(ltrace -p PID)

  • 跟踪进程的系统调用和信号(strace -p PID)

  • 系统日志(/var/log/目录下dmesg、messages、audit、secure)


检测通用rookit的工具(chkrookit、rkhunter,效果感觉一般,如果企业自己有HIDS可以做一些关键文件MD5监测、读取/proc下特定的内容可以获取进程、网络、模块相关信息用于进一步比对发现异常)


Linux下有一些强大的命令可以方便对文件进行查找(find可以基于时间、权限、类型进行查找)、对日志进行分析处理的各种命令(sed、awk、sort、uniq、cut、grep),熟练掌握这些命令的组合用法会极大的提升效率(当然前提是多花时间熟悉其用法)。想起很多年前笔者面试某互联网公司的时候,对方出了个题,怎么从apache访问日志中快速找到访问最多的IP地址并按多少进行排序,当时笔者刚好在学perl,所以我回答写个perl脚本按行读取日志文件,提取IP地址并放入HASH列表,逐次加1进行统计,最后按多少哈希键值大小排序输出,估计也就1-5分钟的时间。对方说其实用linux一条命令就搞定了,给我留下了非常深刻的印象。


四、Web应用专用工具包


把web应用单独拿出来说,是因为光web常见的就有iis、apache、nginx、tomcat,可能在一些奇葩应用甚至直接用的是网上的什么LAMP、LNMP组合工具包,日志文件存放和web应用路径不固定的情况下,不太好有通用的工具包,但还是可以做一些准备工作的,比如webshell检测工具、web日志分析脚本、mysql日志异常分析脚本等。以webshell检测工具为例来说,Windows上可能大家喜欢用现成的比如D盾、360等,Linux下需要自己写或收集了。Webshell查杀往往基于特征码的较多,比如一些关键的函数如eval、system、shell_exec等;也包括一些黑客的版权信息比如4ngel、wofeiwo、c99shell等等。以下为笔者以前写的一个针对php的webshell扫描效果图:

 

金融企业网络安全应急响应之技术篇


标红的是某牛的webshell做了适当的变形处理后依然被发现,主要是基于preg_replace这个函数而已。当然基于特征是很容易被绕过的,应用上线发布做的比较好的企业,通过文件对比(比如文件的属主信息、生成时间、所在文件夹位置等)也能有效发现,或者基于文件变化监控inotify来实现,此处不再展开。平时多收集、测试、对比,在真正需要用时才能得心应手。


五、平台建设


上面这些工具,相当于医疗急救包,在有安全团队的公司,往往更多的是平台建设,比如企业部署了防病毒、防火墙、NIDS、HIDS、WAF、蜜灌、抗DDOS、DLP等系统后,会将各种安全系统在终端、网络、应用上采集的日志集中送往到平台进行关联分析(如SOC系统),再结合一些外部情报实现实时告警。并不是所有的告警都需要进入应急响应状态,前面也说了,比如针对常规扫描,可能WAF就直接拦截了,再往后,IPS报的多了可以自动调用应急处置平台上的功能进行一键全网拒绝,一般也就到此结束了,再有深入的才会进入到应急响应流程。安全平台建设,涉及面比较广,有机会单独阐述,此处不做过多展开,只结合笔者实际应急响应过程中的经验做一些补充。


在实际的工作过程中,可能会碰到有IPS告警但没有采集系统日志、应用日志,那如果要对告警进行更深入的分析,可能还得到系统上去将日志导出再分析,传统的通过文本编辑器查看日志分析原因效率不高,推荐的做法是将日志丢到大数据平台(ELK、Splunk)进行分析,有时候要溯源可能会将大量的历史日志文件截入,比如下面这个图:

 

金融企业网络安全应急响应之技术篇


中间有两个柱子非常高,表示请求这个特定url非常多,一下子就可以将问题定位到特定日期。


除了大数据分析平台外,还有一些场景是需要分析恶意的文件比如邮件的附件,沙箱给出的报告由于某些原因不够准确,需要自己动手分析,在自己机器上双击那肯定是不妥的。那还得有一个恶意文件分析平台,做的好的企业会自建,这自建的程度可深可浅,浅的只需要部署一个虚拟机在上面安装常用的分析工具就行了,深的会在里面加入集成多种杀毒引擎、各种对抗策略等等。当然,将可疑文件发给第三方进行分析也是可以的,前提是收集的准确而且可以提供给对方。还有一些在线的文件分析平台也可以参考,比如大家熟知的:


  • VirusTotal(简称VT,https://www.virustotal.com/)

  • 国内的微步在线(https://x.threatbook.cn/)

  • 腾讯的哈勃系统(https://habo.qq.com/)

  • 金山的火眼(https://fireeye.ijinshan.com/)

  • 等等


在某次应急响应中,我们将一个可疑样本发给某国际知名AV厂商,结果对方回复正常,最后我们在自己的平台证明了其就是恶意样本。


有了工具和平台,接下来还需要的是人,尤其是有安全攻防对抗经验的人。在某种程度上讲,实际的应急响应过程中,一个熟悉企业现有整体安全管控手段又适当懂点业务或应用系统的安全人员,再结合安全攻防对抗经验,往往能在事件的应急响应,事中的及时止血、事后的溯源及现有安全管控手段的查漏补缺方面,都能发挥出很大的作用。


上篇推荐:

金融企业网络安全应急响应之基础篇


往期阅读量最高文章推荐

工作篇:

金融企业信息安全团队建设(务实篇)

金融企业信息安全团队建设(务虚篇)


生活篇

南洋游记

一个有趣的问题


----------------------------------------------

企业安全建设,离不开“守望相助”。金融业企业安全建设微信群,在历次安全事件、安全应急中有大量实况直播,处置措施及时性、有效性,让我自己也获益良多。有兴趣加入的企业安全负责人,请关注微信公众号“君哥的体历”,后台留言,微信号+公司名称,验证身份后入群。


附注:

  • 聂君,信息安全从业人员,十余年金融行业信息安全从业经历,默默无闻。好读书,不求甚解。性格开朗,爱好足球。

  • 本订阅号文章是个人对工作生活的一些体验和经历分享,站在不同角度和立场解读会有偏差,见仁见智,不求正确统一,但求真、善、美。


长按识别二维码,和我交流


金融企业网络安全应急响应之技术篇


-----------------------------------------


赞赏是认同或肯定,更是鼓励更多原创分享


金融企业网络安全应急响应之技术篇


请在下面“赞”这里帮我点一下,谢谢。


本文始发于微信公众号(君哥的体历):金融企业网络安全应急响应之技术篇

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年1月22日01:54:19
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   金融企业网络安全应急响应之技术篇https://cn-sec.com/archives/498913.html

发表评论

匿名网友 填写信息