Данная публикация - перевод серии статей от Pepe Berba - Hunting for Persistence in Linux.

Введение

В предыдущей публикации мы обсудили, как настроить auditd и sysmon, чтобы обеспечить обнаружение техник закрепления на хостах Linux. В этой публикации мы рассмотрим следующее:

• Создание учётной записи

• Существующие учётные записи

• Манипуляции с учётной записью: SSH Authorized Keys

Мы приведём примеры команд для реализации этих техник закрепления, а также примеры оповещений, которые можно использовать для их обнаружения.

2 Создание учётной записи: Локальная учётная запись

2.1 Создание учётной записи для поддержания закрепления

MITRE: https://attack.mitre.org/techniques/T1136/001/

Злоумышленники могут создать локальную учётную запись для сохранения доступа к системам жертвы без необходимости использования дополнительных инструментов. Вместо настройки бэкдор-веб-оболочки, давайте просто создадим пользователя!

Мы выполняем следующие команды:

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@<взломанный_хост>, чтобы получить 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

Ниже представлен необработанный лог auditd для файла /etc/passwd:

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" — тег или ключ из правила auditd

• proctitle=2F7362... — заголовок процесса в шестнадцатеричном коде, который расшифровывается как /sbin/useradd -d /var/www/ -g nginx -s /bin/bash -u 1002 nginx

2.4.1 Примечание про UID пользователей
Если посмотреть в файл /etc/passwd, мы увидим, что у нового пользователя nginx будет большой UID, начинающийся с 100X.

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_LocalAccount_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. Что позволит зафиксировать команды, читающие или записывающие в этот файл.

• Искать команды, использующие useradd или adduser.

Это хороший старт для детектирования создания учеток, однако стоит помнить, что, как мы уже обсуждали, злоумышленник может создать пользователя без использования useradd/adduser.

Также обратите внимание, что правило T1087.001 ищет только команды, содержащие строку /etc/passwd. Если мы можем изменить /etc/passwd, не указывая его явно в команде, то сможем обойти и это оповещение.

Например, мы можем выполнить следующие команды от имени root.

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

Это позволит нам создать пользователя и установить для него пароль без срабатывания двух упомянутых выше оповещений. Мы не использовали 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>

Указанные выше правила смогут обнаружить изменения, выполненные с помощью

vi /etc/passwd
useradd

(Это связано в основном с тем, что эти команды создают временные файлы, например, /etc/shadow+, но не изменяют файл /etc/shadow напрямую.)

Однако не срабатывает при следующих действиях:

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

Хуже того, даже если мы явно пытаемся отслеживать изменения в /etc/shadow, указанное выше правило, похоже, не срабатывает на простое:

passwd user

Это показывает, что в текущем виде использовать sysmon не достаточно для мониторинга целостности файлов.

Я бы также расширил оповещения на другие команды изменения пользователей и групп, аналогично тому, как это сделано в 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://attack.mitre.org/techniques/T1098/ и https://attack.mitre.org/techniques/T1078/

3.1 Злоупотребление существующими учётными записями
3.1.1 Изменение существующих учётных записей

Злоумышленники могут получить учётные данные или изменить настройки существующих учётных записей для закрепления доступа. Поскольку эти учётные записи имеют легитимное назначение, безопасники могут включить в белый список в своих оповещениях.

В этом примере мы добавим бэкдор в учётную запись www-data. Мы зададим пароль и сделаем www-data пользователем с правами sudo.

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

Мы изменяем файл /etc/passwd, чтобы разрешить подключение по SSH под пользователем www-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

• Искать захардкоженные учётные данные в конфигурационных файлах

Эти методы могут обеспечить более скрытые способы закрепления доступа и с меньшей вероятностью будут обнаружены, поскольку используются легитимными пользователями.

3.3 Обнаружение: Аналогично созданию учётной записи

Подобно созданию учётной записи, это может требовать изменений в таких файлах, как /etc/passwd и /etc/shadow, поэтому предыдущие правила обнаружения создания учётных записей также будут работать.

Снятие дампа /etc/shadow будет зафиксировано правилами auditd:

-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 Поиск учётных записей с активными паролями

Если у вас защищённые образы, которые по умолчанию отключают вход по паролю (например, облачные виртуальные машины), то вы не должны видеть учётные записи с активными паролями.

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)

Если у системных учётных записей в качестве оболочки (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, чтобы увидеть, какие пользователи недавно входили в систему.

>> 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 Authorized Keys

MITRE: https://attack.mitre.org/techniques/T1098/004/

4.1 Добавление SSH Authorized Keys

Добавление 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_keys

• /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 Некоторые примечания по SSH-ключам в authorized_keys

Во-первых, чтобы запутать безопасников, при добавлении 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-ключ с комментарием # 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/*.

Вот пример необработанного лога auditd:

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.

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

Это также создаёт проблемы для других правил, на которые я ссылаюсь, таких как:

• T1543.002_CreateModSystemProcess_Systemd.xml

• T1053.003_Cron_Activity.xml

• T1037_BootLogonInitScripts_CommonDirectories.xml

4.6 Обнаружение: OSQuery

Помимо ранее рассмотренных запросов osquery, если у вас есть fleet, один из способов мониторинга файлов 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    |
+----------+-----------------+----------------------------------+

Можно искать SSH-ключи, которые редко встречаются у вас.

Выводы и что дальше

Мы увидели, что создание и изменение учётных записей — это не только поиск команды useradd.

Необходимо также включать оповещения о модификациях файлов /etc/passwd, /etc/shadow, /etc/gshadow и /etc/group. Кроме того, стоит отслеживать изменения в authorized_keys. Для задач мониторинга целостности файлов я предпочитаю использовать auditd и/или auditbeat.