⚙️ Недостаток использования смарт-карт в тирной модели: как одно решение может привести к уязвимости всей инфраструктуры безопасности

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

🏠 Павел Черёмушкин и Анатолий Василенко из команды инженеров безопасности Яндекса детально разобрали на OFFZONE 2025, почему так происходит. А ещё предложили своё решение, так как готовые инструменты от Microsoft имеют ограничения и не покрывают все необходимые сценарии использования.

⏩ В чём проблема

В классической тирной модели инфраструктуры у админов несколько учётных записей для разных уровней доступа в нескольких AD-доменах. Чтобы пароли не повторялись и не хранились на листочках, в систему аутентификации внедряют смарт-карты. Пароль от учёток меняется на случайный, а для входа используют физический токен и ПИН-код. Кажется, что это идеальное решение.

⏩ Но есть нюанс: проброс сертификатов по RDP

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

⏩ Ребята перебрали стандартные решения Microsoft для безопасного удалённого доступа. Увы, они не подошли:

🟣 Restricted Admin. Не работает на доменных контроллерах и требует прав локального администратора, поэтому не подходит для пользователей. При выполнении double hop (подключении с сервера на сервер по цепочке) аутентификация идёт от имени компьютера — это мешает администрированию сервисов, состоящих из нескольких компонент

🟣 Remote Credential Guard. Он тоже не работает на доменных контроллерах, а в новых версиях Windows его ещё и постоянно ломают. К тому же эта технология открывает новые возможности для перемещения внутри инфраструктуры

⏩ Поскольку готовых инструментов нет, Павел и Анатолий разработали инструменты, которые реализуют следующий подход:

🟣 Внедрение в процесс RDP-клиента. Использовали Application Verifier DLLs и COM Hijacking для перехвата интересных нам функций

🟣 Хук вызовов, которыми обмениваются сервер и смарт-карта. С помощью перехвата функции SCardTransmit можно анализировать, какой именно сертификат пытаются использовать для доступа

Это лишь верхушка айсберга. В полном выступлении — технические детали реализации проекта, его подводные камни, разбор APDU-запросов и ответы на вопросы о break-glass-доступе.

📺 Посмотреть доклад можно здесь.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

⚙️ Фестиваль технологий и инженерного воображения

24 сентября мы провели Yandex Neuro Scale — главную конференцию Yandex Cloud. Традиционно многие интерактивы и активности создавали сами разработчики для разработчиков.

Что происходило на площадке:

🟣 Говорящие грибы. Мы подключили мицелий к нейросетям через нейроинтерфейс. Грибы генерировали сигналы, которые YandexGPT превращала в текст, а SpeechKit — в голос

🟣 Серваки и сосиски. На стенде Infrastructure гости собирали серверы, а мы наглядно тестировали безопасность стоек с помощью пальцев-сосисок

🟣 Хаос в Контейнерленде. Мы создали отдельную вселенную, где сервисы не отвечают, поды падают, а хранилища недоступны. Участники могли попробовать себя в роли мастера K8s и исправить типичные ошибки в коде, чтобы всё спасти

🟣 Мечты о будущем можно было визуализировать на платформе SourceCraft, попрограммировав немного с ИИ-ассистентом и подправив YAML-конфиг. Все результаты стали частью частью общего «вихря образов»

Ребята прочитали более 50 докладов, провели 14 воркшопов и организовали 9 зон экспо. Кстати, на офлайн-часть конфы пришли три тысячи участников! Окунуться в атмосферу Yandex Neuro Scale можно по ссылкам ниже ⬇️

〰️ Фото
〰️ Презентации
〰️ Доклады

⏩ А полный разбор нашего техноперформанса вы можете почитать на Хабре.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

⚪️ Как сварить ISO 27001 по рецепту Яндекс 360

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

Меня зовут Люзия Алфёрова, и я консультант по информационной безопасности в Яндекс 360. Сегодня я поделюсь проверенным рецептом внедрения ISO/IEC 27001. А также приёмами, которые помогают нашей команде выдерживать технологический процесс так, чтобы ни одна деталь не была упущена, ничего не пригорело и информационная безопасность получалась стабильно высокого качества.

🍽️ Давайте заглянем на нашу кухню и узнаем, зачем нам вообще нужен этот ISO

Сертификация ISO/IEC 27001 — подтверждение того, что в компании внедрена и эффективно работает система управления информационной безопасностью, которая соответствует международным стандартам. За что она отвечает:

🟣 Единые правила игры. Все команды работают по одним и тем же базовым рецептам

🟣 Прозрачность и контроль. Мы заранее знаем, какие ингредиенты могут испортить блюдо

🟣 Доверие клиентов и партнёров. Подтверждение того, что наши сервисы безопасны

🟣 Непрерывное улучшение. Мы постоянно оттачиваем наши рецепты защиты

🟣 Баланс между стандартизацией и гибкостью. ISO/IEC 27001 помогает нам найти золотую середину

⏩ Как мы готовим основу для сертификации

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

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

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

🟣 Аудит как помощь, а не наказание. Независимая команда внутреннего аудита регулярно пробует каждый сервис на вкус. Её цель — вовремя заметить слабые места и помочь скорректировать курс, а не искать виноватых

⏩ Добавляем специи по вкусу

Без базового набора специй (IAM, логирование, чек-листы) не получится ни одного блюда. Эти практики внедряются во все сервисы по умолчанию. А дальше начинается магия!

Почта требует «долгого тушения» — значит, делаем по-своему. Новый сервис хочет добавить свою специю — пожалуйста! Главное, чтобы результат был безопасным и вкусным. А лучшие находки мы фиксируем на общей доске решений.

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

📖 Если хотите узнать все секреты от шефа, читайте полный разбор нашего фирменного рецепта на Хабре.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

☕️ Музыка, любознательность + кофе

Спросили у ребят на OFFZONE 2025, какие навыки (кроме технических) помогают им в работе. В итоге выяснили, что хороший безопасник — это Индиана Джонс, который изучает артефакты и погружается всё глубже в подземелья кода 🤠

🐚 А вы согласны? Делитесь своим мнением в комментариях.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

💕 Поздравляем с профессиональным праздником, инженеры!

Рассказывайте, как отметили 😎 А мы пока немного погрузимся в историю.

В 1988 году Information Systems Security Association объявила 30 ноября Международным днём защиты информации. Почему именно этот день и этот год?

💻 Дело в том, что 37 лет тому назад свыше 6 тысяч компьютеров, которые работали на сети ARPANET, пали жертвой первого массового вируса-червя. Это был эксперимент, который вышел из-под контроля: вирус создал аспирант Корнеллского университета Роберт Моррис.

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

🔒 Проблемой оперативно занялись учёные из Института Беркли. Им удалось справиться с червём и создать Computer Emergency Response Team. А кейс заинтересовал крупнейшие американские СМИ и указал на то, что сетевую безопасность нельзя недооценивать.

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

⏩ В честь этого мы делимся с вами полезными ссылками на статьи и доклады о защите информации:

🟣 Александр Каледа, Яндекс: «Наш драйвер — ответственность перед миллионами пользователей»

🟣 Составили рекомендации, как безопасно разрабатывать AI‑агентов и мультиагентные системы

🟣 Как атакуют ИИ. Руководитель ИБ «Алисы» и автономного транспорта «Яндекса» — о популярных хакерских техниках

🟣 Расследование инцидентов ИБ в облаке с Yandex Audit Trails

🟣 Что делать, когда нашёл эксплойт: шпаргалка, как помочь владельцу решения

🟣 Хакеры начинают фишинг и выигрывают у Google

🟣 Неугомонный VasyGrek: F6 изучила атаки злоумышленника в августе — ноябре 2025 года

🟣 Обход Cloudflare. Часть I

🟣 Как мошенники крадут криптовалюту под видом вакансий для QA-инженеров

🟣 В кеше — фотка, в ней — payload: новый метод скрытой доставки зловредов

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

📺 Каждый наш бинарник сам рассказывает о своих компонентах

На связи Сергей Краснов, ведущий инженер по информационной безопасности. Многие знакомы с теорией управления уязвимостями, но на практике всегда встаёт вопрос: с чего начать и как сделать процесс по-настоящему рабочим?

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

〰️ Мы поняли, что полагаться на один внешний источник данных об уязвимостях — это рискованно и не гибко

Поэтому создали внутреннюю базу уязвимостей, которая хранит данные по нашей схеме. Это даёт нам:

🟣 Независимость. Мы в любой момент можем сменить поставщика

🟣 Стабильность. Наша база всегда доступна

🟣 Расширяемость. Мы можем обогащать данные любыми полями

Просто генерировать SBOM-файлы недостаточно — их нужно уметь доставлять и сопоставлять с реально работающим кодом

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

Инструменты сборки генерируют SBOM в формате CycloneDX, после чего линкер помещает эти данные в специальную секцию внутри самого бинарника. Необходимая информация становится неотъемлемой частью исполняемого файла, что позволяет сканеру безопасности контейнеров легко извлекать эту информацию прямо из контейнеров.

〰️ Как выглядит наш процесс целиком:

🟣 Собираем все SBOM и обновлённые фиды уязвимостей

🟣 Запускаем MapReduce, который доставляет код к данным

🟣 Выгружаем итоговые результаты их обработки

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

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

⏩ И это лишь часть большой работы, которую мы проделали, чтобы построить наш Vulnerability Management. Остальное ищите в полной записи доклада с Security Party на ютубе или в VK Видео.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity