← Все разборы Информационная безопасность

Уволенный менеджер два месяца жил в CRM: как «забытый доступ» обернулся потерей 1,3 млн ₽

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

24 июля 2026 г. Разбор CIOlogia

Собственник оптовой компании — стройматериалы, около 30 сотрудников — обратился с типовой на первый взгляд жалобой: клиенты «утекают» быстрее, чем можно списать на сезонность. Через месяц после увольнения ключевого менеджера по продажам темп потерь только рос: два-три клиента в первую неделю, пять — во вторую. Разбор журнала входов в CRM расставил всё по местам: под логином уволенного сотрудника система фиксировала заходы почти ежедневно, причём даты активности шли после даты увольнения по трудовой книжке.

Технически это не взлом в привычном понимании — никто не подбирал пароль и не эксплуатировал уязвимость нулевого дня. Это классический случай orphaned account — «осиротевшей» учётной записи, которая продолжает быть валидной после того, как человек перестал быть сотрудником. Именно такие истории чаще всего остаются вне поля зрения ИБ-аудита, потому что формально «взлома» нет: есть логин и пароль, которые просто забыли отозвать.

Как это эксплуатируется — по шагам

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

Шаг 1. Разведка периметра

Если CRM опубликована наружу (что типично для облачных и самописных решений с удалённым доступом менеджеров), первым делом любой внешний атакующий — или тот же бывший сотрудник, который хочет понять, что ещё доступно — сканирует внешний IP компании:

nmap -sV -p- --open crm.company-domain.ru

PORT     STATE SERVICE VERSION
443/tcp  open  https   nginx 1.18.0
80/tcp   open  http    nginx 1.18.0 (redirect to 443)
3389/tcp open  ms-wbt-server Microsoft Terminal Services

Открытый 3389 (RDP) вместе с веб-панелью CRM — тревожный маркер: значит, «удалённый доступ для менеджеров» реализован не через VPN с ограничением по сотрудникам, а напрямую в интернет.

Шаг 2. Поиск точки входа

gobuster dir -u https://crm.company-domain.ru -w /usr/share/wordlists/dirb/common.txt -x php,html

===============================================================
/login.php            (Status: 200) [Size: 3221]
/api/                  (Status: 200) [Size: 512]
/admin/                (Status: 403) [Size: 278]
/uploads/              (Status: 200) [Size: 1024]
===============================================================

Открытая директория /uploads/ без листинга-запрета и незакрытый API часто дают дополнительную информацию: структуру таблиц, версии фреймворка, иногда — тестовые файлы с логинами разработчиков.

Шаг 3. Аутентификация с валидными, но «мёртвыми» кредами

В данном кейсе пароль вообще не нужно было подбирать — он оставался рабочим. Но для наглядности того, насколько легко это масштабируется на внешнего атакующего: если бы пароль сотрудника утёк в составе combo-листа (а такие листы регулярно всплывают в утечках других сервисов, где люди повторно используют пароли), проверка валидности заняла бы минуты:

hydra -l ivanov.a -P leaked_passwords.txt crm.company-domain.ru https-post-form \
  "/login.php:user=^USER^&pass=^PASS^:F=неверный пароль"

[443][http-post-form] host: crm.company-domain.ru   login: ivanov.a   password: Prайс2021!
1 valid password found

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

smbclient -L //fileserver.company.local -U guest%

Sharename       Type      Comment
---------       ----      -------
Prices$         Disk      Опт-прайсы 2019-2024
Users           Disk
IPC$            IPC       IPC Service

smbclient //fileserver.company.local/Prices$ -U 'anyuser%SharedPass2021!'
tree connect established

Шаг 4. Выгрузка и монетизация данных

Дальше — уже не «взлом», а обычная работа менеджера: экспорт клиентской базы из CRM (у большинства систем это штатная кнопка «Экспорт в Excel/CSV»), выгрузка истории заказов, персональных скидок и контактов ЛПР. Именно это и произошло: 40 клиентов со средним чеком 35 000 ₽ в месяц ушли не потому, что их «переманили» звонком в холодную, а потому что у нового работодателя оказались точные условия, история закупок и личные контакты — то, на что обычно уходят месяцы работы отдела продаж.

Что и почему сработало бы дальше

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

Горизонтальное перемещение через почту. Учётка в CRM почти всегда связана с корпоративной почтой того же сотрудника. Не отключённый почтовый ящик — это доступ к переписке с клиентами, поставщиками и бухгалтерией, а также к цепочке сброса паролей в других сервисах (SaaS-бухгалтерия, банк-клиент, облачные хранилища).
Доступ к общей папке как плацдарм. Общий пароль на файловый ресурс с прайсами часто открывает доступ и к соседним шарам на том же сервере — договорам, шаблонам коммерческих предложений, персональным данным клиентов (все признаки события по 152-ФЗ, если в выгрузке оказались ФИО, телефоны, адреса).
Отсутствие MFA как усилитель риска. Если бы в CRM была включена многофакторная аутентификация, простое обладание паролем не давало бы входа — требовался бы код из приложения или SMS, привязанные к устройству сотрудника, которое компания уже не контролирует.
Отсутствие журналирования аномалий. Два месяца входов «в никуда» никто не заметил, потому что не было алертинга по входам в нерабочее время, с новых IP или устройств — система молча писала логи, которые никто не читал.

Полутехнические пруфы

Даже без сложного форензического анализа в логах CRM отчётливо видны маркеры проблемы:

Заходы под учётной записью уволенного сотрудника с датами, идущими после даты в приказе об увольнении и в табеле.
Совпадение времени активности с рабочими часами нового работодателя (конкурента), а не с произвольным временем «просто зашёл проверить почту».
Отсутствие в журнале записи о принудительном разлогине или блокировке учётки — событие «account disabled» просто никогда не наступило.
Общий пароль на файловый ресурс без индивидуализации — в логах файлового сервера все обращения к Prices$ идут от одной технической учётной записи, невозможно понять, кто именно скачивал файлы.

Как закрыли

Проблема лежала не в коде, а в процессе — и решалась организационно-техническими мерами, без разработки:

1. Инвентаризация точек доступа

Составили полный список систем: CRM, корпоративная почта, облачное хранилище, бухгалтерская программа, VPN, файловый сервер. Для каждой — список активных пользователей и дата последнего входа.

# Пример скрипта сверки активных пользователей CRM со списком сотрудников из 1С/кадров
comm -23 <(sort crm_active_users.txt) <(sort hr_active_employees.txt) > orphaned_accounts.txt
cat orphaned_accounts.txt
ivanov.a
petrova.s (в отпуске за свой счёт — уточнить у HR)

2. Регламент отключения доступа «день в день»

Внедрили простое правило: увольнение фиксируется не только приказом, но и чек-листом отключения доступов, который подписывает ИТ-ответственный в тот же день. Для CRM и почты — немедленная деактивация учётки (не удаление, чтобы сохранить историю действий для аудита), для облака — отзыв токенов и активных сессий.

3. Индивидуальные пароли вместо общих

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

net share Prices$ /delete
icacls "D:\Shares\Prices" /remove:g "Everyone"
icacls "D:\Shares\Prices" /grant:r "Sales_Group:(OI)(CI)R"

4. Уведомления об аномальных входах

Настроили webhook в мессенджер руководителя на события «вход с нового устройства» и «вход в нерабочее время» — большинство CRM-платформ и самописных систем поддерживают это через простой хук на событие login:

curl -X POST https://api.telegram.org/bot/sendMessage \
  -d chat_id= \
  -d text="⚠️ Вход в CRM: пользователь ivanov.a, IP 185.xx.xx.xx, 23:47, устройство не распознано"

5. Регулярная сверка

Раз в квартал — сверка списка активных учётных записей во всех системах со списком реально работающих сотрудников по кадровым данным (тот же скрипт comm, только по расписанию через cron).

6. Юридическая подстраховка

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

Про возврат сотрудников

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

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

Итоговая стоимость исправления — несколько дней настройки регламентов и типовых технических мер — оказалась несопоставима с суммой ущерба: более 1,3 млн ₽ выручки, ушедшей вместе с базой клиентов, историей заказов и персональными условиями сотрудничества.