РТ-ИБ

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

📢 В новом выпуске рубрики #От_Эксперта Андрей Амосов, руководитель направления машинного обучения в РТ-ИБ, расскажет о том, как ML применяется в ИБ сегодня, какие сложности возникают при создании таких решений и что необходимо учитывать, чтобы модели эффективно противостояли меняющимся киберугрозам.

Таймкоды для вашего удобства:
1️⃣ 00:10–00:34 — Какие задачи информационной безопасности сегодня невозможно представить без машинного обучения?
2️⃣ 00:38–01:03 — Какие сложности возникают при внедрении ИИ в реальные продукты информационной безопасности?
3️⃣ 01:08–01:43 — Как обеспечить надежность моделей в условиях постоянно меняющихся киберугроз?

Хотите сэкономить время на загрузке видео? Переходите в наше сообщество во ВКонтакте!
Смотрите выпуски #От_Эксперта в удобном формате и не тратьте время на ожидание загрузки.

Что происходит с данными после утечки?

Когда становится известно об очередной утечке, обычно всё сводится к одному совету:

«Смените пароль».

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

📢 Разбираемся, какие данные представляют ценность для злоумышленников, что происходит с ними после кражи и что делать, если ваши сведения оказались в утекшей базе.

Какие данные нужны злоумышленникам?
В первую очередь интерес представляют данные, которые позволяют идентифицировать человека или получить доступ к его аккаунтам:
📎персональные данные — ФИО, номер телефона, адрес электронной почты, адрес регистрации или проживания. Такая информация помогает сделать фишинговые сообщения максимально правдоподобными: обратиться к человеку по имени, сослаться на знакомые ему сервисы или использовать другие детали его жизни
📎документы — паспорт, СНИЛС, ИНН и другие данные. Их используют для кражи личности, оформления кредитов или прохождения процедур подтверждения личности в банках и государственных сервисах
📎учётные данные — логины, пароли и одноразовые коды двухфакторной аутентификации
📎биометрия — изображения лица, отпечатки пальцев и образцы голоса. Эти данные могут использоваться при создании дипфейков или для попыток обхода механизмов аутентификации
📎платёжная информация — реквизиты банковских карт и данные криптокошельков

Что происходит после кражи данных?
Далеко не каждая утечка сразу приводит к хищению денег. В большинстве случаев украденные данные сначала проходят несколько этапов обработки.
1️⃣ Продажа исходной базы
После взлома данные попадают на подпольные форумы и маркетплейсы в виде необработанных архивов. В них обычно содержится смесь актуальной, устаревшей и дублирующейся информации, поэтому стоимость таких баз сравнительно невысока — стартовая цена может составлять около 50 долларов.
2️⃣ Анализ и обогащение
Следующий покупатель — не обязательно мошенник. Часто это участник теневого рынка, который специализируется на обработке данных. Он проверяет актуальность логинов и паролей, ищет совпадения с другими утечками, объединяет сведения из разных источников и формирует полноценные профили пользователей.
По сути, из разрозненных записей создаётся цифровое досье, которое значительно повышает ценность украденной информации.
3️⃣ Повторная продажа
После проверки и структурирования стоимость базы возрастает, и её снова выставляют на продажу. При этом торговля ведётся не только на площадках даркнета — подобные предложения встречаются и в Telegram.
4️⃣ Подготовка новых атак
Чем больше информации собрано о человеке, тем проще провести целевую атаку. Например, злоумышленник может узнать место работы жертвы и отправить письмо от имени руководителя или получить доступ к аккаунту в социальной сети, чтобы использовать личные данные для шантажа.

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

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

Продолжаем рубрику #От_Эксперта

📢 Сегодня Егор Шупик, старший специалист по защите информации, разобрал самые заметные и болезненные регуляторные изменения 2025–2026 годов в сфере ИБ.

В выпуске эксперт объяснил, что изменилось в принятых нормативных документах, какие моменты вызвали больше всего вопросов у специалистов и на что важно обратить внимание при работе с новыми требованиями.
❗️Среди ключевых тем — изменения в 127 приказе Правительства РФ и 117 приказе ФСТЭК.


🐻 Инсайт от команды РТ-ИБ:
чтобы смотреть видео без задержки — переходите на нашу страницу во ВКонтакте.

Осторожно: поддельные репозитории на GitHub

📢 В ходе мониторинга команда RT Protect обнаружила поддельный репозиторий zapret-discord, который маскировался под легитимный проект.

На первый взгляд репозиторий неотличим от оригинального инструмента:
📎описание проекта совпадает с исходным
📎присутствуют привычные исполняемые файлы и скрипты
📎структура репозитория не вызывает подозрений

Однако анализ релиза показал, что вместо ожидаемого ПО он содержит вредоносное ПО класса Dropper.
При этом основной .bat-файл был изменен и содержал всего одну строку:

start "" "DiscordFix.exe"

Даже браузер при попытке скачать релиз через веб-интерфейс GitHub предупреждал, что файл является вредоносным.

Что происходит после запуска?
После запуска DiscordFix.exe дроппер последовательно загружает и запускает несколько вредоносных модулей. Для усложнения обнаружения они маскируются под легитимные системные файлы Windows, например:

C:\Temp\svchost.exe

Как специалисты РТ-ИБ предотвратили угрозу?
Решение RT Protect EDR успешно обнаружило вредоносные модули, запущенные дроппером, после чего аналитики оперативно заблокировали их работу. Это позволило остановить дальнейшее выполнение и распространение вредоносного ПО.

🐻 Буран, киберследователь:

Будьте внимательны и не скачивайте ПО из непроверенных репозиториев GitHub!

Поддельный репозиторий:
Отправьте жалобу на репозиторий, чтобы ускорить его блокировку.
[https://github.com/Perfectionerobey/zapret-discord-youtube-1.9.9d]
Оригинальный репозиторий:
[https://github.com/flowseal/zapret-discord-youtube]

Вы уже 15 часов без перерыва строите защиту объектов КИИ, устанавливаете уровни безопасности и развиваете свою инфраструктуру. Время за пределами системы перестало иметь значение. Синхронизация с реальностью нарушена.

Система фиксирует потерю связи с игроком и выполняет принудительное перемещение.

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

СИСТЕМА УВЕДОМЛЯЕТ:
Время в игре: 15 часов 00 минут.
Зафиксирован разрыв контакта с реальность. Вход в новую локацию произведен.
Актуальный таймер: 00:00:00.

ЗАПУЩЕН ПРОТОКОЛ ВЫБОРА.
Введите эмодзи кубика в комментариях.
Сопоставьте выпавшее значение с номером карточки.
Перемещение осуществляется.

— Если SOC получает 10 000 событий в день, кто гарантирует, что среди них не потеряется реальная атака?

По данным Ponemon Institute, средний центр мониторинга информационной безопасности получает около 10 000 событий в сутки. Большая часть из них — ложные срабатывания: легитимный сканер уязвимостей, который выглядит как разведка, пользователь, несколько раз ошибившийся при вводе пароля, или некорректно настроенное правило детектирования.
📢 Именно поэтому одна из ключевых задач первой линии SOC — быстро определить, какие события можно закрыть, а какие требуют немедленного реагирования.

Что такое триаж?
Триаж в кибербезопасности — это первичная сортировка событий и инцидентов. Аналитик оценивает поступивший алерт и определяет его природу:
📎ложное срабатывание
📎штатная активность
📎подозрительное поведение
📎реальная атака, требующая дальнейшего расследования

🧑‍🎓 Ян, аналитик первой линии:
Без триажа команда безопасности быстро сталкивается с перегрузкой уведомлениями.

Основные задачи триажа:
⚙️ Фильтрация шума — исключение дублирующихся событий, тестовых срабатываний, устаревших правил обнаружения и подтвежденных ложных срабатываний.
⚙️ Выявление критических угроз — обнаружение случаев заражения, компрометации учетных записей, действий злоумышленника внутри сети или попыток несанкционированной передачи данных.
⚙️ Сбор контекста — определение пользователя, устройства, уровня привилегий, активных процессов и связанных событий.
⚙️ Расстановка приоритетов — определение уровня важности инцидентов и выделение тех случаев, которые требуют немедленного реагирования, от событий, которые могут быть рассмотрены позже.

🧑‍🎓 Ян, аналитик первой линии:
На практике первичная оценка занимает несколько минут. Полноценное расследование может длиться часами или даже днями, но именно на этапе триажа принимается первое критически важное решение.

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

Для чего нужен триаж?
Главная задача триажа — ответить всего на три вопроса:
1️⃣ Это реальный инцидент или ложное срабатывание?
2️⃣ Смог ли злоумышленник закрепиться в системе?
3️⃣ Какие действия необходимо выполнить прямо сейчас, чтобы остановить развитие атаки?
В нашем примере ответы следующие:
1️⃣ Это реальная угроза.
2️⃣ Злоумышленник закрепился через Планировщик задач.
3️⃣ Необходимо изолировать устройство и начать расследование.

Частые ошибки при триаже
Триаж теряет эффективность, если аналитик оценивает событие без контекста. Недостаточно увидеть один подозрительный файл или хэш. Важно понять:
📎откуда появился объект
📎кто его запустил
📎что происходило до и после события
📎какие системы могли быть затронуты

Чек-лист ошибок:
1️⃣ Доверять только названию правила — высокий уровень критичности не всегда означает реальную угрозу.
2️⃣ Игнорировать особенности актива — одинаковый алерт на тестовом сервере и контроллере домена имеет совершенно разные последствия.
3️⃣ Не учитывать связанные события — один сигнал редко показывает полную картину.
4️⃣ Копить необработанные алерты — среди старых уведомлений легко потерять новую атаку.
5️⃣ Не фиксировать результаты анализа — без заметок команда будет повторно разбирать уже известные случаи.