Інтегровані ІІ‑асистенти на кшталт Microsoft Copilot перетворюються на повноцінну поверхню атаки. Дослідники компанії Varonis описали уразливість, яку вони назвали Reprompt і яка дозволяла зловмиснику перехопити активну сесію Copilot, отримати доступ до конфіденційних даних користувача та організувати їхню ексфільтрацію фактично в один клік по спеціально сформованому посиланню.
Чому уразливість Microsoft Copilot є критичною для безпеки даних
Copilot глибоко вбудований в екосистему Microsoft: він доступний у Windows, браузері Edge та низці сервісів Microsoft як ІІ‑асистент. Залежно від налаштувань конфіденційності, Copilot може мати доступ до історії запитів, листування, файлів у хмарі, робочих документів та інших персональних даних. Це робить його привабливою ціллю для prompt injection‑атак і сценаріїв перехоплення сесій.
Varonis з’ясували, що веб‑версія Copilot приймає інструкції через параметр q у URL. Якщо в цей параметр підставити заздалегідь підготовлений промпт, асистент автоматично виконує закладені в ньому команди одразу після завантаження сторінки — фактично від імені вже автентифікованого користувача, без будь‑яких додаткових дій з його боку.
Механізм атаки Reprompt: фішингове посилання та прихований канал ексфільтрації
Базовий сценарій атаки Reprompt починався з фішингового листа. Користувачу надсилали посилання, яке виглядало як легітимний URL Microsoft Copilot або пов’язаного сервісу. Домен і шлях у посиланні виглядали довірено, а шкідливі інструкції ховалися в параметрі q, де містився складний промпт для Copilot.
Після переходу за таким посиланням відбувалося кілька ключових подій: по‑перше, Copilot автоматично обробляв промпт із параметра q, не вимагаючи введення тексту чи підтвердження дій користувачем. По‑друге, закладені інструкції ініціювали подальшу взаємодію Copilot із сервером зловмисника, перетворюючи це сполучення на стійкий канал ексфільтрації даних. По‑третє, атака опиралася на вже активну сесію облікового запису Microsoft; за спостереженнями Varonis, така сесія залишалася валідною певний час навіть після закриття вкладки з Copilot, що створювало вікно можливостей для подальшого витоку.
Критичною особливістю Reprompt було те, що наступні інструкції Copilot отримував уже не з початкового URL, а безпосередньо з сервера зловмисника. Клієнтські засоби контролю трафіку бачать лише стартовий промпт і не фіксують подальший обмін даними, через що виявити атаку традиційними засобами було складно.
Обхід захисту Copilot за допомогою «подвійних викликів функцій»
Microsoft реалізувала базові механізми фільтрації, які блокують повернення чутливої інформації під час першого веб‑запиту Copilot. Однак дослідники Varonis продемонстрували, що уразливість Reprompt дає змогу обійти ці обмеження завдяки техніці «double function calling», або «подвійного виклику функцій».
Суть полягає в тому, що шкідливий промпт змушує Copilot виконувати одну й ту саму внутрішню операцію двічі, порівнювати результати та відображати «найкращу» відповідь. У тестовому прикладі дослідники розмістили на доступному Copilot ресурсі приховану секретну рядок і вбудували в параметр q інструкції, які змушували асистента діяти за такою схемою.
У результаті при першому зверненні вбудовані засоби захисту Copilot коректно заблокували повернення секрету. Однак повторний виклик, ініційований самим промптом, уже призвів до розкриття конфіденційної інформації. Таким чином, техніка подвійного виклику показала, що навіть просунуті фільтри на боці постачальника ІІ можуть бути обійдені складними prompt injection‑атаками.
Які версії Microsoft Copilot були вразливими та як Microsoft закрила проблему
За даними Varonis, уразливість Reprompt стосувалася лише Copilot Personal, орієнтованого на домашніх та індивідуальних користувачів. Корпоративний Microsoft 365 Copilot не був підданий ризику завдяки додатковим рівням захисту: Microsoft Purview для аудиту дій, DLP‑політикам (Data Loss Prevention) на рівні орендаря та суворішим адміністративним обмеженням доступу до даних.
Varonis повідомила Microsoft про уразливість 31 серпня попереднього року. У січні 2026 року компанія випустила оновлення безпеки, яке усуває Reprompt. На момент оприлюднення дослідження не було зафіксовано випадків експлуатації уразливості «в дикій природі», однак користувачам наполегливо рекомендується встановити всі актуальні оновлення Windows та компонентів Copilot.
Інтегровані ІІ‑асистенти як нова поверхня атаки
Ситуація з Reprompt демонструє системний тренд: ІІ‑асистенти, глибоко інтегровані в ОС та хмарні сервіси, перетворюються на важливий елемент моделі загроз. Вони оперують широким контекстом — від історії листування до внутрішніх документів організації, — а отже, стають високовартісною ціллю для атак на кшталт prompt injection, фішингу та викрадення сесій.
За оцінками галузевих звітів з кібербезпеки, значна частина успішних інцидентів (понад 70%) стартує з фішингового вектора. У випадку з Microsoft Copilot цей ризик посилюється тим, що один клік по «офіційно» виглядному посиланню може непомітно активувати приховані інструкції для ІІ‑моделі, які важко відстежити традиційними засобами захисту кінцевих точок.
Практичні рекомендації для користувачів та організацій
Для індивідуальних користувачів ключовими заходами залишаються: своєчасне встановлення оновлень Windows і Copilot, підвищена увага до посилань у листах та месенджерах (навіть якщо вони ведуть на знайомі домени Microsoft), обмеження прав доступу додатків до даних і регулярний перегляд налаштувань конфіденційності в екосистемі Microsoft.
Організаціям варто доповнити це централізованими DLP‑політиками, використанням Microsoft Purview або аналогічних рішень для аудиту дій ІІ‑асистентів, а також тестуванням внутрішніх сервісів на стійкість до prompt injection‑атак. Доцільною стає й розробка внутрішніх рекомендацій щодо безпечного використання Copilot та інших ІІ‑інструментів, зокрема обмеження типів інформації, яку дозволено обробляти через такі асистенти.
Reprompt наочно показує, що безпека ІІ‑асистентів повинна розглядатися на рівні з безпекою електронної пошти, браузера чи офісних застосунків. Чим раніше користувачі та компанії адаптують свої стратегії кіберзахисту до реалій ІІ‑екосистеми, тим нижчими будуть ризики витоку конфіденційних даних та руйнівних інцидентів у майбутньому.
