Защита от “watering hole”-атак: проверка репутации корпоративных сайтов

“Watering hole” опасна тем, что сотрудник не кликает на явно подозрительную ссылку из письма. Он заходит на привычный корпоративный сайт, отраслевой портал, сайт поставщика или документацию — и уже там получает вредоносный скрипт, редирект или поддельную форму входа. Поэтому защита строится не только вокруг почты, а вокруг репутации сайтов, которые регулярно посещают сотрудники, и вокруг контроля собственных корпоративных доменов.

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

Не считайте сайт безопасным только потому, что он выглядит официальным, использует HTTPS или находится в списке “проверенных”. При watering hole-атаке злоумышленники как раз стараются попасть на доверенные ресурсы.

Что именно нужно проверять

В такой задаче обычно есть две стороны.

Первая — собственные сайты компании: корпоративный сайт, портал клиентов, сайт продукта, документация, поддомены, лендинги, CDN-адреса. Если их скомпрометируют, они могут заразить клиентов, партнёров или сотрудников, которые заходят туда извне.

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

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

Как выглядит watering hole на практике

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

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

Как построить проверку репутации сайтов

1. Соберите список корпоративных сайтов и ресурсов. Внесите туда собственные домены, поддомены, сайты поставщиков, партнёрские кабинеты, сервисы подрядчиков, отраслевые порталы и страницы загрузок. Для каждого ресурса укажите владельца внутри компании и уровень риска.
2. Разделите сайты по критичности. Логин-порталы, финансовые системы, сайты загрузок, документация по продуктам и ресурсы для администраторов должны проверяться чаще, чем обычные информационные страницы.
3. Настройте автоматическую проверку репутации. Подключите DNS-фильтрацию, web proxy или secure web gateway, EDR, SIEM и feeds с данными об угрозах. Система должна видеть домены, URL, IP, сертификаты, редиректы и файлы, которые скачиваются с сайтов.
4. Проверяйте поведение сайта, а не только его имя. Репутация домена может быть хорошей, но страница может подгружать подозрительный скрипт, открывать iframe или вести на другой домен.
5. Используйте песочницу для сомнительных ресурсов. Если сайт неизвестный, новый или связан с критичной задачей, открывайте его в изолированной среде или через remote browser isolation.
6. Мониторьте изменения. Для собственных сайтов особенно опасны новые поддомены, смена DNS, новые JavaScript-файлы, неожиданные сертификаты и появление внешних скриптов.
7. Заранее подготовьте порядок действий при инциденте. Нужно быстро блокировать домен, изолировать заражённые устройства, собрать логи и понять, был ли доступ к учётным данным.

Какие признаки портят репутацию сайта

Один признак редко даёт стопроцентный ответ. Но если совпадает несколько сигналов, сайт лучше отправить на дополнительную проверку.

• Неожиданные редиректы. Особенно если сайт сначала открывает привычную страницу, а затем уходит на другой домен.
• Новые или странные поддомены. Например, update.company.example, login-secure.company.example или домен, похожий на официальный, но с лишним символом.
• Подозрительный JavaScript. Обфусцированный код, скрытые iframes, загрузка скриптов с неизвестных доменов.
• Неожиданные загрузки. Архивы, установщики, документы с макросами, файлы с двойными расширениями.
• Смена TLS-сертификата. Сам по себе сертификат не говорит о безопасности, но резкая смена на собственном сайте — повод проверить, кто его выпустил.
• Связь с плохим IP или ASN. Если домен недавно переехал на инфраструктуру, связанную с вредоносной активностью, это серьёзный сигнал.
• Несоответствие назначению сайта. Страница документации начинает предлагать обновление браузера, архив с “патчем” или форму повторного ввода пароля.
• Короткая история существования. Новый домен не всегда опасен, но для корпоративного ресурса с большим трафиком это повод смотреть внимательнее.

Сравнение способов проверки

Что проверять на собственном корпоративном сайте

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

Минимальный набор проверок для собственного сайта:

• регулярное сканирование страниц на наличие вредоносного кода;
• контроль всех поддоменов, включая забытые лендинги и тестовые зоны;
• мониторинг изменений в CMS, плагинах, темах и шаблонах;
• проверка сторонних скриптов: аналитики, чатов, виджетов, рекламных сетей;
• контроль TLS-сертификатов и появление новых сертификатов в Certificate Transparency;
• WAF для защиты от типовых веб-атак;
• ограничение прав администраторов и обязательная многофакторная аутентификация;
• резервные копии и понятный план восстановления, если сайт уже заражён.

Отдельно стоит смотреть на сторонние JavaScript-библиотеки. При watering hole и supply chain-атаках часто заражают не сам сайт, а подключённый скрипт. Если на странице есть внешние скрипты, у них должны быть понятные владельцы, версии и контроль изменений.

Как проверять внешние сайты, которые посещают сотрудники

Для внешних корпоративных ресурсов лучше не полагаться на ручные проверки “по ощущениям”. Сотрудник не обязан каждый раз анализировать JavaScript и сертификаты. Его задача — работать, а защита должна стоять на входе в интернет.

Практичная схема выглядит так:

1. Все запросы к внешним сайтам проходят через DNS-фильтрацию или web gateway.
2. Домены и URL проверяются по репутационным источникам и внутренним спискам.
3. Новые, неизвестные и низкорепутационные сайты отправляются в дополнительную проверку.
4. Файлы с таких сайтов открываются в песочнице до допуска к пользователю.
5. Для рискованных категорий включается browser isolation или доступ только с управляемого устройства.
6. События попадают в SIEM: кто зашёл, куда, когда, что скачал, был ли редирект.

Если используется расшифровка HTTPS-трафика, её нужно вводить аккуратно: с понятной политикой, исключением чувствительных категорий и согласованием с юридическими и HR-требованиями компании. Без этого можно получить техническую видимость, но создать новые риски.

Как выбрать решение для проверки репутации

При выборе инструмента не стоит смотреть только на красивую шкалу “репутации”. Хорошее решение должно давать не просто оценку, а объяснимые сигналы и действия.

• Покрытие данных. Проверяет ли система домен, URL, IP, ASN, файлы, сертификаты, редиректы и JavaScript.
• Скорость обновления. При watering hole время играет против компании: ресурс может быть чистым утром и заражённым днём.
• Качество песочницы. Умеет ли она запускать не только файлы, но и анализировать поведение страницы.
• Интеграции. Есть ли связь с DNS, proxy, EDR, SIEM, тикет-системой и каталогом пользователей.
• Работа с ложными срабатываниями. Можно ли быстро добавить исключение для важного поставщика и кто за это отвечает.
• Отчётность. Должно быть видно, какие сайты вызывают подозрение, какие пользователи к ним обращались и какие файлы скачивались.
• API. Без API сложно встроить проверку в собственные процессы и автоматизировать реакции.

Что выбрать в зависимости от ситуации

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

Если сотрудники часто работают с сайтами поставщиков и отраслевыми порталами. Добавьте web gateway, проверку URL и файлов в песочнице. Для сайтов с высоким риском включите browser isolation или доступ только с управляемого устройства.

Если у компании есть публичный сайт или клиентский портал. Сделайте отдельный контур мониторинга собственных доменов: поддомены, сертификаты, изменения файлов, CMS, плагины и внешние скрипты. Здесь задача не только защитить сотрудников, но и не стать источником заражения для других.

Если компания работает в финансах, госсекторе, оборонке, медицине, энергетике или R&D. Нужны более строгие политики: allowlist для критичных групп, постоянный мониторинг Certificate Transparency, passive DNS, интеграция с SIEM и отдельные правила для администраторов.

Если уже есть подозрение на incident. Не спорьте с пользователем и не проверяйте всё вручную на его ноутбуке. Изолируйте устройство, заблокируйте домен, соберите DNS/proxy/EDR-логи, проверьте скачанные файлы, посмотрите, не вводились ли пароли, и при необходимости сбросьте учётные данные.

Частые ошибки при защите от watering hole

• Проверяют только главную страницу сайта. Вредоносный код часто находится на конкретной странице документации, формы входа или загрузки.
• Доверяют HTTPS как признаку безопасности. HTTPS защищает канал, но не гарантирует, что сайт не заражён.
• Смотрят репутацию домена, но не поведение страницы. Домен может быть нормальным, а подключённый скрипт — подозрительным.
• Забывают про поддомены. Старый лендинг или тестовый поддомен часто становится слабым местом.
• Не контролируют сторонние скрипты. Чат, аналитика, виджет или библиотека могут стать каналом атаки.
• Блокируют всё автоматически без разбора. Жёсткая политика без исключений ломает работу с поставщиками и толкает сотрудников на обходные пути.
• Не ведут владельцев ресурсов. Если сайт вызвал подозрение, никто не знает, кто отвечает за проверку и восстановление.
• Не имеют плана действий. В момент инцидента команда начинает спорить, кому собирать логи и кто имеет право блокировать домен.

Как лучше сделать: минимальный план на первый месяц

Если нужно быстро привести защиту в порядок, я бы шёл по такому порядку.

1. Первая неделя. Соберите список собственных доменов, поддоменов и внешних сайтов, которые регулярно используют сотрудники. Назначьте ответственных за каждый ресурс.
2. Вторая неделя. Включите DNS-фильтрацию или web gateway, подключите репутационные feeds, начните собирать DNS и proxy-логи.
3. Третья неделя. Просканируйте собственные сайты, проверьте CMS, плагины, сертификаты, внешние скрипты и подозрительные редиректы.
4. Четвёртая неделя. Настройте правила для неизвестных доменов, файлов и редиректов. Подготовьте короткий playbook: кто блокирует, кто расследует, кто общается с владельцем сайта или поставщиком.

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

Итог

Защита от “watering hole”-атак начинается с понимания, какие корпоративные сайты реально посещают сотрудники и какие из ваших сайтов видны наружу. Репутацию нужно проверять постоянно: по домену, IP, сертификатам, редиректам, скриптам, файлам и поведению страницы.

Минимально рабочий вариант — инвентарь сайтов, DNS/web-фильтрация, репутационные источники, сбор логов и сканирование собственных доменов. Более зрелый вариант — песочница, remote browser isolation, passive DNS, мониторинг Certificate Transparency и автоматические реакции через SIEM/EDR.

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