Мошенничество с ИИ: дипфейки и поддельные распоряжения
Клон голоса, поддельный видеозвонок и перехваченная переписка ведут к одному — поддельному распоряжению об оплате. Защита строится на проверке, а не на распознавании.
В среду днём бухгалтер производственной компании открыла привычную переписку с поставщиком, с которым работали четвёртый год. Ветка была настоящей: внизу висели письма прошлых недель, спецификации, согласование сроков, подпись менеджера с тем же добавочным номером. В последнем письме сообщалось, что компания сменила обслуживающий банк и новые реквизиты приложены во вложении. Стиль совпадал, ошибок не было, вопрос выглядел рутинным. Оплату провели в тот же день. Настоящий поставщик позвонил через две недели, когда началась просрочка. Деньги вернуть не удалось, но дороже обошлось другое: следующий месяц бухгалтерия перепроверяла звонком каждое письмо подряд и на этом потеряла куда больше часов, чем стоила сама потеря.
В этом материале разбираем по порядку: что именно изменил ИИ в мошенничестве, три формы атаки, почему поддельное распоряжение выглядит убедительным, самую дорогую цель — распоряжение об оплате и смену реквизитов, почему призыв быть внимательнее защитой не является, как построить правило проверки, принцип «распоряжение живёт в системе, а не в канале», перевёрнутую версию ловушки со срочностью, риск для клиентов от тех, кто выдаёт себя за вас, действия в первый час после инцидента и минимальную схему, которую реально потянет маленькая команда.
Что именно изменил ИИ в мошенничестве?
Просить перевод от имени руководителя — идея не новая, ей десятки лет. Изменилась не идея, а её себестоимость. Раньше правдоподобное поддельное распоряжение требовало работы: изучить манеру переписки, выстроить безупречный язык, корректно употребить внутренние термины компании. Эти затраты делали атаку осмысленной только против крупных организаций. Сегодня та же работа занимает минуты, и производственная компания на сорок человек становится целью, ради которой стоит стараться.
Второе изменение — язык. Корявые формулировки и странные обращения целое поколение служили самым надёжным предупреждающим знаком. Этого знака больше нет. Третье происходит внутри самой компании: когда сотрудники вставляют тексты договоров, списки клиентов и внутреннюю переписку в неконтролируемые ИИ-сервисы, они сокращают путь атакующему. Как управлять этой стороной, не вводя тотальных запретов, разбираем в материале о теневом использовании ИИ в компании.
Три формы атаки: голос, видео и переписка
Первая — клонирование голоса. Нескольких минут записи руководителя достаточно: промо-ролик, выступление на конференции, запись вебинара. Формат голосового сообщения удобен атакующему идеально: он передаёт всё ощущение узнаваемости и при этом не оставляет собеседнику возможности задать вопрос.
Вторая — видеозвонок. Короткий разговор с плохой связью и подвисающей камерой сегодня генерируется и выглядит ровно так, как от него ждут: большинство рабочих созвонов и так выглядит именно так. Помехи читаются как норма, а не как повод усомниться. Короткая длительность тоже не случайность — чем дольше идёт такой звонок, тем выше шанс, что он развалится.
Третья и на практике самая опасная — перехват переписки. Атакующий не пишет нового письма, он появляется внутри настоящей ветки. Снизу висят подлинные сообщения прошлых недель, подпись верна, тема письма написана вами же. Изменились только реквизиты в последнем сообщении. Эта форма требует меньше всего технологий и даёт самый высокий процент успеха, поэтому и внимания заслуживает больше всех.
Почему поддельное распоряжение выглядит убедительно?
Убедительность идёт не от качества звука, а от точности контекста. Атакующий просит то, чего вы и так ждёте. В сезон выставок — оплату выставочных расходов. В конце года — закрывающий платёж. Если вы ведёте переговоры с новым поставщиком, будет назван именно он. Почти ничего из этого не берётся из закрытых источников: материал даёте вы сами — вакансии, пресс-релизы, публикации в соцсетях, должности в профилях сотрудников.
Второй источник убедительности — иерархия. Запрос приходит оттуда, откуда его неудобно оспаривать. В небольшой компании эффект сильнее: между директором и человеком, который двигает деньги, нет процедурной прослойки, они и так переписываются весь день. Именно эту неформальность и копируют. Сколько ваших данных вообще уходит наружу и что с ними делают ИИ-сервисы — смежная тема, её мы разбираем в материале об ИИ и клиентских данных.
Самая дорогая цель: оплата и смена реквизитов
Почти любое поддельное распоряжение целится в одну точку — счёт, на который уйдут деньги. Самая частая форма: уведомление о смене реквизитов, приходящее от имени реального, давно работающего поставщика. Счёт настоящий, сумма настоящая, работа действительно выполнена; чужой только номер счёта. Поэтому контроль на стороне оплаты должен смотреть не на подлинность счёта, а на то, менялись ли реквизиты получателя.
| Тип поддельного распоряжения | Чего добивается мошенник | Шаг, закрывающий спор |
|---|---|---|
| Смена реквизитов поставщика | Платёж уходит не туда | Звонок на номер из карточки контрагента |
| Срочный перевод от руководителя | Обойти цепочку согласования | Задача второму согласующему в системе |
| Запрос кода от службы поддержки | Вход в учётную запись | Перевести запрос в тикет |
| Устное согласие на видеозвонке | Ощущение подлинности | Подтверждение по второму каналу после звонка |
| Срочный запрос документов | Сбор материала для подделки | Загрузка документа через портал |
Самое действенное правило здесь звучит так: смена реквизитов никогда не завершается тем сообщением, которое её запросило, — только звонком, который инициируете вы. Какие поля должна нести карточка контрагента и где закупочный процесс обязан требовать согласования, разбираем в материале об управлении поставщиками и закупках. Раннее предупреждение даёт и возможность быстро увидеть, на какой счёт реально ушёл платёж; автоматическое сопоставление банковских движений с записями описано в материале об интеграции банковской выписки.
Почему призыв быть внимательнее защитой не является?
Учить команду распознавать подделку — заведомо проигранная гонка. Качество генерации растёт каждый месяц, ресурс человеческого внимания не растёт вообще. Больше того, тренинги по бдительности иногда работают против вас: чем сильнее человек уверен, что различит фальшивку, тем больше он доверяет собственной интуиции и тем законнее ему кажется пропустить процедурный шаг. Команда, которая пытается распознавать подделки, по сути ставит на собственную непогрешимость.
Пытаться распознать дипфейк — проигранная гонка; выигрывает один шаг проверки, после которого распознавание становится ненужным.
Правильный вопрос другой: как устроить работу так, чтобы деньги не ушли, даже если распоряжение поддельное? Ответ смотрит на процесс, а не на человека. Хорошо спроектированный контроль вообще не интересуется, настоящим ли был голос; он спрашивает только, было ли подтверждение по второму каналу. Такой контроль обесценивает даже самую качественную имитацию и полностью снимает с сотрудников обязанность что-то распознавать.
Как построить правило проверки?
Правило должно быть коротким, чтобы его помнили, и узким, чтобы оно не тормозило обычную работу. Перечисленных ниже элементов хватает большинству небольших компаний.
- Разделение каналов: проверяют не тем каналом, которым пришло распоряжение; письмо подтверждают звонком, звонок — записью в системе.
- Источник номера: перезванивают по номеру из карточки или договора, а не по тому, что указан в сообщении; одна эта фраза обрывает значительную часть попыток.
- Правило нового получателя: проверку привязывают не к сумме, а к новизне; любой счёт, на который платят впервые, требует второго человека независимо от размера платежа.
- Настоящий второй согласующий: согласует не тот, кто получил распоряжение; двое, прослушавшие одно голосовое сообщение, — это не проверка, подтверждение должно прийти независимо.
- Право остановить без последствий: письменно зафиксируйте, что задержавшему запрос сотруднику не предъявят претензий, даже если запрос окажется настоящим; без этой строки иерархия побеждает любой контроль.
- Фиксация проверки: кто проверил, когда и по какому номеру — записывается; если позже возникнет спор, смотреть будут в запись, а не в чью-то память.
Эти правила должны умещаться на одну написанную страницу. Как фиксировать критичные потоки в формате, который действительно читают, разбираем в материале о документировании процессов и SOP. Не менее важно держать охват узким: компания, потребовавшая двойного согласования на каждый платёж, за две недели найдёт обход собственного правила, и от контроля останется одна бумага.
Распоряжение живёт в системе, а не в канале
Запрещать голосовые сообщения или мессенджеры и невозможно, и не нужно. Запрет заменяется одним принципом: никакое распоряжение не считается действительным, если у него нет записи в системе. Голосовое — это напоминание, а не распоряжение; само распоряжение существует в платёжной записи, в заявке на закупку или в рабочем процессе. Спор о каналах после этого закрывается сам собой, потому что происхождение сообщения перестаёт иметь значение.
Чтобы принцип работал, должно быть ясно, кто и что может делать внутри системы. Кто создаёт платёжную запись, кто её согласует и кто вправе поменять реквизиты получателя — это три разных права, и определять их нужно раздельно; это разделение мы разбираем в материале об управлении ролями и правами.
У изменения должен оставаться след
Когда меняются реквизиты поставщика, должно быть видно, кто их изменил, когда и на каком основании. В системах без журнала изменений такая правка проходит бесшумно и обнаруживается обычно через месяцы, когда деньги давно ушли. Как устроена история изменений на записи и на что в ней смотреть, объясняем в материале о журнале аудита в CRM. На стороне договоров подписание с подтверждённой личностью стоит на куда более прочном основании, чем сканы живых подписей; как выстраиваются такие процессы, показано в материале об электронной подписи в договорных процессах.
Ловушка срочности и её перевёртыш
Классические памятки ставят срочность на первое место: подозревайте всё, что торопит, требует секретности и опирается на авторитет. Это верно и уже недостаточно. Именно потому, что срочность стала слишком известным признаком, аккуратные атакующие делают наоборот.
Новая форма спокойна и скучна. Сначала приходит маленькая, рутинная и совершенно законная просьба — документ, уточнение реквизита, подтверждение мелочи. Как только её выполняют, происходят две вещи: атакующий узнаёт, где у вас стоят контроли, и становится привычным участником переписки. Настоящее распоряжение приходит через три дня, изнутри ветки, которая уже кажется знакомой. Поэтому подозрение нельзя привязывать к срочности. Триггером должна быть сама операция: если из рук в руки переходят деньги или доступ, проверка выполняется независимо от того, насколько спокойно звучит сообщение.
Те, кто выдаёт себя за вас: риск на стороне клиента
Эту тему обычно обсуждают через собственные потери компании, но второй и часто более крупный риск лежит у клиентов. Поддельный счёт, отправленный от вашего имени, страница под вашим логотипом, звонок голосом вашего менеджера — всё это забирает деньги клиента и вашу репутацию одновременно. Клиент не запомнит, что у него самого не было контроля. Он запомнит ваш бренд.
Ответ здесь не оборона, а разговор заранее. Сообщите клиентам и поставщикам письменно, чего вы не делаете никогда: мы не меняем реквизиты по электронной почте, мы не перенаправляем оплату через мессенджер, мы никогда не просим у вас код подтверждения. Такое короткое уведомление, повторяемое раз в год, заметно снижает шансы того, кто выдаёт себя за вас, и, что важнее, даёт клиенту законный повод остановиться и переспросить.
Первый час после инцидента
Первый час — единственное окно, в котором перевод реально отозвать. Порядок важен: сначала звонок в свой банк с требованием остановить платёж, затем просьба уведомить банк получателя, потом официальные обращения. Параллельно смените пароль и завершите сессии на предположительно скомпрометированной учётной записи, но ничего не удаляйте из почтового ящика: эти сообщения — единственная опора любого последующего разбора.
Всё это нельзя оставлять на память отдельных людей. У каждого, кто проводит платежи, на столе должна лежать карточка на одну страницу: кому звонить и в каком порядке что делать. Если инцидент стал заметен снаружи, как вести коммуникацию, разбираем в материале о кризисных коммуникациях и управлении репутационным кризисом.
Чинить контроль, а не искать виноватого
Самая непродуктивная реакция после инцидента — назначить виновным того, кто провёл платёж. Цена такой реакции высока: следующий подозрительный запрос наверх уже никто не вынесет, потому что ошибиться будет казаться дороже, чем промолчать. Правильный вопрос звучит не как кто это сделал, а как какой шаг это бы предотвратил; ответом почти всегда оказывается один недостающий шаг проверки, который добавляется за день.
Минимальная схема для маленькой команды
В компании из шести человек нет службы безопасности и не будет. Четыре шага всё же закрывают основную часть риска по подъёмной цене. Первый — проверка по второму каналу для любой операции, где переходят деньги или доступ. Второй — второй согласующий для любого счёта, на который платят впервые. Третий — двухэтапная аутентификация на критичных учётных записях и общие пароли в нормальном хранилище, а не в таблице. Четвёртый — след изменений реквизитов в карточках поставщиков и клиентов.
Ни один из этих шагов не связан с ИИ напрямую: это обычная гигиена безопасности, и ИИ лишь сделал потребность в ней срочной. Полный набор базовых мер мы собрали в материале о кибербезопасности для малого бизнеса. Самое дешёвое время выстроить эту схему — пока ничего не случилось; самое дорогое находится где-то внутри того самого первого часа.
Самая надёжная защита от поддельных распоряжений — держать распоряжение в записи, а не в канале: когда реквизиты контрагента, коммерческое предложение, заказ, платёж и согласование лежат в одном месте, одно сообщение не может сдвинуть деньги само по себе. В Rocketly карточки клиентов и поставщиков, финансовый учёт, рабочие задачи и права пользователей собраны в одной системе; создайте бесплатный аккаунт и настройте собственный процесс проверки.