В криптомошенничестве жертву часто не взламывают технически. Её убеждают самой подписать действие, перейти на поддельную страницу или подтвердить проверку, а AI делает давление более персональным и быстрым.
Главный риск — смотреть только на вредоносный файл или эксплойт. В таких инцидентах опасное действие выполняет сам пользователь, поэтому защитнику нужны признаки срочности, шаблонов общения и необычных операций.
Как выглядит злоупотребление
AI помогает быстро менять тон, язык и легенду. Сообщения выглядят личными, учитывают контекст рынка или проекта, создают ощущение дедлайна и подталкивают к немедленному подтверждению операции.
- найти пользователя с интересом к криптопроекту;
- подготовить персональную легенду;
- создать ложную срочность;
- отправить ссылку или просьбу подписать действие;
- подтолкнуть к подтверждению операции;
- перевести активы после ошибки пользователя.
Следы для расследования
- одинаковые сценарии давления в разных чатах;
- внезапная просьба подтвердить операцию;
- новый домен рядом с известным проектом;
- переход после личного сообщения;
- подписание необычного действия;
- обращение в поддержку сразу после потери средств.
Защитные меры
- показывать предупреждение перед критичным действием;
- проверять домены и каналы проекта;
- обучить поддержку признакам AI-сценариев;
- собирать переписки и переходы в одну карточку;
- использовать поведенческую аналитику кошелька;
- останавливать операцию при сочетании срочности и нового домена.
Практический кейс
Кейс: пользователь сообщает, что подписал проверку участия в проекте после личного сообщения. SOC и антифрод собирают переписку, домен, время перехода и действие кошелька, затем добавляют предупреждение для похожих сценариев.
Минимальная проверка
- есть журнал перехода по ссылке;
- есть текст переписки или жалоба;
- известен домен и время операции;
- понятен тип подписанного действия;
- есть связь с похожими сообщениями;
- поддержка знает безопасный сценарий ответа.
Техническая настройка
Процесс нужно запускать как проверяемую защитную процедуру. Владелец сценария заранее определяет источники событий, границы доступа, поля журнала и действия, которые AI не может выполнить сам.
- назначить владельца риска и владельца сценария;
- описать источники данных и срок хранения;
- включить маскирование секретов и персональных данных;
- разделить подсказку, факты и вывод модели;
- запретить автоматическое изменение прав без человека;
- сохранять запрос, ответ и решение аналитика.
Поля журнала
- время события и источник телеметрии;
- учётная запись, роль и устройство;
- тип действия и затронутый объект;
- первичный сигнал риска;
- вывод AI и ссылка на подтверждающие факты;
- решение человека и итоговая причина.
Правило корреляции
Сигнал должен связывать несколько слабых признаков. Один признак остаётся наблюдением, а цепочка признаков открывает карточку проверки.
- первый признак: нетипичное действие или новый канал;
- второй признак: короткий интервал между событиями;
- третий признак: доступ к чувствительным данным;
- четвёртый признак: попытка обхода обычного процесса;
- пятый признак: повтор похожих запросов;
- итог: повышение приоритета и ручная проверка.
Безопасное подключение AI
- передавать только нужное окно событий;
- удалять секреты до отправки в модель;
- требовать ссылку на конкретный факт;
- отделять гипотезу от доказательства;
- не давать модели права менять доступы;
- хранить версию подсказки и результата.
Процедура проверки
- открыть карточку события и исходные журналы;
- проверить самый ранний сигнал в цепочке;
- сравнить поведение с обычным профилем;
- проверить связанные устройства и приложения;
- принять решение об изоляции или наблюдении;
- записать причину решения для последующего аудита.
Критерии готовности
- есть контрольная выборка нормальных событий;
- есть примеры реальных инцидентов;
- измерены ложные срабатывания;
- понятно, какие поля обязательны;
- есть владелец пересмотра правила;
- есть порядок отключения AI-обогащения.
Ограничения автоматизации
AI может ускорить разбор, но не должен становиться источником непрозрачного решения. Любое действие с правами, деньгами, доступом или внешней публикацией требует независимого подтверждения.
- не выполнять критичное действие по одному каналу;
- не доверять сводке без исходного события;
- не смешивать роль пользователя и роль сервиса;
- не скрывать от аналитика источники вывода;
- не хранить секреты в подсказках;
- не считать уверенный тон доказательством.
AI усиливает социальную инженерию скоростью и персонализацией, но защитные сигналы остаются проверяемыми: срочность, новый канал, необычный домен и критичное действие без независимой проверки.
Настройка контрольной карты
Для сценария нужна карта решений, где каждый вывод связан с фактом из журнала. Такая карта снижает риск слепого доверия модели и помогает объяснить решение после инцидента.
- задать обязательные поля для входного события;
- разделить технический риск и бизнес-влияние;
- проверять роль пользователя перед действием;
- отдельно отмечать неподтверждённые гипотезы;
- хранить версию правила и дату пересмотра;
- проводить выборочную ручную проверку.
Метрики пилота
Пилот нельзя оценивать только по скорости. Если карточки закрываются быстрее, но причины решений становятся менее понятными, защитный процесс ухудшается.
- доля подтверждённых выводов AI;
- стоимость ложного срабатывания;
- время до первого полезного факта;
- доля ручных отмен решения модели;
- количество скрытых или отсутствующих полей;
- число случаев, где потребовалась эскалация.
Ручной стоп-кран
В каждом сценарии нужен простой способ остановить AI-обогащение без остановки расследования. Это важно при утечке данных, ошибке подсказки, неверной нормализации или спорном выводе модели.
- отключить передачу новых событий в модель;
- сохранить уже созданные карточки;
- пометить спорные выводы как непроверенные;
- передать инцидент старшему аналитику;
- проверить, какие данные ушли в запрос;
- обновить правило перед повторным включением.
Что показать руководителю
Отчёт по итогам внедрения должен быть коротким и проверяемым. Руководителю важно видеть не обещание экономии, а снижение риска: какие события стали заметнее, какие решения стали быстрее и где человек сохранил контроль.
- сколько карточек прошло через новый процесс;
- какие признаки чаще всего подтверждались;
- какие данные пришлось добавить в журнал;
- какие действия остались только ручными;
- какие правила дали лишний шум;
- какие проверки включены в следующий цикл.
