[Перевод] Поиск способов закрепления в Linux (Часть 2). Манипуляция учётными записями

Данная публикация — перевод серии статей от 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.