«Реальные инциденты информационной безопасности часто кажутся набором случайных ошибок. Но если посмотреть на цепочку событий с высоты, становится очевидна их железная логика — от первого пробного запроса до полного доступа к корпоративным системам. Этот разбор посвящён типичным ошибкам, которые годами воспроизводятся в российском IT-секторе, и показывает, как они соединяются в одну атаку. Конкретная компания здесь не важна — важна схема, которая срабатывает снова и снова.»
Нет «одной уязвимости», есть цепочка уступок
Классическая ошибка при анализе инцидентов — искать «ту самую дыру», которую хакер использовал для проникновения. В реальности редко существует один критический пробел в безопасности. Гораздо чаще злоумышленник проходит по цепочке мелких недоработок, каждая из которых сама по себе может не считаться серьёзной угрозой. Это похоже на серию разбросанных ключей: один открывает калитку, другой — дверь в подсобку, третий — шкаф с документами. В итоге злоумышленник оказывается там, где его быть не должно, и никто не может понять, как это произошло. В разбираемом случае атака началась не с взлома сервера или подбора пароля администратора, а с открытых данных, которые компания сама же и публиковала.
Этап 1. Сбор информации: утечка начинается с открытых источников
Первым делом злоумышленник собрал всё, что можно найти о компании в публичном доступе. Это не хакерский взлом, а рутинная разведка. Были проверены:
- Сайт компании, разделы «Команда», «Вакансии», «Контакты».
- Профили сотрудников в профессиональных социальных сетях.
- Технические форумы и GitHub, где разработчики могли оставлять служебную информацию в примерах кода или вопросах.
- История домена (WHOIS) для выявления связанных технических поддоменов.
Ключевой находкой стал поддомен test.company.ru, упомянутый одним из сотрудников в обсуждении на форуме. На этом поддомене располагалась тестовая версия внутреннего портала для сотрудников.
Этап 2. Тестовый поддомен — забытый шлюз
Тестовые среды — классическая больница безопасности. Их часто разворачивают на скорую руку, копируют туда реальные данные для отладки, а после сдачи проекта в эксплуатацию забывают. Поддомен test.company.ru не был исключением. На нём работала копия внутренней wiki-системы с доступом по логину и паролю. Однако в отличие от боевого портала, здесь:
- Были отключены требования к сложности паролей.
- Отсутствовала двухфакторная аутентификация.
- Система логирования запросов была настроена минимально.
Но как получить учётные данные? Ответ был найден в той же wiki. На одной из технических страниц, оставленной для разработчиков, в виде примера конфигурационного файла был опубликован фрагмент кода с учётными данными для подключения к тестовой базе данных. Логин и пароль из этого примера совпадали с учётными данными одного из администраторов тестового портала — распространённая практика «универсального» пароля для тестовых сред.
От тестовой среды к внутренней сети
Получив доступ к тестовой wiki, злоумышленник не нашёл там ценных данных. Но wiki служила не целью, а плацдармом. В её разделах, посвящённых внутренним процедурам и сетевой архитектуре, были схематично описаны сегменты корпоративной сети, включая адресацию критических систем: файлового хранилища, сервера управления задачами (Jira), почтового сервера.
Важнее была другая находка: в разделе «Новым сотрудникам» был опубликован PDF-документ с инструкцией по настройке VPN для удалённой работы. В приложении к документу находился скриншот окна настройки, где в поле «Адрес сервера» был виден внутренний IP-адрес VPN-шлюза компании. Эта информация, не являясь секретной сама по себе, стала следующим ключом.
Этап 3. Поиск уязвимостей в периметре
Имея список внутренних адресов и адрес VPN-шлюза, злоумышленник провёл сканирование внешнего периметра компании. Цель — найти сервисы, доступные из интернета, которые могут быть связаны с внутренней сетью или иметь уязвимости. С помощью общедоступных инструментов были обнаружены:
- Веб-интерфейс корпоративной почтовой системы (OWA/Webmail), доступный по стандартному адресу.
- Порт для VPN-подключения (обычно 443 или 1194), на котором работало устаревшее ПО с известной уязвимостью.
Уязвимость в VPN-сервисе (например, CVE-2019-11510 для Pulse Connect Secure) позволяла без аутентификации читать произвольные файлы на сервере, включая файлы с конфигурацией и временными паролями пользователей. Эта уязвимость была давно известна, и для неё существовали исправления, но на момент атаки сервер компании не был обновлён.
Этап 4. Внутреннее перемещение: низко висящие плоды
Используя уязвимость VPN-сервера, злоумышленник получил файл, содержащий хеши паролей нескольких пользователей, которые недавно подключались к сети. Хеши не были надёжно «посолены» (использовался простой MD5), что позволило быстро подобрать пароли для двух учётных записей с помощью радужных таблиц. Одна из этих учётных записей принадлежала сотруднику отдела технической поддержки.
Войдя в сеть через VPN под учётной записью техподдержки, атакующий оказался в выделенном сегменте для обслуживающего персонала. Этот сегмент имел ограниченные права, но был сконфигурирован с излишним доверием к другим внутренним системам. В частности, с рабочей станции в этом сегменте был разрешён RDP-доступ к нескольким внутренним серверам для проведения административных работ.
Эскалация привилегий через плохое разделение доступа
RDP-доступ был защищён паролем, но здесь сработал человеческий фактор. На одном из серверов, куда был разрешён доступ, сотрудник техподдержки оставил открытый текстовый файл с заметками. В нём среди прочего был записан стандартный пароль, используемый для первоначальной настройки новых серверов в сети. Этот пароль был одинаков для всех серверов определённого типа и не менялся после ввода в эксплуатацию — вопиющее нарушение базовых правил.
Используя этот стандартный пароль, злоумышленник смог подключиться по RDP к серверу, который использовался как jump-хост для доступа к более критическим системам, включая сервер управления базами данных (СУБД).
Этап 5. Цель: доступ к данным и перспектива долгого присутствия
На сервере СУБД хранились основные бизнес-данные компании: информация о клиентах, внутренние документы, журналы операций. Прямой копией этих данных злоумышленник не ограничился. Вместо этого были предприняты шаги для обеспечения долгосрочного присутствия в системе:
- Создание скрытой учётной записи: В СУБД была создана новая учётная запись администратора с неприметным именем, имитирующим системного пользователя.
- Установка бэкдора: На сам сервер СУБД был установлен легковесный бэкдор, позволяющий получать удалённый доступ по зашифрованному каналу, минуя корпоративные системы аутентификации.
- Очистка логов: С помощью специальных утилит были выборочно очищены журналы событий (логи) на пройденных серверах, чтобы затруднить расследование инцидента.
Финальным действием стало шифрование части файлов на файловом хранилище с последующим вымогательством — хотя основная ценность для атакующего уже была в постоянном невидимом доступе к ядру инфраструктуры.
Разбор ошибок и меры защиты
Эта цепочка атаки стала возможной не из-за одного провала, а из-за системных просчётов в управлении информационной безопасностью. Вот ключевые уроки, актуальные для любой российской IT-компании, работающей в условиях регуляторики ФСТЭК и 152-ФЗ.
| Этап атаки | Ключевая ошибка компании | Мера защиты (в рамках российских требований) |
|---|---|---|
| Сбор информации | Отсутствие контроля за публикуемой информацией (OSINT). | Регулярный аудит публичных ресурсов компании на наличие служебных данных. Обучение сотрудников правилам кибергигиены. |
| Тестовый поддомен | Отсутствие жизненного цикла для тестовых сред, использование реальных данных и паролей. | Изоляция тестовых сред от продуктивных. Автоматическая ротация и хранение учётных данных в защищённых хранилищах (Vault). |
| Уязвимость в периметре | Несвоевременное обновление ПО, особенно внешнедоступных сервисов (VPN). | Внедрение процесса регулярного мониторинга уязвимостей и патч-менеджмента, что соответствует требованиям ФСТЭК к актуальности СЗИ. |
| Внутреннее перемещение | Слабое сегментирование сети, излишнее доверие между сегментами, хранение паролей в открытом виде. | Реализация модели Zero Trust или как минимум строгой сетевой сегментации. Запрет на хранение паролей в незашифрованном виде. Использование PAM-систем. |
| Эскалация привилегий | Использование стандартных или слабых паролей, отсутствие их ротации. | Внедрение строгой парольной политики, многофакторной аутентификации для привилегированных учётных записей, регулярная ротация паролей. |
| Долгосрочное присутствие | Отсутствие мониторинга аномальной активности (SIEM), слабое логирование. | Развёртывание SIEM-системы для корреляции событий. Обеспечение целостности и защищённости журналов аудита, как того требует 152-ФЗ. |
Главный вывод: безопасность, это не набор отдельных инструментов, а непрерывный процесс. Атака развивается по пути наименьшего сопротивления, связывая слабые места воедино. Соответственно, защита должна быть цело стной, перекрывая не только очевидные точки входа, но и всю цепочку возможных перемещений внутри системы. Регуляторные требования ФСТЭК и 152-ФЗ задают необходимый минимум, но реальная устойчивость к современным угрозам требует выйти за его рамки, мысля категориями злоумышленника и закрывая те самые «незначительные» уступки, которые в итоге открывают путь к сердцу инфраструктуры.