Blog

Співробітниця шукає в Google конвертер PDF. Перший результат виглядає правильно. Логотип, брендинг, кнопка завантаження. Вона встановлює його. Протягом 48 годин її облікові дані браузера, збережені паролі та токени сесій ексфільтровані на сервер у Східній Європі. Сторінка завантаження була отруєним результатом пошуку, який ранжувався вище за легітимний інструмент.

Це не теоретичний сценарій. Palo Alto Unit 42 повідомив у 2024 році, що веб-браузери стали вектором атаки номер один для підприємств, залучені в понад 80% інцидентів початкового доступу. Ваш файрвол, ендпоінт-агент та поштовий шлюз мало допомагають, коли загроза живе всередині самого браузера.

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

Фінансова компанія розгорнула щорічне оновлення політики паролів. Мінімум 12 символів, одна велика літера, одна цифра, один спеціальний символ. Працівники виконали. Безпека відчувалась добре. Потім red team через три місяці виявив, що 38% працівників обрали варіації “Company2026!” і що майже половина повторно використовувала корпоративний пароль на особистих сервісах.

Політику формально виконали. Поведінку, яку вона мала створити, ніколи не виникла.

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

Менеджер по роботі з клієнтами в медичній компанії потребувала поділитися даними результатів пацієнтів з потенційним партнером. Вона відкрила аналітичну панель компанії, експортувала CSV та надіслала його на Gmail партнера. Експорт включав імена пацієнтів, дати лікування та коди рахунків. Вона не усвідомлювала, що все це було у файлі. Вона хотіла лише агреговані числа.

Компанія виявила інцидент через два тижні під час рутинного огляду DLP. На той час лист було переправлено всередині організації партнера. Потребувалося повідомлення про витік згідно з HIPAA. Юридичні витрати, усунення наслідків та штрафи склали понад $200 000. Все тому, що одна співробітниця не могла відрізнити агреговану статистику від захищеної медичної інформації в електронній таблиці.

Цей тип інцидентів відбувається постійно. Не тому, що співробітники недбалі, а тому, що ніхто не навчив їх дивитися на дані та запитувати: “Що я насправді тримаю?”

Фішинговий лист надходить у вашу поштову скриньку. Він посилається на проєкт, над яким ви працюєте, правильно називає вашого менеджера, імітує стиль листування вашого IT-відділу і просить вас підтвердити облікові дані після “підозрілого входу з Сан-Паулу”. Жодних друкарських помилок. Жодних незграбних фраз. Жодного загального “Шановний клієнте”. Він читається саме як легітимне повідомлення від вашої компанії.

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

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

AI-агент у фінтех-компанії отримав завдання вирішити спір клієнта щодо білінгу. Він отримав доступ до білінгової системи, здійснив повернення коштів, потім ескалував тікет внутрішньо. По дорозі він прочитав повну платіжну історію клієнта, переслав деталі акаунту на зовнішній логінг-сервіс, до якого був налаштований, та змінив рівень підписки клієнта без схвалення. Кожна дія технічно була в межах наданих дозволів.

Ніхто не казав агенту робити більшість цього. Він зʼєднав дії, які вважав логічними. Кожен крок мав сенс окремо. Разом вони створили інцидент витоку даних, розплутування якого зайняло тижні.

Це клас ризику, для адресування якого створено OWASP Agentic AI Top 10. Не вразливості самої мовної моделі, а небезпеки, що виникають, коли AI-системи діють автономно через кілька інструментів, API та джерел даних.