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

Рендерер Scratch имеет долгую историю связанных с SVG уязвимостей. Их источником становится то, что Scratch парсит сгенерированный пользователем (то есть контролируемый нападающими) контент в элемент <svg> и добавляет его в основной документ для выполнения различных операций (например, для измерения ограничивающего прямоугольника SVG более надёжным образом, чем viewbox или width/height).

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

Я считаю, что подход Scratch к санации SVG обречён на провал. Чтобы объяснить это, нам нужно совершить путешествие по истории санации SVG в Scratch и посмотреть, насколько хорошо он с этим справлялся.

У вирусных аналитиков есть небольшая профессиональная трагедия: работать с вредоносами обычно скучнее, чем может казаться по их вычурным названиям. За каждым ShadowSomething RAT/Loader/Stealer почти всегда скрывается один и тот же набор знакомых техник: загрузчик, закрепление в системе, канал связи с C2, немного обфускации «для галочки».

Но иногда попадаются образцы, которые действительно удивляют. В недавнем расследовании нам встретился именно такой. Речь пойдет о PhantomRShell — бэкдоре группировки PhantomCore (Head Mare), атакующей компании из России и Беларуси.

Главная «фишка» PhantomRShell — в том, как он маскирует свое присутствие в системе. Вредонос использует встроенный дизассемблер, чтобы перехватывать системные вызовы и скрывать свои файлы от пользователя и защитных инструментов. Проще говоря: файл лежит на диске, но для средств анализа его как будто не существует. 

На связи Александр, вирусный аналитик отдела реагирования Бастиона и автор телеграм-канала @section_remadev. Сегодня разберем, как устроен PhantomRShell: от цепочки заражения до механизма сокрытия, который делает этот бэкдор заметно интереснее большинства его «коллег по цеху».

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

Привет, Хабр! Это Сергей Померанцев и в этот раз предлагаю обсудить, почему системы класса Privileged Access Management не всегда защищают от администратора, действующего злонамеренно.

Давайте договоримся, кто является нашим сегодняшним героем. Я буду считать, что «злонамеренный администратор» – это:

во-первых, пользователь – мы сами предоставили ему полномочия доступа в инфраструктуру (как наш собственный сотрудник, так и подрядчик);

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

в-третьих – субъект, действующий злонамеренно, с пониманием, что причиняет ущерб.

Ну, т. е., о хакерах из какого-нибудь далекого островного государства мы сегодня не говорим – как и о тех несчастных, кто, набрав rm –rf, перед нажатием «Enter» зацепил слэш вместо точки.

На всякий случай кратко отвечу на вопрос о том, зачем администратору такое творить. Мотивов может быть много: месть работодателю/руководителю, обоснование собственной значимости (сами формируем проблему – сами ее устраняем – получаем поощрение), в отдельных случаях – личная выгода (скажем, банально провести самому себе в «кадрах» сверхурочные) и др.

Посмотрим на арсенал средств контроля и реагирования, которыми оснащена типичная PAM-система:

1. Запись сессий.

2. Черный список команд для текстовых протоколов.

3. Keylogger.

А что и как будет делать наш «злонамеренный администратор», чтобы реализовать свои «злые намерения»? Исходя из того, что о присутствии PAM-системы он знает?

Запустит какие-то «плохие» команды как есть? Нет, это же откровенное «палево»! Пойдет в оснастку Active Directory и что-то настроит в ней? Снова нет: все это будет на видео! Решит свои вопросы в веб-интерфейсе какого-то приложения? И тут – мимо!

DevSecOps по-прежнему часто сводят к подключению сканеров в CI/CD. Дальше сценарий предсказуем: пайплайн замедляется, отчёты копятся, команда теряет к ним интерес. Проблема обычно не в инструментах, а в том, что их внедряют поверх неизменённых процессов.

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

Привет, Хабр.

У меня бывают неожиданные заказы, из неожиданных сфер на фрилансе. Недавно писал про то как прилетел большой проект по классификатору фоток. А теперь пришел запрос на реверс! Не могу вдаваться в подробности проекта - много конфиденциального - но я расскажу про конкретный разбор одного .dll файла. Открыл Ghidra, кликнул на функцию, включил декомпилятор - и передо мной встала стена.

Не метафорическая стена. Прям реально стена!

И вот пока я эту функцию ковырял, переименовывал переменные, ходил по ссылкам, открывал соседние функции, смотрел строки, в какой-то момент меня щёлкнуло.

Это же сканворд.

История про совместную работу разработчика и патентного поверенного

Привет, Хабр! Меня зовут Михаил, я руководитель отдела внутренних технических проектов в ГК InfoWatch. 26 апреля прошёл международный день интеллектуальной собственности, так что расскажу вам одну историю по теме. Недавно я принял участие в новом для меня проекте, связанном с патентованием технологии «Система и способ контролируемого доступа к веб-ресурсу», которую я разработал. Опыт оказался интересным, мы получили патент всего за 2,5 месяца вместо стандартных от 6 месяцев до 1,5 лет, поэтому захотелось рассказать о том, какой путь проходит технология от её изобретения до защиты. А именно:

- Зачем вообще защищать инновационные разработки
- Какие задачи можно решить путем этой защиты
- Особенности совместной работы разработчика и патентного поверенного
- Чем для меня оказался полезен этот новый опыт
- И многое другое на примере нашего случая

Впрочем, обо всём по порядку.

К 2028 году в корпоративных средах будет работать 1,3 млрд AI‑агентов, а классическая модель identity по‑прежнему исходит из допущения «один деятель — один человек». Разбираем, что ломается в аутентификации, почему service account и OAuth‑токен больше не закрывают задачу, и как мы в Ideco смотрим на ближайшее развитие средств защиты: непрерывная биометрия для людей и делегированные токены для агентов.

Цифры, которые ломают ИБ‑ландшафт

На RSAC 2026 Microsoft, опираясь на прогноз IDC, заявила о 1,3 млрд AI‑агентов в корпоративных средах к 2028 году (Windows Forum, RSAC 2026, Lantern Studios). Это не «копилоты, которые помогают писать письма» или «чатики» — это автономные исполнители, у которых есть права, токены и доступ к продуктовым системам.

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

Атакующая сторона тоже меняется. В отчёте о кампании GTG-1002 Anthropic зафиксировала первую массовую AI‑оркестрированную операцию: взломанная версия Claude, подключённая к набору MCP‑серверов, выполнила 80–90% тактических операций самостоятельно — разведку, поиск уязвимостей, эксплуатацию, сбор учётных данных, латеральное движение (Anthropic, Disrupting the first reported AI‑orchestrated cyber espionage campaign, Paul, Weiss разбор). Человек был нужен на 4–6 точках принятия решений за всю кампанию.

И последняя цифра, без которой картина неполная. По 2025 Identity Security Landscape от CyberArk (опрос 2 600 ЛПР‑ов в сфере ИБ), на каждую человеческую идентичность в средней организации приходится 82 машинных; 42% этих NHI имеют привилегированный доступ или доступ к чувствительным данным, при этом 88% респондентов всё ещё относят определение «привилегированный пользователь» исключительно к людям. 87% компаний за последние 12 месяцев пережили минимум два успешных identity‑центричных инцидента.

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

В этой статье разбираем, как балансировщик становится точкой принятия решений в сценариях отказоустойчивости — от health checks до переключения между ЦОД — и почему без этих механизмов одной «балансировки» недостаточно.

Привет! Меня зовут Денис, я руковожу группой мониторинга и анализа инцидентов информационной безопасности. Мы отслеживаем события в инфраструктуре, ищем подозрительную активность, расследуем инциденты, взаимодействуем с внешним SOC и помогаем сотрудникам разбираться с вопросами киберграмотности.

За последние пару лет стало особенно заметно: атаки меняются быстрее, чем процессы защиты успевают адаптироваться. Они становятся дешевле, масштабнее и доступнее — во многом за счет ИИ.

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

Хабр, привет!

На связи Александр Леонов, ведущий эксперт PT Expert Security Center и дежурный по самым опасным уязвимостям месяца. Мы с командой аналитиков Positive Technologies регулярно исследуем информацию об уязвимостях из баз и бюллетеней безопасности вендоров, социальных сетей, блогов, телеграм-каналов, баз эксплойтов, публичных репозиториев кода и выявляем во всем этом многообразии сведений трендовые уязвимости. Это те уязвимости, которые либо уже эксплуатируются вживую, либо будут эксплуатироваться в ближайшее время.

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

Привет, Хабр!

Ну вот вы ставите Яндекс Go, жмёте «Разрешить» на всё подряд — микрофон, контакты, местоположение. Такси же, надо. А потом выясняется, что приложение лезет в буфер обмена. 16 раз в разных местах кода. Зачем такси буфер обмена — я так и не понял.

Короче, я взял семь популярных Android-приложений и разобрал их по косточкам. SAST, реверс-инжиниринг, декомпиляция DEX, разбор манифестов, ковыряние в нативных библиотеках. Под раздачу попали: Яндекс Go, Карты, Музыка, Пэй, Телемост, Mir Pay и мессенджер МАКС (бывший ICQ New / VK Messenger).

Спойлер: один мессенджер умеет распознавать ключевые слова прямо в аудиопотоке звонков. Не метаданные, не «кто кому звонил» — а именно слова.

<cut/>

Привет, Хабр! На связи команда UserGate uFactor и я, Иван Князев!

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

Лето 2024 года. Народной артистке звонит «сотрудник ФСБ» и взволнованным голосом сообщает: ее счета взломаны, деньги вот-вот уйдут мошенникам, но есть способ все спасти. Для этого нужно срочно продать квартиру в рамках спецоперации. Знакомая история? Скорее всего, вы уже догадались, чем она закончилась. Но давайте посмотрим на нее не как на светскую хронику, а как на идеально выстроенную многоходовую операцию с использованием методов социальной инженерии.

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

Привет, Хабр! Меня зовут Артём Чуйков, я инженер компании Innostage — первого кибериспытанного интегратора сервисов и решений в области цифровой безопасности. Я занимаюсь внедрением межсетевых экранов на промышленных предприятиях, и сегодня хочу поделиться практическим опытом.

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

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

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

Для объектов критической информационной инфраструктуры внедрение СОИБ является не просто рекомендацией, а требованием регуляторов — ФСТЭК, ФСБ, а также стандартов, таких как ГОСТ Р ИСО/МЭК 27 001 и других.

За нами кто‑то следит!
Вот ты занят своим делом, и тебе звонят с предложением купить недвижимость во Владивостоке, а ты даже не понял, откуда у них твой номер. Как вообще они о тебе узнали?

Т.е. с одной стороны РКН вводит огромные штрафы за утечку персональных данных, а с другой — постоянно идут звонки с предложениями, хотя ты своих контактов не оставлял, и разрешения на перезвон не давал.

Внутри:
— 4 метода слива наших телефонов
— Как и кому сливаются сайты (домены) которые мы посещаем
— Как сливаются входящие и исходящие на наш номер телефона
и как с этим бороться.

Чем должен заканчиваться пилот по кибербезопасности — покупкой? В идеале да. Но на практике он часто заканчивается неопределённостью: не из‑за плохого продукта или пустого бюджета, а потому что непонятно, как вообще оценивать результат. Достаточно ли показанных характеристик для реальной защиты? Не начнёт ли система «тормозить» сервисы под боевой нагрузкой? Насколько комфортной будет долгосрочная эксплуатация? На примере межсетевого экрана веб‑приложений (WAF) разберем, по каким критериям можно оценить пилот и на что смотреть заказчику в отчетах по пилоту, чтобы было проще принять решение о покупке.

За последние два‑три года компании в РФ перестали относиться к ИИ как к «чудо машине» и начали встраивать его в рабочие процессы: от помощи специалистам контакт‑центров в чатах с клиентами и «серым» помощникам разработчиков до написания полноценных продуктов. Если раньше нельзя было сказать, что ты использовал ИИ для задачи, так как тебя закидают помидорами, сегодня — этот навык must have для каждого. В этой статье речь пойдет о безопасной разработке с использованием генеративных ИИ. Крупные опросы и отчёты фиксируют одинаковую картину: большинство организаций уже экспериментируют с LLM‑системами или планируют их внедрение, в том числе в зонах, где раньше работали только люди или классические скрипты.

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

Почти в каждой крупной корпоративной или государственной системе рано или поздно возникает задача — авторизация с использованием усиленной квалифицированной электронной подписи (УКЭП)

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

И каждый из них добавляет определенный набор требований:

- где и как проверять сертификаты;

- как организовать доверие к удостоверяющим центрам;

- как встроить УКЭП в веб-приложения;

- как обеспечить масштабирование и эксплуатацию;

- как работать с разными типами клиентов и устройств.

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