Rowhammer и видеокарты

GPUThor развивает идею атаки на оперативную память, впервые предложенную в 2014 году в рамках исследования Rowhammer. Принцип Rowhammer и всех атак этого класса основан на простом факте: ячейки памяти не изолированы друг от друга. Многократное обращение к одному и тому же ряду ячеек может при некоторых условиях вызвать повреждение данных (то есть смену значения) в соседних рядах. А раз такой эффект в принципе возможен, осталось найти способ использовать его во вред. Например, чтобы вызвать так называемый отказ в обслуживании или даже выполнить произвольный код.

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

Особенности атаки GPUThor

Весной 2026 года было опубликовано сразу три исследования, демонстрирующие разнообразные атаки на видеоускорители NVIDIA с памятью GDDR6. Все три показали достаточно скромные результаты: наибольший урон удалось причинить при атаке на «потребительскую» видеокарту, а когда в качестве цели использовали промышленный ускоритель NVIDIA A6000, эффективность атак оказалась значительно снижена. Кроме того, атаки не работали при включенном режиме коррекции ошибок ECC.

GPUThor также исследует возможность атаки на относительно старые ускорители NVIDIA Ampere с памятью GDDR6 (были изучены модели A4000, A4500, A5000 и A6000). Но новый метод показывает гораздо более высокую результативность атаки, измеряемую в количестве ячеек, данные в которых были принудительно изменены. Кроме того, исследователи утверждают, что в теории примененная злоумышленниками техника может быть использована и против более современных ускорителей.

Эффективность атаки GPUThor по сравнению с предшественниками. Источник

Как удалось добиться такого результата? Канадские ученые более подробно исследовали работу технологии Targeted Row Refresh — стандартного средства защиты от атак класса Rowhammer. TRR выявляет попытки многократного обращения и принудительно обновляет информацию в соседних ячейках, затрудняя или делая невозможным повреждение данных. Средством борьбы с TRR со стороны атакующих является обращение к случайным ячейкам так, чтобы «запутать» систему защиты и снизить ее эффективность. Исследователям удалось выяснить, что в видеокартах NVIDIA Ampere система TRR срабатывает только один раз за каждые 72 цикла обновления ячеек памяти. Вооружившись этой новой информацией, исследователи применили метод неравномерного обращения к ячейкам, а если проще — значительно увеличили количество обращений к целевым ячейкам памяти. В результате, если взять за единицу эффективность первой атаки на память GDDR, известную как GPUHammer, то GPUThor оказывается эффективнее в 7–23 тысячи раз!

Результаты и перспективы

Более интенсивная атака в комбинации с другими нововведениями позволила показать результат в 72–377 тысяч поврежденных ячеек видеопамяти на каждый гигабайт. Прошлые варианты Rowhammer могли похвастаться в лучшем случае сотнями повреждений. В результате ученые смогли добиться двойного или даже тройного повреждения данных. Одиночное повреждение легко корректируется системой коррекции ошибок ECC. Двойной сбой ECC скорректировать уже не может.

Кроме того, новый метод позволяет продемонстрировать реальный вред, наносимый атакой класса Rowhammer, — множественные обращения к видеопамяти методом GPUThor вызывают отказ в обслуживании. Ускоритель сначала перезагружается с потерей данных, а потом сигнализирует администратору о необходимости замены.

Но, несмотря на такие впечатляющие результаты, атака GPUThor успешна лишь наполовину. Во-первых, исследователям не удалось продемонстрировать возможность выполнения вредоносного кода в результате повреждения данных (хотя они и заявили о такой возможности даже с включенной ECC). Во-вторых, в тысячи раз более эффективная атака намекает на теоретическую возможность взлома и более современных ускорителей, но доказательств этого также пока нет.

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

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

Образы дисков

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

Наиболее универсален формат ISO, существующий со времен мультимедийных CD. Образ ISO подключается во всех ведущих ОС без дополнительных утилит, как через простые пользовательские инструменты вроде «Проводника», так и через командную строку. Именно поэтому злоумышленники смело отправляют файлы .iso в качестве вложения в письмо.

Чуть реже встречаются контейнеры IMG, которые тоже подключаются без дополнительного инструментария на macOS и Linux, но требуют установить маленькую бесплатную утилиту вроде OSFMount на Windows либо воспользоваться встроенной в последние версии Windows подсистемой WSL2 (Windows Subsystem for Linux 2). Идентичный по содержанию файл также может иметь расширение DD.

Используют злоумышленники и «родной» для Windows формат виртуальных дисков VHD, который, как правило, работает и на Linux-машинах (через qemu-nbd либо guestmount). На macOS потребуется дополнительная утилита для запуска, например та же quemu-nbd. Примечательно, что на необновленных системах Windows жертве даже не нужно ничего делать после подключения диска. Используемая в реальных атаках уязвимость CVE-2025-24993 приводит к запуску кода атакующих сразу после монтирования образа.

Для полноты можно также детектировать VMDK, формат образов дисков, используемый в VMware. Но атаковать обычных пользователей файлами VMDK малоэффективно, на всех популярных ОС потребуется дополнительное ПО.

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

Помимо того что файлы образов не известны как потенциально опасные, они помогают атакующим еще в одном аспекте. Извлеченные из образов файлы под Windows зачастую не несут отметку Mark of the Web, поэтому их запуск не вызывает дополнительных системных предупреждений.

Виртуальные машины и образы дисков важно сканировать EPP / EDR еще и потому, что они используются и на более поздних этапах кибератак. Например, банды вымогателей иногда разворачивают весь процесс шифрования в установленной на компьютере жертвы виртуальной машине, чтобы замаскировать от мониторинга активную деятельность в файловой системе. Шифровальщик RagnarLocker применял VirtualBox, а в кампании CRON#TRAP использовалась среда QEMU.

Файлы MS Office

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

Менее известны и пользователям, и защитным решениям файлы OneNote (.one). По сути, это просто заметки, но в них могут быть вложены другие файлы — не только изображения или ссылки, но и скрипты VBS/WSF/BAT. В тексте заметки вложения отображаются в виде пиктограммы, но злоумышленники накладывают поверх нее картинку с изображением кнопки «Просмотреть документ».

Другой популярный у злоумышленников формат Office — дополнения Excel. Они имеют формат XLL, но являются по сути полноценной библиотекой Windows (DLL), поэтому функциональные возможности такого «дополнения» очень широки. Пользователю присылают вредоносное письмо с «накладной», которое, судя по иконке, откроется в Excel. Если проигнорировать предупреждение безопасности — можно заполучить инфостилер.

«Картинки» SVG

Описание формата SVG, «масштабируемая векторная графика» (Scalable Vector Graphics), звучит максимально невинно. И действительно, 99% файлов в формате SVG — это логотипы и интерфейсные иконки. Но в отличие от PNG или JPG, файлы SVG по сути являются документом XML, и кроме точек, линий и заливок могут содержать JavaScript. SVG мало чем уступают полноценной веб-странице по вредоносному потенциалу. В реальных кибератаках файлы SVG сразу после открытия могут переадресовывать пользователя на фишинговую страницу, а могут полностью отобразить эту фишинговую страницу сами, развернув из блока, закодированного с помощью Base64, полноценный HTML.

Отдельную угрозу файлы SVG представляют для корпоративных порталов, на которые пользователи могут загружать файлы. Если политики безопасности (CSP) на портале недостаточно жесткие и кто-то загрузит на портал вредоносный файл SVG, то JavaScript в этом файле может красть со страницы куки, вставлять в нее посторонний контент и тому подобное.

Файлы-полиглоты

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

Явный джекпот в нашем обзоре собрала вредоносная кампания по распространению инфостилера IcedID. В письма жертвам вложен архив ZIP, из которого распаковывается файл образа ISO. Из него распаковывается файл CHM (справка Windows), который также корректно обрабатывается как приложение mshta (Microsoft HTML Application Host), которое уже скачивает основное вредоносное ПО.

Советы по защите от «экзотических» файлов

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

• настройте EDR, веб- и почтовые фильтры на сканирование всех описанных форматов файлов;
• обрабатывайте архивы и образы дисков так же тщательно, как исполнимые файлы;
• детонируйте потенциально опасные типы файлов в «песочнице» и настройте рекурсивную распаковку вложенных форматов, доходя до конца цепочки (ZIP — ISO — CHM);
• по возможности помещайте на карантин все аномальные для e-mail форматы файлов — в первую очередь образы дисков;
• создайте детектирующие правила на аномальные сценарии использования экзотических файлов. Например, очень маленькие образы дисков встречаются редко и подозрительны;
• изучите техническую документацию на используемые защитные решения и убедитесь, что сложные форматы файлов детектируются с глубоким разбором их структуры, а не только по «магическим» байтам;
• внедрите поведенческое детектирование, которое выявит аномальные схемы работы и запуск легитимных утилит из необычного контекста. Обычные подозреваемые здесь — это mshta, git, wscript, hh, rundll32;
• файлы SVG достойны своей политики. На почтовом и веб-периметре обрабатывайте .svg как активный контент. На корпоративных порталах задавайте жесткую CSP, а файлы, загружаемые пользователями, отображайте, загружая на сервер в отдельном поддомене. Тогда даже вредоносный скрипт из SVG не получит доступ к сессии на портале.

Жертвы парольного бизнеса

Злоумышленники из года в год используют три основных метода похищения учетных записей.

• Перебор паролей. Да, пароли в духе alex1988_ все еще существуют. О том, как их взламывают за минуту, мы писали в отдельном посте.
• Фишинг. Социальную инженерию тоже пока не удалось победить, и пользователи продолжают вводить свои данные на фейковых сайтах и страницах.
• Атака на сторонние сервисы. Укрепляя защиту собственной инфраструктуры, бизнес все еще не застрахован от утечек со стороны внешних сервисов, например CRM-систем или облачных платформ.

Однако не все похитители паролей тут же бросаются масштабировать атаку. Существует отдельная категория злоумышленников, брокеры первоначального доступа, которые «оптом» продают учетные данные на черном рынке, где их скупают APT-группировки и другие хакеры. К услугам таких брокеров прибегает, например, группировка The Gentlemen, которая атакует компании из самых разных отраслей, включая промышленность, IT, финансы и здравоохранение.

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

Браузеры против стилеров

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

Недавно такой инструмент появился в и без того богатом арсенале кибершпионской группировки HoneyMyte (также известна как Mustang Panda и Bronze President). Причем хакеры обзавелись сразу тремя вариациями зловреда, которые используют для атак на государственные организации. Наиболее опасная из них позволяет похищать данные из любого браузера на базе Chromium: Chrome, Edge, Brave и Opera.

Способ, которым зловред извлекает учетные данные из браузера, проще, чем может показаться. А все из-за забавного (и очень небезопасного) метода их хранения. Итак, данные зашифрованы ключом AES и хранятся в файле Login Data. Ключ лежит поблизости, в файле Local State. Он также защищен: предполагается, что воспользоваться им можно, только имея учетную запись Windows, под которой он был создан. Тут начинается самое интересное: стилер HoneyMyte обходит это ограничение, используя API-функцию CryptUnprotectData, получает ключ и благополучно расшифровывает пароли от внутренних порталов, панелей администрирования, облачных сервисов и CRM-систем. Двери в корпоративную инфраструктуру открыты нараспашку.

Один пароль для всей цепочки поставок

Иногда хакерам достаточно скомпрометировать учетные данные одного пользователя, чтобы поставить под угрозу и компанию, и все связанные с ней организации. По такому сценарию, например, развиваются атаки с использованием зловреда Shai-Hulud. Злоумышленники получают доступ к учетной записи разработчика и заражают поддерживаемые им npm-пакеты — готовые компоненты, которые другие специалисты могут подключать к своим JavaScript-проектам. Дальше площадь атаки разрастается естественным образом, без вмешательства хакеров.

После установки зараженного пакета на компьютер жертвы Shai-Hulud начинает искать ключи и токены npm, GitHub, AWS, GCP, Azure, а также другие доступные данные. Все это публикуется на GitHub в виде публичного репозитория, то есть исходный код, техническая документация, конфигурации и другие внутренние материалы компании становятся достоянием Интернета.

Как защитить корпоративные аккаунты

Эти советы помогут обезопасить компанию от компрометации учетных записей.

• Обучайте сотрудников. Рассказывайте им, как правильно создавать пароли и распознавать фишинговые страницы. Объясняйте, что учетные данные нельзя хранить в файлах, сообщениях и документах, — если на устройстве окажется троян или инфостилер, все это мгновенно попадет в руки злоумышленников. Подходя к вопросам безопасности осознанно, сотрудники смогут внести немалый вклад в общую защищенность компании.
• Настройте парольные политики. Длина и срок действия паролей, запрет на использование браузеров для их хранения. Эффективные и не слишком удачные парольные политики мы собрали в посте Политики паролей: как не надо делать.
• Используйте ключи доступа (passkeys). Это криптографическая замена паролей, состоящая из двух ключей — публичного, который хранится в сервисе, и приватного (остается у пользователя). Ключи привязаны к домену, поэтому фишинговые атаки с подменой адреса против них не работают.
• Подключите MFA. Используйте многофакторную аутентификацию везде, где это возможно. Она заметно снижает вероятность взлома даже в том случае, если пароль скомпрометируют.

Самый надежный способ хранения паролей — специализированный менеджер. Новый Kaspersky Password Manager для бизнеса развертывается прямо в инфраструктуре организации, позволяя компании сохранить полный контроль над данными. Продукт хранит данные в зашифрованном виде, а доступ к хранилищу может получить только пользователь с мастер-паролем. Кроме того, Kaspersky Password Manager для бизнеса самостоятельно генерирует уникальные и надежные пароли с учетом корпоративной парольной политики и может автоматически подставлять их в браузерах. Если где-то произойдет утечка, он поможет быстро поменять учетные данные. Компании, применяющие passkeys или MFA, могут использовать Kaspersky Password Manager для бизнеса как хранилище криптографических ключей и одноразовых кодов аутентификации (TOTP).

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

Почему возможно создать файлы polyglot

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

• Большинство форматов файлов нужно декодировать, начиная с первых байтов, но некоторые требуется читать «с конца». Самый яркий пример — архивы ZIP, в которых поврежденный или отсутствующий заголовок совсем не мешает чтению файла, поскольку нужные заголовки находятся в конце. Это позволяет просто «склеить» два файла, в примере выше — PNG и ZIP. Начало читается как корректное изображение PNG, а конец — как корректный ZIP-архив.
• Многие форматы устроены как «матрешки»: несмотря на специфическое расширение и конкретное применение, сам файл по сути является ZIP-архивом с нужными данными. К этой группе относятся офисные документы последнего поколения (DOCX/XLSX/PPTX), установочные пакеты Android (APK), файлы библиотек Java (JAR) и многие другие.
• Некоторые форматы не имеют жестких требований к структуре файла, или требования таковы, что приложение, которое обрабатывает файл, может найти нужный фрагмент, даже если он расположен не в начале.

Многочисленные примеры возможных комбинаций файлов, из которых можно собрать полиглота, описаны в GitHub-репозитории Polydet. По классификации MITRE эта техника относится к группе маскировки (T1036.008, Masquerade File Type).

Примеры файлов-полиглотов в известных кибератаках

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

Группировка Head Mare доставляла зловред PhantomPyramid в виде вложения ZIP. Файл был сконструирован из исполнимого кода Windows (EXE) с небольшим приклеенным архивом ZIP в конце. Жертва открывала архив, внутри которого был файл с расширением .pdf.lnk, который запускал то же самое вложение-полиглот, но уже как исполнимый файл.

В атаке, описанной JPCERT, злоумышленники создали файл, который начинается как PDF и детектируется большинством сканеров как PDF, но имеет расширение DOC и открывается в приложениях Office как корректный DOC-файл с вредоносными макросами.

В атаках по распространению троянов StrRAT и Ratty использовался полиглот из подписанного инсталляционного пакета Windows (MSI) с приклеенным в конце вредоносным кодом на Java (JAR).

В атаках StrelaStealer применялся полиглот с расширением HTML, состоящий из библиотеки Windows (DLL) с приклеенным в конце документом-приманкой HTML. Ярлык в архиве запускал файл два раза: один раз через команду start (аналог двойного клика, открывается браузер с документом HTML), а второй — через rundll32 (запускается вредоносный DLL).

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

Сложная вредоносная «матрешка» была применена во вредоносной кампании по распространению инфостилера IcedID. В письма жертвам был вложен архив ZIP, из которого распаковывается файл ISO. Из него распаковывается файл CHM (справка Windows), который собран по технике polyglot. При просмотре штатным инструментом «Справка Windows», этот файл выполняет встроенный в справку сценарий JavaScript, который запускает стандартное приложение mshta (Microsoft HTML Application Host), указав в качестве параметра тот же CHM-файл. Авторы кампании упаковали приложение HTA внутрь CHM таким образом, что оно не мешает прочитать файл как безобидную справку. А обработчик HTA услужливо пропускает весь «мусор» в начале файла, пока не найдет сценарии HTA.

Как файлы-полиглоты обрабатываются средствами защиты

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

• Большинство защитных решений не верят указанному расширению файла и проверяют его начало, чтобы определить структуру файла. Поэтому файл PDF с расширением DOC в вышеописанной атаке был проанализирован как безобидный PDF, тогда как зловредный макрос был в приклеенном DOC;
• Если файл начинается как что-то безобидное (изображение) и расширение соответствует, файл, вероятно, не будет сканироваться сложными технологиями анализа. При этом сопроводительные инструкции к файлу могут, например, советовать переименовать файл, чтобы поведение в системе жертвы уже было связано со второй нагрузкой, а не с изображениями.

Как защитить организацию от атак с применением файлов polyglot

Защита от полиглотов не требует сложных технических и организационных решений, но нужно качественное соблюдение ИБ-гигиены в организации.

• Используйте закрытые списки приложений (allowlist), разрешенных к запуску на рабочих компьютерах. Исключите из них устаревшие приложения Windows, не используемые в компании административные инструменты Microsoft, ПО удаленного доступа и передачи файлов и тому подобное.
• Используйте продвинутые решения по защите почты, оснащенные технологиями CDR (Content Disarm and Reconstruction — обезвреживание подозрительных вложений и их реконструкция в более безопасные) и детонации (запуск подозрительных вложений в изолированной среде для анализа). Настройте глубокий анализ вложений, которые по внешним признакам могут оказаться полиглотами (все файлы архивных и офисных форматов, файлы нестандартных расширений и так далее).
• Настройте большую глубину анализа потенциальных полиглотов также на стороне EDR.
• Создайте правила мониторинга, которые будут оповещать о нестандартных комбинациях процесса и файлов, которые ему переданы на обработку, вроде запуска файла CHM через приложение mshta или запуска HTML через rundll32 в примерах выше.
• Включите в программу тренингов ИБ-осведомленности базовую информацию о полиглотах, чтобы пользователи были настороже в ситуациях, когда файлу нужно менять расширение или обрабатывать его необычным образом, например открыть в конкретном приложении.

В чем принципиальное отличие нового метода

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

Японские исследователи показали, как можно уверенно прослушивать клавиатурный набор, находясь рядом с жертвой в публичном заведении, записывая звук с онлайн-встречи или даже подслушивая через стену при помощи контактного микрофона! И все это — с высокой точностью и с минимально возможным набором данных для обучения. Достаточно захватить 150–200 нажатий, и все дальнейшие символы будут распознаны с вероятностью 99%.

Варианты и базовая схема атаки, предложенной японскими исследователями. Источник

Как распознать 200 знаков за 200+ попыток

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

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

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

Результаты исследования

Экспериментальная установка для подтверждения теоретических выкладок выглядела следующим образом:

Ноутбук — жертва, смартфон — инструмент шпиона. Источник

Были использованы четыре разных ноутбука, с разным «звучанием» нажимаемых клавиш. В каждом эксперименте участник набирал 2400 символов, а для анализа отбирались от 50 до 400 нажатий. Во всех случаях набираемый текст удавалось надежно распознавать, имея в распоряжении запись от 150 нажатий. Точность распознавания превышала 80%, а при наличии записи 200 нажатий приближалась к 100%.

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

Эксперимент с прослушиванием клавиатурного набора через перегородку. Источник

В этом случае точность распознавания несколько снизилась, но не для всех протестированных портативных ПК. Компьютеры Dell и Lenovo дали точность около 80% при распознавании 200 нажатий, в то время как нажатия на кнопки ноутбуков Apple и HP дали почти стопроцентную точность.

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

Разумная критика

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

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

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

Во-вторых, исследователи справедливо посчитали, что даже несколько вариантов вероятного пароля повышают шансы на взлом какого-то сервиса, принадлежащего жертве. Так вот, как видно на графике выше, если данных для исследования много (426 нажатий), длина пароля всего пять символов и есть сто попыток для подбора, то с вероятностью 90% потенциального шпиона ждет успех. Конечно, пароли большей длины прослушиваются гораздо хуже.

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

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

Что случилось

При тестировании киберспособностей продвинутых ИИ-моделей OpenAI при помощи бенчмарка ExploitGym агент смог найти лазейку в Интернет и взломал инфраструктуру нескольких других компаний, включая Hugging Face. Модель сочла, что там можно найти ответы для ExploitGym. Подробности описаны в десятках статей, не будем их повторять. Важно, что случилось в инфраструктуре Hugging Face (HF) в период с 9 по 13 июля, пока там орудовал ИИ-агент. В отчет HF включена интерактивная страничка с хронологией атаки, поэтому здесь просто перечислим ее основные фазы. Вредоносная конфигурация датасета, загруженного агентом на HF, привела к утечке учетных данных одного из подов (worker pod), а затем обеспечила выполнение кода внутри него. Оттуда агент, используя метаданные облачной среды и побег из привилегированного пода, получил доступ уровня root на узле, прочитал значительное количество секретов из хранилища и, воспользовавшись украденным VPN-ключом и общими учетными данными администратора кластера, проник во внутреннюю сеть и систему контроля исходного кода, пока ИБ-команда HF не перекрыла ему доступ.

Важно ли, что это был ИИ последнего поколения?

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

Многие практики поспешно отмахиваются от этого инцидента со словами «нас не будет взламывать OpenAI». Но эксперты уже несколько месяцев указывают, что исследования ИБ и реальные атаки можно успешно проводить даже с существующими моделями open source. Да, им потребуется руководство человека, но совсем немного. А перебрать десяток уязвимостей, провести в системе жертвы инвентаризацию, быстро найти, как расширить присутствие в сети, могут даже не самые передовые модели. Задача защитников — детально изучать такие инциденты, примерять основные находки к собственной инфраструктуре и адаптировать меры ИБ, чтобы они эффективно работали как против живых и скрытных злоумышленников, так и против быстрых и шумных ИИ-агентов.

Три отличия AI-powered-атак

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

• Пробы и ошибки становятся гораздо дешевле. Там, где живой хакер попробует пять вариантов и путей атаки, агент может перебрать пять сотен. То, что в отделе ИБ считали «теоретически возможной, но непрактичной и маловероятной атакой» и поместили в бэклог, теперь может стать реальной угрозой.
• Время проведения атаки и реагирования на нее сокращается. Сверхбыстрые атаки уже не новость, некоторые операторы ransomware справляются за считаные часы даже без ИИ. Но этот темп вероятно станет новой нормой в ИБ. Захват прав администратора в HF занял у агента 13 часов.
• «Шум» оповещений и журналов от всех проб и ошибок агента может и помочь, и помешать обеим сторонам. Это и признак для детектирования атаки, и камуфляж для скрытия реальных действий, и естественный замедлитель реагирования, если оно целиком ручное.

Что сделать для защиты своей инфраструктуры

Не игнорируйте сигналы о сработавшей защите. Классическая ошибка, много раз отмеченная нашими экспертами по реагированию, случилась и в HF. Вы наверняка блокируете запуск ВПО, сканирование портов, записываете срабатывание WAF, обращение к ресурсам за пределами allowlist, неудачные попытки аутентификации. Все эти события в SIEM получают статус информационных и обычно игнорируются. В инциденте HF многочисленные попытки атаки SSRF за несколько дней были успешно заблокированы, но на них никто не обратил внимания. Как и упорные живые атакующие, агент пробовал снова и снова, пока у него не получилось. Создайте правило и процесс обработки сигналов о сработавшей защите, приоритет которого возрастает, если сигналов стало много.

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

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

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

Ограничивайте исходящий интернет-доступ (egress). Большинству серверов организации не нужен доступ к произвольным внешним хостам. Если применение политик default deny технически затруднено, можно попробовать упрощенную версию: принудительно разрешать доступ к DNS только через корпоративный DNS-сервер, а на нем заблокировать список популярных публичных сервисов, применяемых в качестве командных серверов и для эксфильтрации данных (Pastebin, OneDrive и так далее). Также возможно реализовать такую блокировку на базе NGFW.

Не храните в виде единого объекта и не выдавайте пользователям и приложениям большие наборы секретов. Даже при использовании менеджеров секретов атакующий может получить широкий доступ, если скомпрометированному аккаунту без нужды выдано много доступов. В инциденте HF один объект Kubernetes Secret содержал 136 ключей. Чем меньше секретов выдано — тем меньше будет последствий компрометации и тем проще провести ротацию ключей.

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

Изолируйте приложения от серверов метаданных. Большинство облачных серверов имеют службы, выдающие учетные данные и другую информацию по запросу, например EC2 Instance Metadata Service. Изолировав их от произвольных приложений (правилом межсетевого экрана или правилом IMDSv2), вы уничтожите самый короткий путь от компрометации одного приложения до компрометации всего аккаунта.

Проведите аудит identity, используемых серверами и приложениями. Именно там, а не в «человеческих» учетных записях чаще всего находятся сервисные аккаунты с широкими правами доступа, токены OAuth, ключи, работающие сразу в нескольких средах, в общем, все то, что называется overprivileged accounts.

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

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

Недавно в ходе инцидента, зафиксированного сервисом Kaspersky Managed Detection and Response, наши эксперты выявили попытку применения ScreenConnect для атаки. Это позволило детально изучить способ использования этого приложения злоумышленниками в масштабной кампании по распространению ВПО. На примере этой кампании мы покажем, как могут выглядеть атаки с использованием ScreenConnect, и расскажем, как от них защититься.

Как ScreenConnect попадает на компьютер жертвы

В исследованной нашими экспертами кампании злоумышленники подсовывали жертвам ScreenConnect вместе с бесплатным ПО, которое может быть использовано в рабочих целях. Они создали серию поддельных сайтов, на которых якобы распространялись весьма полезные программы, такие как OBS Studio, DS4Windows, DNS Jumper, Glary Utilities, Bandizip, Process Hacker и ряд других.

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

• легитимный подписанный Microsoft файл install.exe, переименованный под установщик выбранной программы (например, OBS-Studio-Installer.exe);
• вредоносная библиотека install.res.1033.dll;
• папка Assets, содержащая установщики ScreenConnect и программы, которую пользователь собирался скачать.

При запуске файла, замаскированного под установщик скачанной программы, методом DLL-sideloading загружается вредоносная библиотека, которая в тихом режиме, без перезагрузок запускает установку ScreenConnect, а также через стандартный установщик Windows устанавливает программу, которую пользователь изначально пытался установить.

Для привлечения жертв на свои фальшивые ресурсы злоумышленники использовали методы поисковой оптимизации (SEO). Благодаря этому их сайты появляются в числе первых результатов выдачи по запросам конкретного бесплатного ПО в популярных поисковых системах.

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

Подробный анализ IP-адресов и связанных с ними поддельных доменов доступен в более технической статье, опубликованной на Securelist. Там же можно найти и индикаторы компрометации.

Для чего злоумышленники использовали ScreenConnect

В этой конкретной кампании злоумышленники при помощи ScreenConnect создавали и запускали на компьютере жертвы вредоносные скрипты. Они служили для исключения нескольких дисков, директорий и процессов из проверки при помощи Windows Defender, отключения системного механизма контроля учетных записей пользователей UAC, а также устанавливали и запускали на устройстве жертвы вредоносное ПО — троян удаленного доступа AsyncRAT.

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

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

Как защитить инфраструктуру компании

Само по себе приложение ScreenConnect хотя и является легитимным, но все же представляет опасность для рабочей среды. Поэтому решения "Лаборатории Касперского" детектируют его как not-a-virus:HEUR:RemoteAdmin.MSIL.ConnectWise.gen.

Наши эксперты рекомендуют компаниям:

• внедрять средства контроля за установкой программ (списки разрешенного ПО, блокировку установки MSI-пакетов из непроверенных источников);
• отслеживать появление новых сервисов удаленного администрирования и задач планировщика;
• фильтровать трафик с рабочих устройств к неизвестным доменам и IP-адресам.

Как мы уже упоминали ранее, изначально кампания была обнаружена при помощи сервиса Kaspersky Managed Detection and Response.

Особенно привлекательны для атакующего ИИ-агенты, пишущие код, а также инструменты командной строки: Claude Code CLI, Gemini CLI, Codex CLI, Amazon Q CLI и их аналоги. Они умеют читать и изменять файлы, запускать команды оболочки, устанавливать пакеты и обращаться к внешним сервисам. Разработчики часто разрешают им действовать автоматически, чтобы не подтверждать каждую операцию вручную. Для атакующего такой агент становится «мультитулом», который уже имеет нужные привилегии, доступ к важным данным и одобрение от ИБ. Впрочем, атаке могут подвергаться и другие ИИ-агенты, например ассистенты финансового документооборота.

Чем опасны доверенные агенты

ИИ-агент отличается от другого ПО широкими правами доступа, разнообразием способов, которыми можно попросить его о нужных действиях, а также трудностями с детектированием аномального поведения агента. Установленные в организации средства защиты (EPP, EDR, XDR, SIEM) ищут вредоносные файлы, известные команды и подозрительные последовательности действий. Даже если конкретный зловред ранее не встречался, его может выдать поведение: массовый поиск документов, запуск PowerShell, обращение к хранилищам учетных данных или передача информации на внешний сервер со стороны неизвестного ПО вызовут шквал предупреждений в SOC.

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

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

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

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

Атака на Nx: кодинг-агент ищет пароли

Наиболее известный и массовый пример — компрометация npm-пакетов Nx в августе 2025 года, получившая название s1ngularity. Злоумышленники воспользовались уязвимым процессом GitHub Actions, похитили токен для публикации пакетов и выпустили троянизированные версии нескольких пакетов @nx, которые воровали у разработчиков секреты.

Вредоносный постинсталляционный сценарий (postinstall script) проверял, установлены ли на компьютере очередной жертвы Claude Code, Gemini CLI или Amazon Q CLI. Обнаруженному агенту передавалась инструкция найти криптовалютные кошельки, файлы .env, API-ключи и другие ценные данные. Агенты запускались с флагами автоматического подтверждения операций: --dangerously-skip-permissions, --yolo, --trust-all-tools.

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

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

Связь через… журналы ошибок

Исследование AgentJacking не является вредоносной атакой, но по сути отличается от нее только тем, что ее авторы не собирались красть секреты. Разработав технику атаки, исследователи не постеснялись проверить ее глобально — и получили ответные обращения от ИИ-агентов из более чем сотни реальных компаний, включая очень крупные.

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

Исследователи создали в Sentry собственный MCP-сервер, через который ИИ-агенты могут автоматически анализировать отчеты. Далее они отправляли ложное сообщение об ошибке с блоком, оформленным так же, как данные MCP-сервера Sentry. Внутри находилась косвенная промпт-инъекция — инструкция провести «дополнительную диагностику» с помощью команды такого вида: npx @controlled-validation-package --diagnose.

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

Примечательно, что, по словам авторов исследования, в Sentry признали проблему, но не приняли масштабных мер, а только заблокировали конкретный вариант вредоносного запроса, направляемого через MCP. Из скриншота в исследовании видно, что кто-то из сотрудников Sentry назвал защиту от атаки «технически невозможной» (technically not defensible).

Кража финансовых данных через MCP

Злоупотребление беспечными MCP-серверами, как в случае с Sentry, является только одним из способов атаки на этот протокол, который уже называют «USB для ИИ-агентов». Стандарт MCP появился всего год назад, был внедрен поспешно и изначально не был снабжен средствами безопасности. Поэтому атаки на него будут множиться, о чем недавно предупредили в Microsoft.

Угроза может таиться даже в самом описании MCP-инструмента, которым агент еще не воспользовался. Агент читает описание, чтобы решить, когда вызывать инструмент и какие данные ему передавать. Если поставщик MCP-сервера незаметно добавит туда инструкцию собрать дополнительные сведения, агент может выполнить ее как часть нормального рабочего процесса.

Microsoft описывает пример с финансовым агентом, который проверяет реквизиты поставщиков через внешний MCP-сервис. После изменения описания инструмента агент начинает прикладывать к ответу сведения о неоплаченных счетах. Пользователь видит обычный ответ, а конфиденциальные финансовые данные уходят владельцу сервера. Каждая отдельная операция выглядит разрешенной: агент действует с правами сотрудника, обращается к одобренному сервису и использует штатный интерфейс. Но утечка данных все равно происходит.

Из расплывчатой формулировки Microsoft до конца не ясно, является ли этот пример гипотетическим, или пост появился по мотивам расследования конкретной атаки. Но авторство Microsoft Incident Response намекает на последнее.

Промпт-инъекции уже стали массовыми

В 2026 году исследователи Unit 42 обнаружили на многих публичных веб-сайтах попытки скрытого размещения инструкций, предназначенных для ИИ-систем. Многие такие инструкции пытаются заставить модели раскрывать системные промпты, одобрять сайты и посты при проверке рекламных размещений, а также продвигать фишинговые страницы средствами SEO.

В Google при анализе данных Common Crawl также зафиксировали рост подобных материалов: с ноября 2025 по февраль 2026 года доля вредоносных инъекций увеличилась на 32%.

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

Как защищаться от атак через агентов

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

Необходимо:

• вести реестр агентов, MCP-серверов и доступных им инструментов. Ограничивать при помощи (allowlist) инструменты агента и пакеты для установки списком доверенных и одобренных в службе ИБ компонентов. В список должны входить конкретные версии пакетов;
• контролировать изменения версий MCP-инструментов и других зависимостей, проводить с обновлениями повторный анализ перед тем, как включать их в реестр одобренных;
• использовать принцип наименьших привилегий и выдавать агентам только те права, которые нужны им в рамках конкретной задачи на время выполнения этой задачи;
• требовать подтверждения человеком установки пакетов, запуска сценариев, отправки файлов и других рискованных действий (human-in-the loop);
• запускать агентов в изолированных средах с ограниченным доступом к компьютеру разработчика;
• блокировать опасные режимы автоматического подтверждения;
• ограничивать исходящие соединения и разрешать передачу данных только одобренным сервисам;
• хранить секреты в централизованных защищенных хранилищах, использовать короткоживущие токены и регулярно их ротировать;
• передавать в SIEM и XDR журналы промптов, вызовов инструментов, команд оболочки и сетевых обращений агента. Чтобы эти инструменты были эффективны, им необходим подробный контекст работы агента и специальные наборы правил, адаптированные к «агентским» конвейерам обработки данных.

Как устроена техника ConsentFix

В основе всех вариантов ClickFix лежит социальная инженерия. Злоумышленники просят пользователя выполнить некую внешне безобидную инструкцию, что в действительности приводит к компрометации устройства или учетной записи. В случае с ConsentFix инструкция нужна для того, чтобы заставить пользователя выдать согласие на доступ злоумышленника к учетной записи Microsoft 365.

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

1. Нажать кнопку «Подтвердить с помощью Microsoft» (Verify with Microsoft).
2. Войти в рабочую учетную запись (тут злоумышленники предупреждают, что может потребоваться многофакторная аутентификация).
3. После перенаправления на новую страницу дождаться, пока в адресной строке не появится строка, начинающаяся со слова localauth.
4. Перетащить значок информации ⓘ из адресной строки браузера в специально отведенное для этого окно.

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

К чему может привести компрометация сессии Microsoft 365

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

Даже базовые корпоративные подписки Microsoft 365 обычно предоставляют доступ к Outlook, Teams, OneDrive и SharePoint, тогда как более продвинутые тарифы могут включать дополнительные сервисы и инструменты администрирования.

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

Помимо этого, злоумышленники с большой вероятностью получат доступ к учетной записи Microsoft Teams, что даст им еще больший объем информации и еще более широкие возможности для разнообразных мошеннических схем. Не менее опасен и доступ к OneDrive и SharePoint: он открывает злоумышленникам возможности кражи корпоративных документов, загрузки вредоносного ПО в облачное хранилище, подмены существующих документов и так далее. Это создает возможности для развития атаки внутри корпоративной инфраструктуры.

Рецепт атаки в открытом доступе

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

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

Как обезопасить инфраструктуру организации

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

• Обязательно используйте надежное защитное решение на уровне почтового шлюза — так меньше вероятности, что злоумышленники смогут заманить ваших сотрудников на страницу, где реализован механизм ConsentFix.
• Проводите регулярные тренинги по кибербезопасности для сотрудников. Это поможет держать их в курсе самых актуальных техник атак с использованием социальной инженерии. В этом может помочь наша образовательная платформа Kaspersky Automated Security Awareness Platform.

Решая эту проблему устойчивого доступа, в APT ToddyCat, занимающейся преимущественно шпионажем, изобрели новую технику, которую эксперты «Лаборатории Касперского» при препарировании очередной атаки назвали Shadow Token via Remote Debug (STRD). Эта техника позволяет злоумышленникам надежно подключаться к почтовому ящику и другим ресурсам жертвы в Google Workspace. Причем при небольшой доработке этот подход может позволить атаковать и другие сервисы, дающие сторонним приложениям доступ через авторизацию по протоколу OAuth 2.0.

Общий принцип атаки с использованием STRD

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

После запуска вредоносного ПО злоумышленник проводит атаку по технике STRD и подключает дистанционный сервис атакующих к почтовому ящику жертвы при помощи протокола OAuth 2.0. Пользователь ничего не видит и ничего не нажимает, а для корпоративного сервиса (в изученной атаке это был Google Workspace) дело выглядит так, как будто пользователь решил подключить к своему аккаунту стороннее приложение для чтения почты или резервного копирования.

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

В чем суть Shadow Token via Remote Debug

Центральным звеном атаки является подключение к сервисам Google Workspace по OAuth 2.0. Это легитимный сценарий, используемый всякий раз, когда к данным календаря, почты или файлам на Google Drive пытается получить доступ сторонний сервис. Хотите, чтобы в Zoom отображались встречи из календаря и автоматически создавались ссылки на созвоны? Выдайте разрешение сервису Zoom обращаться к Google. Подключаете сторонний клиент почты или календаря? Снова нужно выдать разрешение. В процессе этого подключения сервис, которому нужен доступ, открывает новое окно браузера. В этом окне Google Workspace сначала запрашивает, для какого из аккаунтов пользователя нужно провести операцию. После выбора аккаунта на следующем экране нужно прочитать, какие именно права запрашивает стороннее приложение и согласиться с их выдачей либо отказаться. Чтобы этот сценарий сработал таким образом, пользователь должен заранее войти в браузере в сервисы Google — что, впрочем, абсолютно типично для организаций, использующих Google Workspace. Если пользователь не вошел в Google заранее, в цепочке появляются дополнительные шаги по вводу пароля и многофакторной аутентификации.

«Двухходовку» для случая, когда пользователь уже вошел в Google, и пытается провернуть вредоносный инструмент Umbrij, созданный злоумышленниками из ToddyCat. Первым делом вредоносное ПО определяет, какие браузеры есть в системе и какая папка в каждом из них хранит рабочий профиль пользователя. Атакующих интересуют Chrome и Edge, которые наиболее вероятно используются в организации как «рабочие лошадки».

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

Самое важное: браузер запускается в специальном отладочном режиме, обычно используемом в веб-разработке. Окно браузера и интерфейс на экране вообще не появляются (режим headless), зато браузером можно управлять через отладочный порт по протоколу DevTools, подавая команды и считывая состояние экрана. Для проведения этих действий Umbrij использует легитимную библиотеку Puppeteer.

Убедившись, что «отладочный» браузер успешно запущен, Umbrij открывает в нем легитимный экран OAuth-авторизации Google Workspace для нового приложения. Запрос в Google искусственно сформирован таким образом, чтобы отключить дополнительные проверки безопасности и запросить максимум прав доступа. В качестве кода приложения, которое якобы запрашивает все эти права, указывается одно из двух легитимных приложений: Google Workspace Migration for Microsoft Outlook (GWMMO) или Google Workspace Sync for Microsoft Outlook (GWSMO).

Когда Google отобразит нужное окно в невидимом браузере, Umbrij с помощью инструментов отладки кликает на имя рабочей учетной записи и нажимает кнопки ОК/Разрешить, в результате чего Google генерирует код авторизации для приложения. Этот код Umbrij сохраняет и в дальнейшем пересылает на сервер атакующих. Затем, уже в своей инфраструктуре, а не на компьютере жертвы, злоумышленники обменивают полученный код авторизации на токен доступа OAuth. Это единственное, что нужно злоумышленникам для продолжительного и полноценного доступа к почтовому ящику.

Как защищаться от похищения токенов OAuth

В случае если учетная запись Google Workspace скомпрометирована, меры по реагированию должны включать следующие шаги (после сбора необходимых журналов и других данных для расследования инцидента):

• сброс пароля атакованного пользователя;
• принудительное завершение всех веб-сессий пользователя;
• отзыв OAuth-токенов, разрешений сторонних приложений;
• проверка и удаление доступа через устаревший механизм App Passwords

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

Как защищаться от эксплуатации техники Shadow Token via Remote Debug

Пользователи продуктов «Лаборатории Касперского» защищены от атак с помощью инструмента Umbrij. Несмотря на это, службам ИБ стоит проактивно внедрить политику, которая запретит обычным пользователям запускать браузер в отладочном режиме, — эта функция нужна исключительно разработчикам сайтов и веб-приложений. Для этого можно использовать групповую политику DeveloperToolsAvailability (версия для Chrome, для Edge).

Дополнительно настройте мониторинг в SIEM/XDR, чтобы отслеживать запуск браузера с отладочным портом. Это событие само по себе служит хорошим индикатором данной атаки.