На одном из внутренних пентестов ритейлера мы нашли пароль от PostgreSQL в файле
.pgpass домашнего каталога - три символа, root-доступ к продакшн-базе. Через десять минут этот пароль подошёл к SSH соседнего сервера: администратор переиспользовал его на четырёх машинах. Ни одного эксплойта, ни одного CVE - только знание файловой системы Linux и пара команд find с правильными флагами.Русскоязычные статьи о пентесте Linux годами пересказывают списки инструментов вроде Nmap и Metasploit, но молчат о главном: куда смотреть после initial access, какие артефакты Linux для пентестера дают lateral movement за минуты, и какие следы вы при этом оставляете в логах защитникам.
Требования к окружению
Прежде чем разбирать конкретные пути и команды - условия, без которых примеры не воспроизводятся. Подробнее - в нашем материале про linux для пентестера.- ОС цели: Debian/Ubuntu 18.04+ или RHEL/CentOS 7+. Пути и имена лог-файлов различаются между семействами - ниже указаны варианты для обоих
- Уровень доступа: low-privilege shell (
www-data,nobodyили выданная учётка для grey box). Часть артефактов доступна без root, часть - только после privilege escalation - Инструменты:
find,grep,strings,cat,stat- стандартные утилиты, ничего дополнительного тащить на хост не нужно. Для автоматизации - LinPEAS (проект живой, еженедельные коммиты на GitHub) - Сценарий: внутренний пентест или post-exploitation после initial access через Exploit Public-Facing Application (T1190, Initial Access). Для внешнего пентеста большинство артефактов недоступны до получения shell
- OPSEC-контекст: на хосте может работать auditd, CrowdStrike Falcon for Linux или Elastic Defend - какие команды палятся, разобрано в последнем разделе
Первые минуты на хосте: decision tree сбора артефактов Linux
Получили shell - время работает против вас. Порядок действий определяется двумя вещами: ваш уровень привилегий и наличие мониторинга.Что проверять и в каком порядке
| Условие | Первое действие | Второе действие | Почему |
|---|---|---|---|
| Low-priv shell, нет auditd | .bash_history всех доступных пользователей | Конфиги приложений в /var/www, /opt | Максимум credentials при минимуме шума |
| Low-priv shell, auditd активен | cat /etc/passwd - понять список аккаунтов | Только домашние каталоги своего пользователя | find / по всей ФС создаёт сотни событий в audit.log |
| Root после privesc | /etc/shadow - хеши для офлайн-брута | auth.log / journalctl - кто ещё на машине | С root всё доступно, приоритет - credentials для lateral movement |
| Grey box (выданы low-priv креды) | sudo -l - разрешённые команды | Конфиги в /opt, /srv, /var/www | Выданные креды нередко имеют неожиданные sudo-права |
Это не теория - на реальных проектах я трачу первые 60 секунд на определение контекста, и только потом начинаю перебирать файловую систему Linux для пентеста.
Где искать credentials в файловой системе Linux
Поиск паролей в Linux файловой системе - ядро post-exploitation. Один найденный credential часто стоит дороже, чем часы перебора эксплойтов.Linux логи для пентестера: что читать после initial access
Логи - не только артефакты для forensics. Для пентестера логи показывают, кто ещё работает на машине, какие сервисы запущены и не заходил ли кто-то до вас.auth.log: аутентификация и sudo
Файл/var/log/auth.log (Debian/Ubuntu) или /var/log/secure (RHEL/CentOS) записывает каждую попытку входа, каждый sudo и каждое изменение пароля.Чтение этих файлов требует прав root или членства в группе
adm (Debian/Ubuntu). На low-priv shell (www-data, nobody) этот источник недоступен - переходите к разделам /proc и домашним каталогам. Три вещи, которые здесь ищет пентестер:IP-адреса администраторов. Команда
grep "Accepted" /var/log/auth.log показывает успешные SSH-входы с IP. Эти IP - потенциальные цели для lateral movement: если администратор заходит отсюда, значит, там тоже есть его рабочая станция или jump-host.Учётные записи с sudo. Команда
grep "sudo:" /var/log/auth.log | grep "COMMAND" показывает, кто и что запускал через sudo. Если пользователь deploy делает sudo docker exec - у него есть sudo-права, и его учётка стоит дороже при credential harvesting.Неудачные попытки входа. Команда
grep "Failed" /var/log/auth.log показывает bruteforce-попытки. Если кто-то уже брутил SSH до вас - возможно, на машине был другой атакующий, и стоит проверить persistence-артефакты.Бинарные файлы
/var/log/wtmp (разбирается last) и /var/log/btmp (разбирается lastb, нужен root) дают хронологию входов. Команда lastlog показывает последний вход каждого пользователя - аккаунты, «спавшие» месяцами и вдруг ставшие активны, по данным hadess.io, заслуживают отдельного расследования.auth.log ротируется (обычно раз в неделю через logrotate). Если initial access произошёл давно, старые логи могут быть сжаты в .gz-архивы - проверяйте auth.log.1.gz, auth.log.2.gz через zgrep.journalctl и syslog: сервисы и автозапуск
На systemd-системах (Ubuntu 16.04+, RHEL 7+ - то есть подавляющее большинство серверов сегодня)journalctl агрегирует все журналы. Что полезно пентестеру:journalctl -u cron --since "1 week ago"- какие cron-задачи выполнялись. Cron, запускающий скрипт из/tmpили/dev/shm, - след предыдущего атакующего или persistence-механизмjournalctl -u ssh --since today- SSH-события за сегодня. Логин с незнакомого IP в 3 часа ночи - на машине кто-то естьjournalctl --list-boots- список перезагрузок. Внезапная перезагрузка в рабочий день может указывать на kernel panic от эксплойта или ручное вмешательство администратора после обнаружения инцидента
/var/log/syslog (Debian) или /var/log/messages (RHEL).Следы атаки в файловой системе Linux: /tmp, /dev/shm и /proc
Временные каталоги как стоянка инструментов
Каталоги/tmp и /dev/shm - излюбленные стоянки для инструментов атакующего. Причины просты: /tmp доступен на запись всем, а /dev/shm - tmpfs в оперативной памяти, данные не переживают перезагрузку, что затрудняет forensics. Оба каталога часто исключены из мониторинга EDR на Linux.Что искать:
ls -la /tmp /dev/shm покажет файлы с нетипичными именами. Скрытые каталоги (имя начинается с .) в /tmp - почти гарантированный признак компрометации. По данным hadess.io, скрытые файлы в /tmp и web-writable директориях - стандартные стоянки атакующих. Каталог /var/tmp тоже стоит проверить: в отличие от /tmp, файлы здесь переживают перезагрузку.На legacy-серверах (без EDR, без auditd) артефакты в
/tmp лежат неделями и никого не беспокоят. На modern-инфраструктурах с CrowdStrike Falcon for Linux или Elastic Defend запись бинарника в /tmp с последующим исполнением вызывает алерт за секунды - поведенческий анализ детектирует паттерн «write-then-execute» в мировой директории./proc - живая карта процессов
Виртуальная файловая система/proc содержит информацию о каждом запущенном процессе, и для credential harvesting она бывает ценнее любого конфигурационного файла:/proc/[PID]/cmdline- полная командная строка процесса вместе с аргументами. Иногда здесь видны пароли, переданные через-pили--password: администратор запустилmysqldump -u root -pSecret- и процесс висит/proc/[PID]/environ- переменные окружения.DB_PASSWORD,API_KEY,AWS_SECRET_ACCESS_KEYнередко передаются через env вместо конфигов/proc/[PID]/exe- символическая ссылка на исполняемый файл процесса. Черезcp /proc/PID/exe /tmp/recoveredможно скопировать бинарь, даже если он удалён с диска (пока процесс жив)./proc/[PID]/maps+dd if=/proc/[PID]/mem- для дампа конкретных регионов памяти процесса (например, поиск credentials в heap)
for pid in $(ls /proc | grep -E '^[0-9]+$'); do tr '\0' '\n' < /proc/$pid/environ 2>/dev/null | grep -iE 'pass|secret|token|key' && echo "--- PID: $pid ---"; done ищет пароли в переменных окружения процессов вашего UID с привязкой к PID. Без root вы видите PID-каталоги всех процессов, но environ/mem чужих процессов недоступны из-за прав на файлы (0600, владелец - UID процесса) - доступ есть только к процессам своего UID. Если в /proc выставлен [URL='https://www.kernel.org/doc/html/latest/filesystems/proc.html']hidepid=1[/URL] или hidepid=2 - вы не видите даже PID-каталоги чужих процессов (на legacy-системах этот параметр часто не выставлен).Persistence-артефакты Linux: crontab, systemd и автозагрузка
Поиск persistence нужен пентестеру по двум причинам: обнаружить след предыдущего атакующего и понять, куда можно закрепиться при необходимости.Cron - проверяется на трёх уровнях: системный (
/etc/crontab, /etc/cron.d/, /etc/cron.daily/), пользовательский (/var/spool/cron/crontabs/[user] на Debian, /var/spool/cron/[user] на RHEL) и anacron (/etc/anacrontab).Systemd - на modern-системах:
/etc/systemd/system/ и /lib/systemd/system/ содержат юниты сервисов, systemctl list-timers показывает активные таймеры (современный аналог cron), а в /run/systemd/transient/ создаются юниты через systemd-run - часто используемый путь persistence без файлов в привычных местах.Автозагрузка при логине:
/etc/profile.d/ (скрипты для всех пользователей), ~/.bashrc, ~/.profile - атакующий может вставить reverse shell в .bashrc, и он сработает при следующем SSH-входе легитимного пользователя. На legacy-системах без systemd проверяйте /etc/rc.local.
Код:
# Быстрая проверка всех crontab
for user in $(cut -d: -f1 /etc/passwd); do
crontab -l -u "$user" 2>/dev/null | grep -v "^#" | grep -v "^$"
done
# Systemd-юниты, созданные за последнюю неделю
find /etc/systemd/system -type f -mtime -7 -name "*.service".bash_history на внешний сервер через curl -X POST. Пользователь обнаружил в истории команду transferfiles, которая оказалась алиасом в .bashrc, скрывающим реальную операцию копирования конфиденциальных данных с USB-устройства. Алиасы - отдельный артефакт: grep "alias " ~/.bashrc ~/.bash_aliases 2>/dev/null покажет скрытые за безобидными именами команды. Я встречал алиас ls, который при каждом вызове тихо дописывал содержимое ~/.ssh/id_rsa в скрытый файл.Какие следы оставляет enumeration в логах и SIEM
Всё, что описано выше, оставляет артефакты взлома Linux - но уже ваши. Если на хосте настроенauditd (а на серверах в зрелых инфраструктурах он стоит), каждое действие записывается.Что видит auditd:
- Каждый
open()иread()на/etc/shadowфиксируется с вашим UID, PID и timestamp - Массовый
find /генерирует тысячи событийopenat()- аномалию, которую SIEM-правило ловит за секунды - Чтение
/proc/[PID]/environчужого процесса - событие, которое в нормальной работе практически не встречается - Даже
cat /var/log/auth.logзаписывается, если auditd настроен с правилом на каталог/var/log/
connect()/socket() syscalls или сетевую телеметрию EDR.
Код:
# Проверить наличие auditd ДО начала enumeration
systemctl is-active auditd 2>/dev/null && echo "AUDITD ACTIVE"
auditctl -l 2>/dev/null | head -5- Читайте файлы через
cat, а не текстовые редакторы -vimсоздаёт.swp-файлы и записи в.viminfo,nanoоставляет backup-файлы - Избегайте
find /по всей файловой системе - ищите в конкретных каталогах (/home,/var/www,/opt). Точечное чтение трёх файлов менее заметно, чем сканирование десяти тысяч HISTFILE=/dev/nullотключает запись истории, но auditd всё равно видит каждыйexecve- На серверах с CrowdStrike Falcon for Linux или Elastic Defend запуск LinPEAS вызывает алерт по поведенческому анализу - массовое чтение чувствительных файлов за секунды не характерно для легитимных процессов. Ручной точечный сбор шумит меньше, чем автоматизация
grep по конкретным путям медленнее, зато почти неотличим от легитимной активности администратора. Выбор зависит от контекста: на внутреннем пентесте с зелёным светом от заказчика LinPEAS экономит часы; при red team операции, где детект критичен, ручной подход - единственный вариант.За несколько лет пентестов Linux-инфраструктур я пришёл к неудобному выводу: подавляющее большинство credential-находок - результат не сложной эксплуатации, а того, что администраторы годами не чистят
.bash_history и хранят пароли в .env-файлах с правами 644. Автоматические скрипты вытаскивают основную массу артефактов, но оставшиеся 20% - переменные окружения в /proc, алиасы в .bashrc, нестандартные конфиги в /opt - требуют ручного разбора, и именно они чаще дают выход на domain admin или доступ к production-базам. Рынок движется к vault-решениям и ephemeral credentials, но legacy-серверы с plain-text паролями будут жить ещё пять-семь лет - каждый внутренний пентест это подтверждает. Vault-миграция идёт медленно, а пока она идёт - один grep -ri password /etc/ стоит дороже любого zero-day. На HackerLab есть Linux-задачи, где без грамотного сбора артефактов дальше первого шага не пройдёшь - хороший способ отработать эти навыки до реального проекта.
