Один подрядчик — сто проблем: как защитить бизнес от утечек и взломов при работе с партнерами

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

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

Анализ исторических данных

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

Сервисы вроде SecurityTrails, Censys или Shodan History, Hunter.how сохраняют «снимки» состояния систем. С их помощью можно узнать:

• какие порты и сервисы подрядчик когда-то оставлял открытыми;

• какие версии ПО использовались ранее;

• были ли у него уязвимые домены или поддомены.

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

Разведка по открытым источникам

После анализа истории стоит изучить текущую инфраструктуру подрядчика — без пентеста и без нарушения законов.

Для этого применяются OSINT-инструменты вроде Shodan, HunterHow, FOFA, которые позволяют:

• выявлять версии серверного ПО и фреймворков;

• находить административные панели;

• определять CMS и их плагины.

Дополнительно можно изучить:

• метаданные веб-страниц и файлов;

• открытые комментарии в коде;

• скрытые каталоги и тестовые поддомены.

Эти данные часто становятся точкой входа для злоумышленников, поэтому стоит убедиться, что подрядчик не оставляет «лишнего» в открытом доступе.

Даркнет и публичные репозитории

Darknet — это не только площадки с продажей данных, но и места, где обсуждаются свежие утечки. Подрядчики нередко даже не подозревают, что их API-ключи, пароли или базы данных уже опубликованы.

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

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

Что касается публичных репозиториев, то тут подрядчики нередко оставляют в открытом доступе, в том числе и в коде:

• API-ключи;

• SSH-ключи;

• пароли;

• внутренние IP-адреса или фрагменты конфигураций.

Даже если компания сама не хранит ничего публично, у подрядчика могут быть утечки. Для автоматизации поиска утечек, паролей, фрагментов кода, API и других чувствительных данных, можно применить GitLeaks, TruffleHog и подобное.

Поиск по фавиконам

Favicon — маленькая иконка сайта (/favicon.ico или встроенный link-тег). Поскольку компании часто переиспользуют одну и ту же иконку для основного сайта, поддоменов, тестовых стендов и внутренних приложений, файл фавикона фактически становится «отпечатком» инфраструктуры. По этому отпечатку (хэшу) можно найти другие ресурсы с тем же фавиконом — часто это забытые тестовые серверы, staging-инстансы или фишинговые клоны.

Как хэшируется фавикон

Популярные поисковые движки и датасеты (Shodan, Zoomeye и другие) используют MurmurHash3 (mmh3) от base64-кодированного содержимого фавикона; другие сервисы (например, Censys) также хранят MD5/SHA-хэши фавикона в своих полях. Поэтому рабочий поток — получить файл фавикона, сгенерировать нужный хэш и использовать его в поиске по сервисам. InfoSec Write-ups+1

Практический рабочий алгоритм (шаг за шагом)

1.     Найдите/скачайте фавикон.
Откройте https://example.com/favicon.ico или найдите link rel="icon" в HTML и скачайте файл.

2.     Посчитайте хэш.

• Для поиска в Shodan/Zoomeye используйте mmh3 (MurmurHash3) от base64-контента фавикона.

• Для Censys можно использовать MD5/SHA256 поля (они представлены в индексе).

3.     Поиск по хэшу в сервисах.

• Shodan: используйте фильтр http.favicon.hash:<hash> (например, http.favicon.hash:-2057558656).

• Censys: можно искать по полям, где хранятся MD5/SHA-значения фавикона, или по соответствующим favicons полям в API/интерфейсе.

• Другие: FOFA, ZoomEye и специализированные OSINT-утилиты тоже поддерживают поиск по фавикону (иногда требуется другая форма хэша).

4.     Кросс-проверка и фильтрация.

• Сопоставьте найденные хосты с WHOIS, reverse DNS, IP-диапазонами, сертификатами TLS и записями A/AAA, чтобы понять, действительно ли они принадлежат подрядчику.

• Проверьте метаданные HTTP (Server, X-Powered-By), заголовки, содержимое страниц — это уменьшит количество ложных совпадений.

5.     Что именно искать на найденных хостах.

• Тестовые/стейджинг-сайты с включенной отладкой;

• Неавторизованные бэкапы и дампы;

• Админ-панели, интерфейсы 1С, phpMyAdmin, панели управления без пароля;

• Конфигурационные файлы, содержащие строки подключения/ключи.

Примеры работы с фавиконами:

• Найденные тестовые копии, где включена отладочная информация или сохранены пароли.

• Обнаружение внутренних административных интерфейсов, случайно выставленных во внешний доступ.

• Поиск фишинговых доменов, которые используют те же графические ресурсы (фавикон) для маскировки.

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

Искусственный интеллект в киберразведке

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

Искусственный интеллект (ИИ) помогает анализировать огромные объемы данных, выявлять закономерности и находить потенциальные угрозы задолго до того, как они станут инцидентом.

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

Некоторые направления применения ИИ в киберразведке

1. Автоматический анализ репозиториев и кода подрядчиков

ИИ помогает искать чувствительные данные в открытых репозиториях GitHub, GitLab, Bitbucket. Вместо простого поиска по ключевым словам (password, key, token) нейросеть анализирует структуру и контекст кода, чтобы отличать реальный секрет от комментариев или примеров.

Например:

• распознавание токенов, похожих по структуре на AWS или Telegram API-ключи;

• определение «утекших» .pem-файлов или SSH-ключей;

• классификация фрагментов кода по рискам (высокий / средний / низкий).

Такие инструменты могут быть реализованы на базе BERT, CodeBERT, GPT-моделей, дообученных на утечках.

2. Обнаружение фишинговых доменов и сайтов-клонов

ИИ сравнивает визуальные элементы сайтов подрядчика (фавикон, логотип, цветовую палитру, шрифты) с другими ресурсами в сети. На основе методов computer vision и deep learning (ResNet, Vision Transformer) можно определить, что сайт выглядит «подозрительно похожим» на оригинал, даже если у него другой домен или слегка изменен логотип. Также применяется анализ текста на странице — ИИ распознает подделки по лингвистическим признакам (ошибки, шаблонные тексты, характерные фразы).

3. Мониторинг даркнета, форумов и соцсетей

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

Технологии:

• NLP (Natural Language Processing) — извлечение сущностей: имена компаний, домены, e-mail, IP-адреса, токены.

• Sentiment Analysis — определение тона сообщений (например, обсуждают ли продажу данных подрядчика или просто упоминают компанию).

• Web scraping с BeautifulSoup, Scrapy, Selenium — сбор текстов и метаданных.

• Topic modeling (LDA, BERTopic) — выделение тем, связанных с подрядчиком (утечки, доступы, эксплойты).

Результат — система уведомлений, которая сообщает, если в даркнете появился новый пост с упоминанием компании или подрядчика.

Искусственный интеллект превращает киберразведку из ручного мониторинга в систему предсказательного анализа.

 С его помощью можно мониторить подрядчиков в режиме 24/7, заранее выявлять утечки, даже если о них никто еще не сообщил, автоматизировать проверку кодов и инфраструктуры, сосредоточить внимание специалистов на действительно важных рисках.

Базовые меры для сокращения уязвимостей со стороны подрядчиков

1. Постоянный мониторинг Telegram, GitHub и даркнета

Современные атаки редко начинаются с прямого взлома. Гораздо чаще они начинаются с утечки данных подрядчиков — например, API-ключей, паролей или исходного кода, случайно опубликованных в открытом доступе.

Что делать:

• Настройте OSINT-мониторинг упоминаний вашего бренда, доменов и e-mail-адресов подрядчиков.

• Автоматизируйте поиск по GitHub, GitLab, Bitbucket на предмет утечек ключей и конфиденциальной информации.

• Используйте даркнет-сканеры (CybelAngel, DarkOwl, Flare, OpenCTI) для отслеживания публикаций, связанных с вашей компанией.

• Контролируйте Telegram-каналы, форумы и публичные репозитории — утечки часто появляются именно там.

Инструменты:

• GitGuardian, LeakLooker, Gitleaks — автоматический анализ репозиториев.

• Scrapy, BeautifulSoup, Telegram API — для кастомных OSINT-скриптов.

• Google Dorking и Shodan — поиск открытых ресурсов подрядчиков.

2. Минимизируйте открытые связи между компаниями

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

Даже без технических уязвимостей хакеры часто используют OSINT-разведку, чтобы найти «входные точки» — имена сотрудников, общие проекты, пересечения по доменам.

Что делать:

• Не публикуйте имена подрядчиков в README, презентациях, тендерах и публичных отчетах.

• Используйте общие корпоративные аккаунты (например, dev-partner@company.com), а не личные.

• Избегайте упоминаний подрядчиков в доменных записях (WHOIS, DNS TXT, SPF).

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

3. Давайте доступы только под конкретную задачу

Одна из самых частых ошибок — предоставление подрядчику избыточных прав.
Доступ, выданный «на всякий случай», часто остается активным после завершения проекта и становится уязвимостью.

Что делать:

• Используйте принцип минимальных привилегий (PoLP).

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

• Настройте автоматическое отключение учетных записей подрядчиков после окончания контракта.

• Ведите аудит доступа: раз в квартал проверяйте, кто имеет права на серверы, репозитории, облачные сервисы и панели администрирования.

4. Регулярное обновление ПО подрядчиков

Зачастую подрядчики работают на устаревших версиях CMS, библиотек и веб-серверов. Это прямое окно для атак. Вы можете иметь идеальную защиту, но если подрядчик использует WordPress 5.6 или старый OpenSSL, злоумышленник может взломать их.

Что делать:

• Включите в договор обязательное требование регулярного обновления ПО (например, не реже одного раза в месяц).

• Проводите сканирование инфраструктуры подрядчиков на наличие уязвимостей, общедоступных сервисов и другого (с их согласия).

5. Договорные обязательства

Без четких юридических условий безопасность превращается в «надежду на добросовестность». Договор с подрядчиком должен не просто регулировать оплату и сроки, но и фиксировать обязательства по кибербезопасности.

Что включить в контракт:

• Пункт о конфиденциальности и неразглашении (NDA).

• Условие о своевременном устранении найденных уязвимостей (например, в течение 72 часов с момента уведомления).

• Обязательство уведомлять заказчика о любых инцидентах безопасности в течение суток.

• Требования к аудиту доступа и шифрованию данных.

• Возможность проведения внешнего пентеста или проверки (с согласия сторон).

Итог

Даже если у подрядчика нет SOC, SIEM и собственной команды безопасности, вы можете оценить его надежность по открытым данным и поведению. Регулярный OSINT, аудит, мониторинг упоминаний и анализ утечек позволяют выявить слабые звенья до того, как ими воспользуются злоумышленники. Ключевой принцип — доверяй, но проверяй. Безопасность партнеров — это не их личная проблема, а часть вашего общего цифрового контура.

Автор: Павел Абакумов, аналитик сервиса проактивного мониторинга внешних цифровых угроз Jet CSIRT, «Инфосистемы Джет».