Рисунок 1. Общение по телефону, в сети и при личной встрече может быть частью одной истории. Концептуальная иллюстрация к статье.

Когда узнаваемого голоса уже недостаточно

В финансовом отчёте Arup за 2024 год есть необычное признание. Компания сообщила, что в январе стала жертвой мошенничества с использованием поддельного голоса, подписей и изображений. При этом, по её сообщению, сети не были затронуты. Обман произошёл при принятии решения, и защита сети сама по себе эту проблему не решила. [1]

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

Другой пример — разобранная исследователями кампания Mia Ash. В ней вымышленная онлайн-персона выстраивала отношения с сотрудниками, а через личную переписку на рабочее устройство доставили вредоносный документ. Среди интересовавших атакующего контактов были технические специалисты. К этому случаю мы ещё вернёмся позже. [38]

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

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

Попытка решить всё дополнительными проверками открывает ящик Пандоры. Каждый новый контроль затрагивает удобство, приватность и самостоятельность. Отказываться от защиты нельзя, но и считать любое ограничение полезным только потому, что его назвали антифродом, тоже не стоит.

Масштаб потерь и границы статистики

Начнём с масштаба. По итогам 2025 года Банк России сообщает примерно о 1,6 млн операций без добровольного согласия клиентов на 29,3 млрд рублей. В годовом обзоре рост их количества оценивается в 31,2%, объёма — в 6,4%. Однако у этих цифр есть важное пояснение: после появления сервиса обращения в банковских приложениях люди стали чаще сообщать о небольших потерях. Регулятор связывает с этим часть динамики. Поэтому за ростом зарегистрированных операций может стоять и изменение того, как люди сообщают о случившемся. [50]

За I квартал 2026 года в банковской отчётности отражена 495 761 операция без добровольного согласия клиентов на сумму около 7,4 млрд рублей. Ещё примерно 16,8 млн операций на 1,8 трлн рублей были предотвращены. Здесь легко получить впечатляющую, но мало что объясняющую цифру: сложить эти события в число пострадавших или разделить суммы и назвать результат «эффективностью антифрода». В отчётности, однако, нет всех невыявленных попыток, а с одним человеком могут быть связаны несколько операций. Для такого расчёта этих данных недостаточно. [51]

Статистика защитных продуктов показывает другую сторону проблемы. За 2025 год решения «Лаборатории Касперского» заблокировали более 554 млн попыток перехода по фишинговым ссылкам, а средняя доля спама в исследованном мировом почтовом трафике составила 44,99%. Это данные о потоке угроз, который наблюдала компания. Одно срабатывание защиты не означает одного потерпевшего, а спам может вообще не содержать фишинга. Эти различия стоит помнить, когда мы сопоставляем отчёты. [49]

Часть I Виды мошенничества и устройство атаки

Как мошенники используют социальную инженерию

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

Социальная инженерия может сочетаться с поддельным сайтом, вредоносным файлом, синтезированным голосом и личной встречей. Поэтому для защиты важно проследить всю цепочку: откуда взялось доверие, чего просят от человека и что после этого сможет сделать атакующий. [34, 36, 38, 42]

Что нужно злоумышленнику

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

Цель или сценарий Что пытаются получить Что проверить или предусмотреть
Обман покупателя или продавца Предоплату, реквизиты либо подтверждение чужой операции Условия сделки, безопасный порядок расчётов и настоящий интерфейс площадки
Ложные инвестиции или заработок Деньги под обещание дохода, оплаты заданий или вывода выигрыша Проверка контрагента и понятное, независимо подтверждённое основание платежа
Подмена делового распоряжения Перевод по изменённым реквизитам, оплату фиктивного счёта Отдельное подтверждение изменения реквизитов и разделение полномочий
Захват учётной записи Средство входа, активный сеанс, новый фактор или канал восстановления Защита на всех этапах работы с доступом, включая его восстановление
Романтическая легенда Деньги, документы, рабочие сведения либо действие с устройством Разделение личного доверия и права распоряжаться деньгами или рабочими данными
Проникновение в организацию Проход в офис, гостевой доступ, запуск программы или доступ к данным Порядок посещения офиса, работы поддержки и выполнения привилегированных операций
Шантаж или принуждение Платёж, сведения, выполнение опасного или противоправного задания Понятный способ получить помощь и ограничить дальнейший ущерб

Таблица 1. Основные цели и сценарии. Они могут пересекаться: отношения используют и для финансового обмана, и для кражи рабочих данных, а захваченный аккаунт — для атаки на других людей. Таблица составлена автором на основе [36, 38, 39, 41, 43, 44].

Например, BEC, или Business Email Compromise, — это обман в деловых коммуникациях, в том числе с подменой платёжных поручений. По описанию FBI, злоумышленники используют похожие адреса, захватывают переписку и выдают себя за доверенных участников. Для такого обмана не обязательно взламывать всю корпоративную сеть. При этом и письмо из настоящего рабочего ящика ещё нужно проверять, если в нём просят перевести деньги или изменить реквизиты. [43]

В отчёте Касперского за 2025 год разобран вариант BEC, где предыдущую переписку полностью выдумали. Получателю показывали якобы пересланную цепочку писем и предлагали срочно оплатить лицензию. Видимость давнего согласования тоже оказалась частью легенды. Проверить основание платежа здесь можно через установленный в компании порядок согласования; убедительно оформленная переписка его не заменяет. [49]

В романтическом сценарии тоже важно, к чему ведёт общение. При финансовом обмане человека под вымышленным предлогом просят прислать деньги — такой механизм описывает FTC. Если цель атаки связана с организацией, от собеседника могут ждать документы, сведения об инфраструктуре или доступ к устройству. Знакомство и флирт выглядят похоже, но защищать в этих случаях приходится разное. [44]

Где начинается контакт

Канал показывает, где человек встречается с атакой. По нему одному трудно судить о её сложности или цели: с одним и тем же предлогом можно обратиться по телефону, в письме, через знакомого или при личной встрече.

Канал или носитель Как выглядит контакт На что нельзя полагаться без проверки
Телефон и голосовой вызов Разговор «с банком», «поддержкой», «коллегой» Отображаемое имя, знакомый голос и знание некоторых ваших данных
СМС и push-уведомления Код, просьба подтвердить запрос, ссылка на срочное действие Сам факт получения кода или сообщения в приложении
Электронная почта Счёт, документ, приглашение, продолжение рабочей переписки Знакомая подпись, правдоподобный адрес и наличие старых писем в цепочке
Мессенджеры и соцсети Запрос знакомого, руководителя, рекрутера или нового собеседника Фотография, имя, общие контакты и длительность переписки
Сайты, поиск, реклама и QR-коды Вход, оплата, анкета, установка приложения Привычный дизайн, место в поиске, HTTPS и аккуратно напечатанный QR-код
Видеоконференция Совещание или просьба от лица «знакомого сотрудника» Знакомое лицо и речь, если значимое распоряжение не проверено независимо
Личное взаимодействие Посещение офиса, встреча на мероприятии, знакомство, визит «подрядчика» Уверенное поведение, рабочая одежда, визитка и личная симпатия
Материальный носитель «Полезная» флешка, документ, записка с просьбой или ссылкой Сам предмет и убедительная история о том, откуда он взялся

Таблица 2. Каналы и носители приманок. Составлена автором на основе [1, 34, 36, 38, 41–44]. QR-код и флешка помогают доставить приманку; способ воздействия на человека зависит от сопровождающей её истории.

Привычные признаки подлинности тоже отвечают лишь на часть вопросов. HTTPS защищает соединение с определённым сайтом, но ничего не говорит о добросовестности его владельца. Сообщение из настоящего аккаунта мог отправить человек, захвативший к нему доступ. Подлинное push-уведомление может подтверждать запрос, который сам владелец не делал. Поэтому нужно смотреть, какое именно действие стоит за каждым таким сигналом.

Особое внимание я бы обращал на переходы между каналами. Допустим, общение началось с вакансии, продолжилось в личном мессенджере, перешло в звонок и закончилось установкой программы на рабочий ноутбук. Доверие возникло ещё при знакомстве, но теперь на его основании предлагают совершить совсем другое действие. Так удобно разбирать цепочку атаки. Переходы между платформами встречаются и в документированных случаях, в том числе в кампании Mia Ash. [38]

У Касперского есть и пример корпоративного фишинга под видом кадровых документов. В PDF-вложении размещали QR-код, ведущий к поддельной форме входа. В других случаях QR-код приходил внутри календарного приглашения. Начав с привычной почты или календаря, сотрудник переходил в браузер, а иногда брал другое устройство. Документ выглядел как часть обычной работы, но основания передавать учётные данные это не создавало. [49]

На чём строится воздействие

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

Приём Что меняется для человека Что может помешать атаке
Ложный предлог и подмена роли Просьба выглядит служебной, законной или обязательной Проверить полномочия независимо от рассказа собеседника
Срочность и угроза потери Проверку предлагают отложить ради немедленного действия Предусмотреть право на паузу и отдельную проверку
Вознаграждение и услуга за услугу Опасное действие становится условием желаемой выгоды Независимо проверить основание для платежа или выдачи доступа
Профессиональная солидарность Нужно «выручить коллегу» или быстро решить техническую проблему Следовать обычному порядку подачи заявки и проверки полномочий
Доверие через связи и узнаваемость Общие знакомые и знакомые детали заменяют проверку полномочий Установить полномочия именно для запрошенного действия
Постепенное сближение и обязательства Новая просьба кажется продолжением ранее нормального общения Заново проверять основания для каждой просьбы о новых правах или данных
Секретность, стыд и изоляция Человек перестаёт советоваться и боится сообщить об ошибке Доступная конфиденциальная помощь без унижения человека
Шантаж и прямое принуждение Решение принимается под угрозой последствий для себя или близких Позаботиться о личной безопасности и обратиться за уполномоченной помощью

Таблица 3. Способы воздействия и возможные меры защиты. Составлена автором на основе [15, 36–39, 41–44]. Отдельный речевой признак сам по себе не позволяет установить намерения собеседника.

Разбор атаки через тактики и техники

В MITRE ATT&CK тактика описывает, зачем выполняется действие, техника — как достигается соответствующая цель, а процедура — конкретный способ её реализации. Для разбора происшествия это полезное разделение: мы можем отдельно описать результат, выбранный приём и то, как его применили. При этом бытовые слова «давление» или «флирт» нельзя просто объявить тактиками ATT&CK — у каталога своя структура и свои определения. [33]

Например, T1566 Phishing охватывает доставку через вложение, ссылку, сторонний сервис и голосовую коммуникацию. В карточке T1566.004 описаны голосовые обращения, которыми человека побуждают предоставить доступ или выполнить действия на устройстве. А T1621 посвящена генерации MFA-запросов в расчёте на подтверждение пользователя. В одном разговоре эти действия могут следовать друг за другом, но при разборе важно видеть каждое из них. [34, 35]

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

Рисунок 2. Как разобрать просьбу перенести фактор входа. Условный сценарий на основе [33, 36].

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

Для финансового мошенничества есть и специализированные модели. В отчёте F6 Fraud Matrix за 2025–2026 годы разобраны десять этапов: от разведки и подготовки ресурсов до доступа к аккаунту, совершения мошенничества, монетизации и отмывания. Так можно связать разговор с тем, что затем происходит с деньгами, и дополнить технический разбор по ATT&CK. Правда, количественные данные F6 основаны на срабатываниях собственных средств обнаружения и сведениях заказчиков. По ним можно судить о наблюдавшихся компанией атаках, но не обо всём мошенничестве в целом. [52]

Часть II Кто уязвим и почему знания не создают иммунитет

Почему важны обстоятельства

Представим SOC-аналитика после суточной смены. Он действительно записан к врачу. По дороге домой ему звонят «из клиники» и предлагают подтвердить запись. Это условный пример, но в нём хорошо видна разница между учебной задачей найти мошенника и обычной жизненной задачей попасть на приём.

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

Это учитывает NIST Phish Scale — методика оценки сложности распознавания фишинговых писем. Она рассматривает и подозрительные признаки сообщения, и то, насколько его легенда соответствует обстоятельствам получателя. Методика предназначена для электронной почты и учебных программ, поэтому её оценки нельзя напрямую переносить на звонки. Но сам подход помогает понять, почему одна просьба кажется человеку неуместной, а другая хорошо вписывается в его текущую задачу. [3]

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

Что мы знаем об усталости и нагрузке

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

Например, в эксперименте Джорджа Нассера и соавторов 50 студентов одновременно управляли железнодорожным движением в рамках задания и распознавали фишинговые письма. Лучше справлялись с письмами те, кто лучше использовал значимые признаки. При этом ожидаемого ухудшения результатов с ростом когнитивной нагрузки авторы не обнаружили. Они обсуждают возможное влияние тренировки и ограничения процедуры. Это как раз тот случай, когда исследование не поддерживает удобный, заранее готовый тезис. [4]

Систематический обзор о когнитивных аспектах социальной инженерии охватил 169 статей и 735 гипотез. Авторы отмечают, что эксперименты лишь частично воспроизводят реальные атаки: обстоятельства адресата, многоэтапность и сочетание каналов изучены неравномерно. Учитывать состояние и ситуацию человека нужно, но вывести из этих работ универсальную вероятность обмана для «уставшего пользователя» не получится. [2]

Для проектирования защиты это вполне практический вывод. Сервисом будет пользоваться и выспавшийся внимательный человек, и тот, кто устал, болеет или занят ребёнком. Я бы проверял, может ли каждый из них понять запрос, отказаться от опасного действия и получить помощь. Устойчивость защиты не должна зависеть от идеального состояния пользователя.

Риск определяется не только возрастом

В публикации Банка России об опросе за 2024 год среди пострадавших чаще всего встречались женщины 25–44 лет. Уже поэтому сводить аудиторию мошенников к пожилым людям было бы ошибкой. Но и обратный вывод требует осторожности: состав опрошенных пострадавших не показывает вероятность обмана для любого человека определённого пола и возраста. [40]

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

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

Российские исследования и пределы их выводов

Есть и российские исследования. В работе Д. А. Колодкиной, Н. В. Дворянчикова и К. Н. Дворянчиковой, опубликованной в 2025 году, участвовали 40 человек 21–44 лет. Половина уже сталкивалась с успешным обманом телефонных мошенников, половина такого опыта не имела. Данные собирали в 2021–2022 годах с помощью анкетирования, оценки ценностей и копинг-стратегий. Среди выявленных различий у пострадавших было менее выражено планирование совладания, то есть продумывание способов справиться с трудной ситуацией. [5]

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

В 2026 году опубликована первичная апробация методики оценки уязвимости к приёмам социальной инженерии. Авторы проверяли свой инструмент на 185 респондентах 18–30 лет и сопоставляли результаты с индивидуальными особенностями. Это помогает сформулировать гипотезы для дальнейшей проверки. Однако прежде чем по баллам опросника прогнозировать поведение сотрудника или ограничивать его доступ к работе, нужны независимые проверки и понимание того, применима ли методика к другой аудитории. [7]

Другая отечественная работа 2026 года посвящена людям, совершившим противоправные действия под влиянием телефонных мошенников. Авторы обобщают опыт более ста комплексных судебных экспертиз и обсуждают клинико-психологическую оценку выраженного эмоционального напряжения. Здесь исследуется особая группа уже отобранных случаев. По ней нельзя судить о состоянии каждого, кто разговаривал с мошенником, или называть любой обман гипнозом. [6]

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

Почему специалисты по ИТ и ИБ тоже уязвимы для обмана

Знания по ИБ помогают распознавать знакомые угрозы, но возможность ошибиться остаётся. Специалисту тоже хочется помочь коллеге, понравиться собеседнику или получить интересную работу. К тому же глубокие знания в одном направлении ещё не означают такого же опыта во всех остальных.

Это хорошо видно в эксперименте Robin Sage, который Томас Райан представил на Black Hat USA 2010. Исследователь создал вымышленный профессиональный профиль и за 28 дней получил сотни связей, в том числе среди людей из оборонной, разведывательной и ИБ-среды. В описании доклада говорится о раскрытии сведений с нарушением процедур операционной безопасности. Эксперимент показал, что выдуманный профиль способен вызвать доверие у профессионалов. Насколько часто все ИБ-специалисты попадаются на такой обман, по этой демонстрации оценить нельзя. [37]

Российский пример есть в отчёте Positive Technologies 2018 года по десяти отобранным проектам 2016–2017 годов. Во время согласованных проверок отправили 3332 тестовых письма с безвредными файлами. Сотрудники пересылали подозрительное вложение в ИТ-подразделение: разберитесь, почему оно не открывается. Технические специалисты запускали файл у себя, и так письмо доходило до администраторов и безопасников, которых изначально не было среди адресатов. В этой истории меня интересует именно рабочая привычка: знакомый коллега переслал файл, и его происхождение отошло на второй план. Для разбора таких вложений нужна изолированная среда. [53]

Рисунок 3. Пересылка тестового файла в ИТ-подразделение в согласованных проверках. Изоляция показана как предлагаемая мера защиты. По [53].

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

У ИТ- и ИБ-специалиста к тому же могут быть широкие полномочия: управление пользователями, материалы расследований, доступ к резервным копиям. Поэтому важно оценивать и вероятность ошибки, и то, что удастся сделать с доступными человеку правами. Раздельные повседневная и административная учётные записи, временные привилегии и проверка значимых изменений помогают ограничить последствия одного неудачного решения.

В совместном бюллетене AA23-320A, обновлённом 29 июля 2025 года, описаны атаки на крупные компании и их ИТ-поддержку. Злоумышленники выдавали себя за сотрудников, просили сбросить пароль и перенести MFA, навязывали запросы подтверждения, а затем похищали данные. Поддержка и администраторы здесь сами оказываются целью: мошенникам нужны их законные полномочия. При разборе также важно выяснять, кто и зачем запустил средство удалённой помощи и какие права предоставил. По одному названию настоящей программы об инциденте судить нельзя. [36]

Часть III Личные отношения и физический доступ

Не всякая опасная просьба приходит по сети

При личной встрече легенда иногда выглядит особенно убедительно. Человек в рабочей одежде представляется подрядчиком. Посетитель ссылается на знакомого руководителя. Собеседник на конференции просит ненадолго воспользоваться ноутбуком или показать интересный рабочий проект. Мы видим человека перед собой, но основания для его просьбы от этого не становятся надёжнее.

В рекомендациях NPSA социальная инженерия рассматривается и как способ добиться прохода на объект, доступа к ИТ-системам или раскрытия защищаемых сведений. Поэтому физическую, кадровую и компьютерную безопасность в таких историях приходится рассматривать вместе. [42]

В отчёте Positive Technologies CODE RED 2026 описана согласованная проверка, в которой получение учётных данных через поддельную беспроводную сеть сочеталось с проходом в офис во время мероприятия и доступом к ноутбуку сотрудника. Технические действия помогали физическому проникновению и наоборот. Здесь важно помнить контекст: речь идёт о тестировании на проникновение. Сам отчёт охватывает период с июля 2024 года по сентябрь 2025-го, хотя в его названии указан 2026 год. [54]

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

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

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

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

Сближение как путь к информации и устройствам

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

Теперь вернёмся к Mia Ash. В исследовании Secureworks CTU 2017 года, доступном на сайте Sophos, описана вымышленная фотограф, которая общалась с сотрудником через несколько платформ. Когда контакт был установлен, ему предложили открыть на работе документ, связанный с фотографией. В исследовании подробно описан вредоносный механизм этого файла. Среди контактов профиля были разработчики, инженеры поддержки и другие технические специалисты. [38]

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

Знакомство может закончиться и более привычным финансовым обманом. В обзоре Касперского за 2025 год описаны «культурные свидания»: после общения в дейтинг-сервисе человека приглашали в театр или кино и присылали ссылку на поддельный билетный сайт. После оплаты собеседник исчезал. Доверие к новому знакомому переносилось на предложенный им способ покупки, а целью были деньги. [49]

Есть и документированный случай передачи секретных сведений через сайт знакомств. В сообщении Минюста США от 10 июля 2025 года говорится, что бывший гражданский сотрудник USSTRATCOM Дэвид Слейтер признал вину в сговоре с целью незаконной передачи информации. Его собеседник выдавал себя за женщину и запрашивал чувствительные сведения. Дело показывает, как личная переписка может стать способом получения информации. При этом личность неизвестного собеседника нельзя считать установленной только по тому, кем он представился. [39]

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

Границы полномочий в личных отношениях

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

Смотреть полезнее на то, как меняются просьбы. Если интерес собеседника всё настойчивее смещается к работодателю, непубличным проектам, внутренним документам и обходу обычных процедур, это повод остановиться и проверить происходящее. Такие контакты отдельно рассматривает руководство NPSA по профессиональным знакомствам. Сам по себе интерес к работе ещё не доказывает вербовку, но содержание и настойчивость просьб имеют значение. [41]

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

Часть IV Массовый сценарий может быть хорошо организован

Что остаётся за голосом оператора

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

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

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

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

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

В многоэтапной схеме человека постепенно убеждают иначе понимать происходящее. Сначала он решает обычный бытовой вопрос. Затем узнаёт, что якобы случилось что-то опасное. Ему предлагают помощь, но для «спасения» нужно выполнить новые указания. Согласившись с объяснением угрозы, человек может принять и предложенный способ выхода.

В годовом обзоре Банка России за 2025 год есть пример такой последовательности. После разговора о доставке и просьбы назвать код человеку приходили ложное предупреждение об опасном звонке и сообщение о якобы оформляемом займе или взломе аккаунта. Там же был номер для связи. Человек сам звонил мошенникам и получал указания «спасти» деньги. Казалось бы, он выполнил совет перезвонить. Но номер ему дал тот же атакующий, поэтому независимой проверки не произошло. [50]

Удерживать человека в разговоре может не только страх. Желание выполнить обещание, помочь близкому, не подвести коллегу или содействовать законной проверке тоже даёт мошеннику возможность продолжать. Отказаться от этих качеств в обычной жизни мы вряд ли хотим. Поэтому защита должна мешать превращать такое доверие в доступ к деньгам и учётным записям.

В каталоге CAPEC для воздействия через воспринимаемый авторитет есть отдельный шаблон CAPEC-421 — Influence Perception of Authority. В том числе он описывает ситуацию, когда атакующий выдаёт себя за человека с определёнными полномочиями. Это помогает назвать и описать механизм атаки. Вероятность успеха конкретного разговора каталог не оценивает. [15]

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

Часть V Психология, НЛП и возможности ИИ

Что можно объяснить без ссылок на НЛП

Под НЛП здесь я понимаю нейролингвистическое программирование, или Neuro-Linguistic Programming. С компьютерной обработкой естественного языка — Natural Language Processing — это разные области. Похожие сокращения могут запутывать, поэтому их лучше сразу разделить.

В мошенническом разговоре встречаются уточняющие вопросы, спокойная уверенная речь, демонстрация осведомлённости, чередование тревоги и обещаний помочь. Увидев такой приём, ещё рано приписывать его определённой школе или принимать её теоретическое объяснение. Если называть НЛП любое убедительное общение, мы мало что добавим к пониманию атаки.

Что говорят исследования самого НЛП? В систематический обзор Джеки Стёрт и соавторов 2012 года вошли десять экспериментальных работ о его эффектах для здоровья, в том числе пять рандомизированных исследований. В четырёх из этих пяти значимых различий между группами не было, а риск систематических ошибок оценивался как высокий или неопределённый. Авторы сочли доказательную базу недостаточной. При этом они оговорили, что слабые доказательства эффекта ещё не являются надёжным доказательством полного отсутствия эффекта. [10]

У этого обзора есть и понятная граница: он посвящён вмешательствам в сфере здоровья. По нему нельзя рассчитать, насколько успешным будет телефонный разговор мошенника, или объявить опровергнутым любой речевой приём, который кто-то назвал НЛП. Для таких выводов понадобились бы исследования соответствующих ситуаций.

В другой работе 2012 года Ричард Уайзман и соавторы проверяли утверждения о связи направления движения глаз с ложью. Три исследования не поддержали проверявшийся шаблон, а знакомство с ним не помогло участникам лучше распознавать обман. Это результат проверки конкретной гипотезы. Для меня здесь полезен сам подход: привлекательное объяснение нужно проверять независимо от известности тех, кто его предлагает. [11]

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

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

Что в действительности произошло с CAPEC 431 и CAPEC 432

Иногда в пользу научности НЛП приводят его прежнее присутствие в MITRE CAPEC. Такие записи действительно были: CAPEC-431 называлась Target Influence via Neuro-Linguistic Programming (NLP), а CAPEC-432 — Target Influence via Voice in NLP. По истории карточек видно, что обе появились в версии 2.6 в июне 2014 года. [12, 13]

В текущей доступной версии каталога 3.9 у обеих записей статус DEPRECATED. История относит изменение к 31 июля 2018 года, версии 2.12; в отчёте о различиях между версиями 2.11 и 2.12 они перечислены среди устаревших шаблонов. Исторические карточки при этом сохранились. Поэтому точнее говорить, что шаблоны вывели из актуального набора. [12–14]

Развёрнутого объяснения причин в карточках нет. Утверждение «MITRE исключила их, потому что доказала неэффективность НЛП» добавляло бы к источнику то, чего он не сообщает. Прежнее включение в каталог тоже не доказывало эффективность: CAPEC систематизирует сведения об атаках, а для научной проверки психологических объяснений нужны другие данные.

Как ИИ упрощает подготовку персональных приманок

С генеративными моделями уже есть исследования, более близкие к нашей теме. В работе Фредрика Хайдинга и соавторов, опубликованной в 2026 году, участвовал 101 человек. Доля переходов по ссылке составила 12% в контрольной группе, 54% для писем экспертов, 54% для полностью автоматизированного варианта и 56% для ИИ с участием человека. Группы были небольшими, а сценарий конкретным, поэтому переносить эти проценты на любую атаку нельзя. Но для обсуждения возможностей автоматизации это уже предметные данные. [16]

Рисунок 5. Доли переходов по ссылке в четырёх группах эксперимента с 101 участником. Значения 12%, 54%, 54% и 56% относятся к кликам в условиях этой работы. По [16].

В исследовании USENIX Security 2026 с 7 700 участниками персонализированные письма, автоматически подготовленные с помощью языковых моделей и публичной информации, дали почти втрое больше переходов, чем общие письма. Стоимость персонализации авторы оценили примерно в 0,03 доллара за письмо. Это расчёт для использованных ими процедуры и инфраструктуры; стоимость другой кампании может отличаться. [17]

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

Есть данные и о беседах с ИИ. В рандомизированном исследовании, представленном на USENIX Security 2025, участвовали 502 человека. Специально настроенные разговорные системы получали от участников больше персональной информации, чем добросовестные варианты. Исследовали именно текстовые диалоги. О том, насколько голосовой бот способен управлять поведением человека, эта работа ответа не даёт. [18]

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

Часть VI Почему антифрод не может просто всё запретить

Участники видят разные части одной истории

Для человека звонок, письмо и поток СМС могут быть одной историей. А для обслуживающих систем это отдельные события. Оператор связи видит часть коммуникаций, сервис доставки — запрос кода, система идентификации — попытку входа, банк — платёж или смену настроек. Что именно доступно каждому участнику, зависит от устройства систем, канала общения и его законных полномочий.

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

Даже общая картина ещё требует объяснения. Человек мог сменить телефон, уехать в другой город и восстанавливать доступ к своим аккаунтам. События необычные, но вполне законные. Поэтому системе нужно не только заметить отклонение, но и выбрать реакцию, которая соответствует имеющимся основаниям для подозрения.

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

Получение кода ещё не означает захват аккаунта

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

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

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

С длиной кода связан другой вопрос: насколько трудно его угадать при заданных ограничениях. Шестизначный код тоже можно назвать мошеннику, а по наличию четырёхзначного ещё нельзя определить, какой доступ он даёт. NIST SP 800-63B-4 разделяет устойчивость к подбору, повторному использованию и фишингу. Вручную переносимый одноразовый результат аутентификации фишингостойким не считается. Здесь я использую NIST как технический ориентир: сам по себе этот документ не устанавливает обязательные нормы для любого российского сервиса. [21]

Почему хороший детектор тоже ошибается

Посмотрим на условный пример со 100 000 звонков. Пусть система находит 95% мошеннических, но при этом ошибочно помечает 1% обычных. Это вымышленные параметры для расчёта. Результат будет сильно зависеть от того, сколько мошеннических звонков было в исходном потоке.

Доля мошеннических звонков Верно отмечены мошеннические Ошибочно отмечены обычные Доля мошеннических среди тревог
0,1% — 100 из 100 000 95 999 8,7%
1% — 1 000 из 100 000 950 990 49,0%
10% — 10 000 из 100 000 9 500 900 91,3%

Таблица 4. Расчёт автора при чувствительности 95% и частоте ложных тревог 1%. Последний столбец показывает долю настоящих мошеннических звонков среди всех тревог — точность положительных предсказаний.

Возьмём вторую строку. Система верно обнаружила 950 опасных звонков, но вместе с ними заподозрила 990 обычных. Если автоматически блокировать всё отмеченное, человек может пропустить звонок из клиники или не связаться с курьером. Это ожидаемые последствия выбранного порога. Умения находить атаки недостаточно, чтобы считать любой автоматический запрет полезным.

Рисунок 6. Состав тревог при разных долях атак в условном потоке. Авторский расчёт по данным таблицы 4; это не статистика конкретного продукта.

Поэтому я бы оценивал детектор на реальном потоке, с характерной для него долей атак, и отдельно выбирал реакцию на каждый уровень риска. Незаметная дополнительная проверка, предупреждение о звонке и полная остановка платежа по-разному влияют на жизнь пользователя. Возможность применить более жёсткую меру ещё не делает её необходимой.

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

Часть VII Цена дополнительных барьеров

Внимание пользователя нельзя расходовать бесплатно

Один запрос подтверждения редко кажется серьёзной проблемой. Но человек пользуется десятками сервисов, и каждый просит что-то проверить, прочитать, вспомнить или подтвердить. Для разработчика это небольшое дополнение к своему продукту. Для пользователя — ещё одна задача в череде таких же требований, которая возникает в течение дня.

В исследовании Security Fatigue Брайан Стэнтон и соавторы разбирали полуструктурированные интервью с 40 участниками. Более половины сами заговорили об усталости, хотя исследователи не ставили её отдельной темой беседы. В работе описаны ощущение потери контроля, избегание решений и сомнения в пользе защитных действий. Такие интервью помогают понять опыт участников. Оценить, у какой доли всех пользователей возникает подобное состояние, по ним нельзя. [8]

Есть и другой эффект — привыкание к повторяющимся уведомлениям. В работе The Fog of Warnings показано, что человек может начать уделять меньше внимания частому обычному сообщению, а затем так же отнестись к новому, внешне похожему предупреждению безопасности. Авторы отличают этот эффект от усталости. Поэтому сделать предупреждение ещё настойчивее может быть недостаточно: важно, среди каких сообщений и как часто оно появляется. [9]

Для меня полезность предупреждения начинается с простого вопроса: после его прочтения понятно, что происходит и что делать дальше? Если текст лишь пугает, а для продолжения всё равно приходится нажать знакомую кнопку, человек привыкает закрывать такие окна. В нужный момент это привычное действие может помешать защите.

Где удобство помогает защите

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

Ещё в статье Users Are Not the Enemy 1999 года Энн Адамс и Анджела Сассе связывали обход защитных процедур и с отношением пользователей, и с устройством самих процедур. Они предлагали учитывать рабочие потребности и улучшать взаимодействие со службой безопасности. Технологии с тех пор изменились, но вопрос остался знакомым: помогает ли предусмотренный порядок выполнить работу безопасно? [20]

Кормак Херли в работе 2009 года рассматривал отказ от части советов по безопасности как поведение, которому можно дать экономическое объяснение. Время на выполнение советов тратят все, а польза зависит от реального риска и того, помогает ли совет его снизить. Этот аргумент полезен для оценки требований к пользователю. При этом исторические оценки ущерба нельзя автоматически переносить на современное мошенничество или использовать как повод отказаться от любой защиты. [19]

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

Приватность и право принимать решения

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

Для российской организации здесь действуют требования к обработке персональных данных. Нужно основание по статье 6 Федерального закона № 152-ФЗ. Части 2–5 статьи 5 требуют определённых законных целей, запрещают объединять базы с несовместимыми целями и собирать избыточные данные. Часть 7 связывает сроки хранения с целями обработки и предусмотренными законом или договором основаниями. Поэтому общего объяснения «для безопасности» недостаточно: придётся определить конкретную цель, участников и объём обработки. [29, 30]

Отдельный вопрос — тайна связи по статье 63 Федерального закона № 126-ФЗ. Техническая возможность анализировать коммуникации сама по себе не даёт права произвольно читать их содержание или передавать сведения другим организациям. Для конкретной схемы антифрод-обмена нужно проверить федеральные основания и полномочия участников. Но считать на этом основании запрещённым вообще любой обмен против мошенничества тоже было бы ошибкой. [31]

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

Есть и вопросы, которые не исчерпываются проверкой правовых оснований. Кто решает, что человек ведёт себя «слишком необычно»? Поймёт ли он, почему его ограничили, и сможет ли пройти другую проверку? Как быстро исправят ошибку? Особенно остро это чувствуется, если блокировка мешает получить жизненно необходимую услугу.

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

Что уже регулируется и что пока только обсуждается

В России обмен против мошенничества уже регулируется и специальными нормами. Статья 1 Федерального закона от 1 апреля 2025 года № 41-ФЗ определяет государственную информационную систему для противодействия правонарушениям с использованием ИКТ, категории её пользователей и полномочия по установлению порядка обмена. Согласно части 5 статьи 16, статья 1 вступила в силу 1 марта 2026 года. [45]

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

При чтении закона важно смотреть и на даты. В консолидированном тексте 41-ФЗ, действующем на момент подготовки статьи, отмечены изменения статьи 1 с 1 марта 2027 года. На 2 ноября 2026 года описывать их как уже действующие было бы неверно. Поправка может быть принята раньше, чем начнёт применяться соответствующее требование. [45]

С проектами ситуация другая. В сообщениях о публикации 30 сентября 2026 года третий пакет, известный как «Антифрод 3.0», представлен именно как проект. Обсуждаются дополнительные ограничения и требования к обработке данных и идентификации; доступная ссылка ведёт на карточку проекта № 171465. Эти публикации помогают понять ход дискуссии. А чтобы установить обязанности, нужно сверять формулировки и дальнейший статус по официальному тексту. [46]

Эта дискуссия возвращает нас к цене защиты. Оценивать меры против мошенничества придётся вместе с их влиянием на законную связь, доступ к сервисам и объём собираемых данных. Неудобство само по себе ещё не повод отвергать меру. Но нужно понимать, где она применима, чего позволяет добиться и как проверить результат.

Часть VIII Как снизить риск обмана и ограничить его последствия

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

Устойчивый к фишингу вход и его границы

FIDO2 и WebAuthn используют криптографическое подтверждение, связанное с нужным сервисом. В типичном сценарии passkey пользователь подтверждает вход на своём устройстве. Протокол при этом не выдаёт произвольному чужому сайту секрет, пригодный для входа в настоящий сервис. Часть проверки берёт на себя механизм аутентификации, и пользователю меньше приходится полагаться на собственную внимательность. [22]

Однако из одного слова passkey нельзя сделать вывод, что в любой конфигурации обеспечены два независимых фактора. Нужно смотреть, как проверяется пользователь, какими свойствами обладает аутентификатор и какой уровень доверия требуется. Есть разница и между ключами, привязанными к устройству, и синхронизируемыми ключами. Для последних важны защита провайдера синхронизации и порядок восстановления доступа. [23]

Теперь вернёмся к тому, что именно делает человек. Если он сам открыл настоящее банковское приложение и подтвердил перевод под влиянием мошенника, проверка входа могла отработать совершенно правильно. Она подтвердила владельца, но не то, что он верно понял цель операции. Защита от фишинга при входе также не устраняет вредоносное ПО, кражу активного сеанса и слабые процедуры восстановления доступа.

Рисунок 7. Возможные пути развития атаки и меры, которые могут их остановить. Схема составлена автором с учётом [21–23, 27, 32].

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

Дополнительные проверки при повышенном риске

Адаптивная аутентификация позволяет менять требования в зависимости от обстоятельств. Система может учитывать знакомое устройство, необычный вход, смену реквизитов или восстановление доступа. OWASP рассматривает такой подход как возможность соотносить проверку с риском. При этом география и поведение помогают принять решение о проверке, но сами по себе не заменяют факторы аутентификации. [24, 28]

Например, обычную информацию человек просматривает привычным способом. Чтобы добавить новое средство входа, подтверждает действие уже связанным аутентификатором. А для критичной операции сразу после восстановления доступа проходит дополнительную проверку. Это пример, который нужно оценивать применительно к рискам и возможностям конкретного сервиса.

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

Защита от потока кодов и навязанных подтверждений

Отправка кодов тоже нуждается в собственной защите от злоупотреблений. OWASP рекомендует ограничивать автоматизированные запросы восстановления, в том числе на уровне учётной записи, чтобы ими нельзя было завалить почту или телефон пользователя. Но здесь важно не дать запрашивающему другую возможность — полностью заблокировать чужой аккаунт. [25]

Я бы сочетал ограничения по адресату, источнику и действию, постепенно увеличивал задержки и проверял распределённые запросы. Одного IP-адреса для этого мало: атакующий может использовать много адресов, а добросовестные пользователи — общую сеть. При этом ограничивать отправку кодов и ограничивать попытки их проверки нужно отдельно. В первом случае мы сдерживаем поток сообщений, во втором — подбор.

Поток запросов не должен автоматически превращаться в такой же поток push-подтверждений. NIST рекомендует ограничивать их частоту или количество с момента последней успешной аутентификации. В Microsoft Entra для противодействия MFA fatigue, то есть утомлению навязанными запросами подтверждения, описано сопоставление числа при подтверждении. Это помогает уменьшить риск случайного согласия. Но такую проверку всё равно нельзя считать равноценной фишингостойкому криптографическому входу. [21, 26]

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

Показывать человеку смысл операции

Войти в сервис и разрешить конкретную операцию — разные действия. При критичной операции человеку нужно видеть, что изменится, куда направится результат и какие будут последствия. В OWASP Transaction Authorization это выражено принципом What You See Is What You Sign: пользователь подтверждает именно те значимые данные операции, которые ему показали. [27]

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

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

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

Возвращать контроль после ошибки

После захвата аккаунта одной смены пароля может оказаться мало. У атакующего способен сохраниться активный сеанс, добавленный им фактор входа или изменённый канал восстановления. OWASP рекомендует проверять эти изменения и работать с сессиями при восстановлении скомпрометированной записи. [25, 32]

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

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

Что даёт каждый подход

Подход Какой риск снижает Что ещё нужно проверить
Passkeys и FIDO2 Передачу поддельному сайту средства входа, пригодного для настоящего сервиса Восстановление, сеансы, защиту устройства и действия самого владельца
Адаптивные проверки Выполнение необычных или значимых действий без дополнительной проверки Ложные тревоги, доступность проверки и понятность решений
Контроль запросов кодов Автоматизированный поток сообщений и часть попыток подбора Запросы из разных источников и риск заблокировать законного владельца
Сопоставление числа и ограничение push-запросов Случайное подтверждение навязанного запроса Уговоры, фишинговую ретрансляцию и качество интерфейса
Подтверждение параметров операции Подмену действия или его значимых реквизитов Соответствие показанного серверной операции и понимание её цели человеком
Паузы и ограничение полномочий Рост ущерба после одного ошибочного действия Возможность выполнить срочные законные действия и применимость ограничений
Восстановление доступа Сохранение чужого доступа после обнаружения проблемы Подтверждение владельца и надёжность процедуры обращения в поддержку

Таблица 5. Что дают разные меры и что нужно проверить дополнительно. Составлена автором на основе [21–28, 32]. Эти меры дополняют друг друга и решают разные задачи.

Обучение, которое не заканчивается процентом кликов

Программы Security Awareness помогают объяснять угрозы, тренировать действия и учить сообщать о подозрениях. В России есть платформы с курсами, имитациями атак и отчётностью. Например, Kaspersky ASAP описывает программы для групп с разным уровнем риска, а BI.ZONE Security Fitness — обучение и тренировки по нескольким каналам. По этим описаниям можно оценить заявленные возможности продуктов. Чтобы понять результат их применения в конкретной организации, одной покупки платформы будет недостаточно. [47, 48]

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

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

Наличие WAF, установка DLP или смена пароля по календарю сами по себе эту задачу не решают. WAF не определит намерения романтического собеседника. DLP может заметить часть перемещений данных, но многое зависит от того, какие каналы она контролирует и как настроена. Для каждого средства защиты стоит объяснить, на каком этапе атаки оно помогает. А у человека после обучения должна быть реальная возможность выполнить безопасное действие.

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

Страхование и обещания компенсации помогают работать уже с последствиями события. Здесь нужно читать пределы возмещения, исключения, обязанности сторон и порядок подтверждения случая. Они определяют, на что можно рассчитывать после потери. Ни распознавание атаки, ни восстановление доступа такие договорённости не заменяют.

Кто отвечает за работающую защиту

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

У каждого участника есть своя часть работы. Разработчик определяет, что позволяет сделать интерфейс и какие полномочия выдаёт система. Оператор связи может сдерживать злоупотребления в доступной ему части коммуникаций. Банк или другой исполнитель значимой операции — анализировать и ограничивать её в пределах своих возможностей. Поддержка помогает вернуть контроль, а обучение объясняет человеку, как всем этим воспользоваться. Так я распределяю задачи при проектировании защиты. Юридическая ответственность в конкретном случае зависит от применимых норм и обстоятельств.

Результат я бы оценивал по нескольким связанным показателям. Каковы подтверждённый ущерб и его тяжесть? Какую долю атак обнаружили? Скольких добросовестных пользователей затронули ограничения? Сколько времени заняло восстановление доступа? Удаётся ли исправлять ошибочные блокировки? Какую нагрузку создали дополнительные проверки? Для каждого показателя нужно заранее договориться, какие события учитываются и относительно чего считается доля.

Отдельно стоит посмотреть, что человек делает после тревоги. Выбирает безопасное действие или звонит за помощью по номеру из подозрительного сообщения? Сохраняет доступ к сервису или теряет его из-за самой защиты? Без таких данных трудно отличить полезное предупреждение от ещё одного хорошего показателя в отчёте.

В учебной проверке переход по ссылке, ввод данных, подтверждение запроса и сообщение об угрозе тоже нужно учитывать отдельно. Один процент кликов мало говорит об устойчивости коллектива, особенно если легенды и рабочие обстоятельства различались. А раннее обращение за помощью стоит поощрять. Иначе человек запомнит, что безопаснее промолчать, чем ещё раз услышать насмешку.

В семье тот же вопрос возникает по-другому. Договориться, что близкий может попросить помощи, полезно. Постоянно следить за его сообщениями и решениями — уже совсем другое отношение. Мне ближе заранее выбрать независимый способ связи на случай необычной просьбы, чем пытаться контролировать каждый звонок родственника.

Как проверить неожиданную просьбу

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

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

С кодами тоже нужно смотреть на содержание действия. Код выдачи заказа действительно может потребоваться при получении товара по правилам сервиса. Это отличается от кода входа, восстановления доступа или платежа. Прочитайте, для чего пришёл код, и сопоставьте это с тем, что вы сами делаете. Если смысл остаётся непонятным, можно прервать разговор и сначала разобраться.

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

Рисунок 8. Краткая схема действий при подозрительной просьбе и после ошибки. Конкретные шаги зависят от выполненных операций и возможностей сервиса; см. также [25, 32].

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

Безопасность для нормальной жизни

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

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

Поэтому при обсуждении меры я бы спрашивал и о пользе, и о последствиях. Что она предотвращает и как часто ошибается? Кто поможет исправить ошибку? Сможет ли воспользоваться сервисом человек, который потерял телефон, не имеет нужных документов под рукой или по другой причине не проходит привычную проверку?

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

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

На какие данные опирается статья

В этой статье я сопоставляю исследования, описания инцидентов и технические рекомендации. Это аналитический обзор; систематический обзор литературы с заранее зарегистрированным протоколом здесь не проводился. Чтобы было проще оценить основания выводов, в таблице собраны основные эмпирические работы и их ограничения. Рассуждения о допустимой цене контроля и критериях проектирования выражают мою позицию. Технические руководства помогают выбрать механизмы защиты, но не доказывают одинаковый результат в любой организации.

Источник и метод исследования Что позволяет обсуждать Что нужно учитывать
[2] Обзор 169 статей и 735 гипотез Пробелы эмпирического изучения социальной инженерии Исследования различаются; единой оценки успеха всех атак нет
[4] Лабораторное исследование 50 студентов Распознавание писем по признакам; ожидаемого ухудшения при нагрузке не обнаружено Ограниченная выборка и процедура; возможен эффект тренировки
[5] Российское анкетирование 40 человек Связь рассказов участников об обмане с их ценностями и способами справляться с трудностями Корреляции не устанавливают причины
[7] Первичная апробация на 185 респондентах Гипотезы о личностных различиях по авторской методике Результат опросника ещё не предсказывает поведение при реальной атаке
[8] Качественные интервью с 40 участниками Переживания людей, уставших от требований безопасности По этим интервью нельзя оценить распространённость состояния среди населения
[10] Обзор десяти экспериментов с НЛП Ограниченность доказательств эффектов для здоровья Исследовались эффекты для здоровья, а не телефонное мошенничество
[16] Эксперимент с 101 участником Сравнение вариантов фишинговых писем с участием ИИ Переходы по ссылкам; небольшие группы
[17] Эксперимент с 7 700 участниками Автоматическую подготовку персональных фишинговых писем Измерялись переходы; стоимость относится к конкретной процедуре
[18] Рандомизированное исследование 502 участников Раскрытие данных в беседе со специально настроенным ИИ Исследовались текстовые беседы; влияние голосового бота не проверялось
[37] Исследовательская демонстрация Robin Sage Доверие к вымышленному профилю в профессиональных сетях Результат не описывает уязвимость всех ИБ-специалистов
[38] Наблюдение за кампанией Mia Ash Переход от личного контакта к технической атаке Исследование не подтверждает личные встречи или компрометацию каждого контакта
[39] Официальное сообщение о признании вины Конкретный случай передачи сведений через сайт знакомств По сообщению нельзя судить о частоте таких случаев и настоящей личности собеседника
[40] Опрос Банка России за 2024 год Характеристики пострадавших респондентов По составу пострадавших нельзя рассчитать риск для каждого человека

Таблица 6. Основные исследования и границы их применения. Формальный рейтинг качества работ в таблице не устанавливается.

Как подготовлена статья

Материал подготовлен мной (Максимом Шаманаевым) при участии ChatGPT. Я определил тему, направление рассуждений, основные тезисы и авторскую позицию. Финальная редакторская вычитка и правки перед публикацией остаётся за автором.

ChatGPT участвовал в поиске и обработке большого объёма источников, сопоставлении данных, выстраивании структуры и подготовке текста, а также подготовил инфографику, диаграммы и иллюстрации.

Источники

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

  1. Arup Group Limited. Financial Statement 2024. Сообщение компании о мошенничестве в январе 2024 года. Официальный отчёт.
  2. Burda P., Allodi L., Zannone N. Cognition in Social Engineering Empirical Research: A Systematic Literature Review. ACM Transactions on Computer-Human Interaction, 2024, 31(2), article 19. DOI: 10.1145/3635149; авторская запись в репозитории университета.
  3. NIST Phish Scale User Guide. NIST TN 2276, 2023. DOI: 10.6028/NIST.TN.2276. Карточка и документ.
  4. Nasser G. et al. The Role of Cue Utilization and Cognitive Load in the Recognition of Phishing Emails. Frontiers in Big Data, 2020, 3:546860. Полный текст. DOI: 10.3389/fdata.2020.546860.
  5. Колодкина Д. А., Дворянчиков Н.В., Дворянчикова К.Н. Индивидуально-психологические факторы виктимного поведения жертв телефонного мошенничества. Психология и право, 2025, 15(2), 140–153. Полный текст. DOI: 10.17759/psylaw.2025150210.
  6. Сафуанов Ф.С. и др. Преступники поневоле: патопсихологический синдром повышенного эмоционального напряжения с аффективно-личностной охваченностью у жертв телефонного мошенничества. Психология и право, 2026, 16(1), 1–16. Полный текст. DOI: 10.17759/psylaw.2026160101.
  7. Нурмухаметова И.Ф., Нурмухаметов Э. А. Разработка и апробация методики диагностики уязвимости к техникам социальной инженерии на основе индивидуально-типологического подхода Л. Н. Собчик. Психология и право, 2026, 16(1), 240–265. Полный текст. DOI: 10.17759/psylaw.2026160115.
  8. Stanton B. et al. Security Fatigue. IT Professional, 2016, 18(5), 26–32. DOI: 10.1109/MITP.2016.84. Карточка NIST.
  9. Vance A. et al. The Fog of Warnings: How Non-essential Notifications Blur with Security Warnings. SOUPS 2019, 407–420. Публикация USENIX.
  10. Sturt J. et al. Neurolinguistic programming: a systematic review of the effects on health outcomes. British Journal of General Practice, 2012, 62(604), e757–e764. DOI: 10.3399/bjgp12X658287. Карточка PubMed и ссылки на полный текст.
  11. Wiseman R. et al. The Eyes Don’t Have It: Lie Detection and Neuro-Linguistic Programming. PLOS ONE, 2012, 7(7), e40259. DOI: 10.1371/journal.pone.0040259.
  12. MITRE. CAPEC-431 — DEPRECATED: Target Influence via Neuro-Linguistic Programming (NLP). Карточка и история изменений.
  13. MITRE. CAPEC-432 — DEPRECATED: Target Influence via Voice in NLP. Карточка и история изменений.
  14. MITRE. Differences between 2.11 and 2.12 Content. Официальный отчёт об изменениях CAPEC.
  15. MITRE. CAPEC-421 — Influence Perception of Authority.
  16. Heiding F. et al. Evaluating Large Language Models’ Ability to Automate Spear Phishing. Expert Systems with Applications, 2026, 314, 131546. Публикация издателя; страница соавтора с полным текстом.
  17. Czybik S. et al. A Large-Scale Study of Personalized Phishing using Large Language Models. USENIX Security 2026, 1687–1706. Публикация USENIX.
  18. Zhan X. et al. Malicious LLM-Based Conversational AI Makes Users Reveal Personal Information. USENIX Security 2025. Публикация USENIX.
  19. Herley C. So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users. NSPW 2009. Публикация автора в Microsoft Research.
  20. Adams A., Sasse M.A. Users Are Not the Enemy. Communications of the ACM, 1999, 42(12), 40–46. Авторский текст в репозитории UCL.
  21. NIST SP 800-63B-4. Digital Identity Guidelines: Authentication and Authenticator Management. July 2025. Официальная публикация; полный текст. В частности, разделы 3.1.3 и 3.2.5.
  22. FIDO Alliance. Passkeys; Displace Password + OTP Authentication with Passkeys.
  23. FIDO Alliance. Synced Passkey Deployment: Emerging Practices for Consumer Use Cases. 2024. Официальный документ.
  24. OWASP. Multifactor Authentication Cheat Sheet. Адаптивная аутентификация и факторы.
  25. OWASP. Forgot Password Cheat Sheet. Злоупотребления запросами и восстановление.
  26. Microsoft Learn. Protecting authentication methods in Microsoft Entra ID. Сопоставление числа при подтверждении MFA.
  27. OWASP. Transaction Authorization Cheat Sheet. Подтверждение значимых данных и связь с операцией.
  28. OWASP. Authentication Cheat Sheet. Повторная проверка при значимых событиях.
  29. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», действующая на дату проверки редакция от 26.07.2026. Статья 5.
  30. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных». Статья 6. Для конкретного обмена данными требуется отдельная проверка основания.
  31. Федеральный закон от 07.07.2003 № 126-ФЗ «О связи», редакция от 20.02.2026 с изменениями, вступившими в силу 01.09.2026. Статья 63.
  32. OWASP. Session Management Cheat Sheet. Управление и прекращение сеансов.
  33. MITRE ATT&CK. Frequently Asked Questions. Значение тактик, техник и процедур.
  34. MITRE ATT&CK. T1566 Phishing; T1566.004 Spearphishing Voice.
  35. MITRE ATT&CK. T1621 Multi-Factor Authentication Request Generation.
  36. FBI, CISA и партнёры. Scattered Spider. Joint Cybersecurity Advisory AA23-320A, обновление от 29.07.2025. Официальный документ IC3.
  37. Ryan T. Getting In Bed With Robin Sage. Black Hat USA 2010. Описание исследования в программе конференции.
  38. Secureworks Counter Threat Unit Research Team. The Curious Case of Mia Ash. 27.07.2017. Первичный исследовательский отчёт.
  39. U.S. Department of Justice. Air Force Employee Pleads Guilty to Conspiracy to Disclose Unlawfully Classified National Defense Information. 10.07.2025. Официальное сообщение.
  40. Банк России. Портрет пострадавшего от кибермошенников в 2024 году. 17.02.2025. Результаты опроса.
  41. NPSA. Online Networking Guidance; Think Before You Link. Профессиональные контакты и риски раскрытия информации.
  42. NPSA. Protective Security Guidance — Staying Safe Online. Раздел Social Engineering; доступ к объектам и системам.
  43. FBI. Business Email Compromise. Подмена деловых коммуникаций и платёжных запросов.
  44. Federal Trade Commission. What To Know About Romance Scams. Финансовое мошенничество с использованием романтических легенд.
  45. Федеральный закон от 01.04.2025 № 41-ФЗ «О создании государственной информационной системы противодействия правонарушениям, совершаемым с использованием информационных и коммуникационных технологий, и о внесении изменений в отдельные законодательные акты Российской Федерации», редакция от 26.07.2026. Статьи 1 и 16. Консолидированный текст и примечания о будущих изменениях.
  46. Проект «Антифрод 3.0»: официальная карточка № 171465. Контекст публичного обсуждения: «Минцифры открыло третий антифрод», Коммерсантъ, 30.09.2026; сообщение SecurityLab от 30.09.2026. Сообщения о проекте не равнозначны принятому закону.
  47. Лаборатория Касперского. Kaspersky Automated Security Awareness Platform. Официальное описание возможностей продукта.
  48. BI.ZONE. BI.ZONE Security Fitness. Официальное описание возможностей продукта.
  49. Лаборатория Касперского. Спам и фишинг в 2025 году. Первичный отчёт и описание наблюдаемых кампаний; дайджест от 11.02.2026.
  50. Банк России. Обзор операций, совершённых без добровольного согласия клиентов финансовых организаций, за 2025 год. Обновление от 13.02.2026; форма 0403203. Сводные величины — Итоги работы Банка России 2025, раздел 2.3.
  51. Банк России. Обзор отчётности об инцидентах информационной безопасности при переводе денежных средств за I квартал 2026 года. Публикация от 14.05.2026. Значения могут уточняться по результатам взаимодействия с кредитными организациями.
  52. F6. Актуальные схемы мошенничества в цифровых каналах за 2025–2026 годы, отчёт на основе F6 Fraud Matrix. С. 4, 19–21. Источник сведений об этапах — отчёт разработчика; количественные данные ограничены его наблюдениями и данными заказчиков.
  53. Positive Technologies. Как социальная инженерия открывает хакеру двери в вашу организацию. 23.03.2018. PDF-отчёт, с. 3–6; десять отобранных проектов 2016–2017 годов.
  54. Positive Technologies. CODE RED 2026, Актуальные киберугрозы для российских организаций. Методология — с. 3; пример сочетания физического и сетевого доступа в пентесте — с. 126.
  55. Митник К., Саймон В. Искусство вторжения. Перевод А. Семёнова. Компания АйТи, 2005. ISBN 5-98453-020-1. Предисловие и истории о сочетании технических и социальных приёмов. Исторический сборник рассказов участников.
Социальная инженерия и мошенничество: границы защиты | Максим Шаманаев

Центры обработки данных: под землёй, под водой и за пределами планеты

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

А где все остальные безопасники? Зачем я начал собирать Профессиональный атлас ИБ

Началось всё, в общем-то, не с желания сделать ещё одну карту профессий. Я смотрел существующие проекты — в первую...
Социальная инженерия и мошенничество: границы защиты | Максим Шаманаев

«Остановите нас» — или не мешайте гонке? Что видно, если сложить открытые данные об ИИ в один пазл

Эта статья началась не с научной гипотезы, а с нескольких подозрительно громких новостей. Руководители крупнейших...
Социальная инженерия и мошенничество: границы защиты | Максим Шаманаев

Освободить ЦОД от ответственности за утечки? Всё сложнее, чем кажется

27 августа в СМИ появилась довольно громкая новость: коммерческие центры обработки данных предлагают освободить...
Социальная инженерия и мошенничество: границы защиты | Максим Шаманаев

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

В июле 2026 года Минцифры представило проект Доктрины развития системы противодействия правонарушениям, совершаемым...
Социальная инженерия и мошенничество: границы защиты | Максим Шаманаев

ИИ идёт по kill chain: как модели переходят от поиска уязвимостей к автономным атакам

Социальная инженерия и мошенничество: границы защиты | Максим Шаманаев

Когда интернет начинает цитировать сам себя

ИИ-контент, дефицит «живых» данных и научная версия теории мёртвого интернета
Социальная инженерия и мошенничество: границы защиты | Максим Шаманаев

Проект нового приказа ФСТЭК по ИСПДн: от перечня мер к управляемой защите

Почему главное изменение — не отдельные требования к ИИ, API и контейнерам, а постепенный переход к процессной модели...
Социальная инженерия и мошенничество: границы защиты | Максим Шаманаев

Цифровой след

От повседневных записей к профилю человека и правовым границам наблюдения Максим Шаманаев · 8 ноября 2026...