Защита от кибератак с помощью AI: фишинг, эксплуатация уязвимостей и перехват управления агентами

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

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

Использование AI для атаки и атаки на AI

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

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

Путь атаки	Цель атакующего	Какую границу защищать первой
Целевой фишинг и подмена руководителя	Вход, восстановление учётной записи или одобрение платежа	Аутентификация, восстановление и отдельный канал проверки
Поиск и эксплуатация уязвимостей с помощью AI	Проникновение в открытые сервисы и кража секретов	Открытые ресурсы, исправления и изоляция
Инъекция промптов в агента	Неразрешённое выполнение инструментов или исходящие передачи	Разделение данных и инструкций; права инструментов и сети

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

Защищайтесь от фишинга через аутентификацию и маршруты одобрения

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

Начните с проверки следующих эксплуатационных границ:

• Вход: внедрите устойчивую к фишингу аутентификацию, например FIDO2 или ключи доступа, для поддерживаемых учётных записей и проверьте, что реальные политики входа требуют её. Рекомендации Microsoft по устойчивой к фишингу MFA рассматривают риски перехвата и усталости от подтверждений для SMS, OTP и push-аутентификации, а также переход к более стойким методам.
• Восстановление и регистрация: когда служба поддержки регистрирует новый метод аутентификации или восстанавливает учётную запись, проверяйте личность по доверенным существующим записям и отдельной процедуре. Установите правила, не допускающие одобрения восстановления по одному письму или видеозвонку.
• Бизнес-одобрение: проверяйте изменение банковских реквизитов и запросы на передачу секретов по ранее зарегистрированным контактам или во внутренней системе одобрения, а не по контактам из сообщения. Платёжное мошенничество может сработать без компрометации учётной записи, поэтому усиление входа само по себе не завершает защиту.

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

При реагировании на уязвимости учитывайте открытость и риск эксплуатации

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

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

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

Не превращайте прочитанное агентом содержимое в полномочия исполнения

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

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

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

Записывайте ID задач, идентификаторы исполнителей, имена инструментов, решения политики и результаты. Представляйте причины решений наблюдаемыми кодами политики; собирать скрытые рассуждения модели не требуется. Запись целых исходных документов, токенов или паролей создаёт ещё одну точку утечки. Эксплуатационная граница авторизации описана в статье Границы прав AI-агента.

Сопоставляйте отклонённые передачи после чтения внешнего содержимого

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

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

Пример выполнен на Python 3.13.0 без внешних пакетов, сети или производственных журналов. Сохраните его как correlate.py. Здесь at — секунды от начальной точки примера; реальному сбору нужны синхронизированные временные метки и стабильные ID запусков. Не заполняйте kind или идентификаторы, доверяя тексту документов или произвольным значениям, сгенерированным моделью.

from dataclasses import dataclass


@dataclass(frozen=True)
class Event:
    at: int
    actor: str
    run: str
    kind: str


def correlate(events: list[Event], window: int = 300) -> list[tuple[str, str, int]]:
    if window < 0:
        raise ValueError("window")
    last_read: dict[tuple[str, str], int] = {}
    candidates = []
    for event in sorted(events, key=lambda item: item.at):
        key = (event.actor, event.run)
        if event.kind == "untrusted_read":
            last_read[key] = event.at
        elif event.kind == "egress_denied":
            read_at = last_read.get(key)
            if read_at is not None and 0 <= event.at - read_at <= window:
                candidates.append((event.actor, event.run, event.at))
    return candidates


if __name__ == "__main__":
    events = [
        Event(20, "agent-a", "run-1", "egress_denied"),
        Event(0, "agent-a", "run-1", "untrusted_read"),
        Event(30, "agent-a", "run-2", "egress_denied"),
        Event(40, "agent-b", "run-1", "egress_denied"),
        Event(301, "agent-a", "run-1", "egress_denied"),
    ]
    print(correlate(events))

python3 correlate.py

Фактический вывод исполнения:

[('agent-a', 'run-1', 20)]

Выбрано только событие на 20-й секунде для того же запуска. Отказы для других запусков или субъектов и за пределами окна исключены. Окно 300 секунд — иллюстративный выбор, а не проверенный порог безопасности. Близость во времени не доказывает, что попытку передачи вызвала инъекция. Законная автоматизация может дать ту же картину.

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

Проверяйте результаты исполнения и закрывайте путь ущерба после сигнала

Проверяйте решения политики исполнителя и записи сети и сервиса назначения, а не полагайтесь на заявление агента о блокировке действия. Одно событие egress_denied означает отказ для конкретной попытки; оно не доказывает отсутствия утечки по другому пути. Остановите подозрительный запуск и сопоставьте доступ к источникам, вызовы инструментов и исходящие соединения по ID задачи.

Ситуация	Предлагаемая начальная реакция	Проверки перед возобновлением
Подозрение на вход или изменение учётной записи после фишинга	Аннулировать соответствующие сессии и токены, восстановить учётную запись, проверить зарегистрированные методы аутентификации и выданные согласия	Удалить пути доступа, добавленные атакующим, и проверить легитимный вход
Подозрение на эксплуатацию открытого сервиса	Изолировать затронутые ресурсы, сохранить свидетельства, применить исправленные версии и при необходимости пересобрать	Проверить работающие версии и доступность; исследовать закрепление и боковое перемещение
Неразрешённые вызовы агента	Остановить запуск, отозвать или сменить соответствующие учётные данные, ограничить инструменты и пути передачи	Регрессионно проверить отклонение неразрешённых запросов и успех разрешённой работы

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

Начните с одного внешне доступного ресурса, одной важной учётной записи и одной задачи агента, читающего внешние документы. Для каждого соедините реальное принудительное ограничение, пригодные для расследования журналы и процедуру восстановления, которую владелец сможет выполнить. Включайте успешные законные запросы в повторные тесты и проверяйте, что изменение границ отклонения проваливает проверку, как показано в статье TDD с помощью AI.