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

Статья обзор на «лучшую профессию» современности и будущего — «информационная безопасность».
Идея статьи пришла мне в голову, когда я готовила презентацию для студентов колледжа — будущих специалистов по информационной безопасности.

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

Найди одно отличие которое поможет избежать проблем. Новый тип атак на невнимательных пользователей.

Практический разбор того, как я вынес security-проверки Java-проектов из разрозненных CI/CD-скриптов в переиспользуемый Gradle plugin

Единый плагин для сканирования на безопасность Java проектов. Maven. Или как проверять кучу микросервисов на безопасность управляя этим в одном месте

Привет, Хабр! Меня зовут Максим Кишмерешкин, я ведущий аналитик центра мониторинга и реагирования «Инфосистемы Джет». Сегодня мы поговорим про довольно старую, но до сих пор остающуюся популярной тему — LOTL. Напомню, что LOTL (living on the land), или как я его называю «жизнь на подножном корме» — это использование в атаке инструментов, которые уже есть в системе жертвы. Мы поделимся тем, как мы этот класс атак встречали в реальных кейсах, какие процедуры и техники выявляли, и расскажем, как их можно детектировать.

Приветствую, Хабр!  В анализе криптографических алгоритмов достаточно часто используется понятие оракула. Оракул – это некоторая гипотетическая вычислительная сущность, которая может мгновенно выполнять конкретные требуемые криптоаналитику операции. Например, выдавать истинно случайные числа (случайный оракул), или зашифровывать/расшифровывать данные на некотором априори известном оракулу ключе шифрования (соответственно, оракул зашифрования/расшифрования). 

Предлагаю в этой статье пойти дальше и рассмотреть оракул, способный найти прообраз (точнее, совокупность возможных прообразов) заданного хеш-кода конкретной хеш-функции. Поскольку хеш-функции часто используются в более сложных конструкциях, предлагаем посмотреть и порассуждать, как наличие такого оракула влияет на свойства вышележащих криптографических механизмов. В качестве их примера рассмотрим конструкции HMAC (Hash-based Message Authentication Codes – коды аутентификации сообщений на основе хеширования).

«У нас было два пакета findings SAST’а, семьдесят пять CVE с критичностью — Critical, пять дублей одной и той же CVE в разных сервисах, пол солонки false positive и целая россыпь уязвимостей всех сортов и расцветок: SQLi, XSS, SSRF, RCE, IDOR, утекшие секреты, misconfigs в Kubernetes, написанные человеком, который явно не планировал дожить до аудита.

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

Не то чтобы это был необходимый запас для управления безопасностью приложений, но если уж ты решил строить ASPM через агрегацию всего подряд, рано или поздно ты оказываешься именно в такой машине — на полной скорости, без карты, с разработчиками на заднем сидении, которые только и спрашивают: “Что из этого реально надо исправлять?”». 

Всем привет! Меня зовут Артем Пузанков, я руководитель отдела консалтинга безопасной разработки в Бастионе. Сегодня хотелось бы порефлексировать с вами про управление состоянием безопасности приложений, ASPM, AI-generated код и AppSec.

Эта статья о том, почему будущее ASPM не в том, чтобы собрать все дефекты в «единое окно», а в том, чтобы сопоставить обнаруженные находки, проверить достижимость и отделить реальные угрозы от шума (читай технического долга).

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

Но уже в первом квартале 2026 года картина изменилась. Что произошло и как это меняет подходы к защите — разбираемся под катом.

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

Важные примечания: эта статья предназначена исключительно для образовательных целей. Я НЕ оправдываю и НЕ поддерживаю анализ, обход и взлом игр (будь то с защитой Denuvo или какой-то другой) и НЕ поддерживаю пиратство ни в каком виде. Пожалуйста, поддерживайте разработчиков, упорно трудившихся над этими играми и мерами защиты (мы любим тебя, Blaukovitch).

Цель этой статьи — проанализировать такой способ обхода и способ защиты от него со стороны Denuvo.

Почему был выбран этот способ

Почему вообще выбрали этот способ?

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

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

Введение

В этой статье мы проанализируем релиз обхода основной DLL из недавно выпущенной Resident Evil: Requiem с cs.rin.ru и подробно расскажем о том, как гипервизоры наподобие HyperDBG можно использовать для спуфинга аппаратных значений, фактически, обеспечив таким образом обход DRM Denuvo.

Юрий Подгорбунский, Security Vision

Что есть система безопасности?

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

Системы безопасности создаются субъектами критической информационной инфраструктуры (далее – субъекты КИИ) и включают в себя правовые, организационные, технические и иные меры, направленные на обеспечение информационной безопасности.

Субъектами КИИ являются различные государственные организации и предприятия, юридические лица Российской Федерации, которым на праве собственности или аренды принадлежать объекты критической информационной инфраструктуры (далее – объекты КИИ).

В свою очередь, к объектам КИИ относятся:

·         автоматизированные системы управления (далее – АСУ);

·         информационные системы (далее – ИС);

·         и информационно-телекоммуникационные сети (далее – ИТКС);

которые на законном основании принадлежат субъектам КИИ.

Для чего необходимо создание систем безопасности?

Целью создания систем безопасности является обеспечение устойчивого функционирования значимых объектов критической информационной инфраструктуры (далее – значимые объекты КИИ) при проведении в отношении них компьютерных атак.

Почему системы безопасности должны быть созданы для значимых объектов КИИ? Начнем с того, что предварительно, чтобы объект КИИ стал значимым, проводится категорирование таких объектов – в результате процедуры они делятся на значимые и объекты, которым не присваивается категория значимости. И далее к значимым объектам КИИ предъявляются различные требования безопасности, в частности, создание систем безопасности, а объекты, которым не присваивается данная категория, остаются на откуп субъекта КИИ – т.е. организации.

В части 8, когда мы говорили о том, что нет универсального инструмента для работы в различных концах географии, я объяснял это тем, что имеются местные особенности, и то, что работает в одном месте, не работает в другом.

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

Хорошая же новость состоит в том, что есть агрегатор инструментов, который помогает определиться в зависимости от региона работы: https://map.wddadk.com — он охватывает 242 территории и содержит ссылки на 1592 ресурса, почти весь мир, без Республики Конго — страна не развита в плане интернета.

Раньше я относился к приватности в браузере довольно наивно. Казалось, что если включить режим инкогнито, поставить блокировщик рекламы и периодически чистить cookies, то ты уже сделал примерно всё, что может обычный пользователь. Потом я начал разбираться в browser fingerprinting и понял неприятную вещь: браузер сам по себе может быть идентификатором. Даже без cookies сайт видит набор технических признаков — от размера окна и WebGL до шрифтов, языка, часового пояса и поведения JavaScript API. И если эти признаки достаточно редкие, пользователя можно узнавать снова и снова.

После этого мне стало интересно посмотреть на браузеры не как на «быстрый/удобный/красивый», а как на инструменты приватности и анонимности. Что реально скрывает Chrome? Почему Firefox нужно настраивать аккуратно? Чем Brave отличается от обычного Chromium? Что DuckDuckGo режет, а что не может скрыть? Почему AI‑браузеры вроде Perplexity создают новую поверхность утечек? И почему Tor остаётся отдельной категорией, но тоже не магической кнопкой «стать невидимым».

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

Ledger — это сложная машина Windows на TryHackMe, в центре которой находится неправильная конфигурация служб сертификатов Active Directory (AD CS). Первоначальная разведка выявляет контроллер домена (labyrinth.thm.local) с включенной аутентификацией SMB null и LDAP, раскрывающим учетные данные пользователя в примечаниях. Через certipy-ad находим шаблон сертификата ServerAuth , который уязвим к ESC1, что позволяет любому аутентифицированному пользователю запросить сертификат, выдавая себя за администратора домена. Хэш NT администратора извлекается из поддельного сертификата, а psexec предоставляет командную оболочку NT AUTHORITY SYSTEM. Альтернативный путь эксплуатации через аутентификацию LDAP Schannel для случаев, когда Kerberos PKINIT не срабатывает.

Будит уведомление — 5:03. Сообщение в Telegram от хорошего знакомого: «Привет UserName, могу я тебя попросить?»

Разве я могу отказать хорошему человеку?

Просьба по-человечески тёплая: проголосовать за ребёнка в благотворительном конкурсе. Только знакомый перестал отвечать, домен турецкий, ссылка по HTTP, а под безобидной голосовалкой лежат: PHP-клоакер на свежей /24-подсети с гонконгской шелл-компанией в whois, форк Telegram Web, который проксирует MTProto, и сервис-воркер, ворующий вашу сессию.

Разбираем атаку по слоям — от curl 403 до угнанного аккаунта.

Всем привет! Это Сергей Зюкин, разработчик экспертизы runtime-radar — опенсорсного продукта, обеспечивающего безопасность контейнерной среды выполнения. Я подготовил для вас статью, в которой расскажу, как можно обнаружить инфостилер, встроенный в библиотеку LiteLLM в результате ее недавней компрометации. Помимо этого, мы, конечно же, рассмотрим и боковое перемещение внутри Kubernetes-инфрастуктуры, которое происходит, если скрипт инфостилера запускается в поде с достаточными привилегиями.

Мы не смогли удержаться и проверили, что Runtime Radar может обнаружить при реализации подобной атаки.

Но обо всем по порядку.

Всем привет! Собрали самые интересные ИБ‑события апреля в наш дайджест. В прошлом месяце в заголовках гремела Mythos от Anthropic, в очередной раз заявившей о революции в кибербезе, за которой пока не видно ничего кроме пиара. Не меньше шуму наделал и взлом суперкомпьютера Китая, которого не было.

Апрель также стал месяцем многочисленных атак на цепочку поставок — о них сообщали чуть ли не каждый день. Кроме того, был обнаружен неизвестный предшественник Stuxnet, в ядре Linux нашли худшую LPE за долгое время, а северокорейские хакеры стянули больше полумиллиарда долларов в крипте. Об этом и других ключевых новостях прошлого месяца читайте под катом!

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

Атакующие давно не ломают стены – они входят в дверь по легитимным учетным данным. Разбираем, почему модель периметра: «межсетевой экран + VPN + кольцо доверия» структурно несостоятельна, как идентификатор становится новой плоскостью управления безопасностью и что меняет появление AI-агентов как самостоятельного класса субъектов.

Сценарий, с которого начинается типичный взлом в 2026 году

Сотрудник компании открывает фишинговое письмо, переходит по ссылке, получает на ноутбук инфостилер. В течение нескольких минут вредонос выгружает то, что лежит в браузере: сохранённые пароли, cookie-файлы, активные SSO-сессии Entra ID и облачных сервисов. Через сутки лог уходит на теневую торговую площадку, где его покупают за десятки долларов. Ещё через несколько дней атакующий открывает браузер, подставляет украденную сессию – и логинится в корпоративный SaaS. MFA не срабатывает: токен уже аутентифицирован. Межсетевой экран ничего не видит: это обычный HTTPS с легитимным User-Agent.

Согласно отчету Verizon DBIR 2025 (авторитетному источнику в области ИБ), злоупотребление учётными данными – доминирующий вектор первичного доступа второй год подряд: 22% всех подтверждённых взломов начинаются именно с украденных учётных данных, а на веб-приложениях этот показатель доходит до 88. 54% жертв вымогательского ПО имели предварительную компрометацию в логах инфостилеров ещё до атаки. В прошлом году вредоносы-инфостилеры увели 1,8 млрд учётных данных и обеспечили 86% взломов.

Атакующему часто не нужен эксплойт. Не нужен 0-day. Не нужен обход NGFW. Ему достаточно того, что у вас есть пользователь, у пользователя есть учётные данные, а у учётных данных – действующая сессия.

Привет, уважаемые эксперты!

На связи Альбина Аскерова, руководитель направления по взаимодействию с регуляторами Swordfish Security, и сегодня в моём обзоре будет методический документ ФСТЭК России от 12 апреля 2026, определяющий состав и содержание мероприятий и мер по защите информации в информационных системах.

Форк репозитория — операция настолько привычная, что на нее редко смотрят с подозрением. Но что, если через обычный форк можно запустить произвольный код на CI/CD-воркере чужой приватной компании? 

Именно такую цепочку мы обнаружили в GitFlic — отечественной платформе для совместной разработки ПО и хранения исходного кода от компании «РеСолют». 

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

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

Обнаруженные нами уязвимости были оперативно исправлены разработчиками компании «РеСолют» и зарегистрированы в БДУ ФСТЭК: BDU:2025-12462, BDU:2025-12463, BDU:2025-12464.