Закриті форуми, тіньові маркетплейси та приватні чати в даркнеті давно стали основним майданчиком для торгівлі вкраденими доступами, базами даних і інструментами атак. Google робить спробу радикально змінити підхід до такого моніторингу, запустивши новий сервіс Google Threat Intelligence на базі Gemini, який автоматично відстежує даркнет і виділяє загрози, релевантні конкретній організації. Рішення вже доступне клієнтам у форматі публічного прев’ю.
Моніторинг даркнету Google Threat Intelligence: як працює ІІ на базі Gemini
За даними Google, ІІ‑агенти Gemini щоденно аналізують від 8 до 10 мільйонів публікацій на даркнет‑ресурсах: форумах, маркетплейсах, тіньових чатах і сайтах із закритим доступом. Завдання системи не обмежується простим пошуком згадок бренду — акцент робиться на виявленні значущих індикаторів кіберзагроз.
У фокус моніторингу потрапляють, зокрема:
— активність брокерів початкового доступу (Initial Access Brokers), які продають зламані облікові записи, VPN‑доступи та RDP‑сесії;
— витоки конфіденційних даних, включно з базами клієнтів, обліковими записами співробітників і технічними логінами;
— інсайдерські пропозиції та спроби продажу внутрішньої інформації;
— згадки про плановані атаки, нові експлойти, фішингові кампанії та інструменти зловмисників.
За словами продакт‑менеджера Google Threat Intelligence Брендона Вуда, внутрішні тести показують до 98% точності аналізу. Це потенційно означає істотне зменшення «шуму» порівняно з класичними підходами, однак у реальних умовах будь‑яку ІІ‑модель необхідно додатково валідувати та налаштовувати під конкретний профіль ризику організації.
Чому класичний моніторинг даркнету більше не задовольняє потреби SOC
Більшість традиційних систем моніторингу даркнету спираються на пошук за ключовими словами та регулярними виразами. Такий підхід погано враховує контекст і специфіку жаргону кіберзлочинців: збіг по фразі зовсім не гарантує, що мова йде саме про конкретну компанію чи її активи.
У результаті відсоток хибнопозитивних спрацювань може сягати 80–90%. Для центрів моніторингу безпеки (SOC) це перетворюється на класичну проблему alert fatigue — «втоми від інцидентів»: аналітики витрачають час на розбір нерелевантних алертів і підвищують ризик пропустити дійсно критичну подію.
Підхід Gemini зміщує акцент від простих збігів рядків до семантичного розуміння змісту й контексту повідомлень. Це особливо важливо для даркнету, де активно використовуються сленг, завуальовані формулювання, шифри та евфемізми, покликані обійти класичні фільтри та правила.
Формування профілю організації: OSINT як основа таргетованого Threat Intelligence
Під час першого запуску модуля моніторингу клієнт підтверджує базову інформацію про свою організацію. На основі цих даних система за кілька хвилин будує деталізований профіль компанії, використовуючи виключно відкриті джерела (OSINT).
До такого профілю зазвичай входять:
— основні бізнес‑напрями, галузь та географія присутності;
— технологічний стек, ключові платформи та сервіси;
— VIP‑персони (керівники, публічні спікери, акціонери);
— бренди, торгові марки, дочірні структури та доменні зони.
Кожен елемент супроводжується посиланнями на джерела, що дозволяє командам безпеки верифікувати та скоригувати дані. Надалі саме цей профіль використовується як матриця зіставлення для всієї інформації, що надходить із даркнету.
Векторний аналіз та пріоритизація загроз для бізнесу
Після формування профілю Gemini автоматично генерує попередження про потенційні загрози за останні сім днів. Зібрані дані маркуються ІІ‑агентами та проходять векторний аналіз: текст перетворюється у багатовимірні вектори ознак, що дозволяє порівнювати зміст повідомлень із цифровим «відбитком» організації.
Кожне знайдене згадування отримує пріоритет за ступенем релевантності — від прямого згадування назви компанії, її доменів або систем до непрямих збігів за галуззю, розміром бізнесу чи регіоном. Чим точніше збіг контексту, тим вищим буде пріоритет алерта.
Показовий приклад, який наводить Google: у даркнеті з’являється оголошення про продаж доступу до великого північноамериканського банку з більш ніж 50 000 співробітників і активами близько 50 млрд доларів. Навіть якщо назва банку не вказана, система звіряє ці атрибути з профілем клієнта. У разі збігу ключових параметрів активність маркується як критична загроза.
Додатково сервіс спирається на базу знань аналітиків Google Threat Intelligence Group, які відстежують діяльність 627 угруповань кіберзлочинців. Це дозволяє пов’язувати окремі інциденти з відомими кластерами загроз і точніше оцінювати потенційний вплив на бізнес.
ІІ‑агенти Google Security Operations: крок до частково автономного SOC
Паралельно Google презентувала (також у форматі прев’ю) ІІ‑агентів для Google Security Operations, покликаних автоматизувати обробку та реагування на виявлені загрози.
Такий агент може самостійно:
— аналізувати вхідні попередження з різних джерел;
— агрегувати артефакти та докази (логи, телеметрію, мережеві події);
— формувати висновок щодо природи інциденту та його критичності;
— у людиночитаному форматі пояснювати логіку своїх рішень.
Завдяки підтримці Model Context Protocol (MCP) клієнти можуть створювати власних ІІ‑агентів безпеки, які враховують специфіку інфраструктури, політик доступу та бізнес‑процесів. Підтримка віддаленого MCP‑сервера вже доступна в статусі GA, що відкриває шлях до глибокої інтеграції з наявними SIEM/SOAR‑процесами.
Для організацій це означає можливість поступового переходу від напівавтоматичного реагування до більш автономних сценаріїв — за умови збереження людського контролю, незалежного перегляду критичних рішень і чітко пропрацьованих процедур ескалації.
Поєднання ІІ‑моніторингу даркнету на базі Gemini та ІІ‑агентів Google Security Operations демонструє напрямок розвитку ринку: машини беруть на себе рутинний аналіз і відсікання «шуму», а фахівці зосереджуються на прийнятті рішень, моделюванні загроз і розслідуванні складних інцидентів. Організаціям варто вже зараз переоцінити свої процеси Threat Intelligence та реагування: де можна застосувати ІІ‑інструменти для зменшення кількості нерелевантних алертів, як навчити SOC взаємодіяти з ІІ‑агентами та яким чином інтегрувати нові сервіси у поточну архітектуру безпеки. Ті, хто зробить це раніше, матимуть вищі шанси вчасно виявити витоки, активність брокерів початкового доступу та підготовку таргетованих атак ще на стадії їх обговорення в даркнеті, а не вже після реалізації повномасштабного інциденту.
