На вашем домене развернули фишинг: как узнать об этом первым

MAATRIX

Если на вашем сайте когда-то была уязвимость — устаревший плагин, слабый пароль от FTP, дырявая форма загрузки файлов — есть шанс, что в глубине директорий уже лежит поддельная страница входа в банк или почтовый сервис. Такие страницы почти никогда не портят вид главной: жертву на них приводят по прямой ссылке из письма или мессенджера, а вы годами не заходите в папку /wp-content/uploads/2023/promo/ и не видите, что там происходит. Обычно об этом узнают последними — когда домен уже в чёрном списке Google Safe Browsing, хостинг присылает уведомление о блокировке, или пишет банк, чей логотип использовали для кражи паролей. Ниже — как выстроить процесс, чтобы узнать о фишинге на своём домене первым, а не крайним.

Почему фишинг на вашем домене вы обнаруживаете последним

Логика атакующего прямо противоположна логике дефейса. Если сайт взламывают, чтобы разместить свою рекламу или майнер, это рано или поздно видно — падает производительность, меняется главная страница, растут жалобы пользователей. Фишинг устроен иначе: чем дольше владелец сайта не замечает подделку, тем дольше она собирает пароли. Поэтому страницу кладут в директорию, куда никто не заходит руками: в подпапку загрузок, в неиспользуемый раздел старой версии сайта, иногда прямо рядом с robots.txt, но с именем, которое не бросается в глаза при беглом просмотре списка файлов.

Дальше работает асимметрия по времени. Жертва обычно переходит по ссылке из фишингового письма или сообщения, а не ищет её в поиске — значит, обычный мониторинг доступности сайта (проверка того, что главная страница отвечает 200 OK) проблему вообще не видит: сайт как работал, так и работает. Первым узнаёт кто-то из внешнего контура: спам-фильтр получателя, служба безопасности банка, чей бренд подделали, антивирус посетителя или краулер Google, который сверяет новую страницу с базой известных фишинговых шаблонов. К моменту, когда до вас доходит уведомление о блокировке или жалоба, страница может провисеть от нескольких часов до нескольких недель — а домен уже помечен как небезопасный в браузерах у части аудитории.

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

Как фишинговая страница оказывается в скрытой директории

Точка входа почти всегда одна и та же: уязвимость или слабая учётная запись, через которую на сервер попадает произвольный файл. Дальше сценарий предсказуем.

• Уязвимый плагин или тема CMS. Особенно тот, который давно не обновлялся и о котором забыли — сайт им уже не пользуется, но код остался в файловой системе с правом на запись.
• Скомпрометированные учётные данные FTP/SSH/панели хостинга. Пароль утёк в чужой утечке, переиспользован на нескольких сервисах, или его подобрали брутфорсом без лимита попыток.
• Открытая форма загрузки файлов без проверки расширения и типа содержимого — классический путь для загрузки веб-шелла, через который дальше заливается уже сама фишинговая страница.
• Заражённый компьютер разработчика или подрядчика, с которого угнали сохранённые пароли или SSH-ключ.

Дальше злоумышленник создаёт директорию с непримечательным именем — случайный набор символов, похожий на кеш-папку, или имя, маскирующееся под системное (wp-includes/js/tinymce/plugins/wp-secure/, assets/lib/.cache/). Внутри — копия страницы входа целевого банка или сервиса со стилями и логотипом; форма отправляет данные на сторонний сервер или на почту атакующего, а .htaccess рядом прячет директорию от индексации и блокирует доступ по IP-адресам, похожим на ботов Google, — чтобы страница подольше не попала в поисковые системы.

Ключевой момент для защиты: точка входа и место, где лежит фишинг, почти никогда не совпадают физически. Уязвимость может быть в одном плагине, а страницу зальют совсем в другую директорию — поэтому находка фишинга это сигнал искать дыру во всём проекте, а не только чистить конкретную папку.

Регулярный аудит структуры директорий

Самый надёжный способ поймать подделку до того, как её найдёт кто-то другой, — сравнивать текущее состояние файловой системы с эталонным списком, а не полагаться на то, что вы «и так знаете, что там лежит».

Первый шаг — снять базовый снимок структуры сайта, когда вы уверены, что он чист:

find /var/www/site/public_html -type f -printf '%T@ %s %P\n' | sort -k3 > /root/audit/baseline-$(date +%F).txt

Дальше — регулярное сравнение. Простой вариант на cron без дополнительного софта:

#!/bin/bash
SITE=/var/www/site/public_html
BASELINE=/root/audit/baseline-current.txt
CURRENT=/root/audit/current.txt

find "$SITE" -type f -printf '%P\n' | sort > "$CURRENT"
NEW_FILES=$(comm -13 "$BASELINE" "$CURRENT")

if [ -n "$NEW_FILES" ]; then
  echo "Новые файлы на сайте:
$NEW_FILES" | mail -s "Аудит директорий: обнаружены изменения" you@example.com
fi

Такой скрипт не заменяет систему контроля целостности, но ловит главное — новые файлы и директории между запусками. Для более серьёзного подхода — AIDE (Advanced Intrusion Detection Environment): он считает хеши файлов и хранит базу отдельно от веб-сервера:

apt install aide
aideinit
# после проверки, что база чистая:
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
# ежедневная проверка
aide --check

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

find /var/www/site/public_html -type f -mtime -3 \
  \( -path "*/wp-content/uploads/*" -o -path "*/tmp/*" -o -path "*/cache/*" \) \
  -printf '%T@ %p\n' | sort -n

Особое внимание — к директориям с точкой в начале имени, папкам со случайными именами, .htaccess в неожиданных местах и файлам с двойным расширением (login.php.html, bank-secure.html.php). Запускайте аудит не реже раза в сутки и сразу после обновления CMS или плагинов — именно после апдейтов чаще всего меняются права доступа.

Мониторинг репутации домена в системах безопасности

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

Проверка вручную через Transparency Report Google Safe Browsing бесплатна и не требует ключа — но её неудобно гонять по расписанию. Для автоматизации используется Safe Browsing API v4 (нужен ключ в Google Cloud Console, есть бесплатная квота для небольшого числа запросов в сутки):

curl -s -X POST \
  "https://safebrowsing.googleapis.com/v4/threatMatches:find?key=$GSB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "client": {"clientId": "myproject", "clientVersion": "1.0"},
    "threatInfo": {
      "threatTypes": ["SOCIAL_ENGINEERING", "MALWARE"],
      "platformTypes": ["ANY_PLATFORM"],
      "threatEntryTypes": ["URL"],
      "threatEntries": [{"url": "https://example.com/"}]
    }
  }'

Пустой ответ {} означает, что URL чист; непустой matches — что домен или страница уже в базе. Смысл в том, чтобы прогонять по этому запросу не только главную страницу, а список известных URL сайта, дополняя его свежими путями из логов веб-сервера, — так можно поймать подделку, о существовании которой вы ещё не знаете.

Search Console и Яндекс.Вебмастер работают медленнее — это отдельные краулеры со своим расписанием, и между заливкой фишинга и уведомлением может пройти от суток до нескольких дней. Тем не менее подключить оба сервиса и включить e-mail-оповещения нужно обязательно — это бесплатный второй контур мониторинга, независимый от вашей инфраструктуры: он продолжит работать, даже если скомпрометирован сам сервер.

Настройка алертов: от находки до уведомления за минуты

Мониторинг репутации и аудит файлов бессмысленны, если результат никто не видит вовремя. Правило то же, что и для любого другого мониторинга: если алерт падает в чат, который никто не читает, толку от него ровно ноль — этой ошибке была посвящена отдельная статья про мониторинг, который никто не смотрит, и логика там применима один в один.

Практическая схема для проекта среднего размера:

1. Cron-задача аудита директорий (см. выше) раз в сутки, а на высоконагруженных или часто атакуемых сайтах — каждые несколько часов.
2. Проверка Safe Browsing API по расписанию, отдельно от аудита файлов — она ловит то, что уже увидел внешний краулер, даже если ваш локальный снимок ещё не обновился.
3. Healthchecks.io или аналог как «мёртвая рука»: если cron-задача аудита вообще перестала запускаться (например, сервер лёг или скрипт упал с ошибкой), вы узнаёте не только о фишинге, но и о том, что сам контроль перестал работать.
4. Доставка алерта минимум в два канала — почта плюс мессенджер (Telegram-бот через webhook — самый простой вариант), чтобы не зависеть от одного канала, который тоже может замолчать.

Минимальный пример отправки в Telegram из скрипта аудита:

send_alert() {
  curl -s -X POST "https://api.telegram.org/bot$TG_TOKEN/sendMessage" \
    -d chat_id="$TG_CHAT_ID" \
    -d text="$1"
}

if [ -n "$NEW_FILES" ]; then
  send_alert "Аудит $(hostname): новые файлы в public_html:
$NEW_FILES"
fi

Важно держать порог чувствительности разумным: если алерт срабатывает на каждый файл кеша, через пару недель его начнут игнорировать. Исключите из аудита директории, которые легитимно меняются сами (кеш CMS, временные файлы сборки, папки сессий), и следите отдельно за оставшимся.

Первые часы после обнаружения: как ограничить репутационный ущерб

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

Немедленно, до разбора причины:

• Удалите или переместите вне веб-корня саму фишинговую директорию — не просто index, а всю папку целиком, включая вспомогательные файлы (стили, шрифты, скрипты формы).
• Сохраните копию удалённых файлов в отдельном месте вне продакшена — она понадобится для разбора точки входа и, возможно, для обращения в банк, чей бренд подделали.
• Проверьте логи веб-сервера на предмет того, как долго страница существовала и кто на неё заходил — это подскажет масштаб утечки и то, скольким людям, возможно, стоит сообщить.

В течение суток:

• Найдите точку входа. Начните с проверки времени изменения файлов вокруг даты появления фишинговой директории — злоумышленник почти всегда что-то модифицирует незадолго до или сразу после заливки (конфиг, .htaccess, файл плагина).
• Смените все пароли и ключи, которые теоретически могли быть скомпрометированы: FTP, SSH, панель хостинга, административный доступ CMS.
• Обновите или удалите уязвимый компонент, через который произошла заливка. Если не уверены, какой именно, — временно закройте загрузку файлов и административные разделы по IP, пока не разберётесь.

Для восстановления репутации:

• Подайте запрос на пересмотр через Google Search Console (раздел «Проблемы безопасности» → «Запросить проверку») только после того, как убедились, что вредоносного контента больше нет нигде на сайте, а не только в найденной директории.
• Проверьте домен через Transparency Report и Яндекс.Вебмастер повторно — пометка снимается не мгновенно, обычно требуется от нескольких часов до нескольких дней после подтверждения очистки.
• Если пострадал не только поиск, но и репутация в спам-фильтрах или антивирусах, процесс похож на делистинг из чёрных списков — общие принципы и таймлайны разобраны в статье про восстановление доменной репутации.

Полный порядок действий при взломе сервера в целом — с изоляцией, поиском закладок и восстановлением из чистого бэкапа — подробно расписан в статье «Взломали сервер: пошаговый план»; при фишинге в скрытой директории применимы те же базовые шаги, только с акцентом на скорость снятия конкретной страницы и на быструю коммуникацию с системами репутации.

Частые вопросы