Забытый бэкап в открытой папке, слабый пароль без двухфакторной аутентификации и сегментация без контроля маршрутов — это не мелкие недочеты, а прямой путь к инциденту. По материалам DSEC и Solar 4RAYS, именно такие ошибки снова и снова открывают злоумышленникам дорогу в корпоративные сети.

История инцидента

В одном из разборов Solar 4RAYS атакующие пришли в медицинскую организацию через уязвимое веб-приложение собственной разработки. Защитники заметили вторжение, закрыли часть систем и отключили приложение, но пропустили Linux-сервер с менеджером паролей. Через несколько месяцев злоумышленники вернулись уже с сохраненными учетными данными, добрались до 1С, виртуализации, доменных контроллеров и бэкапов, а затем запустили шифровальщик через групповые политики.

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

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

Что пошло не так в защите

Первая ошибка — слабая парольная политика. В одном из пентестов DSEC достаточно было собрать учетные записи через Autodiscover и перебрать пароли по словарю, чтобы получить доступ к 1С, HR-порталу и другим сервисам. Без 2FA любой украденный или угаданный пароль превращается в полноценный вход.

Вторая ошибка — секреты в открытом виде. Архивы с исходниками, конфиги с логинами, бэкапы в общей папке, отладочные скрипты без авторизации — все это не «технический долг», а готовые ключи от инфраструктуры. Одна утечка репозитория или каталога может открыть доступ сразу к нескольким системам. Подобные сюжеты уже разбирались и в атаке через package.json и Linux-вредонос, и в истории с подменой тегов пакетов в Laravel-Lang.

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

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

Уроки для читателя

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

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

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

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

Практические выводы и чек-лист

  • Включите двухфакторную аутентификацию для почты, админок, облаков и критичных внутренних сервисов.
  • Проверьте, где у вас лежат бэкапы, архивы с исходниками и конфиги с паролями. Все, что доступно «по пути», надо закрыть.
  • Уберите отладочные скрипты и временные интерфейсы из публичного доступа.
  • Ограничьте права учетных записей администраторов и сервисных интеграций.
  • Проверьте, не хранит ли менеджер паролей или иной сервис секреты на сервере, который выпал из зоны контроля.
  • Настройте мониторинг нестандартных соединений между сегментами и следите за цепочками промежуточных хостов.
  • Регулярно проводите пентесты и Compromise Assessment, особенно после изменений в инфраструктуре.
  • Обновите парольную политику: длинные уникальные пароли, запрет на словарные варианты и контроль повторного использования.
  • Если сотрудник работает из поездок или подключается к корпоративным ресурсам вне офиса, заранее настройте защищенный канал связи и правила доступа.
  • Проверьте, можно ли восстановить систему из бэкапов без ручного «колдовства» — это тест не на удобство, а на живучесть.

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

Поделиться: