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

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

Меня зовут Дмитрий Бессольцев, я руковожу компанией ALP ITSM. Мы 30 лет помогаем компаниям приводить ИТ в порядок. У нас 140+ инженеров, поддержка в 900+ городах и опыт: 200+ клиентов из 12 отраслей — от производства и розничных сетей до медицины. Мы видим риски компаний с первого взгляда и успешно закрываем их.

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

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

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

• учетные записи, за которыми никто не следит;

• простые пароли, которые не меняются годами;

• доступы к данным у сотрудников и подрядчиков, которым они уже не нужны или никогда не были нужны;

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

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

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

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

• устаревшие протоколы VPN‑доступа;

• отсутствие прозрачной матрицы прав на файлы и сервисы;

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

• старые ОС, «дырявый», но уникальный по функционалу софт.

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

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

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

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

• процессов контроля и мониторинга нет, все держится на ручных действиях;

• резервные копии либо не делаются нормально, либо никогда не проверялись на восстановление;

• удаленный доступ выдавался «на время ковида» всем, а потом его просто не закрыли;

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

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

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

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

• открытые RDP, VPN, базы данных;

• устройства с известными уязвимостями;

• слабые пароли и дефолтные настройки.

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

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

• финансовый профиль и выручку;

• сезонность бизнеса;

• зависимость от непрерывности (производство, логистика, кассы);

• наличие филиалов, складов, распределительных центров.

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

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

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

• ПК инженеров, где крутится управляющий софт;

• удаленный доступ подрядчиков, которые обслуживают линии;

• серверы, к которым подключены эти системы;

• отсутствие сегментации: производственный контур «зашит» в общую офисную сеть.

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

• POS‑контур (кассы и терминалы);

• ERP, где живут заказы, остатки, цены;

• системы управления складом и логистикой;

• сайты, порталы, личные кабинеты поставщиков.

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

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

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

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

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

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

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

• грамотный язык;

• домены‑двойники;

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

• иногда еще и предварительный звонок.

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

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

Универсальной цифры нет: разброс огромный. Для части МСБ в России при хорошем резервировании и понятной архитектуре простой после атаки шифровальщика может уложиться в день‑два. Если заражение ушло глубоко, а резервные копии либо недоступны, либо тоже задеты, речь идет уже о неделях простоя, сорванных контрактах и реальной угрозе бизнесу.

Практически это считают так:

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

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

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

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

В итоге был брошен усиленный состав инженеров, поднят отдельный «чистый» контур, куда за 12 часов восстановили критичные сервисы из проверенных копий. Завод вернулся к работе без выплаты выкупа. По деньгам оказалось, что стоимость внедрения нормальной системы резервного копирования + аварийного восстановления была в несколько раз ниже суммы выкупа, не говоря уже о том, что выкуп не дал бы никаких гарантий сохранности данных и защиты от повторной атаки.

Почему же многие компании все‑таки платят? Причина почти всегда в математике:

• простой обходится в десятки миллионов,

• резервных копий нет или они сомнительны,

• восстановление «по‑честному» занимает недели,

• задеты критичные данные: разработки, проектная документация, финансовые базы, заказы, логистика.

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

У этой логики есть несколько неприятных «но»:

• выкуп не гарантирует рабочего дешифратора;

• не гарантирует, что все расшифруют до конца и быстро;

• не гарантирует, что украденные данные не всплывут в даркнете;

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

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

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

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

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

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

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

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

• что будет, если завтра сгорит единственный сервер;

• что будет, если зашифруют все общие папки;

• что будет, если затопит серверную;

• что будет, если уволенный сотрудник удалит документы с сетевого диска;

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

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

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

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

• правило 3‑2‑1: не менее трех копий, на двух типах носителей, одна — вне основного контура;

• регулярные тесты восстановления, а не просто отчеты «бэкап прошел успешно».

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

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

Чек-лист

Проверить здоровье ИТ-систем можно за пять минут. Мы собрали короткий чек-лист «7 cимптомов, что ИТ работает на "честном слове"». Ответьте на несколько вопросов и получите вердикт. Забираем чек-лист в телеграм-боте

Забрать чек-лист

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

• не открывать вложения и ссылки «на автомате»;

• проверять нетипичные запросы по второму каналу (перезвонить, уточнить);

• не использовать один и тот же пароль везде;

• не запрашивать себе повышенные права «для удобства»;

• включать MFA везде, где это предлагают;

• не ставить софт и не подключать носители без согласования;

• не пересылать рабочие данные в личные мессенджеры и почту.

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

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

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

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

1. Определить 10–20 критичных активов и процессов: что остановит бизнес быстрее всего и где хранятся ключевые данные.

2. Провести ИТ‑аудит с упором на ИБ и высокую доступность: снять карту инфраструктуры, найти точки входа, оценить резервное копирование и DRP (если есть).

3. Закрыть базовые дыры: пересмотреть права доступа, убрать открытый RDP, внедрить MFA, обновить наиболее «дырявые» системы, сегментировать сеть, защитить резервные копии, настроить мониторинг ключевых событий.

4. Договориться внутри бизнеса, что считается приемлемым простоем и потерей данных. Без этого любые цифры RTO/RPO — «для отчета», а не для решений. На основе согласованных требований — сформировать или актуализировать DRP.

5. Выстроить регулярные тесты восстановления: раз в квартал — точечные проверки критичных систем, раз в полгода — сценарные тренировки, раз в год — полноценные учения с участием не только ИТ, но и бизнеса.

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

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

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

Что сделать сейчас

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

Заказать аудит

Если тема откликается, можно посмотреть наши материалы о том, как подготовиться к сбоям и не терять деньги на ИТ:

• как собрать «цифровую аптечку» для бизнеса (план DRP);

• как увольнять «незаменимого» админа без остановки работы.

ТГ-канал ALP ITSM

Делимся 30-летним опытом: как сделать ИТ драйвером роста, а не центром затрат. Кейсы, разборы, советы - помогаем принимать стратегически верные решения и обеспечивать непрерывную работу ИТ и бизнеса.

Подписаться

Реклама: ООО «КТ-АЛП», ИНН 7703402450, erid: 2W5zFGW1JeD