Уволенный менеджер два месяца сливал CRM через забытый VPN: разбор кейса на 1,2 млн рублей

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

Архитектура, в которой была дыра

Несколько лет назад для удалённой работы менеджеров с 1С и CRM арендовали VPS. На нём поднят VPN-сервер (в таких кейсах чаще всего это PPTP или OpenVPN с одним общим клиентским конфигом), через который менеджеры попадали во внутреннюю сеть — на терминальный сервер с 1С и веб-интерфейс CRM. Логика была простая: один туннель — один пароль на всех, потому что «зачем плодить учётки, если и так работает».

Проблема в том, что при такой схеме:

• невозможно отличить одного сотрудника от другого в логах — все заходят под одной и той же учётной записью;
• при увольнении человека нужно физически вспомнить, что у него был доступ, и вручную сменить общий пароль — а это неудобно, потому что «сломается всем»;
• сам факт подключения никто не мониторит: файл openvpn-status.log или журнал PPTP-соединений просто лежит на сервере и не проверяется.

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

Как это эксплуатируется

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

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

nmap -sV -p1-65535 --open 203.0.113.10

PORT     STATE SERVICE     VERSION
1723/tcp open  pptp        Microsoft Windows PPTP
3389/tcp open  ms-wbt-server Microsoft Terminal Services
1433/tcp open  ms-sql-s    Microsoft SQL Server 2016

Открытый 1723/tcp — классический признак PPTP, протокола, который считается устаревшим и уязвимым: используемый в нём MS-CHAPv2 ломается практически гарантированно (см. давно опубликованный разбор Мокси Марлинспайка про восстановление ключа DES за фиксированное время). Открытый 1433 говорит о том, что MS SQL, на котором обычно крутится база 1С, торчит наружу — потенциально ещё один вектор помимо VPN.

2. Получение учётных данных

Если бы доступа не было изначально, здесь в ход пошёл бы перебор:

hydra -l admin -P rockyou.txt pptp://203.0.113.10

[1723][pptp] host: 203.0.113.10   login: admin   password: qwerty2020
1 of 1 target successfully completed, 1 valid password found

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

3. Закрепление и доступ к данным

xfreerdp /v:10.10.10.5 /u:sales_common /p:'****' +clipboard

После подключения к терминальному серверу через RDP открывается 1С в режиме «Предприятие», где видна вся база клиентов, история заказов и закупочные цены. Если бы требовался прямой доступ к СУБД в обход интерфейса — тот же результат достигается через sqlcmd или sqlmap на веб-публикацию 1С:

sqlcmd -S 203.0.113.10,1433 -U sa -P '****' -Q "SELECT TOP 100 * FROM _Reference_Клиенты"

Дальше данные просто выгружаются в Excel-отчёт или копируются вручную — никакого «взлома» в классическом смысле уже не требуется, всё легитимно с точки зрения системы, потому что подключение идёт под старым, никем не отозванным логином.

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

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

• создание дополнительной локальной учётной записи на терминальном сервере с правами администратора — типовой способ «застолбить» доступ на случай, если основной пароль всё же сменят;
• выгрузка хэшей локальных пользователей утилитой вроде Mimikatz и последующий подбор через hashcat -m 1000 hashes.txt rockyou.txt — если сервер плохо пропатчен, это открывает путь к соседним машинам в сети;
• установка туннеля через легитимный сервис (ngrok, любой reverse-shell на PowerShell) для доступа в обход VPN, даже если сам VPN потом закроют.

В нашем случае ничего из этого не понадобилось — «дыра» была настолько удобной, что бывший сотрудник просто methодично обзванивал клиентов из выгруженной базы, предлагая те же позиции дешевле уже от нового работодателя. Три клиента, около 1,2 млн рублей недополученной прибыли за квартал — и это без учёта того, что один из ушедших клиентов был источником рекомендаций.

Как нашли и закрыли

Первым делом подняли журнал подключений — благо, VPN-сервер и так вёл лог, просто его никто не смотрел:

cat /var/log/openvpn/status.log | grep CLIENT_LIST

CLIENT_LIST,sales_common,203.0.113.87,10.8.0.6,1145678,0,2024-01-15 09:12:03
CLIENT_LIST,sales_common,203.0.113.87,10.8.0.6,987654,0,2024-01-22 09:05:44

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

Дальше — стандартный набор гигиены доступов, но применённый последовательно:

1. Переход с общего логина на персональные сертификаты OpenVPN — на каждого сотрудника отдельный сертификат через easyrsa build-client-full ivanov nopass, что позволяет отозвать доступ конкретного человека командой easyrsa revoke ivanov без остановки VPN для остальных.
2. Включение двухфакторной аутентификации на вход — код в приложении на телефоне сотрудника вместо одного статичного пароля.
3. Чек-лист для отдела кадров: увольнение = заявка в ИТ на мгновенный отзыв VPN-сертификата, смену пароля от терминального сервера и удаление учётки из 1С — в тот же день, а не «когда руки дойдут».
4. Уведомление руководителю в мессенджер при подключении с нового IP или устройства — простой вебхук из скрипта, который парсит тот же status.log раз в минуту и шлёт алерт при появлении незнакомого адреса.

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

Почему это касается почти всех

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

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

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