OSINT в пентесте сайтов: как собрать максимум данных из открытых источников

Хороший пентест начинается задолго до первой атаки

Когда говорят о тестировании безопасности, обычно представляют сканеры, перехваченные запросы и попытки эксплуатации уязвимостей. Кажется, что пентестер сразу открывает Burp Suite, запускает несколько инструментов и начинает проверять сайт на прочность.

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

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

Такой подход называется OSINT, или Open Source Intelligence - сбор и анализ информации из открытых источников. В пентесте OSINT помогает построить карту цели ещё до активной фазы и определить места, которые заслуживают особого внимания.

Разведка нужна не ради коллекции доменов

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

Но настоящий результат заключается не в количестве строк в отчёте. Важно понять, что именно означают найденные данные и как они связаны с областью тестирования.

Поддомен dev.example.com может оказаться обычной заглушкой, а может вести на тестовую версию приложения без полноценной авторизации. Старый IP-адрес способен больше не принадлежать компании, а может продолжать обслуживать забытый сервер. Упоминание фреймворка ещё не доказывает наличие уязвимости, но помогает выбрать дальнейшие проверки.

OSINT превращается в полезный инструмент только тогда, когда отдельные факты складываются в гипотезы. Какие системы могут быть устаревшими? Где могла сохраниться старая версия приложения? Какие сервисы доступны извне? Не раскрывает ли публичная информация внутренние названия и структуру инфраструктуры?

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

Домен рассказывает больше, чем кажется

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

Через WHOIS и RDAP можно узнать дату регистрации домена, срок его действия, регистратора, используемые серверы имён и некоторые сведения о владельце. Сегодня персональные данные часто скрыты сервисами приватности, поэтому увидеть настоящее имя или адрес удаётся далеко не всегда.

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

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

Один WHOIS-запрос редко приводит к серьёзной находке. Но он становится начальной точкой, от которой постепенно расходятся новые направления исследования.

DNS как карта внешней инфраструктуры

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

Для пентестера DNS представляет собой карту публичной части инфраструктуры. Записи типа A и AAAA указывают адреса серверов, MX раскрывает почтовую инфраструктуру, NS показывает используемые DNS-серверы, а TXT нередко содержит настройки проверки домена и внешних сервисов.

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

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

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

Поддомены расширяют границы приложения

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

Для их разделения используются поддомены:

api.example.com
dev.example.com
admin.example.com
status.example.com
old.example.com

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

Поддомен сам по себе не является уязвимостью. Интерес представляет то, что за ним находится. Тестовый сервер может использовать упрощённую авторизацию, старая версия сайта - уязвимые компоненты, а забытая административная панель - стандартные настройки.

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

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

Пассивный и активный поиск поддоменов

Методы обнаружения поддоменов условно делятся на пассивные и активные.

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

Активная разведка предполагает обращения к DNS-серверам, проверку предполагаемых имён и подтверждение найденных адресов. Она может дать более полную картину, но уже становится заметной для средств мониторинга и требует явного разрешения.

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

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

Сертификаты помнят имена, о которых сайт давно забыл

Для работы HTTPS сервер использует TLS-сертификат. Он подтверждает связь между доменным именем и открытым ключом, а также позволяет установить зашифрованное соединение.

С точки зрения OSINT особенно интересны альтернативные имена, указанные в поле SAN. Один сертификат может обслуживать сразу несколько доменов и поддоменов:

example.com
www.example.com
api.example.com
portal.example.com

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

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

При этом наличие имени в старом сертификате ещё не означает, что соответствующий сервер существует сегодня. Такие записи следует воспринимать как повод для проверки, а не как подтверждённую активную цель.

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

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

DNS-зона содержит набор записей, относящихся к определённому домену. Для синхронизации между авторитетными DNS-серверами используется зональный трансфер.

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

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

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

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

Один IP-адрес может скрывать несколько сайтов

Современный сервер редко обслуживает только один домен. Благодаря виртуальным хостам один IP-адрес может принимать запросы для десятков или сотен сайтов.

Веб-сервер определяет нужное приложение по имени хоста, которое клиент передаёт в запросе. Поэтому прямое открытие IP может показать стандартную страницу, ошибку или совсем другой сайт, хотя на этом же адресе работают дополнительные приложения.

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

Однако общий IP ещё не означает, что все размещённые на нём сайты принадлежат одной организации. На виртуальном хостинге тысячи клиентов могут использовать один адрес. То же самое относится к CDN и облачным платформам.

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

Старые версии сайта продолжают жить в архивах

Сайт меняется со временем. Разделы удаляются, страницы переименовываются, API получают новые версии, а старые документы исчезают из навигации. Но удаление с сервера не всегда означает исчезновение из интернета.

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

Старая документация способна раскрыть адреса API, структуру параметров и названия внутренних сервисов. В архиве может остаться ссылка на административную панель, тестовый поддомен или файл, который позже убрали из меню.

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

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

Поисковые системы как инструмент технической разведки

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

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

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

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

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

Метаданные документов тоже оставляют цифровой след

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

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

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

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

Как и другие OSINT-находки, метаданные редко представляют серьёзную проблему сами по себе. Их ценность появляется при сопоставлении с другими источниками.

robots.txt не закрывает страницы от посетителей

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

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

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

Похожую роль играет sitemap.xml. Он предназначен для поисковых систем и содержит список страниц, которые владелец хочет индексировать. В нём иногда обнаруживаются адреса, отсутствующие в навигации, языковые версии и старые разделы.

Ни robots.txt, ни карта сайта не должны рассматриваться как уязвимость автоматически. Они лишь помогают понять структуру приложения и найти доступные ресурсы.

Что можно найти в /.well-known

Каталог /.well-known используется для стандартизированных служебных файлов. Через него публикуются данные для автоматической проверки домена, конфигурации отдельных протоколов и контактная информация.

Одним из наиболее полезных для исследователя файлов является:

/.well-known/security.txt

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

В /.well-known также встречаются настройки авторизации, мобильных приложений и других сервисов. Обычно они публикуются намеренно и не считаются секретными.

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

Технологический стек помогает выбирать направление проверки

Понимание используемых технологий заметно упрощает дальнейшее тестирование. Веб-сервер, CMS, фреймворк, JavaScript-библиотеки и внешние сервисы имеют свои особенности и типичные ошибки конфигурации.

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

Если сайт работает на WordPress, исследователь обратит внимание на плагины, темы и служебные маршруты. Для приложения на Laravel будут интересны характерные cookies, структура ошибок и публичные файлы. Обнаружение определённой JavaScript-библиотеки может подсказать, какие клиентские компоненты стоит изучить внимательнее.

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

Даже правильно определённая версия не доказывает, что система уязвима. Компонент мог получить исправление без изменения публичного номера или использовать дополнительную защиту. Результат фингерпринтинга создаёт гипотезу, которую ещё предстоит проверить.

Публичный код способен раскрыть больше документации

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

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

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

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

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

Электронная почта и сотрудники тоже являются частью поверхности атаки

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

Вакансия системного администратора может перечислять конкретные продукты, облачные платформы и средства защиты. Публичный профиль разработчика иногда содержит ссылки на рабочие репозитории. Формат адресов электронной почты помогает определить возможные имена учётных записей.

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

Цель пентеста состоит не в создании досье на сотрудников, а в оценке того, насколько публичные сведения помогают атакующему. В отчёт обычно попадают риски и общие закономерности, а не лишние персональные подробности.

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

Облачные сервисы расширяют цифровой след компании

Современное приложение редко размещается на одном физическом сервере. Оно использует облачные хранилища, CDN, системы аналитики, платформы для отправки почты и сторонние API.

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

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

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

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

Почему данные из открытых источников бывают ошибочными

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

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

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

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

Навык OSINT заключается не только в поиске информации, но и в оценке её достоверности.

Автоматизация помогает собирать, но не анализировать

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

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

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

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

Хороший специалист использует автоматизацию для устранения рутины, но не передаёт ей принятие решений.

OSINT не отменяет правила тестирования

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

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

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

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

В bug bounty нужно отдельно читать правила программы. Одни компании разрешают пассивный поиск поддоменов и тестирование всех принадлежащих им ресурсов, другие ограничивают работу небольшим списком конкретных адресов.

Как разведданные превращаются в план пентеста

После сбора информации начинается наиболее важная часть - анализ.

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

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

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

Так OSINT экономит время активной фазы. Вместо случайного сканирования всего подряд специалист концентрируется на наиболее вероятных и значимых направлениях.

Как устроен модуль «OSINT в пентесте сайтов» в Kraken Academy

В Kraken Academy модуль посвящён не просто поиску отдельных сведений, а построению полноценной карты веб-инфраструктуры из открытых источников.

Сначала пользователь разбирается с доменами, WHOIS, RDAP и основными типами DNS-записей. Затем учится искать поддомены, изучать сертификаты, работать с архивами и анализировать служебные файлы сайтов.

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

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

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

Главная задача обучения - сформировать привычку сначала понимать цель и только потом переходить к активным проверкам.

Иногда самая важная уязвимость уже видна издалека

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

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

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

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