Новий підхід змушує агент пентесту на базі LLM доводити факт зламу, а не просто заявляти про нього, використовуючи одноразові нонси (nonces) типу «запит-відповідь», що усувають хибнопозитивні результати. Ця техніка, продемонстрована у фреймворку HALO, перетворює «схоже, ми отримали shell» на «ми дійсно маємо shell».

Чому хибнопозитивні результати зламу мають значення

Автоматизовані рушії експлуатації, побудовані на великих мовних моделях, можуть видавати десятки «успішних» компрометацій портів за один запуск. Багато сервісів відображають такі рядки, як «uid=0», у банерах, і спеціально підготовлена ціль може імітувати ці виводи, навіть не виконуючи код зловмисника. Коли агент довіряє таким відповідям, кожне наступне рішення — чи здійснювати півотинг (pivot), викрадати дані чи переміщатися латерально — ґрунтується на брехні. Команди безпеки витрачають години на переслідування фантомних точок доступу, а фахівці з реагування на інциденти можуть неправильно розставити пріоритети щодо реальних загроз.

Перетворення заяви на доказ

Це рішення запозичено з класичних методів автентифікації. Перед запуском експлойту система зловмисника генерує унікальний токен, або nonce, і вбудовує його в корисне навантаження (payload). Експлойт має повернути саме цей токен, щоб контролер прийняв результат як справжній злам. Підробка банера не зможе вгадати nonce; вона повинна виконати код зловмисника, щоб вставити токен у відповідь. Якщо у повернутих даних немає відповідного nonce, спроба відкидається як хибнопозитивна.

Ця зміна змінює модель перевірки з «вивід виглядає правильно» на «вивід доводить виконання». Це усуває «упередження оптимізму», яке притаманне автономним інструментам наступу.

Побудова надійних ланок доставки

Доставка корисного навантаження до цілі все одно потребує надійного ланцюга доставки. HALO класифікує три поширені шляхи:

  • Reverse shells — скомпрометований хост ініціює з'єднання назад із лісенером (listener), який контролює зловмисник. Корисно, коли вхідний трафік заблоковано.
  • Bind shells — зловмисник підключається безпосередньо до сервісу, що очікує на підключення на цілі. Працює, коли фільтри вихідного трафіку не суворі.
  • Blind callbacks — односторонній сигнал (наприклад, DNS-запит), який підтверджує виконання у суворо обмежених середовищах, де неможливо відкрити прямий канал.

Кожен крок у цьому ланцюгу має зберігати nonce, інакше етап доведення не спрацює на наступних стадіях.

Забезпечення автономності експлойтів

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

Очищення слідів розробки

Під час підготовки до публічного релізу автор виявив реальні IP-адреси, що залишилися в історії Git. Чиста робоча гілка не стирає ці записи; Git зберігає кожен коміт. Автор переписав репозиторій в один чистий коміт і замінив виточені адреси діапазонами лише для документації, визначеними RFC 5737 (наприклад, 192.0.2.0/24). Це запобігає випадковому розкриттю продуктивної інфраструктури під час поширення інструменту.

Практичні правила для інструментів безпеки

  • Використовуйте лише документаційні діапазони IP-адрес у кожному тестовому наборі.
  • Видаляйте секрети та файли конфігурації з початкового коміту.
  • Застосовуйте nonce типу «запит-відповідь» для перевірки будь-якого заявленого зламу.
  • Перевіряйте саме той файл, який буде доставлений, а не просто схожий скрипт.

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