Двойной удар: почему хакеры полюбили заводы и торговые сети

Меня зовут Дмитрий Бессольцев, я руковожу компанией ALP ITSM. Наша компания уже 30 лет помогает наводить порядок в ИТ: строить устойчивую инфраструктуру, закрывать дыры в безопасности, настраивать бэкапы, чтобы даже при атаке бизнес не вставал.

В статье делюсь тем, что мы видим изнутри атаки на заводы и сети: как сегодня выбирают жертв, какие контуры (ERP, склад, POS, инженерные станции) оказываются самыми болезненными при ударе и что имеет смысл сделать CEO или операционному директору уже сейчас, чтобы не обсуждать с советом директоров, платить выкуп или нет.

Где хакеры заходят в заводы и сети

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

Классический набор:

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

Особенно этим грешат многочисленные подрядчики по 1С, складским системам, ERP, аудиторы. На самом деле грешат не они, а ИТ‑специалисты, которые выдали доступ один раз и забыли. Внутренняя политика звучит примерно так: «антивирус тормозит и мешает», «резервные копии съедают ресурсы», «не будем усложнять», «да у нас все свои». Цена такой политики — потеря информации за годы работы и сотни человеко‑часов на ручной добор платежей и документов в 1С.

Если разобрать это технически, то картина обычно такая:

• рабочая группа вместо домена, или домен без нормальных групповых политик;
• устаревшие протоколы VPN‑доступа;
• отсутствие прозрачной матрицы прав на файлы и сервисы;
• морально и технически устаревшее оборудование, включая POS‑терминалы и складские терминалы, которые не умеют шифровать трафик и требуют «открытого» доступа к базе;
• старые ОС, «дырявый», но уникальный по функционалу софт.

Все это формирует ИТ‑ландшафт, похожий на минное поле: пока не наступил, кажется, что все нормально.

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

Опасные иллюзии: «у нас что‑то настроено» и «наш ИТшник все знает»

Самая частая ошибка — иллюзия, что защита уже «какая‑то есть». Это то самое «наш ИТшник там все знает, он у нас молодец».

Стоит задать несколько вопросов — и выясняется:

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

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

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

Случайные сканы и целевая охота: как выбирают жертву

В интернете непрерывно работают боты и сканеры, которые по сути «простукивают» весь внешний периметр компаний. Они ищут:

• открытые RDP, VPN, базы данных;
• устройства с известными уязвимостями;
• слабые пароли и дефолтные настройки.

Если компания «светится» наружу уязвимой точкой, она может попасть под атаку просто потому, что попала в выборку. Это массовый, статистический процесс.

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

• финансовый профиль и выручку;
• сезонность бизнеса;
• зависимость от непрерывности (производство, логистика, кассы);
• наличие филиалов, складов, распределительных центров.

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

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

Какие системы бьют больнее всего

На производстве слабым звеном часто оказывается не сама SCADA, а все, что вокруг нее:

• ПК инженеров, где крутится управляющий софт;
• удаленный доступ подрядчиков, которые обслуживают линии;
• серверы, к которым подключены эти системы;
• отсутствие сегментации: производственный контур «зашит» в общую офисную сеть.

В торговле список выглядит иначе, но принципы те же:

• POS‑контур (кассы и терминалы);
• ERP, где живут заказы, остатки, цены;
• системы управления складом и логистикой;
• сайты, порталы, личные кабинеты поставщиков.

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

Реальный пример: у клиента на 12 часов практически встал завод, потому что была зашифрована ключевая 1С‑база. В нее нужно было загружать сведения о произведенной продукции и оттуда забирать данные по заказам. Формально «сломалась 1С». Фактически — на полдня остановился весь производственно‑логистический цикл.

Если смотреть прагматично, «слабое звено» — это не обязательно самая старая система. Это та система, потеря которой сильнее всего бьет по прибыли.

Фишинг и социнженерия: директор из мессенджера и «налоговая» во входящих

Фишинг в промышленности и ритейле выглядит очень буднично — и поэтому эффективно.

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

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

Сегодня фишинг стал заметно качественнее:

• грамотный язык;
• домены‑двойники;
• вложения, похожие на реальные бизнес‑документы;
• иногда еще и предварительный звонок.

Отдельный риск 2026 года — использование AI для подготовки писем, сценариев общения и даже имитации голоса. Это уже не фантастика, а рабочие инструменты атакующих.

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

Сколько стоит день простоя и почему компании все-таки платят выкуп

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

Экономика таких инцидентов считается по довольно приземленной формуле:

Потери от простоя=(годовая выручка ÷ рабочее время в году) × доля процессов, завязанных на пострадавшие системы × часы простоя

Если критичные ИТ‑системы обеспечивают 70–80% оборота, несколько часов остановки ERP, склада или кассового контура превращаются в заметную сумму. И это только прямые потери. Поверх них накладываются штрафы за невыполненные обязательства, переработки сотрудников, срочные доработки систем и ускоренное восстановление.

Ориентиры масштаба дают открытые истории из ритейла. У крупных сетей один день простоя уже измеряется сотнями миллионов рублей. В 2024 году сбой в работе ритейлера «Верный» оценивался в 120–140 млн рублей в день, а трехдневный простой сети «Винлаб» — примерно в 1 млрд рублей недополученной выручки.

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

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

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

Важно понимать ограничения этого подхода:

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

Фактически в момент кризиса компания платит не за результат, а за шанс. Более зрелые организации подходят к вопросу иначе. Они анализируют, какие данные реально зашифрованы, какие ресурсы доступны офлайн, возможно ли поэтапное восстановление, какова истинная глубина компрометации и какие юридические и репутационные последствия будет иметь тот или иной сценарий — в том числе сценарий с выплатой. Критически важно, что такие компании инвестируют в архитектуру, резервное копирование и планы аварийного восстановления до инцидента. Это дает им в кризис не только возможность отказаться от выкупа, но и реальный выбор, как именно пережить атаку и за сколько времени вернуть бизнес к работе.

Почему компании шифруют снова и снова

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

Как выглядит типичный цикл «нас снова зашифровали»

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

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

DRP и бэкапы: когда кажется, что они есть

Самая частая ошибка с планом аварийного восстановления (DRP) — считать его красивой папкой для аудиторов. Рабочий DRP — это не схема в презентации, а очень конкретный ответ на вопросы:

• что будет, если завтра сгорит единственный сервер;
• что будет, если зашифруют все общие папки;
• что будет, если затопит серверную;
• что будет, если уволенный сотрудник удалит документы с сетевого диска;
• что будет, если умрет диск на ПК бухгалтера, где «для спокойствия» живут все базы 1С.

Кто будет поднимать системы? Откуда? В какой последовательности? Сколько это займет времени?

Разработка DRP начинается с приоритета: какие сервисы критичны, от недоступности каких компания пострадает быстрее всего. На это уже ложатся цифры RTO/RPO — допустимое время простоя и допустимая потеря данных.

С резервным копированием история похожая. Абсолютно неуязвимых схем нет, но есть базовые принципы, которые радикально повышают шансы пережить атаку:

• правило 3‑2‑1: не менее трех копий, на двух типах носителей, одна — вне основного контура;
• регулярные тесты восстановления, а не просто отчеты «бэкап прошел успешно».

Шутка «сисадмины делятся на тех, кто не делает бэкапы; кто уже делает; и тех, кто проверяет» — написана кровью и убытками. Копия, которую ни разу не поднимали в тесте, — это не защита, а надежда.

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

Люди и культура: почему одна ошибка не должна убивать бизнес

Кибергигиена для сотрудников — это не про героические многочасовые лекции раз в год. Рабочий минимум выглядит так:

• не открывать вложения и ссылки «на автомате»;
• проверять нетипичные запросы по второму каналу (перезвонить, уточнить);
• не использовать один и тот же пароль везде;
• не запрашивать себе повышенные права «для удобства»;
• включать MFA везде, где это предлагают;
• не ставить софт и не подключать носители без согласования;
• не пересылать рабочие данные в личные мессенджеры и почту.

Но кибергигиена не работает, если сотрудника наказывают за «лишнюю осторожность». Если бухгалтеру неловко перепроверить «директора», а инженеру страшно сообщить о странном поведении станции, компания сама выращивает инцидент.

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

Что делать компании, которая только начинает выстраивать защиту

Начинать нужно не с покупки «коробок», а с понимания себя.

Трезвый порядок шагов:

1. Определить 10–20 критичных активов и процессов: что остановит бизнес быстрее всего и где хранятся ключевые данные.
2. Провести ИТ‑аудит с упором на ИБ и высокую доступность: снять карту инфраструктуры, найти точки входа, оценить резервное копирование и DRP (если есть).
3. Закрыть базовые дыры: пересмотреть права доступа, убрать открытый RDP, внедрить MFA, обновить наиболее «дырявые» системы, сегментировать сеть, защитить резервные копии, настроить мониторинг ключевых событий.
4. Договориться внутри бизнеса, что считается приемлемым простоем и потерей данных. Без этого любые цифры RTO/RPO — «для отчета», а не для решений. На основе согласованных требований — сформировать или актуализировать DRP.
5. Выстроить регулярные тесты восстановления: раз в квартал — точечные проверки критичных систем, раз в полгода — сценарные тренировки, раз в год — полноценные учения с участием не только ИТ, но и бизнеса.

Компании не нужен «идеальный киберщит». Ей нужно не потерять бизнес из‑за самой простой атаки и иметь гарантированный сценарий восстановления без паники.

Один совет для CEO

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

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

Заключение: с чего начать прямо сейчас

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

Если по описанию вы узнали свою ситуацию — удаленка «со времен ковида», подрядчики с широкими правами, бэкапы, про которые вспоминают только в момент ЧП, — разумно начать с небольшого шага. Экспресс‑аудит критичных контуров (ERP, склад, POS, инженерные станции), схемы резервирования и плана восстановления дает понятную основу для разговора: что надо менять в этом году, что можно отложить, а от чего отказаться совсем.

Если вы как раз выбираете, с кем идти в такой аудит и дальнейшие изменения, посмотрите наш чек‑лист по выбору ИТ‑партнера. Он помогает оценивать подрядчиков не только по цене и SLA, но и по тому, как они работают с архитектурой, бэкапами и DRP — то есть с тем, что в кризисный момент решает, будет ли ваш бизнес стоять день или неделю.