ASPIRE

安全应急响应检查清单

=Start=

缘由：

凡事预则立，不预则废。

正文：

参考解答：
几个处理原则：
  1. 不能造成二次伤害（系统故障、日志丢失等等）；
  2. 需要及时保存操作记录和结果记录；
需要的准备：
  • 静态编译的 w/last/lastb/lastlog/ps/top/ss/netstat/lsof/find/rpm 等命令；
  • 一些常见的检查工具/脚本；
操作分类：
  • Unusual Processes and Services（异常的进程和服务）
  • Unusual Files（异常的文件）
  • Unusual Network Usage（异常的网络使用情况）
  • Unusual Scheduled Tasks（异常的计划任务）
  • Unusual Accounts（异常的账户）
  • Unusual Log Entries（异常的日志条目）
  • Other Unusual Items（其它的异常情况）
  • Additional Supporting Tools（额外的一些支撑工具）
异常的账户：
查看 /etc/passwd 中的账户列表，并根据UID进行排序：
# sort -nk3 -t: /etc/passwd | less
常规用户都会在其中，尤其注意那些 UID < 500 的账户。

查看异常的 UID为0 的账户：
# egrep ':0+:' /etc/passwd

On systems that use multiple authentication methods:
# getent passwd | egrep ':0+:'

查看系统上的「孤儿文件」，这些文件可能是由攻击者创建的临时账户产生的：
# find / -nouser -print
异常的进程和服务：
# top
# ps -aux
# lsof -p $pid
# chkconfig --list
异常的文件：

用命令 rpm -Va 进行packages校验：

# rpm -Va | sort

这条命令会对比当前文件和RPM数据中记录的文件的大小、MD5值、权限、类型、属主、属组、修改时间等信息：

S – File size differs（文件大小发生变化）
M – Mode differs(permissions)（文件权限/模式发生变化）
5 – MD5 sum differs（文件MD5值发生变化）
D – Device number mismatch（设备名不匹配）
L – readLink path mismatch（readLink路径不匹配）
U – user ownership differs（用户所有者不同）
G – group ownership differs（属组所有者不同）
T – modification time differs（文件修改时间发生变化）

对于在 /sbin, /bin, /usr/sbin, 和 /usr/bin 等目录中的文件要尤其注意。在部分Linux发行版中，这个分析可以用内建的 check-packages 脚本来完成。

查找那些文件链接数异常（比如链接数为0）的运行中进程，攻击者可能将一些数据隐藏在其中，或是通过这类文件启动后门：

# lsof +L1

查找异常的SUID(root)文件：

# find / -uid 0 -perm -4000 -print

查看最近都有哪些文件发生了变动：

# ls -alt /
# find / -mtime -2d -print0 | xargs -0 ls -lt

查找一些文件名中有「空格」、「点」的伪装文件：

# find / -name " " -print
# find / -name ".. " -print
# find / -name ". " -print

查找一些异常的大文件（>10MB）：

# find / -size +10000k -print
异常的网络使用情况：

查看网络是否处于混杂模式：

# ip link | grep PROMISC

查看网络端口的使用情况：

# 查找异常端口监听情况
# netstat -nap
# ss -pln

# 查看是哪些进程占用了哪个端口
# lsof -i

查看ARP的情况：

# arp -a

查看DNS和hosts设置：

# vim /etc/resolv.conf
# vim /etc/hosts
异常的计划任务：

查找异常的root用户的计划任务：

# crontab -u root -l

查找异常的系统级别的计划任务：

# cat /etc/crontab
# ls -lt /etc/cron.*

查找异常的开机启动项：

# ls -lt /etc/rc*.d
异常的日志条目：
# w
# last
# lastb
# lastlog
# ls -lt /var/log/
# vim /var/log/messages
# vim /var/log/secure
其它的异常情况：
# uptime
# free -m
# df -h
# df -hi
额外的一些支撑工具：
  • Chkrootkit
  • Tripwire
  • AIDE
  • The Center for Internet Security
  • The free Bastille Script
参考链接：

=END=

Docker

, , ,
, , ,

《 “安全应急响应检查清单” 》 有 25 条评论

  1. 静态编译的 w/last/lastb/lastlog/ps/top/ss/netstat/lsof/find/rpm 等命令可能不太容易获取，退而求其次，可以考虑从一个相同架构、版本的纯净Linux机器上获取到这些命令，然后打包放到新机器的某个目录上，执行时记得使用 `./命令名` 的方式进行，不过最好是自己写一个lib脚本然后提前 source 一下，因为Bash执行/解析命令的优先顺序中alias(别名)是高于其它的command(外部命令)的：
    `
    $ type w
    w is /usr/bin/w
    $ type last
    last is /usr/bin/last
    $ type lastb
    lastb is /usr/bin/lastb
    $ type lastlog
    lastlog is /usr/bin/lastlog
    $ type ps
    ps is /bin/ps
    $ type top
    top is /usr/bin/top
    $ type ss
    ss is /usr/sbin/ss
    $ type netstat
    netstat is /bin/netstat
    $ type lsof
    lsof is /usr/sbin/lsof
    $ type find
    find is /bin/find
    $ type rpm
    rpm is hashed (/bin/rpm)
    $ which rpm
    /bin/rpm
    $ hash -d rpm
    $ type rpm
    rpm is /bin/rpm
    `

    回复

  2. 一些日志：
    /var/run/utmp
    /var/log/wtmp
    /var/log/lastlog
    /var/log/messages
    /var/log/secure
    /var/log/auth.log
    /var/log/faillog

    一些命令：
    ls/ps/netstat/login/find/ifconfig/ip/sshd/ssh

    一些模块：
    /lib/security/pam_unix.so
    /lib64/security/pam_unix.so

    回复

  3. 感觉真的好复杂啊，一脸懵逼没看懂，大神知不知道有没有视频资源对这方面进行讲解的，求介绍

    回复

    • 不好意思，这方面的视频资源我也没有，不过你可以去YouTube上搜一搜，老外那边应该有不少。
      应急响应这东西经历过一两次应该就会有个较深刻的印象了。。。

      回复

  7. 永远着急的应急响应（一）
    https://mp.weixin.qq.com/s/WEjjmOK0Uvs5zfoX9U95ug
    `
    一、有思路
    信息安全事件很多时候都是现象级的，跟运维事件的现象基本重合。应对这些现象级的事件要求应急人员必须有清晰的思路，对业务系统也要有相当的熟练程度。我们一般分为三个阶段：
    · 第一阶段要找到问题点，并在短时间内判断此次事件是否与安全有关。这个阶段重点是「速度」，在发现故障后快速定位问题点考验的是运维团队和安全团队的综合能力。
    · 第二阶段要快速恢复业务。这个阶段重点是「准确」，应急预案的选择和执行是否有效是关键。
    · 第三阶段要进行全面排查，消除隐患。这个阶段重点是「细致」，入侵者一般都会给自己留条后路，一个入侵点被封堵后不至于毫无办法。所以，需要应急团队能够找出共性的特征（如：后门文件、反连域名等），然后进行细致筛查。

    二、有办法
    安全团队和运维团队能否精诚合作？
    安全检测和防御手段是否可用？
    如何利用外部应急团队？

    三、能复盘
    1、应急方向
    2、入侵方向

    四、搞建设
    稍有追求的信息安全团队都不甘于永远应急。每次安全建设最好能解决一类问题，而不是一个问题。
    `

    回复

  8. 【应急响应】windows入侵排查思路
    https://mp.weixin.qq.com/s/17L_fQJ1qjSvt8UL7VSemg
    `
    0x00 前言
    常见的应急响应事件分类：
    web入侵：网页挂马、主页篡改、Webshell
    系统入侵：病毒木马、勒索软件、远控后门
    网络攻击：DDOS攻击、DNS劫持、ARP欺骗

    0x01 入侵排查思路
    一、检查系统账号安全
    二、检查异常端口、进程
    三、检查启动项、计划任务、服务
    四、检查系统相关信息
    五、自动化查杀
    六、日志分析

    0x03 工具篇
    病毒分析
    病毒查杀
    病毒动态
    在线病毒扫描网站
    webshell查杀
    `

    回复

  10. 浅谈安全应急响应中的快速止损
    https://paper.tuisec.win/detail/9b8c084fcb5058c
    https://www.secpulse.com/archives/81295.html
    `
    1.快速隔离入侵机器，防止内网扩散；
    2.最大限度保留入侵现场，以便溯源；
    3.平台化，系统化操作，避免人肉登录服务器来操作。

    # 止损方案
    整个过程分成止损、恢复两部分，通过iptables/ipsec脚本完成网络层隔离、恢复。
    Linux平台–使用iptables命令
    Windows平台–使用ipsec方案
    `

    回复

  14. 常见的几种windows后门持久化方式
    https://paper.tuisec.win/detail/5330717c8df89bc
    https://www.freebuf.com/vuls/195906.html
    `
    0×0 背景
    持久化后门是指当入侵者通过某种手段拿到服务器的控制权之后，通过在服务器上放置一些后门（脚本、进程、连接之类），来方便他以后持久性的入侵，简单梳理一下日常遇见windows用的比较多的一些持久化方式方便以后排查问题使用。

    0×1 注册表自启动
    0×2 用户登录
    0×3 定时任务
    0×4 WMI
    0×5 webshell
    0×6 自启动服务
    0×7 dll劫持
    0×8 COM劫持
    0×9 Bootkit

    0×10 总结
    Windows环境的持久化还有更多霸气侧漏的姿势没有遇见总结到，相对于之前建立隐藏账户、网站跟目录下的webshell、一个后门的exe程序、定时任务这些手法一些更新的手法显得更加隐蔽与难以查杀，希望能给日常背锅的运维、安全应急、开发大佬与首席道歉师在客户现场搞的焦头烂额时候提供一些排查思路吧。
    `

    回复

  15. 通过chkrootkit学习如何在linux下检测RootKit
    https://www.giantbranch.cn/2018/10/08/%E9%80%9A%E8%BF%87chkrootkit%E5%AD%A6%E4%B9%A0%E5%A6%82%E4%BD%95%E5%9C%A8linux%E4%B8%8B%E6%A3%80%E6%B5%8BRootKit/
    `
    总体流程：
    1、首先删除别名，确保接下来的一些操作不会用了被RootKit改变了的别名
    2、一开始会检测一些必要的命令是否可用，可执行，因为检测基于这些命令
    awk
    cut
    echo
    egrep
    find
    head
    id
    ls
    netstat
    ps
    sed
    ssh
    strings
    uname
    3、接下来就是检测ps的参数ax好不好使，好使就使用ax，不好使就用-fe
    ……

    通过分析脚本，总结出检测方法如下：
    1. 搜索通用的ROOTKIT特征的字符串
    2. 对某种特定的rootkits，或者命令的特殊的感染特征进行检测
    3. 对某种特定的rootkits生成的特定文件的检测
    4. 对程序的SUID位的设置进行检测
    5. 对ldsopreload的检测
    6. 查找可疑的log文件
    7. 查找可疑的php文件
    8. 检测.history文件
    9. 检测有无程序监听了一些可疑的端口
    10. 检测Linux可加载内核模块
    11. 检测有无隐藏进程
    12. 检测目录的软链接异常
    13. 检测网络接口的异常
    14. 检测用户的登录日志
    15. 检测上一次登录
    16. 检测可疑的没有tty记录的进程
    `

    回复

  16. 威胁快报|挖矿团伙8220进化，rootkit挖矿趋势兴起
    https://paper.tuisec.win/detail/6b7cded824ed973
    https://www.4hou.com/system/18409.html
    `
    近日，阿里云安全团队发现8220挖矿团伙为了更持久的驻留主机以获得最大收益，开始使用rootkit技术来进行自我隐藏。这类隐藏技术的使用在watchdogs等挖矿蠕虫使用后开始出现逐渐扩散和进化的趋势，此后预计主机侧的隐藏和对抗将成为主流。

    8220挖矿团伙是一个长期活跃的利用多个漏洞进行攻击和部署挖矿程序的国内团伙[1-2]，该团伙组合利用WebLogic XMLDecoder 反序列化漏洞(CVE-2017-10271)、Drupal RCE(CVE-2018-7600)、JBoss 反序列化命令执行漏洞(CVE-2017-12149)等多个漏洞进行攻击并部署挖矿程序进行牟利。

    通过对相关脚本和该so的简单分析，我们确认8220团伙已经在其攻击工具包使用ProcessHider[3]对自身进行隐藏。ProcessHider是被众多恶意软件广泛利用的rootkit。挖矿蠕虫利用该工具使管理员难以通过常规手段检测到挖矿进程，从而提高挖矿进程的存活时间以最大化挖矿收益。随着时间的推移，可能会有越来越多的挖矿蠕虫加入rootkit功能。

    修复方案

    1.由于本地命令可能都已被劫持，因此首先下载静态编译的busybox来执行指令，保证执行的系统命令不受劫持影响。

    下载二进制
    #wget https://www.busybox.net/downloads/binaries/1.27.1-i686/busybox
    赋予执行权限
    #chmod +x busybox

    2.清理动态劫持

    ./busybox rm -f /usr/local/lib/libkk.so 2>/dev/null./busybox chattr -i /etc/ld.so.preload 2>/dev/null./busybox chattr -i /usr/local/lib/libkk.so 2>/dev/null./busybox rm -f /etc/ld.so.preload
    ./busybox touch /etc/ld.so.preload
    ./busybox chattr +i /etc/ld.so.preload
    ldconfig

    3.杀恶意进程和相关文件

    ./busybox ps -ef | ./busybox grep -v grep | ./busybox egrep ‘kworkerds’ | ./busybox awk ‘{print $1}’ |./busybox sed “s/root//g” | ./busybox xargs kill -9 2>/dev/null./busybox ps -ef | ./busybox grep -v grep | ./busybox egrep ‘107.174.47.156’ | ./busybox awk ‘{print $1}’ |./busybox sed “s/root//g” | ./busybox xargs kill -9 2>/dev/null./busybox rm -f /var/tmp/kworkerds
    ./busybox rm -f /var/tmp/sustse*

    4.修复 crontab

    5.再次修复下 crontab,回到第3步再次执行

    6.修复完成和重启crontab
    `

    回复

  18. Window日志分析
    https://mp.weixin.qq.com/s/4kB26XQyAgVzrfOfIt2QvQ
    `
    0x01 Window事件日志简介
    Windows系统日志是记录系统中硬件、软件和系统问题的信息，同时还可以监视系统中发生的事件。用户可以通过它来检查错误发生的原因，或者寻找受到攻击时攻击者留下的痕迹。

    Windows主要有以下三类日志记录系统事件：应用程序日志、系统日志和安全日志。

    系统日志

    记录操作系统组件产生的事件，主要包括驱动程序、系统组件和应用软件的崩溃以及数据丢失错误等。系统日志中记录的时间类型由Windows NT/2000操作系统预先定义。

    默认位置：%SystemRoot%\System32\Winevt\Logs\System.evtx
    应用程序日志

    包含由应用程序或系统程序记录的事件，主要记录程序运行方面的事件，例如数据库程序可以在应用程序日志中记录文件错误，程序开发人员可以自行决定监视哪些事件。如果某个应用程序出现崩溃情况，那么我们可以从程序事件日志中找到相应的记录，也许会有助于你解决问题。

    默认位置：%SystemRoot%\System32\Winevt\Logs\Application.evtx
    安全日志

    记录系统的安全审计事件，包含各种类型的登录日志、对象访问日志、进程追踪日志、特权使用、帐号管理、策略变更、系统事件。安全日志也是调查取证中最常用到的日志。默认设置下，安全性日志是关闭的，管理员可以使用组策略来启动安全性日志，或者在注册表中设置审核策略，以便当安全性日志满后使系统停止响应。

    默认位置：%SystemRoot%\System32\Winevt\Logs\Security.evtx
    系统和应用程序日志存储着故障排除信息，对于系统管理员更为有用。安全日志记录着事件审计信息，包括用户验证（登录、远程访问等）和特定用户在认证后对系统做了什么，对于调查人员而言，更有帮助。

    0X02 审核策略与事件查看器
    Windows Server 2008 R2 系统的审核功能在默认状态下并没有启用 ，建议开启审核策略，若日后系统出现故障、安全事故则可以查看系统的日志文件，排除故障，追查入侵者的信息等。

    PS：默认状态下，也会记录一些简单的日志，日志默认大小20M

    查看系统日志方法：

    在“开始”菜单上，依次指向“所有程序”、“管理工具”，然后单击“事件查看器”

    按 “Window+R”，输入 ”eventvwr.msc“ 也可以直接进入“事件查看器”

    0x03 事件日志分析
    对于Windows事件日志分析，不同的EVENT ID代表了不同的意义，摘录一些常见的安全事件的说明。

    0x04 日志分析工具
    Log Parser
    Log Parser（是微软公司出品的日志分析工具，它功能强大，使用简单，可以分析基于文本的日志文件、XML 文件、CSV（逗号分隔符）文件，以及操作系统的事件日志、注册表、文件系统、Active Directory。它可以像使用 SQL 语句一样查询分析这些数据，甚至可以把分析结果以各种图表的形式展现出来。

    LogParser Lizard
    对于GUI环境的Log Parser Lizard，其特点是比较易于使用，甚至不需要记忆繁琐的命令，只需要做好设置，写好基本的SQL语句，就可以直观的得到结果。

    Event Log Explorer
    Event Log Explorer是一款非常好用的Windows日志分析工具。可用于查看，监视和分析跟事件记录，包括安全，系统，应用程序和其他微软Windows 的记录被记载的事件，其强大的过滤功能可以快速的过滤出有价值的信息。
    `

    回复

  19. 应急检测脚本
    https://github.com/tide-emergency/yingji
    `
    当企业被攻击者入侵，系统被挂暗链、内容遭到恶意篡改，服务器出现异常链接、卡顿等情况时，需要进行紧急处理，使系统在最短时间内恢复正常。由于应急处理往往时间紧，所以尝试将应急中常见处理方法整合到脚本中，可自动化实现部分应急工作。应急脚本采用python2.0完成，由于所有需要执行的命令都是依靠ssh进行远程链接，所以在运行脚本之前，需要输入正确的主机ip地址、ssh远程连接端口、ssh远程登录账户、ssh远程登录密码。

    一、脚本实现的主要功能

    1、获取主机信息
    获取的主机信息包括：主机ip地址、主机名、当前系统内核版本、当前系统版本、系统当前时间；

    2、获取异常进程
    获取异常进程主要是采用两种方式，第一种，通过执行netstat -antp获取当前主机存在哪些链接，并通过判断外部链接地址归属地，如果归属地不是中国，则会提取相关pid，并根据pid定位出文件所在位置。第二种，通过cpu占有率，一旦发现cpu占用率高于%15时，会提取对应程序的pid，根据pid定位异常文件位置。

    3、判断常见命令是否被篡改
    在之前的应急响应中出现过常见命令被非法篡改情况，如ps、netstat命令被恶意替换，利用stat查看文件详细信息，通过比对时间的方式判断命令是否被篡改。

    4、查看系统启动项
    很多恶意程序会修改系统启动项，这样即使系统进行重启时，恶意程序也能自动启动，查看init.d目录下的启动文件，根据修改时间提取最近被修改的启动文件，并根据时间排序列出前5个。

    5、查看历史命令
    查看.bash_history历史命令，通过匹配关键字，如wget、cur等，来查看系统在被入侵后是否被执行了恶意操作。

    6、判断非系统默认账户
    恶意程序可能会在系统中新建账户，通过查看login.defs文件获取最小uid，从而根据uid查看passwd文件，获取之后新建的系统用户。

    7、获取当前登录用户
    通过调用who，查看当前登录用户（tty为本地登录，pts为远程登录），判断是否存在异常用户登录情况。

    8、查看系统当前用户
    通过查看etc/passwd,查看相关用户信息，确定是否存在异常用户。

    9、查看crontab定时任务
    查看/etc/crontab定时任务，并将输出结果保存到log中

    10、查看、保存最近三天系统文件修改情况
    通过find命令，查找最近三天修改过的文件，由于修改的系统文件较多，所以修改文件被单独保存在本地file_edit文件中

    11、查找特权用户。
    查看passwd文件，查找用户id为0的特权用户

    12、secure日志分析
    日志分析是应急的重头工作，尤其是在应急后期的溯源阶段，日志分析更显得尤为重要，由于日志种类包括服务器日志、应用日志，此处只是分析了secure服务器日志，提取日志的ip地址进行判断，并对ip归属地进行判断，查看的secure日志单独保存在本地secure中。

    脚本整体的思路比较简单，就是远程登录到linux执行常见的应急命令，脚本中的命令在centos下都是可正常运行的，可以在根据实际环境自行在对命令做调整。上面的部分功能如果有好的实现方法也可灵活调整，如判断常见命令是否被篡改，脚本中是根据时间进行判断，在实际应用中也可根据文件大小进行判断，代码整体写的比较渣，有意见欢迎大家多多指出，希望通过改进能让功能更加完善。
    `

    回复

  20. MySQL日志安全分析技巧
    https://mp.weixin.qq.com/s?__biz=MzA3NzE2MjgwMg==&mid=2448904152&idx=1&sn=1d3c78c678ee7106d4f2a0dd627de903
    `
    常见的数据库攻击包括弱口令、SQL注入、提升权限、窃取备份等。对数据库日志进行分析，可以发现攻击行为，进一步还原攻击场景及追溯攻击源。

    0x01 Mysql日志分析
    general query log能记录成功连接和每次执行的查询，我们可以将它用作安全布防的一部分，为故障分析或黑客事件后的调查提供依据。

    1、查看log配置信息
    show variables like ‘%general%’;
    2、开启日志
    SET GLOBAL general_log = ‘On’;
    3、指定日志文件路径
    SET GLOBAL general_log_file = ‘/var/lib/mysql/mysql.log’;

    0x02 登录成功/失败
    不同的数据库连接工具，它在连接数据库初始化的过程中是不同的。通过这样的差别，我们可以简单判断出用户是通过连接数据库的方式。

    另外，不管你是爆破工具、Navicat for MySQL、还是命令行，登录失败都是一样的记录。

    在日志分析中，特别需要注意一些敏感的操作行为，比如删表、备库，读写文件等。
    关键词：drop table、drop function、lock tables、unlock tables、load_file() 、into outfile、into dumpfile。
    敏感数据库表：SELECT * from mysql.user、SELECT * from mysql.func

    0x03 SQL注入入侵痕迹
    检查方法：

    1、检查网站目录下，是否存在一些木马文件：
    2、检查是否有UDF提权、MOF提权痕迹
    检查目录是否有异常文件
    mysql\lib\plugin
    c:/windows/system32/wbem/mof/
    检查函数是否删除
    select * from mysql.func
    3、结合web日志分析。
    `

    回复

  21. MSSQL日志安全分析技巧
    https://mp.weixin.qq.com/s/_IlvfpuixxJoETLryWGZ-Q
    `
    常见的数据库攻击包括弱口令、SQL注入、提升权限、窃取备份等。对数据库日志进行分析，可以发现攻击行为，进一步还原攻击场景及追溯攻击源。

    0x01 MSSQL日志分析
    首先，MSSQL数据库应启用日志记录功能，默认配置仅限失败的登录，需修改为失败和成功的登录，这样就可以对用户登录进行审核。

    登录到SQL Server Management Studio，依次点击 管理–SQL Server 日志

    双击日志存档文件即可打开日志文件查看器，并可以对日志进行筛选或者导出等操作。

    另外，MSSQ提供了一个工具SQL Server Profiler ，方便查找和发现SQL执行的效率和语句问题。

    0x02 SQL注入入侵痕迹
    在利用SQL注入漏洞的过程中，我们会尝试利用sqlmap的–os-shell参数取得shell，如操作不慎，可能留下一些sqlmap创建的临时表和自定义函数。
    检查方法：
    1、数据库表检查
    2、检查xp_cmdshell等存储过程
    3、需要结合web日志，通过查看日志文件的大小以及审计日志文件中的内容，可以判断是否发生过sql注入漏洞攻击事件。
    `

    回复

  23. 持久化研究-Scheduled Tasks
    https://xz.aliyun.com/t/6822
    `
    0x01 什么是Scheduled Tasks
    * Schtasks.exe
    0x02 Metasploit与计划任务
    * 扩展阅读 regsvr32.exe
    0x03 持久化工具包SharPersist
    0x04 Empire与计划任务
    0x05 防御
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注