88% компаний используют ИИ, но только 1% достиг зрелости. Главный барьер — не технология, а безопасность данных. Что мы делали два года и почему пришли к гибридной архитектуре.
Жемал Хамидун, Head of AI Alpina Digital, CPO AlpinaGPT, автор тг-канала «Готовим ИИшницу».
Всем привет! Хочу поделиться, возможно, не новым, но, на мой взгляд, довольно изощренным видом фишинга. Кто-то уже наверняка сталкивался с таким методом, а для кого-то он окажется в новинку.
Привет, Хабр!
Меня зовут Данил Зарипов, я эксперт центра безопасности (PT ESC) Positive Technologies. Эту статью мы подготовили вместе с моим коллегой Кириллом Масловым, продуктовым экспертом по направлению Asset Management. Мы закрываем наш цикл статей про аудит ИТ‑активов, и сегодня поговорим о системах виртуализации.
Виртуальная инфраструктура — это не просто удобный способ экономить железо. Это сложная система, в которой переплетаются гипервизоры, виртуальные машины, сети, системы хранения и управляющее ПО. И если злоумышленник получает к ней доступ, считайте в его руках ключи от любой «двери» в компании. Для защитника же‑ это огромный пласт данных, который помогает увидеть инфраструктуру целиком, найти уязвимости, отловить небезопасные настройки и вовремя заметить избыточные права доступа.
Как устроена виртуальная инфраструктура изнутри? Почему атакующие всё чаще охотятся за ней? И главное — что с этим делать защитникам, чтобы не дать превратить свои сервера в чужой ботнет? Давайте разбираться на примере продуктов VMware!
Разработанный в компании «Криптонит» (входит в «ИКС Холдинг») алгоритм S3G-5G прошёл новый этап согласования: Технический комитет 26 (ТК 26) по стандартизации «Криптографическая защита информации» утвердил методические рекомендации по его применению. Алгоритм представляет собой российский аналог криптографических функций 3GPP (f1–f5), предназначенных для выработки вспомогательных секретных ключей и аутентификационных векторов в сетях подвижной радиотелефонной связи пятого поколения (5G). Его внедрение позволит значительно повысить безопасность абонентов.
Методические рекомендации S3G-5G — это усовершенствованная и специализированная для сетей 5G версия ранее принятых рекомендаций S3G-256 (Р1323565.1.003-2024). Ключевое отличие заключается в добавлении случайности со стороны устройства абонента (UE — User Equipment), что делает невозможными атаки повторного воспроизведения (replay attack). В отсутствие такой защиты злоумышленник может легко отследить факт аутентификации и перемещения пользователя, выяснить, где и когда он бывает, и получить возможность для целенаправленных атак. Таким образом, основная функция нового алгоритма — надёжная защита от отслеживания местоположения абонентов.
В данной статье расскажем о кейсах с наиболее интересными угрозами, связанными с применением LLM, проведем анализ вариантов применения AI/LLM Firewall, сопоставим их с актуальными тактиками и техниками из фреймворка MITRE ATLAS и списка рисков OWASP Top 10 for LLM. Разберем сценарии атак с детальными схемами и методами защиты на примере решения INFERA AI.Firewall.
Почему традиционных средств защиты недостаточно?
Современные системы на базе LLM представляют собой принципиально новую атакуемую поверхность. Как справедливо отмечается в отчете Cloud Security Alliance (CSA) на саммите RSAC 2025, «защита промптов – это лишь часть проблемы, а не её решение». Если традиционный межсетевой экран (WAF) защищает от эксплуатации веб-протоколов (HTTP-инъекции, XSS), то AI/LLM Firewall работает на уровне семантики – он понимает значение и контекст запроса, что никогда ранее не рассматривалось средствами защиты.
Более того, фреймворк MITRE ATLAS уже включает более 80 техник, направленных именно против ИИ-систем и не пересекающихся с угрозами для других систем. Игнорировать этот объем угроз – значит подвергать бизнес серьезному риску.
AI/LLM Firewall становится тем инструментом, который позволяет реализовать около 70% мер защиты, интегрируя их в существующие рабочие процессы центров безопасности SOC. Но, прежде чем говорить о защите, необходимо понять, от чего именно мы защищаемся.
Всем привет, на связи команда DFIR JetCSIRT!
Недавно мы столкнулись с кейсом, где злоумышленники были обнаружены на ранних этапах атаки. Они не успели довести дело до импакта, но изрядно наследили, что дало нам возможность изучить их тактики, техники и процедуры (TTP) в действии.
Мы готовы рассказать, как это было, и дать рекомендации по повышению уровня защищенности.
Что произошло через месяц после выступления Бони по блокировкам. Доступность телеграм. Что работает и нет по обходу блокировок.
Есть типовой путь, по которому команды приходят к разочарованию в Threat intelligence. Сначала кто-то в компании слышит, что фиды помогут раньше видеть атаки, быстрее реагировать, меньше пропускать. Потом кто-то другой берет пачку индикаторов из разных источников и по-быстрому заливает их в NGFW, прокси, SIEM или IDS. После СЗИ начинает сходить с ума: сыпятся алерты, в логах всплывают легитимные сервисы, аналитики несколько дней разгребают мусор…
В итоге всё это счастье переводят в режим «только мониторинг», чтобы ничего не сломать. В результате напрашивается вывод: Threat intelligence — это, конечно, модно, но нам не нужно и вообще больше похоже на дорогую игрушку для крупных SOC. Вот только проблема не в TI, а в том, что сырые фиды никто не должен использовать в проде.
Под катом разбираемся, почему именно так происходит, какие фиды стоит брать, а какие выкидывать, и как не превратить TI в генератор ложных срабатываний.
Tor часто описывают слишком просто: «браузер для анонимности», «вход в даркнет», «инструмент обхода блокировок». Формально всё верно, но такие описания почти ничего не объясняют.
Мне интереснее другое: что происходит между нажатием Enter в адресной строке и загрузкой страницы. Почему сайт не видит мой реальный IP. Почему провайдер видит факт подключения к Tor, но не видит сайт. Почему выходной узел опасен для HTTP. Почему Tor Browser не стоит превращать в обычный Firefox с двадцатью расширениями.
Разбираю именно механику.
Бэкап раньше был последним рубежом обороны. Теперь — первой целью атаки: современные шифровальщики ходят в резервное хранилище раньше, чем трогают рабочие данные, потому что без копий компания заплатит выкуп почти гарантированно. Классическое правило 3-2-1 в этой реальности уже не работает — а 4-3-2 как раз и есть индустриальный ответ.
В феврале 2026 года Claude Cowork стирает 15 лет семейных фотографий одной командой. За полгода до этого, в августе 2025-го, случился кейс Nx supply chain: малварь впервые в истории использует локальные ИИ‑CLI как инструмент разведки. В марте этого года Google Cloud Threat Horizons H1-2026 подтверждает: часть украденных в Nx токенов используется кампанией UNC6426 для перехода CI/CD → cloud admin через злоупотребление OIDC. 72 часа от первого коммита до админских прав в AWS.
Всё это примеры того, что может происходить, когда у ИИ‑агента есть руки и мы забываем, на чьей машине эти руки действуют.
Данная статья предназначается для неравнодушных инженеров, AppSec, DevSecOps специалистов и всех тех, кто хоть раз запускал агента у себя на машине. Запрещать агентов в контуре бесполезно, отказываться от них самому глупо, но чем они так опасны? Сперва развеем туман неясности, построим модель угроз, собранную на реальных инцидентах и опубликованных CVE, а после будут конкретные рекомендации, как ограничить агента песочницей без ущерба для эффективности разработки. И как запускать --dangerously-skip-permissions без страха.
Привет, Хабр! На связи uFactor. В одной из предыдущих статей мы рассказывали о туннелировании файловой системы NTFS и затронули тему карвинга. В этой статье — на примере из предыдущей — разберем, как можно осуществить поиск удаленных записей USN-журнала в незанятой области.
Давайте вспомним следующую историю из прошлого материала: мы подменили содержимое файла 5ac761dd7e05df02eef0f0d7562f45c2.png, записав в него другое изображение и при этом сохранив все временные метки в $MFT. Использовали нестандартную технику совместно с туннелированием. Операция для туннеля — переименование файла: file → new_file → file. Также определились, что основными Reason для таких событий будут RENAME_NEW_NAME и RENAME_OLD_NAME.
Теперь посмотрим записи USN-журнала для этого события.
Вы всегда знаете, что скрывается за простым ярлыком? Почему злоумышленники часто используют вредоносные ярлыки для заражения? Сегодня попытаемся разобраться, почему и как простой ярлык может привести к компрометации, как исследовать такие подозрительные файлы и почему эту угрозу так сложно устранить.
AI, которому запрещено быть правым
Когда AI подключают к криптографической системе, обычно задают вопрос: может ли модель найти правильный ответ? Но в криптографии это неправильный вопрос. Правильный вопрос другой: можно ли встроить AI так, чтобы даже при ошибке он не мог принять опасное решение? В этой статье я показываю, как мы реализовали в nonce-observatory отдельный слой governed solver orchestration — архитектуру, в которой AI может:
анализировать public-safe feature contract;
предлагать solver routes;
строить очередь запусков;
помогать с triage и объяснением маршрутов;
но не может:
видеть truth/private/nonce поля;
принимать candidate_d;
принимать k;
формировать recovery claim;
превращать свой score в криптографическое evidence.
Иными словами:
AI suggests. Exact verifier decides. Разбираю, почему для high-assurance систем важен не “умный AI”, а AI без authority, как устроена граница non-escalation, где проходит deterministic integrity gate, и почему в зрелой криптографической системе модель должна оставаться только планировщиком, а не источником истины.
Внутри статьи:
ECDSA / Schnorr / BIP340 контекст;
governed solver orchestration;
non-escalation boundary;
safe payload и forbidden fields;
solver queue vs cryptographic evidence;
deterministic verifier;
clean-control refusal;
claim boundary: что мы не утверждаем.
Статья будет полезна не только тем, кто работает с криптографией, но и всем, кто проектирует AI в критических системах, где ошибка модели не должна автоматически становиться принятым фактом.
Anthropic попала в заголовки прессы, заявив, что Claude Mythos создала «первый удалённый эксплойт ядра, обнаруженный и использованный ИИ». Мы решили изучить, как ей это удалось, и нашли 20-летний баг, скрывавшийся на ровном месте.
Давайте разберёмся, что, по нашему мнению, сделала Mythos, и что это означает для кибербезопасности.
Привет, Хабр!
Мы вернулись через четыре года. Зимой мы уже отметились в блоге Samsung статьёй для тех, кто думает сделать свой MDM. Теперь решили возродить свой блог. Пока на три месяца, а дальше посмотрим.
Мы всегда стараемся доходчиво объяснять сложные вещи, и поэтому начать вторую жизнь нашего блога решили с разбора свежего документа от ФСТЭК России в части защиты мобильных устройств.
Из статьи вы узнаете, что теперь BYOD для госорганов — это не принеси (bring), а купи (buy) себе устройство для работы, и что MDM для мобильных устройств теперь нужен не меньше, чем антивирус. На самом деле даже больше. Почему? Давайте под кат!
Подключить MFA к современному веб-приложению обычно несложно: достаточно подключить SAML или OIDC на стороне самого приложения и включить второй фактор на Identity Provider. Проблемы начинаются там, где сервис не умеет ни в SAML, ни в OIDC, а переписывать его рискованно, дорого или попросту некому.
Во многих корпоративных сетях до сих пор живут монолитные legacy-системы, которые лучше не трогать, и кастомные сервисы, давно оставшиеся без активного развития.
На такой случай придумана концепция предаутентификации. Она позволяет вынести всю сложную логику проверки прав, работу с токенами и криптографией на внешний контур. По сути, перед приложением устанавливается барьер, который отсекает нелегитимные запросы еще до того, как они дойдут до бэкенда.
В этой статье системный инженер Артур Газеев и я, Аскар Добряков, ведущий эксперт направления защиты данных и приложений в К2 Кибербезопасность разбираем, как вынести MFA на периметр для legacy-системы, которую нельзя быстро переписать. Покажем архитектуру решения, объясним, почему выбрали связку Nginx + OAuth2 Proxy + Indeed AM, и разберем, на каких настройках поднимали и отлаживали эту схему.
Аутсорсинг - передача компанией на основании договора части своих задач или функций другой компании, действующей в нужной области. Например, на аутсорсинг могут быть переданы такие функции, как ведение бухгалтерского учёта, уборка помещений, рекламные услуги, транспортные услуги, внедрение и сопровождение информационных систем и, даже, обеспечение информационной безопасности. Тех, кому передаются задачи/функции по договору подряда, еще называют подрядчики. И они составляют подмножество контрагентов, с которыми нужно и можно взаимодействовать безопасно, сокращая поверхность атак и снижая киберриски. Об этом мы писали в нашей статье «Киберугрозы при взаимодействии с контрагентами и как защититься от них». В статье мы выделяли основные киберриски:
Привет, Хабр! Меня зовут Денис Ульянов, я уже 12 лет в IT и последние полтора года руковожу командой Antibot в Wildberries.
До работы в WB я три года был на тёмной стороне и занимался продуктами по сбору данных из открытых источников. Нейтрально намекаю на парсеры :) Должен признать, этот опыт помогает мне отстреливать ботов на ресурсах WB.
Сегодня поделюсь, как моя команда сделала не только антибота, но и собственный парсер для атак на себя. Надеюсь, после публикации не произойдёт массовое нападение ботов!
На прошлой неделе разработчики браузера Mozilla Firefox опубликовали детальный отчет об использовании искусственного интеллекта для поиска уязвимостей (оригинальный пост, новость на Хабре). Публикации предшествовал краткий анонс в конце апреля: тогда стало известно, что в Mozilla получили доступ к ИИ-модели Claude Mythos компании Anthropic, которая пока недоступна публично всем желающим. В анонсе разработчики браузера не стеснялись в хвалебных эпитетах, предрекая скорый конец уязвимостям нулевого дня — когда разработчик ПО обнаруживает баг, который уже эксплуатируется в реальных атаках.
В новой публикации приведены конкретные примеры в виде 12 уязвимостей. Всего в релизе Firefox 150 была закрыта 271 проблема, все они были найдены с применением Claude Mythos. Если добавить уязвимости, найденные и закрытые другими методами (в том числе обнаруженные с помощью других ИИ-моделей), всего за апрель получится 423 патча, в то время как за весь предыдущий год было закрыто 353 проблемы, так или иначе влияющих на безопасность работы браузера. Из 271 уязвимости, найденной с помощью ИИ, 180 имеют рейтинг sec-high — это внутренняя квалификация Mozilla, указывающая на высокую (но не максимальную) опасность проблемы. Такие баги могут быть эксплуатированы без дополнительных сложностей — например, пользователя достаточно будет заманить на подготовленную страницу.