«Подход «Яндекса»
к тому, что стало стандартом кибербезопасности, возник не из абстрактных угроз, а из тщательного анализа собственных инцидентов. Их методология, ставшая основой для внутренних требований,, это оцифрованный ответ на конкретные истории взломов. Когда я вижу описание очередной атаки, я проверяю, какой из этих фундаментальных процессов был нарушен».
Публичный разбор реальных инцидентов безопасности — один из самых эффективных способов обучения в ИТ. Он превращает абстрактные угрозы в конкретные сценарии, где можно увидеть, как стандартные практики безопасности срабатывают или терпят неудачу. Однако компании часто публикуют лишь обезличенные и сильно сглаженные версии событий, из которых трудно извлечь прикладные уроки.
Давай сконструируем реалистичный кейс, основанный на типичных ошибках, но с достаточным уровнем детализации, чтобы понять логику каждой стадии атаки. Этот кейс — не пересказ одного инцидента, а синтез паттернов, которые встречаются снова и снова в отчётах российских подразделений ФСТЭК и КИИ.
Сценарий: целевая атака на регионального поставщика ИТ-услуг
Наша цель — компания «ТехноСистема», которая предоставляет услуги аутсорсинга и облачных серверов для среднего бизнеса в своём регионе. У неё около 50 сотрудников, внешний сайт, собственная небольшая инфраструктура в ЦОД и клиенты, включающие местные производства и логистические фирмы.
Для злоумышленников такая компания, это ворота. Взломив её, они получают доступ не к одному, а сразу к нескольким её клиентам через доверенные соединения, VPN, сервисные аккаунты. Цель атаки — не сама «ТехноСистема», а её клиенты: чтобы украсть данные, установить шифровальщик на производственных линиях или провести целевую киберразведку.
Этап 1: Разведка и подбор вектора входа
Первым делом злоумышленники собирают информацию в открытых источниках. В России это не только LinkedIn, но и Habr Career, «Хабр Фриланс», профили на СберХабе и других корпоративных площадках, публичные репозитории Git (GitLab, GitHub, Gitea), где сотрудники иногда оставляют не только код, но и конфигурационные файлы с тестовыми ключами доступа.
В нашем случае они находят у одного из системных администраторов репозиторий с ansible-скриптами для настройки серверов. В одном из файлов остался закомментированный блок, содержащий логин и пароль для тестового стенда. Этот стенд давно выведен из эксплуатации, но пароль — часть стандартной схемы, которую администратор использует для всех служебных учёток. Пароль имел вид «ТехноСистема2023!» — то есть состоял из названия компании, года и знака.
Этап 2: Первичный доступ к периметру
Используя найденный логин и стандартный пароль, атакующие методом перебора пробуют получить доступ к различным внешним сервисам компании. Они проверяют:
- Внешний VPN для сотрудников (часто на базе OpenVPN или MikroTik).
- Веб-интерфейс корпоративной почты (OWA, веб-морда Zimbra).
- Панель управления CRM или ERP-системой, вынесенной для удалённого доступа.
- Портал самообслуживания для клиентов (например, для загрузки отчётов).
Успех приходит на портале для клиентов. Оказалось, что админская учётка для администрирования этого портала имеет тот же логин, что и в старом ansible-скрипте, а пароль был лишь слегка модифицирован: «ТехноСистема2024!». Многофакторная аутентификация отключена для этой учётки «для удобства».
Этап 3: Закрепление в системе и горизонтальное перемещение
Получив доступ к панели администрирования портала, злоумышленники изучают её функционал. Они обнаруживают возможность загружать «информационные модули» — по сути, произвольные PHP или Python-скрипты, которые выполняются на сервере. Этой функцией почти не пользуются, но она есть.
Атакующие загружают веб-шелл — небольшой скрипт, дающий доступ к командной строке сервера. Теперь у них есть выполнение команд на веб-сервере портала. Этот сервер находится внутри внутренней сети компании, хотя и в отдельном VLAN.
Следующий шаг — разведка внутренней сети с этого сервера. С помощью стандартных утилит (nmap, netstat) они выясняют:
- Существует основной сервер управления доменом (Active Directory).
- Есть несколько файловых шаредов для сотрудников.
- В сети присутствуют серверы виртуализации (например, на базе VMware ESXi).
Этап 4: Кражa учётных данных и повышение привилегий
Веб-сервер работает от имени пользователя www-data с ограниченными правами. Чтобы двигаться дальше, нужны права администратора домена. Атакующие пытаются найти файлы с паролями или ключами на самом веб-сервере. В директории с логами они обнаруживают старые бекапы конфигураций, где в открытом виде лежит файл с паролями для подключения к внутренней базе данных.
Этот пароль также является частью той же самой схемы. Получив доступ к базе данных, они находят таблицу с хэшами паролей сотрудников для внутренней wiki-системы. Хэши слабые (MD5 без соли), и часть из них удаётся быстро «расколоть» с помощью предварительно вычисленных радужных таблиц.
Один из расколотых паролей принадлежит старшему системному администратору. Этот сотрудник использовал один и тот же пароль для wiki и для своей учётной записи в домене. Теперь у атакующих есть учётные данные привилегированного пользователя в Active Directory.
Этап 5: Достижение цели и действия в инфраструктуре клиентов
Войдя в домен под учётной записью администратора, злоумышленники получают полный контроль над внутренней сетью «ТехноСистемы». Они изучают документацию и обнаруживают главное: для обслуживания клиентов используется выделенная VPN-сеть (site-to-site), через которую «ТехноСистема» имеет доступ к внутренним сетям своих заказчиков для удалённой поддержки.
Ключи и сертификаты для этих VPN-туннелей хранятся на одном из файловых серверов. Атакующие их копируют. Теперь они могут имитировать трафик от доверенной компании-поставщика и попасть прямо во внутренние сети клиентов, минуя их внешние средства защиты.
Какие нарушения базовых принципов безопасности привели к инциденту
Разобрав сценарий, можно выделить ключевые уязвимости, которые стали звеньями одной цепи. По сути, это классический список того, что проверяет ФСТЭК при аттестации.
| Этап атаки | Техническая ошибка | Нарушенный принцип / требование регулятора |
|---|---|---|
| Разведка | Публикация конфиденциальных данных (логинов/паролей) в открытых репозиториях. | Отсутствие политики работы с кодом и контроля за размещением служебной информации (п. 5.4 Требований ФСТЭК). |
| Вход в систему | Слабые, предсказуемые пароли, отключение МФА для учётных записей администрирования. | Несоблюдение требований к парольной политике и многофакторной аутентификации (п. 5.7, 5.14). |
| Горизонтальное перемещение | Хранение паролей в открытом виде в файлах на сервере, слабые хэши паролей в БД. | Несанкционированный доступ к информации из-за некорректного хранения аутентификационных данных (п. 5.15). |
| Повышение привилегий | Повторное использование одного пароля для разных систем (wiki и AD). | Отсутствие сегментации учётных записей и контроля за их использованием. |
| Достижение цели | Отсутствие сегментации и мониторинга трафика между сетями поставщика и клиентов. | Невыполнение требований к защите соединений между информационными системами (п. 4.2, 4.4). |
Что должно было быть сделано иначе
Разбор показывает, что инцидент не был результатом одной сложной уязвимости. Это серия простых, исправимых промахов.
В части организационных мер:
- Обязательное обучение сотрудников, особенно разработчиков и сисадминов, основам безопасности при работе с кодом и конфигурациями.
- Внедрение и строгое соблюдение политики паролей: использование менеджеров паролей, генерация уникальных сложных паролей для каждого сервиса.
- Обязательное применение МФА для всех видов доступа, особенно административного и к внешним сервисам.
В части технических мер:
- Регулярный аудит открытых источников (OSINT) на наличие утечек данных компании.
- Сегментация сети: клиентский портал должен быть изолирован от внутренней сети компании, доступ к управляющим элементам инфраструктуры должен осуществляться только через выделенные «джамп-хосты».
- Запрет хранения паролей в открытом виде в любых файлах, использование выделенных хранилищ секретов (HashiCorp Vault, российские аналоги).
- Активный мониторинг аномальной активности: необычные входы в системы, доступ к файлам с ключами, установка неподписанного ПО на серверы.
- Для доступа к клиентам — отказ от постоянных VPN и переход на системы привилегированного доступа с сессионным аудитом и одобрением каждой операции.
Инцидент с «ТехноСистемой», это не история о хакерах-гениях, а история о системных уязвимостях, которые возникают, когда безопасность воспринимается как разовая задача, а не как непрерывный процесс. Каждый из этапов можно было прервать относительно простыми средствами, если бы они были внедрены и работали. Фактически, ФСТЭК как раз и требует построить такую систему защиты, где сбой одного элемента не приводит к катастрофе. Ценность подобного разбора в том, что он показывает, где находятся самые слабые и при этом самые критичные звенья в типичной российской ИТ-инфраструктуре.