ZeroDay | Кибербезопасность

NAT, PAT и Proxy: в чём разница?

👋 Приветствую в мире цифровой безопасности!

Все три механизма могут скрывать внутренний адрес клиента, но делают это по-разному.

⏺NAT меняет IP-адрес в заголовке пакета. Например, внутренний хост 192.168.1.10 выходит в Интернет через публичный 203.0.113.5:

192.168.1.10 → NAT → 203.0.113.5 → Internet

NAT меняет адреса и отслеживает соответствие соединений. Сам трафик при этом продолжает идти между клиентом и сервером.

⏺PAT использует ещё и номера портов. Поэтому несколько внутренних машин могут одновременно выходить через один публичный IP:

192.168.1.10:49152 → 203.0.113.5:40001
192.168.1.11:49153 → 203.0.113.5:40002

По номеру порта роутер понимает, какому внутреннему соединению вернуть ответ.

⏺Proxy работает иначе. Он принимает соединение от клиента и сам устанавливает отдельное соединение с сервером:

Client → Proxy → Server

Поэтому proxy может разбирать HTTP-запросы, применять фильтры, вести логи или терминировать TLS при включённом TLS inspection.

⏺В Wireshark это особенно заметно при сравнении TCP-сессий. При NAT клиент и сервер всё ещё находятся в одном TCP-соединении, только адрес источника изменён. У proxy появляются две отдельные сессии:

Client ↔ Proxy
Proxy ↔ Server

У них могут отличаться TCP-параметры, временные характеристики и даже версии протоколов.

⏺Поэтому NAT сам по себе не является firewall, PAT не делает трафик анонимным, а proxy может стать полноценной точкой контроля трафика. Запомнить можно так: NAT меняет адрес, PAT меняет адрес и порт, Proxy принимает одно соединение и создаёт другое.

ZeroDay | Белый Хакер | #NAT #PAT

Ну что, поехали! Пятый сезон CyberCamp стартовал!

И у нас сразу три новости:

📣 Открыта регистрация на CampGO — командные киберучения пройдут с 24 октября по 6 ноября в три тура на выбывание. Собирай команду из 3–6 человек и готовься к 10+ заданиям по разным направлениям кибербеза. Заявки принимаем до 15 октября.

📣 Запустили новую платформу CyberCamp. Теперь здесь будут жить мероприятия сезона, доклады, практика и другие активности. Постепенно платформа будет расти и превращаться в полноценную площадку для комьюнити

📣 CyberCamp теперь целый сезон. Впереди CampGO, встречи, практика, сайбы и мерч, а в феврале — большой онлайн-кэмп.

Тема пятого сезона — антихрупкость-ИТ: как переживать кибератаки, восстанавливаться после них и становиться крепче к следующему раунду.

Регистрируйся на платформе, собирай команду для CampGO и залетай в пятый сезон. Будет интересно!

Zeroization: как правильно уничтожать секреты в памяти

👋 Приветствую в мире цифровой безопасности!

⏺Zeroization - это практика безопасного удаления чувствительных данных из памяти после использования. Ключи, пароли, токены и другие секреты не должны оставаться в RAM дольше необходимого.

⏺Проблема в том, что обычного освобождения памяти недостаточно.

Например:

char secret[32] = "super-secret-key";

use_secret(secret);

memset(secret, 0, sizeof(secret));

На -O2 компилятор может увидеть, что результат memset() больше нигде не используется, и удалить операцию очистки. Проверить можно так:

gcc -O2 test.c -o test
objdump -d ./test | less

⏺Для секретов используют функции, специально предназначенные для очистки памяти:

explicit_bzero(secret, sizeof(secret));

На Windows аналогичный вариант:

SecureZeroMemory(secret, sizeof(secret));

⏺Но есть ещё одна проблема: секрет может существовать сразу в нескольких местах. Например, посмотреть память процесса можно через /proc:

grep -a "super-secret-key" /proc/$PID/mem

На практике доступ к /proc/$PID/mem ограничен правами и настройками ядра, поэтому для анализа собственного процесса чаще используют отладчик или дамп.
Например:

gdb -p $PID

А затем можно посмотреть отображённые области памяти:

info proc mappings

⏺Ещё один источник утечек - core dump. Проверить его настройку:

ulimit -c
cat /proc/sys/kernel/core_pattern

Если процесс упадёт, содержимое его памяти потенциально может оказаться в дампе. Поэтому для сервисов, работающих с ключами и токенами, важно отдельно контролировать создание и хранение core dump.

⏺И не стоит забывать про swap. Проверить, используется ли он:

swapon --show

Сам факт наличия swap не означает, что конкретный секрет туда попал, но чувствительные приложения учитывают этот риск и используют механизмы вроде mlock() для страниц с ключами.

⏺Главный нюанс zeroization в том, что недостаточно стереть один буфер. Секрет мог скопироваться при передаче между функциями, попасть в другой объект или остаться в памяти после временного преобразования.

⏺Поэтому хороший подход выглядит так: минимальное время жизни секрета → минимум копий → контролируемое хранение → явная очистка → контроль дампов и swap. Zeroization - это не просто memset(secret, 0, ...). Это управление всем жизненным циклом секрета в памяти.

ZeroDay | Белый Хакер | #zeroday

Анализ скрытых MITM в Wireshark: часть 2

👋 Приветствую в мире цифровой безопасности!

В прошлой части смотрели на сертификаты и сетевые параметры. Теперь копнём глубже: разберём признаки, которые по отдельности ещё ничего не доказывают, но вместе могут вывести на след прокси или перехватывающего узла.

⏺Начнём с TLS Alert. Если посредник не может нормально обработать соединение, он может оборвать сессию прямо во время handshake:

tls.alert_message

Смотрим, какие соединения заканчиваются Alert, и сравниваем их с успешными сессиями того же клиента. Один случай - ещё не сенсация. Повторяющийся сценарий - уже повод насторожиться.

⏺Следующий фильтр ловит неожиданные сбросы TCP:

tcp.flags.reset == 1

Особенно интересно, если RST прилетает сразу после Client Hello или Server Hello. Сам по себе сброс не означает MITM, но если он регулярно появляется в одном и том же месте handshake, картина становится подозрительной.

⏺Теперь проверим, куда клиент вообще пытается установить TLS-соединение:

tls.handshake.extensions_server_name

Сверяем SNI, DNS-ответ и фактический IP назначения. Например, клиент запрашивает api.example.com, DNS отдаёт один адрес, а соединение снова и снова уходит на другой. Это может быть CDN, балансировщик или корпоративная инфраструктура, но такое расхождение точно стоит проверить.

⏺Отдельно смотрим ALPN:

tls.handshake.extensions_alpn_str

Сравниваем несколько соединений одного клиента. Если обычно используется h2, а часть сессий внезапно переключается на http/1.1, возможны промежуточный прокси, TLS inspection или другая прослойка между клиентом и сервером.

⏺Ищем повторные handshake через Client Hello:

tls.handshake.type == 1

Добавляем к просмотру:

tcp.stream

Теперь сравниваем потоки. Сценарий Client Hello → несколько пакетов → FIN/RST → новый Client Hello, который повторяется снова и снова, выглядит гораздо интереснее, чем единичный разрыв соединения.

⏺Ещё один полезный фильтр:

tcp.analysis.retransmission || tcp.analysis.out_of_order

Здесь важно не просто посчитать retransmission, а найти закономерность. Например, повторные передачи начинаются только после TLS handshake или возникают исключительно при обращении к конкретному IP.

⏺Чтобы быстро собрать всё в одну картину, открываем:

Statistics → Conversations → TCP

Сортируем соединения по количеству пакетов и смотрим пары IP:port. Затем открываем подозрительный поток через Follow → TCP Stream и проверяем всю цепочку: TCP handshake, TLS handshake, Alert, retransmission и завершение соединения.
MITM редко оставляет один очевидный след. Гораздо интереснее, когда DNS, SNI, TLS, TCP и поведение нескольких сессий начинают противоречить друг другу. Вот тогда уже есть за что зацепиться.

ZeroDay | Белый Хакер | #MITM

Как дать контейнеру SSH и при этом не дать ему украсть ключ?

Контейнеру нужно забрать код из приватного Git или сходить на сервер. Самый очевидный путь - сунуть внутрь ~/.ssh. Только вместе с SSH-доступом приложение получает и приватный ключ: если процесс взломают, ключ можно прочитать и унести.

⏺Автор статьи решил сделать наоборот - оставить контейнеру полноценный SSH, но сам секрет от него спрятать. Вместо ключа внутрь пробрасывают только сокет ssh-agent, но тут rootless Docker подкидывает неприятный сюрприз: UID внутри контейнера не совпадает с UID на хосте, и простой SSH_AUTH_SOCK перестаёт работать. В статье разбирают этот затык, собирают схему с non-root, read-only filesystem и без capabilities.

ZeroDay | Белый Хакер | #Статья

ZeroDay | #мем

Человек, который научил Интернет не бояться чужих глаз

👋 Приветствую в мире цифровой безопасности!

Сегодня расскажу о Мартине Хеллмане, одном из людей, благодаря которым защищённое соединение в интернете вообще стало возможным.

⏺В 1970-х Хеллман работал профессором в Стэнфорде и занимался криптографией. Тогда она в основном ассоциировалась с военными и закрытыми государственными разработками. Даже коллеги советовали ему не лезть в эту область: у АНБ были огромные ресурсы и многолетнее преимущество.

⏺В 1976 году вместе с Уитфилдом Диффи Хеллман опубликовал работу New Directions in Cryptography. Главная идея была почти переворачивающей правила игры: двум людям больше не нужно заранее передавать друг другу секретный ключ. Они могут договориться о нём через открытый канал, который видит потенциальный перехватчик.

⏺Так появился протокол Диффи-Хеллмана. Наблюдатель может видеть весь обмен данными, но не получает сам общий секрет. Сегодня этот принцип лежит в основе защищённых соединений с банками, почтой, облачными сервисами и другими интернет-системами.

⏺Но с публикацией возникла проблема. АНБ пыталось ограничить распространение исследований и даже предупреждало издателей о возможной ответственности за публикацию криптографической работы. Начался один из первых эпизодов так называемых «криптовойн».

⏺Позже Хеллман продолжил заниматься не только криптографией, но и вопросами приватности и безопасности. В 2015 году он вместе с Диффи получил премию Тьюринга за вклад в развитие криптографии с открытым ключом.

⏺Самое забавное: сегодня мы воспринимаем HTTPS, цифровые подписи и обмен ключами как обычную часть интернета. А когда-то сама идея сделать сильную криптографию доступной широкой публике была спорной.

ZeroDay | Белый Хакер | #история

Cross-Site Leaks: полная защита

👋 Приветствую в мире цифровой безопасности!

В прошлый раз разобрали как атакующий вытаскивает данные через побочные эффекты браузера. Сегодня будем защищаться.

⏺Fetch Metadata на сервере: браузер сам добавляет к каждому запросу контекст откуда он пришёл. Проверяем его до выполнения любой логики:

def fetch_metadata_check(request):
    site = request.headers.get('Sec-Fetch-Site', '')
    mode = request.headers.get('Sec-Fetch-Mode', '')
    dest = request.headers.get('Sec-Fetch-Dest', '')

    if site in ('same-origin', 'same-site', 'none'):
        return True

    # Cross-site разрешаем только прямую навигацию
    if mode == 'navigate' and dest not in ('object', 'embed'):
        return True

    return False

Timing атака через fetch требует mode: no-cors и Sec-Fetch-Site: cross-site - этот паттерн детектируется сразу и запрос отклоняется до того как база данных вообще получила вопрос.

⏺Constant-time responses: убираем информационный сигнал из времени ответа. Если поиск отвечает быстрее когда ничего нет и медленнее когда есть, атакующий это видит:

import time

def search_with_constant_time(query, min_time=0.1):
    start = time.monotonic()
    results = db.search(query)
    elapsed = time.monotonic() - start
    if elapsed < min_time:
        time.sleep(min_time - elapsed)
    return results

Независимо от результата ответ всегда приходит через одинаковое время.

⏺Connection pool exhaustion - менее очевидный вектор: атакующий открывает много соединений к целевому серверу и измеряет задержку следующего запроса жертвы. Если соединений не хватает, жертва ждёт, но атакующий это видит. Защита через отдельные connection pool'ы для аутентифицированных и анонимных запросов - они не делят ресурсы и утечки информации через задержку нет.

⏺Resource Isolation Policy целиком выглядит так: Fetch Metadata middleware отклоняет кросс-сайтовые зонды, CORP на всех ресурсах убирает error oracle, одинаковые HTTP-статусы для существующих и несуществующих объектов, constant-time на поиске и любых эндпоинтах где результат бинарный. Четыре слоя, и каждый убирает отдельный канал утечки.

⏺Инструмент для проверки своего сайта: xsleaks.dev/docs/defenses - там по каждому вектору атаки написано какая именно защита что закрывает. Удобно проверять не заткнул ли ты только очевидное.

ZeroDay | Белый Хакер | #атака

Cross-Site Leaks: как атакующий читает чужие данные через браузер

👋 Приветствую в мире цифровой безопасности!

XS-Leaks - класс атак, где один сайт узнаёт информацию о юзере на другом сайте, не нарушая Same-Origin Policy напрямую. Разбираем как это работает 👇

⏺Браузер изолирует сайты: один не может прочитать ответ запроса к другому. Но атакующий может наблюдать за побочными эффектами: сколько времени занял запрос, произошла ошибка или нет, сколько редиректов случилось. По этим сигналам вытаскивается приватная информация.

⏺Timing атака: поиск на банковском сайте отвечает быстрее когда результатов нет и медленнее когда есть. Атакующий делает cross-origin запрос и замеряет время:

async function probeBankSearch(query) {
    const start = performance.now();
    try {
        await fetch('https://bank.com/search?q=' + query, {
            mode: 'no-cors',
            credentials: 'include'
        });
    } catch(e) {}
    return performance.now() - start;
}

const time = await probeBankSearch('salary transfer');

Куки летят автоматически, ответ прочитать нельзя, но время можно. Если больше порога - результаты есть.

⏺Error oracle ещё проще. Многие сайты возвращают разные статусы для существующих и несуществующих ресурсов:

function checkUserExists(userId) {
    const img = new Image();
    img.onload = () => console.log('User exists');
    img.onerror = () => console.log('404 or blocked');
    img.src = `https://target.com/avatar/${userId}`;
}

Без CORP атакующий узнаёт существует ли пользователь, заблокирован ли аккаунт, есть ли у него определённая роль.

⏺Frame counting через history.length: если страница делает редиректы в зависимости от состояния - залогинен, не залогинен, заблокирован - количество записей в истории меняется:

const win = window.open('https://target.com/dashboard');
setTimeout(() => {
    console.log(win.history.length); // отличается по числу редиректов
    win.close();
}, 2000);

⏺Что закрывает эти атаки: CORP на ресурсах убирает error oracle через img и script теги. COOP разрывает доступ к window.history открытого окна. Fetch Metadata позволяет серверу отклонять подозрительные cross-site зонды:

Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: no-cors

Сервер видит такой запрос к чувствительному эндпоинту и возвращает одинаковый ответ независимо от состояния - информационный сигнал исчезает.

Во второй части расскажу о защите от подобных атак.

ZeroDay | Белый Хакер | #атака

Velociraptor: как искать следы атаки на хосте

👋 Приветствую в мире цифровой безопасности!

После алерта хочется быстро понять, что вообще происходило на машине. Какие процессы запускались, что менялось в системе, какие артефакты остались. Для этого есть Velociraptor.

⏺Velociraptor собирает данные с Windows, Linux и macOS через VQL. Запросы можно запускать прямо на endpoint и получать состояние системы без ручного обхода каждого источника.

⏺Для быстрого старта достаточно поднять локальный GUI:

velociraptor gui

После запуска можно собрать готовые артефакты с локального клиента. Например, посмотреть доступные артефакты через интерфейс и выбрать только нужные для конкретного расследования.

⏺Сам VQL выглядит примерно так:

SELECT
  Pid,
  Name,
  CommandLine,
  Exe
FROM pslist()

Получаем список процессов и сразу видим командную строку, с которой они запущены.

⏺Можно проверить файлы в конкретном каталоге:

SELECT
  FullPath,
  Size,
  Mtime
FROM glob(globs="C:/Users/*/Downloads/*")

И отдельно собрать сетевые соединения:

SELECT
  Pid,
  Laddr,
  Raddr,
  Status
FROM netstat()

⏺Если локального сбора мало, Velociraptor разворачивается с сервером и клиентами на endpoint’ах. Для автономного triage можно собрать собственный collector: в GUI выбираем нужные Server Artifacts → Build Collector, настраиваем набор данных и получаем готовый сборщик.

⏺Сила Velociraptor именно в VQL и артефактах: не нужно каждый раз писать отдельный скрипт для процессов, файлов, сети и системных следов. Выбираешь нужные источники, запускаешь сбор и уже потом разбираешь результаты.

ZeroDay | Белый Хакер | #Инструмент

Сервер, который не отвечает без сертификата: как mTLS отсекает атаки ещё до HTTP

Автор поднял homelab на одном сервере с Traefik и Dokploy и решил проверить mTLS не на схеме, а на реальных атаках. Сначала определил, что именно нужно защищать и от кого, а потом начал ломать собственный сервер без клиентского сертификата.

⏺В статье показывают, как mTLS отсекает brute force, credential stuffing и попытки добраться до уязвимостей приложения ещё на этапе TLS-рукопожатия, но не спасает от всего подряд. Заодно разбирают CRL и отзыв сертификатов, OCSP, проверку цепочки и SAN, нагрузку от TLS-атак и конкретный недостаток Traefik, из-за которого с отзывом сертификатов приходится городить отдельное решение.

ZeroDay | Белый Хакер | #Статья

DLL Hijacking: когда Windows загружает не ту библиотеку

👋 Приветствую в мире цифровой безопасности!

Расскажу, как работает атака DLL Hijacking.

⏺Допустим, программа запускает helper.dll, не указывая полный путь. Если рядом с приложением лежит DLL с таким именем, Windows может загрузить её вместо той, которую разработчик рассчитывал найти в системном каталоге.

⏺На этом и строится DLL Hijacking. Атакующему не обязательно ломать само приложение. Достаточно разместить библиотеку там, где программа будет искать её раньше настоящей.

⏺Больше интересен сценарий с каталогом, доступным для записи обычному пользователю. Приложение запускается с более высокими правами, ищет helper.dll, находит подменённую библиотеку и загружает её уже в свой процесс.

⏺Именно поэтому при расследовании смотрят не только на сам EXE, но и на то, откуда приехала каждая DLL. В Sysinternals Process Monitor это можно увидеть по операциям CreateFile и Load Image: приложение сначала ищет DLL по нескольким путям, получает NAME NOT FOUND, а затем внезапно находит библиотеку в неожиданном каталоге.

⏺Для защиты помогает указывать абсолютные пути к библиотекам, не оставлять каталоги поиска доступными для записи обычным пользователям и контролировать загрузку DLL из пользовательских директорий.

Если нужна вторая часть с разбором защиты от атаки, ставьте 🔥

ZeroDay | Серверная Админа | #windows

Почему /tmp может стать точкой атаки

👋 Приветствую в мире цифровой безопасности!

/tmp есть почти на любом Linux-сервере. Туда приложения складывают временные файлы, сокеты, lock-файлы и прочие данные, которые долго хранить не нужно.

⏺Проблема в том, что каталог обычно доступен для записи разным пользователям. Если программа создаёт там файл с предсказуемым именем, появляется возможность подменить его или подсунуть вместо него символическую ссылку.
Например, приложение делает:

echo "data" > /tmp/app.lock

А другой пользователь заранее создаёт /tmp/app.lock как ссылку на другой файл.

⏺Особенно интересно это становится, когда программа работает от root. Ошибка в работе с временными файлами может превратить обычный доступ к /tmp в способ заставить привилегированный процесс изменить файл, к которому пользователь сам доступа не имеет.

⏺Поэтому в таких программах используют безопасное создание временных файлов, проверяют владельца и права, а для более сложных случаев применяют специальные механизмы ядра вроде O_NOFOLLOW и openat2().

⏺Проверить права самого каталога можно обычной командой:

ls -ld /tmp

Обычно там увидите drwxrwxrwt. Последний t здесь как раз важен: sticky bit не позволяет одному пользователю просто удалить или переименовать чужой файл внутри /tmp.
Но от ошибок самого приложения он не спасает.

ZeroDay | Белый Хакер | #tmp

Git как поверхность атаки: что остаётся после удаления секрета?

👋 Приветствую в мире цифровой безопасности!

В первой части разобрали очевидный сценарий: секрет случайно попал в коммит. Кажется, что достаточно удалить файл и сделать новый commit. Но Git так не работает.

⏺Старый коммит никуда не исчезает. Если объект всё ещё доступен в истории или на него ссылается другая ветка, тег, fork или reflog, содержимое можно найти снова. Удалённый .env не становится автоматически секретным.

⏺Проверить, что осталось в локальном репозитории, можно через историю:

git log --all --full-history -- .env

А для поиска недостижимых объектов:

git fsck --full --no-reflogs --unreachable

⏺Но искать конкретный ключ по всей истории вручную неудобно. Здесь и пригодятся TruffleHog и Gitleaks. Первый можно запускать по Git-истории, второй удобно встроить прямо в CI, чтобы проверка происходила до попадания изменений дальше по пайплайну.

⏺Есть ещё важный момент: обнаружение секрета не означает, что проблема решена. Если AWS key или токен уже попал в удалённый репозиторий, сначала нужно считать его скомпрометированным и отозвать. Переписывание Git-истории убирает данные из определённых объектов, но не отменяет уже произошедшее раскрытие.

⏺Поэтому нормальная защита строится в несколько слоёв: проверка истории, сканирование новых изменений, секреты вне Git и автоматическая ротация при обнаружении утечки.
Git отлично помнит то, что разработчик уже успел забыть.

ZeroDay | Белый Хакер | #GIT

Кибербез после прихода ИИ

👋 Приветствую в мире цифровой безопасности!

Вот есть обычный SOC. Ночью прилетает сотня алертов, аналитик разбирает логи, ищет связь между событиями, проверяет подозрительный файл и пытается понять, это атака или очередной false positive. А теперь часть этой работы делает ИИ.

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

⏺И тут появляются вопросы интереснее самого хайпа вокруг AI. Что будет, если система сама примет неправильное решение? Кто отвечает за ошибку? Сколько контроля можно отдать машине? И что произойдёт, когда такие возможности одновременно появятся у защитников и атакующих?

⏺Об этом будут говорить на SOC Forum 2026, который пройдёт 27–28 октября в московском кластере «Ломоносов». Главная тема форума в этом году как раз связана с ИИ в руках атакующих и защитников.

⏺27 октября больше внимания уделят бизнесу, регуляторике, трендам и влиянию ИИ на процессы компаний. 28 октября перейдут к технологиям: реальные инциденты, Offence, Defence, архитектура ИТ и ИБ, мониторинг, расследования и автоматизация.

⏺Кроме докладов будут выставка, интерактивные площадки и возможность пообщаться с людьми из отрасли. А сам форум станет центральным событием Российской недели кибербезопасности, которая пройдёт 26–30 октября.

Регистрация на форум уже открыта.

ZeroDay | Белый Хакер | #SOC

Fibratus: как Windows выдаёт следы атаки

👋 Приветствую в мире цифровой безопасности!

Вредоносный процесс не обязан носить имя malware.exe и лежать в подозрительной папке. Гораздо интереснее посмотреть, что он делает после запуска. Fibratus как раз собирает системные события Windows и ищет в них подозрительное поведение.

⏺Fibratus как раз собирает такую телеметрию в реальном времени через ETW. Он видит процессы, потоки, файлы, реестр, сеть и операции с памятью, а затем прогоняет события через движок поведенческих правил.

⏺Фишка в том, что правило может смотреть не на отдельное событие, а на цепочку. Например, один процесс создаёт файл, после чего запускается другой с определёнными параметрами. По отдельности ничего особенного, вместе уже получается повод для алерта. Правила пишутся на YAML и могут связывать события по времени и родословной процессов.

⏺Отдельно Fibratus умеет заглядывать в память процессов через YARA. Это позволяет искать fileless-малварь, shellcode и другие артефакты, которые могут вообще не существовать в виде обычного файла на диске.

⏺А если хочется не только ловить, но и разбираться, события можно сохранить в capture-файл для последующего анализа или отправить дальше в инфраструктуру. Для своих сценариев есть filaments: Python-расширения, которые получают события и позволяют добавить собственную обработку.

⏺Поставить можно одной командой из PowerShell от администратора:

irm https://install.fibratus.io | iex

И дальше уже смотреть, чем занимается Windows вживую, вместо того чтобы гадать по одному подозрительному файлу.

ZeroDay | Белый Хакер | #Инструмент

Пункт договора, который исчез сам собой: как языковую модель развели слить чужой промпт

Разработчик сервиса для проверки договоров поймал в логах фразу, замаскированную под пункт о неустойке, с командой выдать системный промпт. Модель повелась частично, но куда страшнее другое: тем же трюком ее заставили тихо выкинуть из отчета невыгодный пункт, не оставив в ответе вообще ничего подозрительного.

⏺В статье разобрали, как модель завернула слитый промпт в свою же JSON-схему, почему правило «не слушай чужие команды» прямо в промпте оказалось пустой табличкой на двери, какая кириллическая регулярка месяцами пропускала настоящую атаку из-за путаницы с \w, и какую дыру автор так и не закрыл, перепробовав четыре слоя защиты.

ZeroDay | Белый Хакер | #Статья

Prompt Injection: как ИИ заставляют делать то, о чём его не просили

👋 Приветствую в мире цифровой безопасности!

Вы просите ИИ-агента разобраться с Python-библиотекой. Он открывает документацию, читает страницу и находит там инструкцию, которую никто из вас не писал. Юзер видит обычный текст, а агент получает ещё одну команду.

⏺В одном эксперименте вредную инструкцию спрятали в CSS за пределами видимой области страницы и в JSON-LD. Страница выглядела как обычная документация, но агенту предлагали купить лицензионный ключ за $3 и отправить криптовалюту на указанный адрес.

⏺Проверили 26 моделей. Четыре из них действительно выполнили платёж. Сайт при этом никто не взламывал. Инструкция просто лежала на странице, которую агент должен был прочитать.

⏺Такой текст можно положить и в README, комментарий кода, письмо, Jira, базу знаний или ответ API. Агент соберёт всё это в контекст, а модель должна решить, где полезная информация, а где попытка ею управлять.

⏺А теперь добавим агенту доступ к Git, файлам, терминалу или API. Он уже не просто отвечает текстом. Он может что-то изменить, отправить или запустить. Поэтому один и тот же prompt injection у агента с доступом к инструментам и у обычного чат-бота имеет совершенно разный результат.

Во второй части посмотрим именно на инструменты и MCP: как через них одна чужая инструкция может пройти от текста до реального действия и где в этой цепочке можно поставить защиту.

ZeroDay | Белый Хакер | #пентест