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

В прошлом году мы уже рассказывали тут, как R-Vision SOAR помогал командам защитников на Standoff 16 автоматизировать реагирование на инциденты, работая в условиях непрерывных атак. Тогда мы впервые представили продукт на одной из самых масштабных кибербитв страны, где по масштабу инфраструктуры условия близки к корпоративной среде, но плотность атак и скорость развития событий значительно выше.

На Standoff 17 мы решили расширить сценарий участия и впервые представили R-Vision SIEM, систему управления событиями безопасности. Решение использовала команда akPots для мониторинга инфраструктуры телеком-оператора, обнаружения атак и расследования инцидентов.

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

Всем привет! На связи Сергей Иванов, аналитик технологий машинного обучения R‑Vision.

В первой части эксперимента мы выяснили, как на производительность локальной LLM влияют длина контекста, количество параллельных запросов и объем генерируемого ответа. Стресс‑тесты позволили определить границы конфигурации Qwen3.5–122B‑A10B‑GPTQ, vLLM и NVIDIA RTX PRO 6000 Blackwell Max‑Q с 96 GB видеопамяти.

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

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

Отдельно остановимся на режиме рассуждений. В сценарии интеграции LLM в конвейер R‑Vision SOAR мы сознательно использовали модель с отключенным thinking mode (режимом рассуждений). Ниже на результатах реальных экспериментов покажем, почему именно такой режим оказался наиболее эффективным для задач SOC.

Всем привет! На связи Сергей Иванов, аналитик технологий машинного обучения R-Vision.

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

Материал будет полезен ML-инженерам, работающим с LLM, а также CISO и SOC-командам, которые оценивают применение генеративного ИИ в задачах кибербезопасности.

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

На R-EVOlution Conference 2026 такой площадкой стал технический трек. Мы запустили его впервые как отдельную секцию для специалистов, которым важны не общие формулировки, а конкретные сценарии, ошибки и рабочие решения.

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

В этой статье собрали короткий гид по техническому треку: кто выступал, о чём рассказывал и какие доклады стоит посмотреть, если вам близки практические задачи SOC, VM, Threat Hunting, TI, SIEM/SOAR, AI Security и Linux detection.

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

В начале октября этого года прошла Standoff 16 – крупнейшая кибербитва России и одно из самых реалистичных соревнований в мире по кибербезопасности. На виртуальном полигоне «Государства F» сошлись более 30 команд атакующих и защитников. В течение трёх дней участники оттачивали навыки противодействия кибератакам, отражая атаки на инфраструктуру, максимально приближенную к реальной: городскую среду, металлургию, банковский сектор и логистику.

В этот раз событие стало особенным: на Standoff защитники получили возможность работать с системой класса SOAR – R-Vision SOAR. Для нас, как разработчика, это стало настоящим экспериментом: мы хотели проверить, как автоматизация поведёт себя в динамике кибербитвы, когда атакующие действуют максимально агрессивно и счёт идёт на минуты.

В статье рассказываем и показываем как всё прошло.

Привет, Хабр! На связи Алина Корсакова, тестировщик в кластере качества RVN Support, R-Vision.

Если вы работаете в разработке, то наверняка сталкивались с QA-командой. Кто-то считает тестировщиков тормозом релиза, кто-то — формальными исполнителями чек-листов, а кто-то вообще полагает, что всё за них решит автоматизация.

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

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

 – Что самое важное в тестировании?

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

Хабр, привет! Меня зовут Елена Петренко, я бизнес-аналитик по информационной безопасности в компании R-Vision.

В прошлой статье мы подробно рассматривали интеграцию SOAR-системы с АСОИ ФинЦЕРТ для автоматизации взаимодействия с регулятором. Сегодня я расскажу, почему интеграции в целом являются ключевым элементом эффективного управления ИБ, какие бывают способы интеграции систем и рассмотрю практические кейсы интеграции SOAR с другими популярными сервисами: Telegram и Kaspersky Security Center, а также поделюсь опытом работы с АСОИ ФинЦЕРТ в более широком контексте.

Привет, Хабр! Меня зовут Елена Петренко, я бизнес-аналитик по информационной безопасности в компании R-Vision. Сегодня хочу поделиться историей о том, как мы разработали интеграцию между SOAR-системой и АСОИ ФинЦЕРТ для автоматизации взаимодействия с регулятором. Вы узнаете, какие задачи она решает и какие технологии лежат в её основе.

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

Меня зовут Ксения Змичеровская, я системный аналитик в компании R-Vision. Совсем недавно мы выпустили собственный плагин R-Object для работы с R-Vision SIEM. Наш плагин – это полноценная среда разработки с преднастроенными шаблонами объектов, подсветкой синтаксиса, подсказками и валидацией VRL-кода. Плагин позволяет выполнять автоматическое тестирование правил, проводить полнофункциональную пошаговую отладку, а также запускать тесты на производительность.

Объекты экспертизы в R-Vision SIEM составляются с помощью специального языка R-Object. Каждый объект описывается в отдельном yaml-файле с расширением .ro и может содержать блоки на языке выражений VRL. В этой статье мы подробно изучим работу с плагином от его установки до запуска тестов и написания правил.

Привет, Хабр! На связи команда R-Vision.

Мы традиционно выступили партнером фестиваля PHDays, который прошел в Лужниках с 23 по 26 мая. Наши коллеги активно делились экспертизой — 5 докладов, большинство из которых посвящены технологии SIEM, вызвали живой интерес у аудитории.

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

Меня зовут Валерия Чулкова, я продакт-менеджер R-Vision TIP. Сегодня совместно с Анастасией Перковой и Сергеем Ивановым мы расскажем про сервис для распознавания отчетов о киберугрозах, созданный командой экспертов в области машинного обучения R-Vision. В этой статье мы объединили усилия ML-разработчика и двух ML-аналитиков.

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

В предущей статье мы разобрали основы и механизмы работы атаки DCSync, а также рассмотрели несколько наиболее популярных утилит для ее реализации: mimikatz, secretsdump, DSInternals и существующие между ними различия. В результате анализа стало понятно, что у всех утилит прослеживается один и тот же принцип проведения атаки и присутствует одинаковый фактор для ее выявления - DRSReplicaSync.

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

DCSync - атака, позволяющая злоумышленнику выдавать себя за контроллер домена (DC, domain controller) с целью получения учетных данных пользователей для последующего горизонтального перемещения в сети и/или доступа к конфиденциальной информации.
В основе атаки лежит механизм, предусмотренный для выполнения репликации данных между контроллерами домена (DC).

Доброго времени суток, Хабр!

В этой статье я продолжу исследование вредоносного ПО на реальных сэмплах, используемых различными АРТ-группировками, в частности группировки Kimsuky. APT Kimsuky известна своими фишинговыми кампаниями с целью проникновения в организации и кибершпионажа. В этом году злоумышленники активно работали и на территории Российской Федерации.

Я не буду углубляться в описание всех тактик и инструментов данной группировки, которые постоянно развиваются и о которых уже было сделано достаточно исследований, доступных в открытых источниках. Основное внимание будет уделено практической части – расследованию инцидента, связанного с распространением Kimsuky вредоносных документов форматов Power Point и Microsoft Office Word.

Давайте приступим.

Всем привет!

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

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

В предыдущей части мы рассмотрели основные способы обхода UAC, которые используют в своей основе DLL Hijacking, Registry, COM, привели небольшой обзор источников событий и возможный вариант по детектированию UAC Bypass, который базируется на базе COM.

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

Сегодня мы хотим рассказать о возможных вариантах обхода контроля учётных записей пользователей (UAC) и способах их детектирования.

Если коротко, UAC (User Account Control) – механизм, поддерживаемый всеми последними версиями Windows, который призван предотвратить несанкционированныадминистративные действия, потенциально опасные для системы. UAC Bypass является достаточно распространённой атакой среди вредоносного ПО. Из последних ярких примеров – червь Raspberry Robin, который использует утилиту fodhelp.exe. Малварь, обнаруженный Microsoft в сетях сотен организаций, способен обходить User Account Control (UAC) в зараженных системах с помощью легитимных инструментов Windows. Поэтому мы решили не проходить UAC Bypass стороной, а подробно его изучить.

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

Но для начала предлагаем ознакомиться с самим механизмом работы UAC немного глубже. Если для вас UAC не нуждается в представлении, то можете сразу переходить к разделу Способы обхода UAC.

Привет, Хабр!  В предыдущей статье мы разобрали пример фишинга с использованием зловредного PDF вложения на примере задания GetPDF от CyberDefenders.

Сегодня мы поговорим о руткитах (от англ. root – корневой, kit –набор, в данном контексте означает получение неограниченного доступа) – типе вредоносного ПО, предназначенного для предоставления злоумышленнику прав суперпользователя на устройстве жертвы без ее ведома. А также потренируемся в расследовании инцидента, связанного с атакой и заражением этим зловредом.

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

Те, кто хорошо знаком с Active Directory (AD), согласятся, что несмотря на то, что протокол аутентификации Kerberos, по-прежнему остается одним из самых безопасных, архитектурные особенности системы активно используются злоумышленниками для проведения кибератак. В том числе и с помощью Golden Ticket, которая нацелена на уязвимые системные настройки, слабые пароли или распространение вредоносного ПО. Атаки с использованием Золотых билетов весьма опасны. Злоумышленник не только нарушает обычные рабочие процессы аутентификации, но и получает неограниченный доступ к любой учетной записи или ресурсу в домене AD.

Многие специалисты уже довольно долгое время стремятся задетектировать технику Golden Ticket и на сегодняшний день есть разные методы для ее обнаружения. Мы разберем основные существующие примеры детекта Золотых билетов и расскажем о том, почему, как нам кажется, эти методы могут не сработать. А также приведем способ детектирования, который, опираясь на нашу практику, оказался более эффективным для выявления подобных атак.  Мы не беремся утверждать, что предложенный нами метод является единственным верным способом детектирования Golden Ticket, скорее наша цель поделиться с вами успешным опытом обнаружения подобной атаки.

Привет, Хабр! Меня зовут Антон, я ведущий инженер по ИБ в компании R-Vision, принимаю активное участие в развитии экспертизы в части расследования инцидентов и реагирования на них. А в свободное время я увлекаюсь расследованиями в направлении Digital Forensics & Incident Response (DFIR), Malware Analysis.

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

Замечу, что одной из самых популярных техник взлома крупных мировых корпораций был и остается фишинг с вредоносным вложением T1566.001. Пожалуй, яркий тому пример – взлом Garmin в июле 2020 года, когда известный производитель умных устройств подвергся атаке хакеров-вымогателей. Преступники атаковали системы Garmin с помощью малвари WastedLocker. В результате, сервисы компании на три дня вышли из строя, так как авторы малваря зашифровали данные и требовали выкуп в размере $10 млн за ключи дешифровки.

Как известно, логика подобного проникновения в инфраструктуру довольно проста: атакующие проводят таргетированную фишинговую кампанию – targetor sprear[T1566.001], доставляют в корпоративную среду зловреды с помощью рассылки электронных писем с вредоносными вложениями и ссылками. Пользователь открывает файл (pdf, xlsx, docx и др.), тем самым запуская вложенный туда вредоносный код, который подгружает недостающие для атаки компоненты (вирусы, трояны, шифровальщики, бэкдоры и тд.).

В этой статье я не буду углубляться в тактики и инструменты фишинговых атак, а хочу поделиться с вами личным опытом разбора техники с фишингом вредоносного файла * pdf и наглядно продемонстрировать ход расследования подобного инцидента на примере лабораторного задания GetPDF с ресурса Cyberdefenders.

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