LLM-фішинг: як кіберзлочинці використовують ШІ для нових атак

Фішинг довгий час асоціювався з підробними листами та очевидно фальшивими сторінками входу. Але нові дослідження показують: ця модель стрімко застаріває. Про це розповіло видання TechRound, посилаючись на аналітику Unit 42 — команди кіберрозвідки Palo Alto Networks.

Йдеться про принципово інший підхід до атак. Замість того щоб надсилати жертві готовий шкідливий код, зловмисники завантажують у браузер сторінку, яка на перший погляд виглядає цілком безпечною. У ній немає ані фішингових форм, ані підозрілих скриптів. Шкідливий компонент з’являється вже після завантаження сторінки — і генерується безпосередньо в браузері жертви.

Як LLM перетворюють «чисту» сторінку на фішингову

Механіка атаки побудована навколо великих мовних моделей. Коли сторінка відкривається, вона надсилає запит до легітимного сервісу LLM через браузерний API. У запиті міститься опис того, яку функціональність має виконувати код: наприклад, зімітувати сторінку входу відомого бренду або обробити введені облікові дані.

У відповідь LLM повертає JavaScript-код у вигляді тексту. Уже в браузері цей текст збирається, компілюється та запускається — і сторінка миттєво перетворюється на фішингову, причому спеціально під конкретного користувача. До моменту виконання коду його фізично не існує, що робить попередній аналіз сторінки практично неможливим.

Чому традиційні системи захисту цього не бачать

Дослідники Unit 42 наголошують: ключова проблема полягає у «runtime assembly» — збиранні коду під час виконання. За їхніми даними, вже 36% шкідливих вебсторінок, які щодня фіксує Palo Alto Networks, використовують цю техніку.

Підписуйтеся на наші соцмережі

У випадку з LLM ефект посилюється. Кожен запит до мовної моделі генерує нову, унікальну версію коду з іншим формулюванням і структурою, але з тим самим результатом. Це робить марними блоклисти й сигнатурні методи: статичних зразків просто не існує.

Додатковий фактор — джерело трафіку. Код надходить із доменів легітимних LLM‑сервісів, доступ до яких у багатьох компаніях дозволений за замовчуванням. Для мережевих фільтрів такий трафік виглядає як звичайне корпоративне використання ШІ.

Доказ на практиці: експеримент Unit 42

Щоб перевірити життєздатність підходу, команда Unit 42 створила proof of concept на базі відомого фішингового фреймворку LogoKit. У класичній версії він використовує статичний JavaScript для персоналізації сторінок і викрадення облікових даних. У тесті цей код замінили на скрипти, які генерувалися LLM у реальному часі.

Сторінка робила прямі запити до популярного LLM‑сервісу, отримувала код для імітації брендованих форм входу та надсилала зібрані дані на зовнішній сервер. Важлива деталь: прямі запити з очевидно шкідливими інструкціями часто блокувалися. Натомість нейтральні формулювання — наприклад, прохання створити функцію для передавання даних — успішно проходили фільтри.

Кожна відповідь моделі відрізнялася від попередньої. Невизначеність (non‑deterministic output) LLM забезпечувала постійну мутацію коду, який при цьому в більшості тестів працював без помилок.

Новий масштаб і нові ризики

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

Фактично браузер стає головним полем бою. Саме там відбувається трансформація безпечного тексту в шкідливий код, і саме там традиційні засоби захисту виявляються сліпими.

Що реально може спрацювати

Unit 42 робить акцент на захисті під час виконання коду. Поведінковий аналіз у браузері дозволяє виявляти підозрілі дії — перехоплення облікових даних, спроби ексфільтрації — у момент їх здійснення, а не до цього.

Додатковий рівень — контроль доступу до несанкціонованих LLM‑сервісів у корпоративних середовищах. Це не панацея, але воно перекриває один із найпростіших каналів доставки шкідливого коду. Окремо дослідники зазначають потребу в жорсткіших guardrails усередині самих LLM‑платформ: експеримент показав, що чинні механізми фільтрації запитів легко обходяться дрібними змінами формулювань.

Що це означає для компаній, CISOs та IT-директорів

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

Для CISOs критичним стає фактор довіри до легітимних LLM-сервісів. Запити до мовних моделей використовуються як канал доставки шкідливого коду й маскуються під звичайне корпоративне використання ШІ. Це вимагає перегляду політик доступу до LLM, але саме по собі блокування сервісів не вирішує проблему.

Для IT-директорів практичний висновок зводиться до одного: ефективний захист можливий лише на рівні поведінки. Unit 42 прямо вказує, що виявлення перехоплення облікових даних і спроб ексфільтрації під час виконання коду є ключовим способом протидії атакам, у яких LLM забезпечують постійну мутацію фішингових сторінок.

У підсумку LLM-фішинг слід розглядати не як окрему техніку, а як системний зсув: безпека більше не визначається походженням коду чи доменом, з якого він надходить, а виключно тим, що цей код робить у браузері користувача.