В операционных системах семейства Linux файл /etc/shadow представляет собой один из наиболее критичных с точки зрения безопасности объектов. В нем хранятся криптографические хэши паролей пользовательских учетных записей, а также сопутствующая информация, такая как сроки действия паролей и блокировки учетных записей. В отличие от некогда используемого /etc/passwd, доступ к /etc/shadow по умолчанию имеет только суперпользователь (root). Прямое или косвенное обращение к этому файлу неавторизованным процессом или пользователем является высокоценным индикатором потенциальной компрометации.
Это действие может сигнализировать о попытке кражи учетных данных для последующей горизонтальной или вертикальной эскалации привилегий, персистентности или подготовки к атакам на другие системы в сети. Для специалистов по информационной безопасности (SOC-аналитиков, инженеров по расследованию инцидентов, пентестеров) понимание контекста, методов обнаружения и анализа таких событий является обязательным навыком.
Механизмы доступа к /etc/shadow и легитимные сценарии
Прежде чем классифицировать событие как враждебное, необходимо четко понимать легитимные способы взаимодействия с файлом. Прямой доступ с правами root характерен для утилит, требующих проверки или изменения паролей. Например, команды passwd, chpasswd или usermod обращаются к файлу при изменении пароля. Демон SSH (sshd) также считывает хэш для верификации при аутентификации по паролю; это легитимный доступ, но его источником должен быть исключительно процесс sshd. Аналогично, система PAM (Pluggable Authentication Modules) использует модули вроде pam_unix.so для взаимодействия с /etc/shadow в процессе аутентификации пользователей. Кроме прямого доступа, легитимные приложения могут использовать программные интерфейсы, такие как getspnam(), для получения информации о записях shadow, что также требует повышенных привилегий.
Ключевые индикаторы компрометации и методы их детектирования
Мониторинг обращений к /etc/shadow должен быть многоуровневым и контекстуальным. Наиболее эффективным и детализированным методом является аудит с помощью auditd (Linux Audit Framework). Наиболее эффективный и детализированный метод. Правило для auditd позволяет фиксировать все события доступа к файлу.
| 1 | auditctl -w /etc/shadow -p rwa -k shadow_access |
Где:
- -w: наблюдение за файлом
- -p rwa: отслеживание чтения, записи и изменения атрибутов
- -k: ключ для поиска
Правило позволяет фиксировать все события чтения, записи и изменения атрибутов файла, генерируя записи в лог /var/log/audit/audit.log
Пример лога на попытку чтения файла пользователем www-data:
| 1 | type=SYSCALL msg=audit(1649325600.123:456): arch=c000003e syscall=2 success=no exit=-13 a0=7ffc34a3b1a0 a1=0 a2=1fffffffffff0000 a3=7ffc34a3b0b0 items=1 ppid=1000 pid=1500 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33 egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="cat" exe="/usr/bin/cat" key="shadow_access" |
Где:
- success=no и exit=-13 (EACCES - доступ запрещен): указывают на неудачную попытку.
- uid=33 (www-data): идентификатор пользователя, инициировавшего вызов.
- comm="cat" exe="/usr/bin/cat": процесс и исполняемый файл.
Дополнительным слоем защиты выступает мониторинг целостности файлов (FIM — File Integrity Monitoring). Инструменты вроде AIDE, Tripwire или OSSEC детектируют не только чтение, но и любые изменения файла /etc/shadow. Несанкционированная модификация, такая как добавление или изменение записи, — это индикатор уже успешной компрометации, часто связанный с созданием скрытых учетных записей или изменением паролей существующих.
Современные системы класса Endpoint Detection and Response (EDR/XDR) обеспечивают глубокий анализ, выходя за рамки единичных событий. Они отслеживают цепочки процессов и их поведенческие аномалии. Например, обращение к /etc/shadow из процесса веб-сервера (apache2, nginx), интерпретатора (python, php) или офисного приложения почти всегда аномально. Подозрительным является и использование утилит для дампа памяти, таких как cat, less или strings, из shell-сессии, которая не является интерактивным логином администратора. Косвенным признаком может быть запуск специализированных утилит типа unshadow (из набора john), предназначенных для подготовки хэшей к оффлайн-перебору.
Практические примеры атак и соответствующие IoC
Рассмотрим типичные сценарии атак, связанные с доступом к /etc/shadow. В первом сценарии злоумышленник эксплуатирует уязвимость Remote Code Execution в веб-приложении, работающем под учетной записью www-data, для выполнения команды cat /etc/shadow. Индикатором компрометации в аудит-логе в этом случае станет событие чтения файла exe="/usr/bin/cat", причем родительским процессом, вероятно, будет apache2 или php-fpm.
Другой распространенный сценарий не оставляет прямых следов на атакуемой системе. Если злоумышленник получает доступ к системе хранения и копирует образ диска виртуальной машины или файл резервной копии, он может извлечь /etc/shadow для оффлайн-атаки перебора. Прямого индикатора на целевой системе не будет, однако факт компрометации может быть выявлен косвенно: через мониторинг доступа к бекапам, анализ сетевого трафика при передаче больших файлов, а также последующие события - например, успешный логин с учетной записью, пароль которой был подобран.
В рамках постэксплуатации злоумышленник, уже получивший привилегии root, может использовать встроенные средства для сбора информации. Например, копирование файла командой cp /etc/shadow /tmp/.hidden_shadow или выполнение Python-скрипта, вызывающего spwd.getspall(). В первом случае сработает правило мониторинга целостности файлов на появление новой копии. Во втором - аудит зафиксирует обращение к файлу со стороны процесса python3. Ключевым маркером угрозы здесь является контекст сессии: такое действие, как правило, выполняется в shell-сессии, установленной после успешного взлома, а не в ходе плановой работы администратора или выполнения запланированного зададания.
| 1 2 3 4 | # Злоумышленник копирует файл для последующей передачи cp /etc/shadow /tmp/.hidden_shadow # Или использует встроенные средства для кражи хэшей python3 -c "import spwd; print(spwd.getspall())" |
Процесс расследования и реагирования
Обнаружение подобного индикатора должно запускать четкий процесс расследования и реагирования. Первым шагом является триггеринг - получение алерта от системы мониторинга (SIEM) на основе логов auditd, FIM или EDR. Далее следует критически важный этап контекстуализации. Необходимо немедленно ответить на ряд вопросов: какой пользователь или процесс инициировал доступ и каков был его уровень привилегий? Было ли это событие единичным или наблюдались массовые попытки? Источником являлся локальный процесс или удаленная команда? Какие сопутствующие события, такие как попытки повышения привилегий или сетевые подключения, происходили до и после инцидента?
На этапе сбора артефактов необходимо обеспечить сохранность доказательств. Это включает дамп памяти и образ диска затронутой системы, извлечение полной истории команд из файлов .bash_history и журналов аудита, а также фиксацию сетевых соединений и открытых файлов на момент инцидента с помощью утилит netstat, ss и lsof.
Меры сдерживания и ликвидации должны быть незамедлительными. Затронутую систему следует изолировать от сети. При малейшем подозрении на успешную кражу хэшей необходима принудительная смена паролей для всех пользователей, а также анализ всех систем в инфраструктуре на предмет использования скомпрометированных учетных данных. Финальным этапом является восстановление. Предпочтительным и наиболее безопасным вариантом часто является полная переустановка системы. Альтернативой может служить тщательная зачистка с восстановлением критичных файлов исключительно из доверенных резервных копий, созданных до момента инцидента.
Рекомендации по укреплению защиты
Для минимизации рисков, связанных с кражей хэшей паролей, необходимо внедрять комплекс мер. Фундаментальным принципом является строгое соблюдение правила наименьших привилегий; ни пользовательские, ни сервисные процессы не должны обладать избыточными правами доступа. Обязательным к внедрению является расширенный аудит через настройку и постоянный анализ логов auditd с их централизованным сбором.
На технологическом уровне важно использовать современные и устойчивые алгоритмы хэширования паролей, такие как yescrypt или bcrypt, с применением длинных солей. Следует максимально ограничить прямое парольную аутентификацию, переходя на аутентификацию по ключам SSH для административного доступа, внедряя многофакторную аутентификацию (MFA) и интегрируя системы с централизованными каталогами вроде LDAP или Kerberos.
Особое внимание нужно уделить защите резервных копий, которые часто становятся целью атакующих. Бекапы должны надежно шифроваться, а доступ к системам их хранения — строго контролироваться и мониториться. Завершает цикл защиты практика регулярных проверок, включающих purple team упражнения и аудиты, направленные на симуляцию атак с кражей учетных данных для оценки реальной устойчивости инфраструктуры.
Заключение
Обращение к файлу /etc/shadow - это не просто подозрительное действие, а высокоточный индикатор, сигнализирующий о потенциально глубокой компрометации Linux-системы. Для эффективного противодействия необходимо выходить за рамки простого детектирования факта доступа и проводить глубокий контекстуальный анализ: кто, когда, как и в рамках какой цепочки атаки совершил это действие. Комбинация проактивного мониторинга (auditd, EDR), корреляции событий в SIEM и четких процедур реагирования позволяет не только обнаружить кражу учетных данных, но и прервать цепочку убийства до того, как злоумышленник достигнет своих конечных целей. В современных условиях, когда атаки становятся все более изощренными, мониторинг доступа к /etc/shadow остается одним из фундаментальных элементов защиты критичной инфраструктуры.
