DShield蜜罐环境中的文件上传探索[客座日记]
[这是一篇由Nathan Smisson撰写的客座日记，他是SANS.edu BACS项目的ISC实习生]
本项目的目标是测试dshield生态系统中各种数据入口点的适用性，以确定哪些指标可能产生持续有趣的结果。本文探讨了对上传到cowrie蜜罐服务器文件的分析。在整个项目中，开发了许多工具来帮助提高使用cowrie蜜罐进行研究分析师的工作流程效率。这里使用了一个名为upload-stats的相对简单的工具来枚举默认cowrie"下载"目录(/srv/cowrie/var/lib/cowrie/downloads)中文件的基本信息。本项目开发的此工具和其他工具可在https://github.com/neurohypophysis/dshield-tooling 上使用或贡献。
我的蜜罐配置故意非常典型，紧密遵循https://github.com/DShield-ISC/dshield/tree/main 上的安装和设置指南。本文使用的节点设置在AWS us-east-1区域的EC2实例上，即使按AWS标准来看，这个区域也很老旧且规模很大。
第一部分：已识别Shell脚本调查
upload-stats工具通过枚举下载目录中文件的一些基本信息，并将其与在蜜罐事件日志中发现的任何相应信息一起打印出来。如果日志仍然存在于系统上，它将自动识别源IP、上传时间等信息，以及其他有助于进一步探索看起来有趣文件的统计信息。
在没有参数的情况下，该工具生成系统上可用文件的快速摘要：
在这种情况下，21个文件被报告为空；如果您正在跟随操作，您可能会注意到许多此类空文件的名称很短，如tmp5wtvcehx。当上传开始时，cowrie会创建一个临时文件，用上传文件的内容填充它，然后将其重命名为结果的SHA哈希值。对于具有临时占位符名称的空文件，这可能意味着上传因某种原因失败。
在提供的前几种文件类型中，我们有一个被UNIX文件实用程序识别为Bash脚本的单个文件。事实证明，在运行此命令时，目录中的文件里这不是唯一的shell脚本。为什么只有一个被识别为shell脚本的原因将在本文后面探讨。首先，让我们看看这个异常值。幸运的是它相对较短，所以我可以在这里包含整个脚本的内容。
幸运的是，这个脚本非常重复且易于阅读，所以让我们逐行查看一个迭代模式（我可能会补充说，如果攻击者使用了for循环，可能会更加简洁）。
第1行
|
|
脚本的每一行都开始尝试更改到几个目录(cd /tmp || cd /var/run || cd /mnt || cd /root || cd /)。这个回退序列表明首先偏好可写、低监控的位置(/tmp)，并且只有在先前目录失败时才会尝试替代目录，文件根目录作为最后手段。
第2行
|
|
接下来是从攻击者的FTP服务器下载特定架构载荷的命令。更具体地说，如果执行整个脚本（并假设我们安装了ftpget，但我们没有），它将下载14种不同架构的载荷，撒了一个相当宽的网。包含-v（详细）开关表明攻击者期望或至少希望在此上下文中有非盲RCE，尽管如果执行成功，我们可以假设来自受害者的FTP服务器访问对攻击者是可见的，无论如何。
为求彻底，以下是目标CPU架构变体：
- mips, mipsel (MIPS变体)
- sh4 (SuperH架构)
- x86_64 (64位Intel/AMD)
- arm6, arm, arm5, arm7 (各种ARM版本)
- i686, x86 (32位Intel/AMD)
- powerpc, ppc4fp (PowerPC变体)
- m68k (Motorola 68k系列)
- spc (模糊；可能指SPC-700等。我必须询问恶意软件作者以进行澄清)
一个有趣的列表，当然。在研究了一些更模糊的变体之后，基本的共同点似乎是针对IoT/嵌入式/OT设备或（可能是遗留的）网络设备。虽然很难确定除此之外的任何事情，但其中许多比其他架构的应用要有限得多（例如，SuperH、Motorola 68000系列和SPC与x86_64相比）。值得注意的是缺少任何Apple芯片或许多Android手机中使用的现代芯片。考虑到使用这些专用硬件集的设备类型，最终载荷不太可能尝试任何涉及繁重工作负载的事情。
我还注意到使用旧的明文FTP进行载荷传输：旧的又变成新的了。
第3行
|
|
此步骤将下载的载荷的权限更改为可执行，然后使用参数’telnet’执行它，我猜这表明了预期的后门方法。请注意，收到的脚本将尝试执行所有下载的载荷，这意味着任何环境发现可能都发生在此步骤，并且只有与受感染主机芯片架构对应的载荷才会成功执行。
第4行
|
|
最后，载荷被移除，可能表明持久性机制已在上一步安装，更明显地表明希望在目标系统上留下稍少的取证工件。
第二阶段载荷服务器分析
地址87.121.84.163没有出现在任何其他上传文件中。根据Speedguide和Talos的报告，它出现在几个IP信誉阻止列表中，尽管spamhaus.org引用的数据库没有返回任何立即可见的结果。无论如何，RIPE记录将/24网络块注册到属于荷兰VPS提供商VPSVAULTHOST的AS，看起来它在英国运营。我假设它是一个云托管服务器。有趣的是，ISC页面将国家列为保加利亚，尽管我在搜索中没有看到任何其他指向那里的内容。ISC网站上没有报告其他内容。
不幸的是，我没有此攻击来源的其他直接记录。87.121.84.163也没有出现在任何其他记录中，考虑到其在攻击中作为载荷服务器的角色，这是预期的。在下一节中，我们将看到具有关联日志条目的蜜罐上传实例，从而可以更完整地了解攻击来源和生命周期。
第二部分：僵尸网络蠕虫发现
继续研究上传文件中的模式，我注意到系统识别为"data"的所有文件类型似乎都是可读文本。在早期的bash脚本分析中，我指出有问题的文件不是存在的唯一shell脚本。也就是说，它不是唯一包含shebang(!#/bin/bash)的文件。此外，可能允许将shell脚本识别为此类的文件权限（即644 - 除root外的用户可读）并非此文件独有。事实上，所有"data"文件不仅可读，而且一致地包含字符串’bin/bash’。在以下命令中，我过滤了匹配’data’并包含’bin/bash’的文件类型：
注意：许多文件没有相应的"元数据"，因为与这些文件关联的日志记录已从系统中老化，但文件本身没有。此外，此屏幕截图中的文件总数更多，因为此调查的时间线不是完全线性的。
在之前的屏幕截图中，我们看到对包含bash解释器路径的data文件的查询返回了六个匹配项。重新运行该工具而不带参数，似乎这六个文件占我们"data"类型文件的100%。查看其他文件类型，可读性要么是不言自明的（ASCII、Unicode、shell脚本、空），要么是不一致的（一些"常规文件"是二进制的，而其他的是基于文本的）。
分配权限变化（目录中所有文件为0600或0644）背后的原因与从cowrie视角的活动来源有关。查看cowrie的VFS（虚拟文件系统）模板fs.pickle可能会揭示这些权限如何分配的具体细节，但就我们的目的而言，目前没有必要。为了大致了解系统上不同文件类型的来源，我们可以从检查与上传不同类型文件的IP关联的行为模式开始。为了设定基线，我使用了另一个工具ip-activity来聚合与上传"常规"文件的地址关联的所有日志事件。
幸运的是，并非所有与这些文件相关的日志都已老化。这组数据应揭示这些文件如何上传的背景中的任何一致性，确实如此。对于所有标记为"常规"的文件，攻击者进行多次登录尝试，成功，然后通过SFTP上传文件。有了这些知识，与"data"文件相关的活动模式应该会脱颖而出。
如希望的那样，这种模式也是一致的：对于标记为"data"的文件，来源来自活动SSH会话期间的stdin。也就是说，对于这些文件，攻击者在将载荷推送到其上之前和/或之后在认证会话期间与系统交互，至少对于81.172.146.181和176.188.22.163是如此。一旦验证，此类信息将有助于包含在upload-stats工具后续版本的输出中。
在查看这两个地址的活动时，登录尝试引起了我的注意。两个客户端都尝试了pi/raspberry和pi/raspberryraspberry993311。显然，在这种情况下它们都在寻找RBP设备，但raspberryraspberry993311是一个相当具体的猜测，考虑到它是两个（据我们目前所知）独立主机的仅两次猜测中的第二次。对我来说，这表明此密码可能不是来自暴力破解尝试的随机猜测。
对"raspberryraspberry993311"的一些研究揭示了一种特定的与Pi IoT设备关联的僵尸网络恶意软件株，被Trend Micro识别为UNIX_PIMINE.A。下面链接的2019年文章对恶意软件进行了全面分析，我将与我的设备上捕获的活动进行比较。
首先，让我们比较成功认证到蜜罐后跟随的命令。从我的输出中，每个命令都保存到单独的tty日志文件，所以不幸的是，值得尊敬的playlog.py在这种情况下不是特别有用。但是，我们仍然可以直接从日志中提取命令事件，我这样做了。对于那些不知道的人，playlog.py是由Upi Tamminen (desaster@dragonlight.fi)创建的工具，解析cowrie TTY日志（保存在/srv/cowrie/var/lib/cowrie/tty/）并允许分析师实时重放活动。
我们的两个攻击者都立即使用scp将文件拉到/tmp，然后将其权限设置为可执行并运行它。到目前为止，这与UNIX_PIMINE.A文章中描述的活动完全一致。接下来我将检查上传的文件，看看它们是否遵循相同的路径，它们可能在哪里不同，以及它们是否看起来是同一僵尸网络通道的成员。
上面引用的researchgate.net文章的屏幕截图
静态恶意软件分析：UNIX_PIMINE.A
比较由81.172.146.181和176.188.22.163上传的两个样本，它们之间的唯一区别是添加到文件顶部的scp控制消息：分别是C0755 4745 ocM8dVVu和C0755 4745 komDY9Nv。以后者为例，此控制消息分解为"复制文件komDY9Nv，大小为4745，权限为0755。“作为旁注，从stdin上传的文件顶部存在控制消息可能解释了为什么"data"文件未标记为shell脚本。此外，文件末尾的空字节可能解释了为什么它们被分类为"data"而不是ASCII文本。
在继续分析与仅这两个地址相关的脚本之前，您可能已经注意到在早期枚举"data"文件时，我们缺少日志数据的剩余文件的大小似乎是相同的。对剩余文件运行vimdiff确认我们的其他4个data文件记录是来自同一僵尸网络成员攻击的实例。继续向下看代码，一切似乎都与引用文章中给出的描述一致。恶意软件将自身复制到/opt内具有随机8位数字名称的文件，修改/etc/local.rc以在重启时执行后门，然后指示系统执行此操作。
之后，恶意软件尝试杀死并移除许多其他（明显的）加密挖掘程序，这些程序可能已经存在于受感染系统上，然后连接到端口6667上的Undernet Internet Relay Chat (IRC)通道，在那里它加入#biret C2通道，用户名基于受感染系统uname输出的md5哈希。正如文章中指出的，对于唯一用户名来说，这是一个相当低熵的生成方案，因为具有相同’uname -a’输出的多个系统的概率非常高，导致用户名冲突并最终限制蠕虫的增长因子。我怀疑自文章发布以来可能发生了通道轮换，但击中我的机器的实例实际上来自2019年的同一僵尸网络。事实证明，独立于其发起者无限复制自身的恶意软件非常难以修补。
蠕虫的传播机制涉及安装sshpass以简化基于ssh的新目标连接和Zmap用于端口扫描。具体来说，它扫描IP（每次迭代100,000个地址）的端口22可用性，并将可到达地址存储在临时文件中，然后尝试其2个凭据集：pi/raspberry和pi/raspberryraspberry993311。密码’raspberry’是Pi设备长期运行的默认值。然而，在这一点上，仍然不完全清楚为什么特别使用这第二个组合；它与各种pi相关攻击强相关，但据我所能发现，它似乎不是常见的默认密码。可能其他恶意软件变体（例如此蠕虫尝试移除的那些）在受感染主机上创建具有这些凭据的帐户，导致此蠕虫希望感染的设备类型成功认证的可能性增加。
源地址考虑：受感染的Pies
了解我们对此恶意软件传播方式的了解，会话活动非常清楚。在这种情况下，最好将攻击者地址视为同一蠕虫的两个受感染受害者；即，同一僵尸网络的成员。从我们手头的两组日志来看，81.172.146.181似乎是荷兰ISP分配的公共地址，属于DELTA Fiber Nederland B.V.的网络。根据我们目前所见，我猜这是一个网络/IoT设备或可能位于SOHO网关路由器后面具有端口转发的RBP。176.188.22.163是类似的情况：在这种情况下，属于法国ISP (Bouygues Telecom)。ISC网站上没有报告任一地址的恶意活动。
结论：文件上传和攻击描述
事件日志与上传到蜜罐的文件关联已证明对于发现高度特定的攻击模式有效。此外，围绕cowrie（或其他蜜罐）环境内部操作的上下文对于理解事件的时间顺序和实质至关重要。自动化过程，如事件关联以及将文件、IP和其他信息分组到离散存储桶的能力，大大减少了此类调查所需的开销并鼓励分析洞察。这种方法的一个缺点是，相对于未记录在文件上传中的事件量，活动范围非常小，尽管根据调查意图，这可能不是问题。
本文中观察到的攻击主要突出了对遗留系统维护和监控的需求，以及在将系统暴露给公共互联网之前更改默认密码的必要性。
[1] https://github.com/neurohypophysis/dshield-tooling [2] https://github.com/DShield-ISC/dshield/tree/main [3] https://www.sans.edu/cyber-security-programs/bachelors-degree/
Guy Bruneau IPSS Inc. 我的GitHub页面 Twitter: GuyBruneau gbruneau at isc dot sans dot edu
关键词：BACS DShield DShieldSIEM 调查 ipactivity uploadstats