Истории из реальных аудитов, где всё пошло «чуть‑чуть не так».
Мы бываем в десятках компаний в год — от заводов и банков до IT-стартапов. Кто-то зовёт нас «для галочки», кто-то «перед проверкой Роскомнадзора», кто-то просто «посмотреть, всё ли у нас нормально».
И каждый раз мы приезжаем в уверенную, стабильную, «защищённую» компанию. Админы показывают аккуратные схемы сети, SIEM светится зелёным, политики паролей лежат в папке "ИБ_утверждено.pdf".
Но чем глубже смотришь - сервера, забытые VPN, бэкапы, которые съедают прод, и принтеры, через которые можно войти в почту директора.
И самое поразительное - почти никогда нет злого умысла. Только спешка, удобство и уверенность, что «оно же работает, зачем трогать».
Мы собрали несколько историй, которые особенно запомнились. Все они реальные, из аудитов последних месяцев. Ошибки неочевидные, но каждая могла обернуться катастрофой.
1. История про Wi-Fi, который слышал всё
Обычный корпоративный Wi-Fi. Для сотрудников одна сеть, для гостей — другая, через VLAN. На бумаге всё идеально.
Но когда мы посмотрели arp -a, внезапно появился контроллер домена.
Трассировка показала, что гостевая сеть идёт тем же маршрутом, что и внутренняя. А DNS-запросы обслуживает корпоративный DNS с SRV-записями Kerberos.
Любой гость с ноутом в переговорке мог поднять responder, перехватить NTLM-хэши и начать брутить офлайн.
— «Это не страшно, у нас сложные пароли», — ответили сетевики.
Один хэш — пароль Summer2022!.
Одна дырка в маршрутизации, и гость с Wi-Fi превращается в потенциального доменного пользователя.
2. История про бэкап, который съел прод
Финтех-компания. Всё красиво: nightly-бэкапы, crontab, отчёты в Telegram.
На одном сервере полный диск. Открываем /backup — 800 ГБ архивов .tar.gz.
Всё бы ничего, но скрипт писал бэкапы в тот же volume, куда монтировались Docker-контейнеры продакшна. В один момент контейнер перезапустился и затёр базу недельным дампом.
Потери: четыре часа данных, два дня восстановления. Не вирус, не взлом, просто крон без --exclude.
3. История про Telegram-бота, который выдал всё
В одной компании сделали внутреннего Telegram-бота: уведомления из CI/CD, алерты, деплои — всё красиво и автоматизировано.
Бот писал в чат:
"Деплой завершён успешно"
До тех пор, пока кто-то не заметил в логе пайплайна строку:
Using token: sk_live_51Hy...
Database password: P@ssw0rd!
Токен самого Telegram-бота тоже хранился в переменной окружения — без шифрования. Когда один из разработчиков случайно засветил .env в публичном коммите, токен попал в открытый репозиторий. Через несколько часов бот уже слал странные сообщения с внешних IP — кто-то воспользовался украденным токеном.
Пришлось отзывать ключи, чистить пайплайны и пересоздавать все webhook-и.
Даже внутренние боты часть инфраструктуры. Если их токены, ключи и логи не под защитой, они становятся той же дырой, что и открытый сервер.
4. История про Smart-UPS, который стал backdoor
Офис, серверная, 20 стоек. Сканируем сеть - Apache/2.2.8, порт 80, /admin.
Думаем: что за древний веб? Оказалось — это сетевой ИБП APC Smart-UPS. Пароль — apc.
Из веб-панели можно было не только выключить питание, но и послать SNMP-trap, который триггерил перезагрузку других стоек.
ИБП стоял в одной подсети с продом, чтобы "удобнее мониторить". Один запрос — и можно было вырубить пол-инфраструктуры.
5. История про 1С и ярлык смерти
На производстве пользователи подключались к 1С через RDP. Чтобы не мучиться, им сделали ярлык:
rdp://admin@192.168.0.50
и сохранили пароль.
Когда бухгалтер ушла в отпуск, её коллега включила компьютер, кликнула ярлык — и оказалась под админом. Случайно удалила папку с актами.
Резервка двухдневной давности.
GPO требовала менять пароли каждые 90 дней, но в ярлыке оставался старый кэш. Автоматизация удобства против здравого смысла.
6. История про "умную" SIEM, которая писала в никуда
На одном объекте внедрили отечественную SIEM: агенты, корелляции, алерты — всё как положено. Через месяц выяснилось, что агенты шлют логи… на тестовый сервер разработчика. DNS-имя никто не обновил, IP теперь у обычного ПК в офисе.
Логи терялись, алертов не было, а SIEM-дашборд светился зелёным.
Инцидент был — система не заметила, потому что сама себя не видела.
7. История про принтер, который стал хабом утечек
В компании начался утечный трафик из подсети МФУ. Оказалось, один из принтеров HP имел старую уязвимость (CVE-2017-2750). Пароли пользователей к корпоративной почте хранились в settings.xml.
Доступ без пароля, прямо через браузер.
Принтер стоял у ресепшена. Кто угодно мог подключиться и прочитать логины всей бухгалтерии. Офисная техника — тоже сервер, просто без внимания.
8. История про резервный VPN
В логистической компании нашли резервный OpenVPN, "на всякий случай".
Никто им не пользовался год. Сертификаты истекли, но TLS-ключи остались, логин backup, пароль Backup2023. Порт 1194 открыт наружу.
В логах нашли подключения из Польши месяц назад. Старый VPN не бывает безопасным, он просто тихо дожидается гостя.
9. Финальная история немного о другом
Эта история случилась совсем недавно. Нам в панике позвонили из компании: «Нас вот-вот взломают, данные под угрозой, нужно срочно реагировать». Приезжаем, выслушали участников — и выяснилось вот что.
Разработчик развернул тестовую сборку нового модуля у себя на личном сервере, чтобы показать идею. Скинул ссылку директору. Тот, впечатлившись, отправил её знакомому программисту: «посмотри, что мы пилотируем».
Программист открыл код и воскликнул: «У вас всё открыто, я могу влезть в компанию!» Началась паника: совещания, штрафы, остановка проекта. Между тем сервер не имел ни одного соединения с корпоративной сетью — это была обычная демка без продовых данных.
До нашей встречи потратили неделю: закрывали тест, замораживали релиз, выписывали санкции. Всё из-за отсутствия базового понимания, где реальная угроза, а где просто «страшно звучит». В итоге мы провели аудит и назначили топ-менеджменту краткие базовые уроки по безопасности — чтобы в следующий раз не рубить по секундам.
Что повторяется во всех этих историях
Ни одна не началась с взлома.
Везде первопричина — удобство, забывчивость и неверная оценка рисков.
Безопасность рушится не от хакеров, а от человеческого «да потом закроем».
И вот здесь начинается совсем другая тема
Потому что информационная безопасность — это не только пароли, шифрование и SIEM. Это ещё и здравый смысл, особенно на уровне руководителей. Если топы не понимают, что именно считается угрозой, то даже идеальные политики не спасут.
Расскажите свои истории из практики? Сталкивались ли вы с подобным?
Читайте в следующей статье:
«Безопасность для топов: базовый минимум или роскошный максимум?»
Разберём, почему руководители часто становятся слабым звеном, как их страхи превращаются в паралич решений и как построить диалог между бизнесом и безопасностью — без паники и ненужных потерь.