Одна уязвимость, дюжина названий, 321 запись и стенд, за которым конкуренты договорились “дружить”. История создания самого известного идентификатора в кибербезопасности по первоисточникам 1999 года.
Есть такое уютное заблуждение: выключил Wi-Fi и мобильные данные – и все, ты невидимка. Спокойно можно строить теории заговора. На деле всё немного иначе. Даже в полном офлайне встроенные датчики смартфона продолжают исправно работать и копить информацию о том, чем вы занимались. Разбираемся, как смартфоны на самом деле следят за нами без сети, чего стоит опасаться по-настоящему, а что — просто повод для паранойи.
Привет, Хабр!
На связи Дмитрий Ларин, я руковожу продуктовым направлением по защите баз данных, в Гарде.
Маскирование данных — важное направление нашей работы (в продуктовой линейке Гарды даже представлен отдельный продукт для выполнения таких задач). Поэтому нам не привыкать к разнообразным вопросам об этом методе защиты — от банального «зачем вообще нужно маскирование?» до провокационного «почему бы не скормить поиск ПДн нейронке?».
Далеко не всегда можно «вытащить из рукава» однозначный ответ, ведь дьявол, как известно, кроется в деталях: особенностях корпоративной сети, специфике бизнеса, сценариях использования данных.
Недавно мы провели вебинар с говорящим названием «Маскирование данных: битва мнений». Мы постарались честно и взвешенно ответить на частые и животрепещущие вопросы по этой теме, и теперь делимся своими ответами в статье.
Итак, поехали.
Я наблюдал ситуации, когда компания формально соответствует требованиям регулятора, регулярно проходит аудиты, имеет утвержденные Политики, настроенные СЗИ, выделенный SOC и несколько сотен страниц Регламентов на случай любой проверки.
Но однажды, после первого инцидента, выяснялось, что:
— Учетная запись имела многофакторную аутентификацию (что после компрометации сессии значения не имеет).
— SIEM собирал события, но расследование затруднялось тем, что в разных источниках один и тот же пользователь имел разные идентификаторы.
— Доступ сотрудника был вовремя отозван в Active Directory, но остался в одном из SaaS-сервисов.
— Резервное копирование выполнялось ежедневно, но восстановить критичный сервис в установленный RTO невозможно.
Значит ли это, что мы должны отказываться от формальностей? Нет, конечно. Соответствие требованиям необходимо. Без него невозможно выстроить управление ИБ, тем более в регулируемых отраслях.
Но здесь легко попасть в ловушку формального контроля, ведь соответствие требованиям — это подтверждение того, что определенные правила и процедуры существуют. Требования задают определенный минимальный уровень контроля, но не могут описать всю конкретную инфраструктуру компании, все зависимости между системами, особенности бизнес-процессов и все возможные сценарии атаки.
Предлагаю посмотреть на области, которые уже соответствуют требованиям, немного другим взглядом. Рассмотрим MFA, SIEM, управление доступом, DLP и прочие моменты с точки зрения слабых мест бумажной безопасности.
Пока рынок спорил, достаточно ли «умного» фильтра на промпт, агенты уже начали вызывать инструменты, ходить в MCP, трогать платёжные API и уносить ключи с рабочих станций. Для нас это был момент, когда защита модели перестала быть достаточным контуром. Промпт можно инспектировать, но действие нужно останавливать до исполнения.
В этой статье опишем рабочую модель runtime‑контроля, расскажем как устроен контур, который видит эксплуатация: где перехватывается вызов, как компилируется политика, какой вердикт выносится до исполнения действия и почему «нашли всех агентов» ещё не равно «контролируем агентов».
За агентом всегда есть контур сущностей: скиллы и расширения, MCP‑серверы и их инструменты, модели, машины и эндпоинты, сессии, инструменты вызова (tool‑call), обращения в сеть, граф межагентного взаимодействия.
Если сотрудник с ноутбука вышел за контролируемый перечень ИИ‑моделей и сходил во внешнюю LLM — это тоже событие контура, которое попадает в блок «теневого» ИИ (Shadow AI). Чтобы это было контролируемо — нужно понимать, что происходит на рабочей станции сотрудника. Без агента на хосте остаётся только то, что проходит через шлюз.
Большинство разговоров о сетевой безопасности крутятся вокруг систем, которые стоят на пути трафика и должны принять решение здесь и сейчас: NGFW, WAF, IDS. Но есть и другой класс систем — те, что работают не с самим трафиком, а с его зеркальной копией, и потому могут анализировать происходящее сколько угодно долго. Эта статья — про то, что удаётся увидеть NTA/NDR-системам именно благодаря этому запасу времени: от восстановления цепочки атаки шифровальщика по сохранённым метаданным до обнаружения ботнета, для которого ещё не существовало сигнатуры.
Threat Intelligence — одна из тех тем в информационной безопасности, про которые вроде бы все что-то слышали, но почти каждый понимает по-своему. Для кого-то TI — это просто фиды с IP-адресами. Для кого-то — дорогая платформа, которую «надо купить, потому что так делают все». Для кого-то — модный термин из презентаций CISO.
Проблема в том, что из-за этого разнобоя ожиданий Threat Intelligence очень часто внедряют неправильно. Формально TI в компании есть, бюджеты освоены, отчёты формируются — а реальной пользы почти ноль. В итоге появляется устойчивое ощущение, что TI «не работает», «переоценён» или «нужен только большим корпорациям».
TI — это не просто «база индикаторов», но и не магия
Начнём с самого важного. Да, современный Threat Intelligence давно ушёл дальше примитивных списков IP-адресов, доменов и хэшей. Сегодня существуют TI-платформы, в которых на основе данных об угрозах строятся корреляции, сценарии, гипотезы, а иногда и полноценные обнаружения. В том числе это относится к коммерческим решениям — например, в продукте Security Vision TIP индикаторы используются не сами по себе, а как часть логики анализа и детекта.
Но здесь появляется опасная иллюзия. Кажется, что, если платформа «умеет в детекты», значит, она автоматически понимает, что для нас важно, а что нет. На практике это почти никогда не так. Любой детект, даже самый сложный, всё равно опирается на предположения — о структуре инфраструктуры, качестве логирования, допустимом поведении пользователей, уровне зрелости процессов. И если эти предположения не совпадают с реальностью конкретной компании, TI снова начинает либо шуметь, либо молчать там, где должен был помочь.
Мне в руки попался обычный файл с расширением .vbs. Ничего необычного. Открываю посмотреть, что там внутри, и сначала даже немного разочаровался. Какой-то VBScript, временные файлы, cmd.exe, PowerShell. Ну, думаю, очередной скрипт-загрузчик. Но потом заметил одну деталь. Скрипт читал сам себя. И вот тут стало уже интереснее.
Я искал причину падения и грепал журнал по тексту ошибки. В соседней строке, среди неудачных попыток входа, в поле имени пользователя лежало не имя. Лежала строка, которая именем быть не могла: длинная, со спецсимволами, явно чей-то пароль.
Дальше я выгрузил из журнала все значения поля имени пользователя за месяц по неуспешным попыткам и оставил те, что не совпадают ни с одной существующей учётной записью и не похожи на имя: длинные, со спецсимволами, не повторяющиеся между собой. Набралось около сорока.
Хеширование паролей у нас настроено правильно, в базе всё как надо. Просто до хеширования эти строки не дошли: код их паролями не распознал.
В новом релизе Ideco NGFW Novum мы собрали функции, которые обычно приходится искать в разных слоях инфраструктуры: видимость AI-сервисов, развитую динамическую маршрутизацию, QoS и строгую аутентификацию. Разберем задачи, которые релиз закрывает в больших распределенных сетях, ЦОД, на перегруженном WAN-канале и в регулируемом контуре.
AI уже в сети, даже если его ещё нет в реестре ИБ
Shadow AI начинается с обычного рабочего действия: сотрудник открывает чат-бот (а уже наверное и разворачивает агент), разработчик подключает API-модели, аналитик загружает таблицу в ассистент, а инженер запускает локальный inference-сервис для эксперимента. У каждого действия может быть разумная цель, но у ИБ нет ответа на базовый вопрос: какие AI-инструменты реально используются в сети?
Масштаб разрыва между официальным внедрением и фактическим использованием может быть огромным.
Это не только вопрос дисциплины. AI-агент внутри сети может быть развернут злоумышленниками для быстрого закрепления в инфраструктуре. Или небезопасно настроенный и используемый агент может в будущем «заразиться» и перейти на «темную сторону силы».
Запретить все AI-сайты целиком – простой, но слабый ответ. Он не отделяет утверждённый корпоративный сервис от личного аккаунта, не помогает понять реальный спрос и подталкивает пользователей искать обходы. До политики нужен инвентаризационный слой: сначала увидеть сервисы, затем классифицировать риск, определить допустимые сценарии и только после этого применять ограничения.
Кроме того, из-за официальной недоступности в России многих AI-сервисов, в рунете широкое распространение получили сервисы-прокси и агрегаторы AI-моделей, самостоятельно составлять и поддерживать их списки – неблагодарная работа.
Всем привет! Меня зовут Сергей Бобров aka BlackFan. Я работаю в Лаборатории Касперского, занимаюсь анализом защищенности мобильных и веб-приложений, участвую в пентестах и редтимах. В свободное время я также разрабатываю собственные инструменты, занимаюсь исследованиями в области безопасности и ищу баги на платформе Standoff Bug Bounty. Сегодня мы разберем на практике мисконфигурации, связанные с объектным хранилищем S3, и углубимся в проблемы, возникающие при его интеграции в веб-приложения через прокси (например, nginx). В основе статьи — 10 лабораторных стендов, каждый из которых поясняет различные уязвимости интеграции: от классической хранимой XSS и подмены бакетов до обхода правила rewrite и отравления кэша.
Пентест принято мерить по количеству найденных дыр. По-хорошему мерить надо бы по другому: что осталось после команды. Работает ли инфраструктура, не разошлись ли данные, не прилетело ли тем, кого в проекте вообще не было.
Я работаю в Singleton Security. Ниже 5 ошибок, после которых проект превращается в проблему. Часть я видел со стороны, часть слышал в кулуарах на конференциях, где такое рассказывают охотно, а в отчётах не пишут никогда. Два случая наши собственные: упавший сервер и домен, который не надо было регистрировать. Свои разбирать проще, про них хотя бы точно знаешь, как всё было.
«Кто я?» — вопрос, над которым люди размышляют веками. Но whoami для админа — обычная команда. А для атакующего, который только что нашел OS сommand injection, это буквально первая фраза при знакомстве с сервером. В статье покажем, как из одного слова можно получить 37 196 синтаксически разных вариантов одной и той же команды, а также рассмотрим свежие CVE, связанные с этой уязвимостью.
— Есть Grafana.
— Есть n8n.
— Есть Dockge.
— Есть несколько внутренних админок и staging‑сайтов.
У каждого из них уже есть собственная авторизация. Казалось бы, что ещё нужно?
Но меня долго смущала одна простая вещь: почему форму логина вообще должен видеть весь интернет?
Я решил проверить, способен ли MAX Desktop обнаружить VPN, если VPN-клиента в Windows вообще нет. В моей сети Split Routing выполняет роутер Keenetic: часть трафика идёт напрямую, а часть — через OpenConnect-туннель на удалённый VPS.
Во время эксперимента я фиксировал действия MAX с помощью Process Monitor, TCPView и Wireshark, а трафик на стороне VPN-сервера — через tcpdump. Проверил, какие системные параметры читает MAX, куда подключается и появляются ли признаки целенаправленного поиска VPN-маршрута.
Задача просмотра сетевого трафика интересна тем, что позволяет увидеть, что фактически передаётся между двумя хостами, и разобраться, что происходит внутри сетевого соединения, которое в обычной ситуации выглядит как «чёрный ящик».
Мне в руки попался файл с расширением .sh и, конечно же, его пришлось изучить. Открываю файл — первая половина более-менее читаемая, а дальше начинается классика: Base64, ROT13 и еще немного Base64. Вроде ничего страшного. Декодируем, смотрим результат, радуемся жизни. Но не тут-то было. Автор скрипта решил сделать небольшой квест в стиле: А что если положить один скрипт внутрь другого скрипта, а потом еще один внутрь него?
В 2026 году отдел киберразведки PT ESC зафиксировал серию атак, объединенных использованием легитимной среды выполнения Deno для запуска вредоносного JavaScript-кода. Загрузочный компонент получил публичное название DinDoor; в подробно исследованных MSI- и LNK-ветках за ней следует полнофункциональный агент удаленного доступа DenoRAT.
Целями этих действий на территории Российской Федерации стали предприятия ОПК, военные структуры, банки, финансовые и консалтинговые организации. В качестве фишинговых приманок злоумышленники используют документы военной и финансово-кредитной тематики.
В статье последовательно рассматриваются две основные цепочки первоначального запуска: MSI-ветка, выявленная в рамках фишинговой рассылки с финансовой тематикой, и LNK-ветка. Отдельно разбирается вредоносный установщик DeltaScan, выявленный при исследовании той же инфраструктуры и использующий сходную многостадийную схему запуска Deno. Совокупность пересечений в логике, техниках и сетевой инфраструктуре позволяет нам рассматривать эти эпизоды как активность одного актора.
Раньше утечка данных была в первую очередь репутационной проблемой. Информация разошлась, несколько дней её обсуждали в телеграм-каналах, компания объяснилась — и постепенно история забывалась. Штраф тоже редко становился серьёзной проблемой: 60 тысяч рублей — примерно стоимость корпоратива для отдела.
Хабр, привет!
На связи команда инженер-аналитиков R-Vision. Мы проанализировали широкий спектр уязвимостей, выявленных в августе 2026 года, и включили в дайджест лишь те, что представляют наибольший практический интерес по уровню риска, подтверждённой эксплуатации и актуальности для специалистов по информационной безопасности.