在Linux中寻找持久性控制第2部分:帐户创建和操作

介绍

在上一篇博文中，我们讨论了如何设置 auditd 和 sysmon，以便我们可以开始在 linux 主机中寻找持久性技术。具体来说，我们讨论了一些可以检测 web 服务器中 web shell 的创建和使用的方法。

在这篇博文中，我们将讨论以下内容：

• 创建账户：本地账户
• 有效账户：本地账户
• 帐户操作：SSH 授权密钥

我们将给出一些关于如何实现这些持久性技术的示例命令以及一些可用于检测这些的警报。

如果您需要有关如何设置 auditd、sysmon 和/或 auditbeats 的帮助，您可以尝试按照第1 部分附录中的说明进行操作。

这是 linux 持久性系列的第 2 部分：

• 在 Linux 中寻找持久性（第 1 部分）：审计、日志记录和 Webshel​​l
  • 服务器软件组件：Web Shell
• 在 Linux 中寻找持久性（第 2 部分）：帐户创建和操作
  • 创建账户：本地账户
  • 有效账户：本地账户
  • 帐户操作：SSH 授权密钥
• (WIP) 在 Linux 中寻找持久性（第 3 部分）：Systemd、定时器和 Cron
  • 创建或修改系统进程：Systemd 服务
  • 计划任务/作业：Systemd 计时器
  • 计划任务/作业：Cron
• (WIP) 在 Linux 中寻找持久性（第 4 部分）：初始化脚本、Shell 配置等
  • 启动或登录初始化脚本：RC 脚本
  • 事件触发执行：Unix Shell 配置修改

2 创建账户：本地账户

2.1 创建账户保持持久化

MITRE： attack.mitre.org/techniques/T1136/001/

攻击者可以创建一个本地帐户来维护对受害者系统的访问，而无需任何其他工具。与其配置后门 web shell，不如创建一个用户！

我们运行以下命令

sudo adduser --shell /bin/bash --home /var/www/ nginx  
sudo usermod -aG sudo nginx

这将创建一个名为的用户nginx并将其添加到sudo组中。（也许这会欺骗可能认为nginx是该nginx服务合法用户的初级分析师）

我们可以为此设置密码，或者如果您想拥有公钥 ssh，那么您可以执行其他操作。

mkdir /var/www/.ssh  
echo "ssh-ed25519 AA ... " > /var/www/.ssh/authorized_keys

有了这个，我们现在可以nginx@<pwned_host>用来获得对主机的 root 访问权限。

通常，当您创建本地帐户时，您必须授予该帐户额外的权限才能使其有用。这就是为什么您会看到我们的检测包括帐户创建和修改。

2.2 检测：用户在auditbeat的系统模块中添加

使用默认配置 auditbeat，我们可以看到event.module: system日志process_started事件。我们将能够看到的其中之一

但除此之外，我们还可以看到以下内容event.action：

• user_added: 将用户添加到 passwd 和 shadow
• password_changed: 设置用户密码
• user_changes: 添加用户到sudo组

2.3检测：变化/etc/shadow，/etc/passwd和/etc/group

在幕后，诸如passwd和adduser修改以下文件的命令：

• /etc/gshadow
• /etc/shadow
• /etc/passwd
• /etc/group

即使不运行adduser命令，对这些文件的修改也可以创建有效用户。

您可能会注意到/etc/nshadow,/etc/passwd.lock/和其他文件的创建。这些副产品passwd和usermod命令。

监控这些关键文件的修改可以帮助检测这些类型的持久性技术。

2.4 检测：使用auditd检测用户创建

如果我们想在auditd中本地找到这些，我们可以使用以下规则：

-w /etc/group -p wa -k etcgroup  
-w /etc/passwd -p wa -k etcpasswd  
-w /etc/gshadow -k etcgroup  
-w /etc/shadow -k etcpasswd

-w /usr/sbin/useradd -p x -k user_modification  
-w /usr/sbin/adduser -p x -k user_modification
-w /usr/bin/passwd -p x -k passwd_modification

如果我们想添加辅助操作，例如将用户添加到组等：

-w /etc/sudoers -p rw -k priv_esc  
-w /etc/sudoers.d -p rw -k priv_esc

-w /usr/sbin/usermod -p x -k user_modification  
-w /usr/sbin/userdel -p x -k user_modification  
-w /usr/sbin/groupadd -p x -k group_modification  
-w /usr/sbin/groupmod -p x -k group_modification  
-w /usr/sbin/addgroup -p x -k group_modification  

这将寻找：

• sudoers 目录的任何读/写
• 对/etc/group或的任何写入或更新/etc/passwd
• 对/etc/gshadow和的任何操作/etc/shadow
• 如果执行特定命令如useradd和usermod

这是一个原始的审计日志 etcpasswd

  
type=SYSCALL msg=audit(1637599618.765:11426): arch=c000003e syscall=82 success=yes exit=0 a0=7ffeb8ffa160 a1=564262d92020 a2=7ffeb8ffa0d0 a3=2 items=5 ppid=13573 pid=13578 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=19 comm="useradd" exe="/usr/sbin/useradd" subj==unconfined key="etcpasswd", type=PATH msg=audit(1637599618.765:11426): item=0 name="/etc/" inode=131075 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PATH msg=audit(1637599618.765:11426): item=1 name="/etc/" inode=131075 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PATH msg=audit(1637599618.765:11426): item=2 name="/etc/shadow+" inode=131557 dev=08:01 mode=0100640 ouid=0 ogid=42 rdev=00:00 nametype=DELETE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PATH msg=audit(1637599618.765:11426): item=3 name="/etc/shadow" inode=144749 dev=08:01 mode=0100640 ouid=0 ogid=42 rdev=00:00 nametype=DELETE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PATH msg=audit(1637599618.765:11426): item=4 name="/etc/shadow" inode=131557 dev=08:01 mode=0100640 ouid=0 ogid=42 rdev=00:00 nametype=CREATE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PROCTITLE msg=audit(1637599618.765:11426): proctitle=2F7362696E2F75736572616464002D64002F7661722F7777772F002D67006E67696E78002D73002F62696E2F62617368002D750031303032006E67696E78

从这里我们可以看到以下内容：

• comm="useradd" exe="/usr/sbin/useradd" 正在运行的可执行文件
• name="/etc/shadow" 正在修改的文件
• key="etcpasswd" 来自审计规则的标签或键
• proctitle=2F7362... 这是解码为的进程的十六进制编码标题 /sbin/useradd -d /var/www/ -g nginx -s /bin/bash -u 1002 nginx

2.4.1 用户UID注意事项

如果我们查看/etc/passwd我们会看到这个新创建的用户nginx将有一个很大的 UID100X

messagebus:x:104:105::/nonexistent:/usr/sbin/nologin  
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin  
_chrony:x:106:112:Chrony daemon,,,:/var/lib/chrony:/usr/sbin/nologin  
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin  
user:x:1000:1001::/home/user:/bin/bash  
nginx:x:1002:1003:,,,:/var/www/:/bin/bash

尽管 Linux 系统确实会为新用户分配高 UID，但这只是按照惯例，攻击者可以轻松修改此设置，以便新创建的帐户可以显示为系统帐户，因为它们的 UID 较低。

2.5 检测：使用sysmon检测用户创建

我们必须了解 MSTIC 配置中可用的潜在规则：

• T1136.001_CreateLocalAccount_Commands.xml
• T1087.001_Lo​​calAccount_Commands.xml

    <RuleGroup name="" groupRelation="or">
      <ProcessCreate onmatch="include">
        <Rule name="TechniqueID=T1087.001,TechniqueName=Account Discovery: Local Account" groupRelation="or">
          <CommandLine condition="contains">/etc/passwd</CommandLine>
          <CommandLine condition="contains">/etc/sudoers</CommandLine>
        </Rule>
        <Rule name="TechniqueID=T1136.001,TechniqueName=Create Account: Local Account" groupRelation="or">
          <Image condition="end with">useradd</Image>
          <Image condition="end with">adduser</Image>
        </Rule>
      </ProcessCreate>
    </RuleGroup>

这会：

• 查找其中包含的任何命令/etc/passwd。这可能会捕获读取或写入的命令/etc/passwd
• 寻找我们useradd或adduser

这是一个很好的起点，但是请注意，我们已经讨论过攻击者可以在不使用useradd/adduser.

另请注意，T1087.001仅查找包含字符串的命令/etc/passwd。如果我们可以在/etc/passwd不直接在命令中引用它的情况下进行修改，那么我们也可以绕过该警报。

例如，我们以 root 身份执行以下命令。

echo "nginx:x:0:0::/home/nginx:/bin/bash" >> /etc//passwd
passwd nginx 

这将允许我们创建一个 root 用户并设置它的密码，而不会触发上面的 2 个警报。我们不需要使用useradd并且我们能够引用/etc//passwd并且这不会触发对字符串的检查，/etc/passwd因为/我们已经添加了额外的内容。

我们想要的是类似的东西

-w /etc/passwd -p wa -k etcpasswd  

因为有很多方法可以直接或间接修改/etc/passwd、/etc/shadow/等，所以我们应该有一个额外的规则来检测对这些文件的任何更改。据我所知，我们在 sysmon 中最接近的东西是。

    <RuleGroup name="" groupRelation="or">
      <FileCreate onmatch="include">
        <Rule name="etcpasswd" groupRelation="or">
          <TargetFilename condition="contains">/etc/passwd</TargetFilename>
          <TargetFilename condition="contains">/etc/shadow</TargetFilename>
        </Rule>
        <Rule name="etcgroup" groupRelation="or">
          <TargetFilename condition="contains">/etc/group</TargetFilename>
          <TargetFilename condition="contains">/etc/gshadow</TargetFilename>
        </Rule>
      </FileCreate>
    </RuleGroup>

不幸的是，Sysmon 事件 ID 11FileCreate仅在创建或覆盖文件时触发。在撰写这篇博文时，如果文件被修改，则不会触发任何事件。

上面的规则将能够检测到所做的修改

vi /etc/passwd
useradd

（这主要是因为这些命令制作的临时文件，例如/etc/shadow+但不是/etc/shadow直接修改）

但不是由以下触发

echo "<TEXT>" >> /etc/passwd
sed -i 's/BEFORE/AFTER/g' /etc/passwd

更糟糕的是，即使我们明确地试图观察 at /etc/shadow，上面的规则似乎也不是由简单的

passwd user

这表明，sysmon对于文件完整性监控而言，实际上并不完全可靠。在下一篇博文中，我们将展示T1543.002_CreateModSystemProcess_Systemd.xml等规则如何无法检测到 systemd 服务的安装

我还将警报扩展到其他用户和组修改命令，类似于 auditd

    <RuleGroup name="" groupRelation="or">
      <ProcessCreate onmatch="include">
        <Rule name="group_modification" groupRelation="or">
          <Image condition="end with">groupmod</Image>
          <Image condition="end with">addgroup</Image>
          <Image condition="end with">groupadd</Image>
        </Rule>
        <Rule name="user_modification" groupRelation="or">
          <Image condition="end with">usermod</Image>
          <Image condition="end with">userdel</Image>
        </Rule>
        <Rule name="passwd_modification" groupRelation="or">
          <Image condition="end with">passwd</Image>
        </Rule>
      </ProcessCreate>
    </RuleGroup>

3 有效账户操作：本地账户

MITRE： https和https://attack.mitre.org/techniques/T1078/

3.1 滥用合法账户

3.1.1 修改已有账号

攻击者可能会获取凭据或修改现有帐户的配置以保持持久性。由于这些帐户具有合法用途，因此防御者可能会将它们列入其警报的白名单，或者如果他们不熟悉帐户的基线配置，则在进行任何重大补救时会谨慎。

在此示例中，我们将向www-data帐户添加后门。我们添加一个密码，让我们wwww-data成为一个 sudo-er

sudo passwd www-data  
sudo usermod -aG sudo www-data

我们修改/etc/passwd，以使我们能够作为SSHwww-data从

www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

到

www-data:x:33:33:www-data:/var/www:/bin/bash

在某些服务器配置中，可能会禁用密码身份验证。我们可能需要修改/etc/ssh/sshd_config以启用密码。

PasswordAuthentication yes

并重启服务。

sudo service ssh restart

这将允许攻击者以 SSH 身份www-data运行并以 sudo身份运行。

3.2.2 其他滥用本地账号的方式

有时，攻击者甚至可能不需要操纵帐户。也许他只能：

• 转储/etc/shadow和破解哈希
• 获取用户.ssh文件夹中的私钥
• 下载 CLI 服务帐户密钥和令牌（GCP 和 AWS）
• 在配置文件中查找硬编码凭据

这些可能提供更隐蔽的保持持久性的方法，并且由于用户合法使用它们而不太可能被检测到。

3.3 检测：类似于创建账户

与创建帐户类似，这可能需要我们修改诸如此类的文件/etc/passwd，/etc/shadow因此以前用于帐户创建的检测规则也会捕获此信息。

倾销/etc/shadow将被审计规则检测到

-w /etc/shadow -k etcpasswd

对于sshd配置的改变，可以使用如下auditd规则

## SSH configuration  
-w /etc/ssh/sshd_config -k sshd  
-w /etc/ssh/sshd_config.d -k sshd

3.4 检测：使用 osquery 寻找创建或操纵的帐户

3.4.1 查找登录用户

您可以查询您的车队以找到活动会话。那里可能有一个您不知道的持久性会话。

询问

SELECT type, user, host 
FROM logged_in_users 
WHERE type = 'user';

结果

+------+----------+-----------------+
| type | user     | host            |
+------+----------+-----------------+
| user | www-data | 1.2.3.4 |
| user | user     | 1.2.3.4 |
+------+----------+-----------------+

3.4.2 查找具有有效密码的帐户

如果您拥有默认禁用密码登录的安全映像（如云 VM），则您不应看到活动密码。

SELECT password_status, username, last_change
FROM shadow 
WHERE password_status = 'active';

+-----------------+----------+-------------+
| password_status | username | last_change |
+-----------------+----------+-------------+
| active          | www-data | 18953       |
| active          | legit    | 18819       |
+-----------------+----------+-------------+\

3.4.3 在特殊组中查找帐户

查找具有可用于 privesc 的特殊权限的帐户。每个用户都应该考虑在内。

SELECT uid,  username, groupname 
FROM user_groups 
JOIN users 
USING(uid)
JOIN groups 
ON user_groups.gid=groups.gid 
WHERE 
  (groupname = 'sudo' 
  OR groupname = 'root')
  AND username != 'root';

+------+----------+-----------+
| uid  | username | groupname |
+------+----------+-----------+
| 33   | www-data | sudo      |
| 1001 | legit    | sudo      |
| 1002 | nginx    | sudo      |
+------+----------+-----------+

3.4.4 查找设置了shell的用户

可以作为这些用户登录。如果系统帐户已经/bin/bash设置，那么这可能是一个后门。

SELECT uid, username, directory, shell
FROM users 
WHERE shell != "/usr/sbin/nologin";

+------+----------+-------------+-----------+
| uid  | username | directory   | shell     |
+------+----------+-------------+-----------+
| 0    | root     | /root       | /bin/bash |
| 4    | sync     | /bin        | /bin/sync |
| 33   | www-data | /var/www    | /bin/bash |
| 1000 | user     | /home/user  | /bin/bash |
| 1001 | legit    | /home/legit | /bin/bash |
| 1002 | nginx    | /var/www/   | /bin/bash |
+------+----------+-------------+-----------+

3.4.5 查找与账户创建或操作相关的命令

类似于我们在 auditd 和 sysmon 中设置的内容。如果攻击者没有清理 bash 历史记录，那么我们也许能够找到不良活动的痕迹。

这还包括检查 authorized_keys

SELECT uid, username, command 
FROM users 
JOIN  shell_history 
USING(uid) 
WHERE  regex_match(command, 'useradd|adduser|passwd|usermod|groupmod|addgroup|groupadd|authorized_keys', 0)  IS NOT NULL;

+------+----------+--------------------------------------------------+
| uid  | username | command                                          |
+------+----------+--------------------------------------------------+
| 0    | root     | passwd www-data                                  |
| 0    | root     | vi /etc/passwd                                   |
| 0    | root     | cat /etc/passwd                                  |
| 0    | root     | echo "ssh-ed25519 AA..." >> .ssh/authorized_keys |
| 1000 | user     | echo "ssh-ed25519 ..." >> authorized_keys        |
| 1000 | user     | usermod -aG sudo legit                           |
| 1000 | user     | sudo usermod -aG sudo legit                      |
| 1001 | legit    | sudo vi authorized_keys                          |
+------+----------+--------------------------------------------------+

3.5 手动命令

3.5.1 上次日志

我们可以使用lastlog查看最近登录的用户

>> lastlog | grep -v Never
Username         Port     From             Latest
www-data         pts/1    1.2.3.4  Wed Nov 24 11:17:46 +0000 2021
user             pts/0    1.2.3.4  Wed Nov 24 11:41:22 +0000 2021
legit            pts/1    1.2.3.4   Sun Jul 11 16:18:58 +0000 2021
nginx            pts/1    1.2.3.4  Mon Nov 22 16:59:47 +0000 2021

3.5.2 /var/log/auth.log

或者我们可以查看最近的身份验证日志并查看哪些用户在 SSH 会话中使用。

>> cat /var/log/auth.log | grep sshd | grep -i Accepted
Nov 22 16:36:05 test-auditd sshd[13413]: Accepted publickey for user from 1.2.3.4 port 17629 ssh2: ED25519 SHA256:AA...
Nov 22 16:38:42 test-auditd sshd[13446]: Accepted publickey for user from 1.2.3.4 port 18131 ssh2: ED25519 SHA256:AA...
Nov 22 16:54:55 test-auditd sshd[13634]: Accepted publickey for nginx from 1.2.3.4 port 21020 ssh2: ED25519 SHA256:AA...
Nov 22 16:59:46 test-auditd sshd[13683]: Accepted publickey for nginx from 1.2.3.4 port 17676 ssh2: ED25519 SHA256:AA...
Nov 24 10:37:40 test-auditd sshd[11981]: Accepted publickey for user from 1.2.3.4 port 18970 ssh2: ED25519 SHA256:AA...
Nov 24 11:17:45 test-auditd sshd[15854]: Accepted password for www-data from 1.2.3.4 port 18669 ssh2
Nov 24 11:41:21 test-auditd sshd[16566]: Accepted publickey for user from 1.2.3.4 port 17873 ssh2: ED25519 SHA256:AA...

4 账户操作：SSH 授权密钥

MITRE： attack.mitre.org/techniques/T1098/004/

4.1 添加SSH授权密钥

添加 SSH 密钥是攻击者可以保持持久性的一种简单方法。此外，该authorized_keys文件通常由 GCP 和 AWS 等平台抽象，因此工程师很少手动与这些文件交互。因此，如果您能够插入 SSH 密钥，那么它可能会在那里停留很长时间。

该authorized_keys文件可以放在<home>/.ssh/机器中每个用户的目录中。

如果我们有以下用户

root:x:0:0:root:/root:/bin/bash

user:x:1000:1001::/home/user:/bin/bash  
nginx:x:0:0:,,,:/var/www/:/bin/bash

然后我们想将我们的 SSH 密钥添加到：

• /var/www/.ssh/authorized_keys
• /home/user/.ssh/authorized_key
• /root/.ssh/authorized_keys

然后我们可以运行以下命令

# create .ssh directory if it does not exist  
mkdir /var/www/.ssh

echo "ssh-ed25519 AA ... " >> /var/www/.ssh/authorized_keys  
echo "ssh-ed25519 AA ... " >> /home/user/.ssh/authorized_keys  
echo "ssh-ed25519 AA ... " >> /root/.ssh/authorized_keys

4.2 关于authorized_keys中SSH密钥的一些注意事项

首先，为了让防御者更加困惑，在添加 SSH 密钥时复制其他 SSH 密钥中的用户名。

ssh-ed25519 AAAAC3NzaC1lZDI1NTg3f2vasdcascTcwuq8CVppeNDQv85MQ3fsdsa592q86W1 paul@LP-291221  
ssh-ed25519 AAAAC3NzaC1lZDascacasbI1NTE5AAAAIB7q5ZK6GMNO6lTd90yutRohmGPugoCruTL paul@LP-291221

SSH 密钥中的“电子邮件地址”只是可以更改为任何内容的注释。这比kali在你的后门 SSH 密钥中要好得多。

接下来，您可以向 SSH 密钥添加注释，例如

# DO NOT REMOVE  
ssh-ed25519 AAAAC3NzaC1lZDI1NTg3f2vasdcascTcwuq8CVppeNDQv85MQ3fsdsa592q86W1 security-team  
ssh-ed25519 AAAAC3NzaC1lZDascacasbI1NTE5AAAAIB7q5ZK6GMNO6lTd90yutRohmGPugoCruTL paul@LP-291221

这可能对 Google Cloud Platform 等环境有用。

默认情况下，SSH 密钥在项目范围内设置，并使用注释添加到项目中的所有实例中# Added by Google 。这些 SSH 密钥是“托管的”，在项目中删除 SSH 密钥时应自动删除。但是，我发现当我们在最后添加一些空格时，即使在项目范围的元数据服务器中找不到 SSH 密钥，也不会删除它们。

所以我们添加我们的 SSH 密钥并添加 # Added by Google

# Added by Google        
ssh-ed25519 AAAAC3NzaC1lZDI1NTg3f2vasdcascTcwuq8CVppeNDQv85MQ3fsdsa592q86W1 security-team  
# Added by Google  
ssh-ed25519 AAAAC3NzaC1lZDascacasbI1NTE5AAAAIB7q5ZK6GMNO6lTd90yutRohmGPugoCruTL paul@LP-291221

这使得这些 SSH 密钥更容易被防御者忽视。

4.3 检测：文件完整性监控

默认情况下，auditbeat 不监视这些文件。您必须事先了解机器的用户才能监控.ssh每个用户的文件夹

- module: file_integrity  
  paths:  
  - /bin  
  - /usr/bin  
  - /sbin  
  - /usr/sbin  
  - /etc  
  - /root            # <--- Add  
  - /home/user/.ssh  # <--- Add  
- module: system  
  datasets:  
    - package # Installed, updated, and removed packages

这使我们能够检测authorized_keys现有用户的更改。如果添加了其他用户，这些将超出范围，但希望我们之前讨论的“创建/修改用户”检测规则能够检测到它们。

4.4 检测：Auditd

与FIM类似，我们需要显式地放置每个用户的目录才能对其进行监控。

-w /root/.ssh -p wa -k rootkey  
-w /home/user/.ssh -p wa -k userkey

这会寻找对这些/home/user/.ssh/*和的写入或更新/root/.ssh/*

这是原始审计日志的示例输出

type=SYSCALL msg=audit(1637609476.111:15803): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=563001182d80 a2=241 a3=1b6 items=2 ppid=15409 pid=15410 auid=1000 uid=1000 gid=1001 euid=1000 suid=1000 fsuid=1000 egid=1001 sgid=1001 fsgid=1001 tty=pts0 ses=50 comm="bash" exe="/usr/bin/bash" subj==unconfined key="userkey", type=PATH msg=audit(1637609476.111:15803): item=0 name=".ssh/" inode=526594 dev=08:01 mode=040700 ouid=1000 ogid=1001 rdev=00:00 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PATH msg=audit(1637609476.111:15803): item=1 name=".ssh/authorized_keys" inode=527241 dev=08:01 mode=0100600 ouid=1000 ogid=1001 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0, type=PROCTITLE msg=audit(1637609476.111:15803): proctitle="-bash"

4.5 检测：Sysmon

    <RuleGroup name="" groupRelation="or">
      <FileCreate onmatch="include">
        <Rule name="TechniqueID=T1098.004,TechniqueName=Account Manipulation: SSH Authorized Keys" groupRelation="or">
          <TargetFilename condition="contains">authorized_keys</TargetFilename>
          <TargetFilename condition="contains">.ssh</TargetFilename>
        </Rule>
      </FileCreate>
    </RuleGroup>

如果我们运行命令，并且authorized_keys文件还不存在，这将生成一个日志

echo "ssh-ed25519 AA ... " >> /var/www/.ssh/authorized_keys

<Event>
  <System>
    <Provider Name="Linux-Sysmon" Guid="{ff032593-a8d3-4f13-b0d6-01fc615a0f97}"/>
    <EventID>11</EventID>
    <Version>2</Version>
   
    <EventRecordID>12463</EventRecordID>
    <Correlation/>
    <Execution ProcessID="20655" ThreadID="20655"/>
    <Channel>Linux-Sysmon/Operational</Channel>
    <Computer>sysmon-test</Computer>
    <Security UserId="0"/>
  </System>
  <EventData>
    <Data Name="RuleName">TechniqueID=T1098.004,TechniqueName=Acco</Data>
   
    <Data Name="ProcessId">20667</Data>
    <Data Name="Image">/usr/bin/bash</Data>
    <Data Name="TargetFilename">/var/www/.ssh/authorized_keys</Data>
    <Data Name="CreationUtcTime">2021-11-24 09:22:36.722</Data>
    <Data Name="User">root</Data>
  </EventData>
</Event>

但是，如果authorized_keys文件已经存在，则不会触发该规则。

现在攻击者可以通过创建文件.ssh夹的文件输出而不命名authorized_keys并将其重命名为轻松绕过此警报authorized_keys

echo "ssh-ed25519 AA ... " >> /tmp/keys 
mv /tmp/keys /var/www/.ssh/authorized_keys

我在 linux 中定义我的规则 sysmon 规则的方式可能有问题，或者它可能是sysmon我的测试 VM中安装的版本，但这确实表明这sysmon对于文件完整性监控是不可行的。

这对于我为此引用的其他规则也是有问题的：

• T1543.002_CreateModSystemProcess_Systemd.xml
• T1053.003_Cron_Activity.xml
• T1037_BootLogonInitScripts_CommonDirectories.xml

4.6 检测：OSQuery

除了之前的 osquery 查询之外，如果您有一个车队，那么您可以监控的一种方法authorized_keys是获取您的车队的快照authorized_keys

SELECT authorized_keys.*   
FROM users   
JOIN authorized_keys   
USING(uid)

+----------+-----------------+----------------------------------+
| username | key             | key_file                         |
+----------+-----------------+----------------------------------+
| root     | ssh-ed25519 ... | /root/.ssh/authorized_keys       |
| root     | ssh-ed25519 ... | /root/.ssh/authorized_keys       |
| www-data | ssh-ed25519 ... | /var/www/.ssh/authorized_keys    |
| www-data | ssh-ed25519 ... | /var/www/.ssh/authorized_keys    |
| user     | ssh-ed25519 ... | /home/user/.ssh/authorized_keys  |
| user     | ssh-ed25519 ... | /home/user/.ssh/authorized_keys  |
| user     | ssh-ed25519 ... | /home/user/.ssh/authorized_keys  |
| user     | ssh-ed25519 ... | /home/user/.ssh/authorized_keys  |
| user     | ssh-ed25519 ... | /home/user/.ssh/authorized_keys  |
| legit    | ssh-ed25519 ... | /home/legit/.ssh/authorized_keys |
| nginx    | ssh-ed25519 ... | /var/www/.ssh/authorized_keys    |
| nginx    | ssh-ed25519 ... | /var/www/.ssh/authorized_keys    |
+----------+-----------------+----------------------------------+

并调查差异。您可以查看未在 AWS 或 GCP 中注册的公钥。查看在您的队列中不常见的 SSH 密钥等。

结论和下一步

我们已经看到帐户创建和操作不仅仅是寻找useradd命令。

我们也必须包括对修改警报/etc/passwd，/etc/shadow，/etc/gshadow和/etc/group。我们还想查找对 的修改authorized_keys。对于这些文件完整性任务，我将坚持auditd和/或auditbeats.

我还没有找到适用于这些场景的 sysmon 规则。SysmonForLinux 可能不是为此而构建的……当我得到解决方案时，我会四处询问并更新这些博客文章。

from

转载请注明出处及链接