Матрешка из Base64 и ROT13: разбираем вредоносный .sh, нацеленный на FreePBX
Вредоносные shell-скрипты редко ограничиваются одной-единственной командой. Зачастую перед аналитиком оказывается целая цепочка вложенных полезных нагрузок, где каждый следующий слой скрыт за Base64, ROT13 или другими простыми способами обфускации.
Именно такой образец попался при анализе файла с расширением `.sh`. Начальная часть выглядела относительно понятно, однако затем начиналась последовательность декодирования: Base64, ROT13, снова Base64 и дополнительные фрагменты, замаскированные под обычный текст. После расшифровки одного блока появлялся следующий, а внутри него - еще один. Получилась своеобразная цифровая матрешка.
Сам по себе Base64 не является шифрованием и не обеспечивает защиту данных. Его используют лишь для изменения представления содержимого. ROT13 работает аналогично: символы заменяются по фиксированному правилу. Однако в сочетании с большим количеством мусора, повторяющихся строк и вложенных команд такие приемы заметно усложняют первичный анализ.
Как безопасно изучать подобные файлы
Наиболее опасный фрагмент скрипта практически сразу получает данные с удаленного сервера и передает их непосредственно в `bash`. Для злоумышленника это удобно: содержимое полезной нагрузки можно изменить в любой момент, не заменяя исходный файл. Для исследователя это серьезная проблема - результат анализа сегодня может отличаться от результата завтра.
Запускать такую конструкцию в рабочей системе нельзя. Даже изолированная виртуальная машина должна быть подготовлена заранее: без доступа к корпоративной сети, с отключенными общими папками и снимком состояния перед началом работы.
Безопаснее сначала сохранить ответ сервера в отдельный файл, затем изучить его статически. При необходимости сетевое обращение можно заменить заранее подготовленной копией ответа. Для снятия обфускации удобно использовать небольшие локальные скрипты, которые выполняют операции поэтапно и сохраняют каждый промежуточный результат.
После удаления мусора и повторяющихся блоков в образце проявились несколько основных направлений атаки:
- создание веб-шеллов в каталогах FreePBX;
- добавление пользователей с идентификатором UID 0;
- изменение учетных записей и паролей;
- перестройка конфигурации SSH;
- закрепление через cron;
- удаление существующих пользователей;
- кража конфигурации Asterisk;
- загрузка дополнительных payload'ов;
- попытка затруднить удаление вредоносных файлов.
Таким образом, перед нами не обычный bash-скрипт, а полноценный постэксплуатационный набор.
Веб-шеллы и несколько точек входа
PHP-код записывается в веб-директории, после чего копируется в несколько дополнительных мест. Среди имен встречается `ajax.php`, но этим набор не ограничивается: создаются и другие файлы с похожим содержимым.
Такая схема рассчитана на выживание после частичной очистки. Если администратор обнаружит и удалит один файл, другой может остаться незамеченным. Несколько копий также увеличивают вероятность того, что злоумышленник сохранит доступ через веб-сервер.
Отдельно скрипт пытается создать или изменить `.htaccess`. Это может использоваться для управления обработкой запросов, перенаправления обращений или упрощения доступа к спрятанным PHP-файлам. Поэтому при расследовании недостаточно просмотреть только каталоги с расширением `.php`: необходимо проверить скрытые конфигурационные файлы, права доступа и дату изменения содержимого.
Защита backdoor от удаления
В образце встречается попытка установить для вредоносных файлов атрибут immutable с помощью `chattr +i`. Такой атрибут запрещает обычное изменение, переименование и удаление файла даже при наличии подходящих прав.
В результате команда удаления может завершиться ошибкой, хотя пользователь работает с административными полномочиями. Для расследования это важный признак: необходимо проверять атрибуты не только подозрительных PHP-файлов, но и связанных конфигураций.
Проверка выполняется средствами `lsattr`. Если обнаружен установленный флаг `i`, его следует снять только после фиксации состояния системы и сохранения копии объекта для дальнейшего анализа.
Пользователи с UID 0
Один из самых серьезных фрагментов - создание учетных записей с UID 0. В Linux именно UID определяет идентичность пользователя с точки зрения ядра, поэтому имя такой учетной записи вторично. Любой пользователь с UID 0 фактически получает права root.
Это означает, что злоумышленнику необязательно каждый раз входить под именем `root`. Достаточно использовать созданную учетную запись, которая обладает теми же привилегиями.
Проверку следует начинать с анализа `/etc/passwd`, сопоставляя UID всех пользователей. В штатной системе UID 0 обычно принадлежит только `root`. Дополнительные записи с тем же значением требуют немедленного расследования. Нужно также проверить соответствующие строки в `/etc/shadow`, группы, домашние каталоги, историю команд и журналы входов.
Удаление существующих учетных записей
После создания собственных точек доступа скрипт начинает удалять пользователей. В первую очередь могут удаляться дополнительные аккаунты с UID 0, за исключением стандартного `root`. Затем затрагиваются пользователи, имеющие домашние каталоги в `/home`.
Отдельные команды работают напрямую с `/etc/passwd`, `/etc/shadow`, `/etc/group` и `/etc/gshadow`, удаляя строки вручную. Это грубая, но эффективная тактика: легитимные администраторы могут потерять возможность войти в систему, а другие потенциальные backdoor'ы конкурирующих злоумышленников будут устранены.
Подобное поведение особенно опасно для FreePBX-серверов, которые нередко обслуживаются несколькими специалистами и имеют отдельные технические учетные записи. После обнаружения компрометации необходимо не только вернуть удаленных пользователей, но и проверить, не были ли изменены их ключи, пароли и права доступа.
SSH и изменение паролей
Скрипт также приводит в порядок SSH-конфигурацию под нужды атакующего. Проверять следует разрешение входа с повышенными привилегиями, возможность парольной аутентификации, список разрешенных пользователей, дополнительные конфигурационные файлы и содержимое `authorized_keys`.
Особое внимание нужно уделить каталогам `/root/.ssh` и домашним каталогам пользователей. Неизвестный публичный ключ может обеспечить постоянный доступ даже после смены пароля.
Смена паролей в такой ситуации не решает проблему автоматически. Если сохранены SSH-ключи, cron-задачи, веб-шеллы или другие механизмы закрепления, злоумышленник сможет войти повторно. Сначала следует устранить все точки persistence, затем выполнить ротацию учетных данных и ключей.
Закрепление через cron
Для сохранения доступа вредоносный скрипт добавляет задания в cron. Особенно подозрительно наличие нескольких одинаковых или почти одинаковых строк. Это может быть сделано намеренно: если администратор удалит одну запись, другая продолжит запускать payload.
Проверять нужно сразу несколько уровней:
- пользовательские crontab;
- `/etc/crontab`;
- `/etc/cron.d`;
- каталоги `cron.hourly`, `cron.daily`, `cron.weekly` и `cron.monthly`;
- системные таймеры `systemd`;
- задания, запускаемые из профилей оболочки.
Повторяющиеся задания могут свидетельствовать как о небрежности автора, так и о расчете на частичное удаление. Каждую запись нужно сопоставить с временем изменения файлов и событиями в журналах.
Кража конфигурации Asterisk и FreePBX
Отдельное направление атаки - сбор конфигурационных файлов Asterisk и FreePBX. В них могут находиться учетные данные SIP-абонентов, пароли к базам данных, параметры внешних шлюзов, сведения о маршрутизации звонков и настройки интеграций.
Компрометация таких файлов опасна не только для самого сервера. Злоумышленник может использовать SIP-учетки для несанкционированных звонков, получить доступ к голосовой инфраструктуре, прослушивать отдельные сервисные каналы или атаковать связанные системы.
После инцидента необходимо сменить пароли SIP-абонентов, учетные данные базы данных, секреты API и пароли внешних операторов. Также следует проверить CDR, журналы регистрации и нетипичные международные направления вызовов.
Дополнительные удаленные payload'ы
После основной настройки системы скрипт загружает дополнительные фрагменты с удаленных узлов. Это позволяет разделить атаку на несколько этапов: начальный файл выполняет подготовку, а дальнейшее поведение определяется содержимым, полученным позже.
Такой подход затрудняет восстановление полной картины. Один и тот же образец может выполнять разные действия в зависимости от ответа сервера, времени суток, IP-адреса или наличия определенных процессов.
При расследовании важно зафиксировать DNS-запросы, сетевые соединения, HTTP-заголовки, URI, временные метки и полученные ответы. Даже если удаленный сервер уже недоступен, записи в прокси, firewall, DNS или сетевых сенсорах могут помочь восстановить последовательность событий.
Попытка скрыть следы
Вредоносный код может удалять временные файлы, очищать отдельные журналы, менять даты файлов и маскировать процессы под легитимные имена. Однако полное уничтожение следов встречается реже: злоумышленник часто оставляет ошибки, временные каталоги, историю команд или записи в системных журналах.
Искать признаки компрометации стоит не только в содержимом файлов, но и в метаданных:
- необычное время создания или изменения;
- файлы в системных каталогах, появившиеся одновременно;
- PHP-скрипты с короткими именами;
- новые задания cron;
- неизвестные процессы;
- исходящие соединения к редким адресам;
- изменения владельца и прав доступа.
Почему FreePBX представляет интерес
FreePBX объединяет веб-интерфейс, Asterisk, базы данных, SIP-учетки и системные службы. Компрометация одной компоненты может привести к контролю над всей телефонной инфраструктурой.
Веб-панель особенно привлекательна для атакующих: через нее можно получить доступ к конфигурации, а при наличии уязвимости или слабых учетных данных - выполнить команды от имени системного пользователя. Если сервис доступен из интернета, его необходимо ограничивать межсетевым экраном, VPN или списком разрешенных адресов.
Что проверить после обнаружения
Минимальный перечень действий включает:
1. Изолировать сервер от сети, сохранив возможность локального реагирования.
2. Зафиксировать оперативную память, список процессов и сетевые соединения.
3. Сохранить подозрительные файлы и их хэши.
4. Проверить UID 0, SSH, cron, systemd и веб-каталоги.
5. Проанализировать конфигурацию Asterisk и FreePBX.
6. Сменить все пароли, ключи и секреты после устранения persistence.
7. Проверить журналы входов, SIP-регистрации и исходящие звонки.
8. По возможности восстановить систему из заведомо чистого образа.
IOC
К потенциальным индикаторам компрометации относятся:
- неизвестные IP-адреса и домены, с которых загружаются скрипты;
- подозрительные URI;
- копии `ajax.php` и других PHP-файлов;
- измененные `.htaccess`;
- пользователи с UID 0, кроме `root`;
- новые ключи в `authorized_keys`;
- задания cron с одинаковым содержимым;
- файлы с установленным атрибутом immutable;
- неожиданные изменения конфигурации SSH;
- обращения к файлам конфигурации Asterisk и FreePBX.
Итог
Рассмотренный скрипт сочетает сразу несколько механизмов: обфускацию, веб-шеллы, создание root-подобных пользователей, изменение SSH, persistence через cron, удаление конкурирующих учетных записей, кражу конфигурации телефонии и загрузку новых компонентов.
Главный вывод прост: подозрительный `.sh` нельзя запускать "для проверки", даже если его первая часть выглядит безобидно. Безопасный анализ начинается с изоляции, сохранения исходного образца и пошагового снятия обфускации. Если хотя бы один из описанных признаков обнаружен на реальном сервере, систему следует считать скомпрометированной до тех пор, пока не доказано обратное.