Account takeover киберинцидент или мошенничество с клиентом

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

Технически authentication сработала штатно.

Но есть проблема: клиент в этот момент вообще не управлял своим аккаунтом.

Злоумышленник мог украсть активную session, получить credentials через phishing или infostealer, перехватить recovery-процесс, провести SIM swap или убедить службу поддержки изменить данные.

И в этот момент внутри компании начинается спор о классификации.

ИБ говорит: корпоративная инфраструктура не взломана.

Product team отвечает: authentication выполнила все предусмотренные правила.

Antifraud рассматривает конкретную транзакцию.

Support видит обращение клиента.

Legal пытается понять ответственность и возможность компенсации.

А сам клиент видит гораздо более простую картину:

«Я потерял контроль над своим аккаунтом, а компания этого не остановила».

На мой взгляд, именно здесь находится главная ошибка традиционного подхода к account takeover.

Мы слишком рано пытаемся решить, чей это инцидент.

Гораздо важнее сначала восстановить контроль над identity и остановить всю цепочку ущерба.

Одна из самых опасных ментальных моделей звучит так:

«Пользователь успешно прошёл authentication — значит, система сделала всё правильно».

Сегодня этого недостаточно.

Если злоумышленник украл уже аутентифицированную session, он может вообще не проходить MFA повторно.

Если клиент под воздействием социальной инженерии сам подтвердил операцию, cryptographic proof не отвечает на вопрос, понимал ли человек смысл действия.

Если compromised recovery позволяет заменить authenticator, сильный основной login control можно обойти через более слабый соседний процесс.

Поэтому authentication event — это не доказательство легитимности пользователя.

Это лишь один из сигналов в более длинной системе доверия.

Нужно смотреть шире:

identity → device → authenticator → session → behavior → account changes → transaction → recovery → customer confirmation.

Account takeover происходит не тогда, когда «сломался пароль».

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

Предположим, antifraud заметил подозрительный перевод и остановил его.

Отличный результат.

Но аккаунт всё ещё находится под контролем злоумышленника.

Что он может сделать дальше?

Изменить email.

Добавить другое устройство.

Создать нового beneficiary.

Оформить продукт.

Запросить восстановление.

Получить дополнительные сведения о клиенте.

Попробовать другую финансовую операцию через несколько часов.

Поэтому fraud containment и identity containment — это разные задачи.

Заблокировать деньги недостаточно, пока мы не восстановили доверие к identity.

И наоборот.

Сбросить пароль недостаточно, если остаётся активная украденная session.

Разлогинить устройство недостаточно, если attacker уже изменил recovery details.

Восстановить login недостаточно, если fraudulent transaction уже ушла в обработку.

Именно поэтому account takeover требует end-to-end response, а не последовательности независимых tickets.

Кто тогда должен владеть account takeover?

Я бы не передавал весь процесс одной функции.

SOC не должен самостоятельно принимать все решения по компенсации.

Antifraud не должен владеть архитектурой authentication.

IAM не должен определять fraud loss.

Legal не должен управлять техническим containment.

Но у сценария должен существовать end-to-end owner, отвечающий за то, что вся цепочка реакции действительно завершена.

Это может быть customer protection, fraud risk, security или отдельная cross-functional роль — конкретная модель зависит от бизнеса.

Главное, чтобы ownership охватывал всю цепочку:

signal → identity containment → transaction containment → device/session review → customer verification → credential recovery → financial decision → monitoring → lessons learned.

Проблема появляется не тогда, когда ответственность распределена.

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

Именно здесь техническая дискуссия становится управленческой.

Предположим, клиент сам сообщил злоумышленнику код подтверждения.

Должна ли компания компенсировать потерю?

Универсального ответа я бы не давал.

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

Нужно анализировать не только последнее действие клиента, но и дизайн всего customer journey.

Например:

Это не означает автоматическую компенсацию любого случая.

Но решение о redress должно учитывать качество системы доверия, которую построила сама компания.

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

Я бы использовал девять шагов.

1. Signal Зафиксировать cyber, identity, fraud или customer signal.

2. Identity containment Ограничить возможности атакующего действовать от имени клиента.

3. Transaction containment Остановить возможную монетизацию доступа.

4. Device/session review Определить, какие sessions и devices всё ещё можно считать доверенными.

5. Customer verification Независимо подтвердить законного владельца.

6. Credential recovery Безопасно восстановить credentials и authenticators.

7. Financial decision Разобрать операции, ответственность и возможный redress.

8. Monitoring Временно повысить чувствительность controls для аккаунта.

9. Lessons learned Передать findings обратно в IAM, fraud models, support scripts, product design и customer communications.

Последний шаг часто недооценивают.

Каждый account takeover должен немного менять систему.

Иначе компания просто возвращает аккаунт клиенту и ждёт следующей вариации той же атаки.

Я не считаю account takeover исключительно проблемой клиента даже в ситуации, когда первоначальная компрометация произошла на его собственном устройстве.

Компания выбирает способ authentication.

Компания проектирует recovery.

Компания решает, сколько живёт session.

Компания определяет, что можно сделать сразу после входа.

Компания проектирует transaction confirmation.

Компания создаёт antifraud controls и support procedures.

Поэтому она отвечает как минимум за качество созданной системы доверия.

Это не означает, что клиент никогда не несёт ответственности.

Это означает другое:

фраза «наша система технически работала штатно» не доказывает, что система безопасности была спроектирована хорошо.

Если в компании есть клиентские цифровые аккаунты, я бы выбрал несколько реальных ATO cases и задал команде пять вопросов:

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

Account takeover — не спор между cyber и fraud.

Это проверка всей архитектуры доверия между цифровым сервисом и клиентом.

И завершать такой инцидент нужно не тогда, когда заблокирован один перевод или сменён пароль.

Он заканчивается тогда, когда компания снова имеет основания доверять тому, кто находится по другую сторону аккаунта.