Axxtel | Кибербезопасность

GitLab был уязвим с 2014 года. А одну из критических уязвимостей уже используют в атаках.

За последние недели у GitLab сразу несколько серьезных проблем: чтение файлов без авторизации и две RCE с максимальной оценкой критичности. Одна из них затрагивает версии GitLab начиная с 7.0 — то есть код оставался уязвимым около 12 лет.
Для self-managed GitLab просто установить обновление сейчас недостаточно.

Если сервер был доступен извне, важно проверить, не произошло проникновение до установки патча?

В новом материале разбираем:

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

CVE-2026-85706 уже внесена в каталог активно эксплуатируемых уязвимостей, поэтому для открытых в интернет инсталляций вопрос особенно актуален.

Полный разбор и рекомендации — на сайте Axxtel →читать

#ПрактикаИБ #GitLab #ЭкспертизаAxxtel

Почему внедрение SIEM не заканчивается подключением логов

После запуска SIEM инфраструктура продолжает меняться: появляются новые приложения, обновляются средства защиты, сотрудники получают новые роли.

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

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

Полезно регулярно задавать три вопроса:

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

В рамках работы SOC-центра мы часто дорабатываем или заменяем базовую экспертизу SIEM своими правилами.

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

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

Где помогает гибридный SOC

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

Внутренняя ИБ-команда помогает оценить происходящее с учетом устройства конкретной компании.

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

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

Такая работа требует понятного распределения ответственности и доступного канала связи. Если контекст нельзя получить вовремя, проверка сигнала затягивается.

Поэтому активное взаимодействие — один из основополагающих факторов успешной работы гибридного SOC-центра.

SIEM дает SOC общую основу для обнаружения и расследования. События можно сопоставлять, проверять и восстанавливать по ним ход действий.

Но ее практическая ценность проявляется в конкретном результате: команда замечает подозрительную активность, понимает, что произошло, и успевает принять меры.

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

#SIEM #SOC #ЭкспертизаAxxtel

PHP2Shell пять дней спустя.
Что стало известно и как защищаться.

21 октября разработчики PHP экстренно закрыли две критические RCE-уязвимости — CVE-2026-109618 и CVE-2026-109619 (9,2 по CVSS 4.0). Обе позволяют при определенных условиях выполнить код без авторизации.

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

Что выяснилось за пять дней?

1. Атаки начались раньше раскрытия

Amazon Threat Intelligence обнаружила попытки эксплуатации еще 17 октября — за четыре дня до выхода исправлений. Это первая известная дата в их телеметрии, а не начало всех атак.

Поэтому при ретроспективном Threat Hunting предлагаем проверять события минимум с 17 октября, а при наличии журналов — с 17 сентября. Дополнительные 30 дней — запас для поиска разведки и подготовки, а не установленный средний срок атаки.

И важный момент: патч устраняет уязвимость, но что делать, если эксплуатация уже произошла?

2. Известно, какие запросы стоит проверять

Многие вендоры уже опубликовали дополнительные механизмы обнаружения PHP2Shell.

Среди признаков:

• необычные POST-запросы с multipart/form-data
• подозрительные сочетания PHP_SESSION_UPLOAD_PROGRESS с параметрами загрузки
• нетипичные размеры и серии запросов
• HTTP 500 вместе с сообщениями PHP о нехватке памяти.

Один POST или HTTP 500 еще не означают атаку. Но аномальные последовательности — повод для проверки. Здесь полезен поведенческий анализ WAF.

С помощью ИИ-генератора ловушек HoneyCorn мы оперативно разработали ловушку на CVE-2026-109618, чтобы видеть подобные атаки на периметр и автоматически их блокировать.

3. После взлома трафик может выглядеть обычным

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

Первоначальный эксплойт ему больше не нужен. Он может использовать обычный HTTPS, права веб-сервера и доступные приложению подключения. Часть запросов будет выглядеть легитимно. WAF их пропускает, сигнатуры PHP2Shell молчат, сайт продолжает работать.

А злоумышленник все еще внутри.

Поэтому мало искать следы конкретной CVE. Нужно проверять признаки закрепления, внутренней разведки и горизонтального перемещения.

4. Как искать того, кто уже проник?

Здесь полезна связка SOC + Deception.

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

Аналитики SOC сопоставляют событие с данными WAF, EDR и сетевого мониторинга и восстанавливают картину возможной атаки.

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

Что сделать сейчас?

• Обновить PHP до исправленной версии: 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 или установить патч поставщика.
• Проверить историю запросов, ошибок PHP и событий безопасности с 17 октября; по возможности — с 17 сентября.
 • Искать неизвестные файлы, подозрительные процессы, аномальные соединения и обращения к внутренним ресурсам.
 • Проверить, способны ли действующие средства защиты увидеть активность после первоначального проникновения.

Уязвимость закрыта. Сигнатуры обновлены. Критических событий нет. Но злоумышленник может оставаться внутри.

Вы уверены, что в вашей инфраструктуре сейчас нет посторонних? И на основании каких данных?

Мы можем помочь с аналитикой инцидента: коммерческий SOC и HoneyPot & Deception на базе HoneyCorn помогут проверить признаки присутствия злоумышленника, подозрительную активность и определить дальнейшие шаги.

Важно не только закрыть уязвимость, но и выяснить, не успели ли ею воспользоваться.

#PHP2Shell #ПрактикаИБ #ЭкспертизаAxxtel

SIEM: от корреляции до расследования

Представим условную ситуацию:

1. По учетной записи сотрудника происходит 15 неудачных попыток входа в VPN.
2. Через минуту вход удается с непривычного IP-адреса.
3. Затем учетная запись обращается к файловому серверу, с которым обычно не работает.
4. После этого фиксируется передача большого объема данных.

Корреляционное правило может связать эти события по учетной записи и времени и сформировать сигнал для проверки.
 
Но сама цепочка еще не доказывает атаку.
 
Сотрудник мог вернуться из командировки, несколько раз ошибиться в пароле и скачать архив для новой задачи.
 
Возможен и другой сценарий — учетную запись использует посторонний.
 
Аналитику предстоит проверить устройство, историю активности, назначение файлов и обстоятельства доступа. SIEM помогает собрать данные для этой проверки и выделить подозрительную последовательность.
 
В первую очередь стоит связаться с сотрудником и верифицировать активность, подтвердить ее легитимность. Многие кейсы решаются уже на этом этапе.
 
Если действия нелегитимны, необходимо изолировать потенциальную точку входа: например, выполнить сетевую изоляцию хоста и блокировку учетной записи VPN.
 
После купирования необходимо определить точку проникновения и принять меры, чтобы предотвратить подобные инциденты в будущем.
 
В этом кейсе явно есть риск компрометации учетных данных VPN. Значит, меняем пароль, проверяем хост сотрудника на наличие ПО, которое могло перехватить учетные данные. Параллельно вычищаем следы деятельности злоумышленника и проверяем, не оставил ли он себе обходных путей.

Что происходит после срабатывания
SIEM может показать алерт в консоли, отправить уведомление, создать тикет или передать сигнал в SOAR для запуска сценария реагирования.
 
Однако способ доставки — только часть задачи.
 
Для работы с сигналом нужно понимать:
 
✔️ что именно вызвало срабатывание
✔️ какие учетные записи и системы затронуты
✔️ почему сигналу присвоен такой приоритет
✔️ какие данные необходимо проверить дальше
✔️ кто отвечает за проверку и последующие действия.
 
Приоритет зависит и от контекста.
 
Подозрительный вход под учетной записью с широкими правами требует иного внимания, чем похожее событие в изолированной тестовой среде.
 
Автоматическая блокировка тоже требует заранее согласованных условий: ошибка может прервать законную работу.
 
Поэтому связь между обнаружением и реагированием нужно проектировать вместе с владельцами инфраструктуры.
 
SIEM не принимает решение вместо аналитика. Она должна дать ему достаточно данных, чтобы это решение можно было принять быстро и обоснованно.
 
#SIEM #SOC #ПрактикаИБ

Что дает SIEM, или как собрать из отдельных сигналов историю атаки

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

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

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

Приведем пример периодически встречающегося кейса.

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

В целом — три частых срабатывания, ничего необычного.

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

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

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

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

Полезнее начать с вопроса: какие действия мы хотим видеть?

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

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

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

Помимо этого, есть базовые источники, которые нужны практически в любой инфраструктуре: DNS, Active Directory, ядро сети, прокси-серверы, различные СЗИ.

События от всех источников SIEM должна обработать и нормализовать.

Зачем нужна нормализация
Источники передают события в разных форматах и по-разному называют одни и те же сущности.

Нормализация позволяет привести записи к общей структуре: кто выполнил действие, когда, откуда, с каким объектом и с каким результатом.

Возьмем пользователя Иванова. В одном журнале он записан как ivanov, в другом — DOMAIN\ivanov, в третьем — ivanov@company.ru.

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

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

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

Одна из частых проблем — синхронизация времени и часовых поясов.

Если событие произошло в одном часовом поясе, а SIEM работает в другом, аналитику становится сложнее построить потенциальный kill chain, а время расследования увеличивается.

Разные SIEM-системы решают это по-разному: одни отображают события во времени рабочей станции, другие используют сдвиг timestamp или дополнительные поля, чтобы сохранить исходное время события.

В следующей части — как из нормализованных событий SIEM собирает цепочку атаки и что аналитик делает после срабатывания.

#SIEM #SOC #ПрактикаИБ

Первые 24 часа после инцидента

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

Что делать сразу:

👉 Зафиксировать время обнаружения и начать журнал действий: кто, что и когда сделал.

👉 Изолировать затронутые узлы от сети, по возможности не выключая их до фиксации volatile-данных.

👉 Сохранить логи — SIEM, межсетевые экраны, почта, VPN, Active Directory и другие критичные источники — до того, как сработает ротация.

👉 Зафиксировать оперативную память и снять образы критичных систем. Здесь лучше сразу подключать специалистов по DFIR/форензике, чтобы не повредить артефакты самим.

👉 Определить масштаб: какие системы, учетные записи и данные могли быть затронуты.

Чего лучше не делать до фиксации артефактов:

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

🚫 Удалять вредоносные файлы и «чистить» систему до того, как все зафиксировано.

🚫 Массово сбрасывать пароли без сценария реагирования. Это может предупредить атакующего и заставить его сменить тактику.

🚫 Переустанавливать системы до снятия необходимых образов.

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

Кого подключать:

➡️ руководителя ИБ и ИТ-команду
➡️ руководство и юристов
➡️ специалистов по реагированию и форензике — внутренних или внешних
➡️ ответственного за персональные данные, если есть признаки утечки ПДн
➡️ для субъектов КИИ — ответственных за взаимодействие с ГосСОПКА/НКЦКИ в рамках применимых требований.

При инциденте с персональными данными сроки действительно жесткие: оператор обязан уведомить Роскомнадзор в течение 24 часов о самом инциденте и в течение 72 часов — о результатах внутреннего расследования.

Но самое важное начинается еще до инцидента.

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

Хорошее реагирование начинается не с первого алерта, а с заранее подготовленного плана.

#ПрактикаИБ #IncidentResponse #ЭкспертизаAxxtel

Камень преткновения – проект N 169583

Если посмотреть на изменения законодательства в области ИБ, в них можно увидеть определенную цикличность.

Сначала изменения касаются требований для ГИС и иных информационных систем органов государственной власти и ФОИВ. Затем тенденция затрагивает процессы обработки персональных данных. После этого регулятор обращает внимание на производственный сектор — ОПК, КИИ. ЦБ при этом стоит несколько обособленно, но учитывает опыт коллег и формирует нормативную базу уже для финансового сектора.

В 2025 году начался новый виток развития.

И если изменения, касающиеся ГИС и иных ИС ОГВ и ФОИВ, прошли достаточно спокойно, то второй шаг этого цикла уже идет со скрипом.

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

Документ должен заменить действующий приказ ФСТЭК № 21 и расширить требования к защите персональных данных.

Сам проект размещен на Федеральном портале проектов нормативных правовых актов.

Что же пошло не так?

На определенных этапах разработки проект нормативного правового акта размещается на regulation.gov.ru и проходит предусмотренные процедуры обсуждения и экспертизы.

В общем виде цепочка выглядит так:

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

И именно публичное обсуждение стало здесь стоп-фактором.

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

Нет явной привязки к уровням защищенности, установленным ПП РФ № 1119, что усложняет практическую реализацию мер защиты информации.

Снова возникают неоднозначные формулировки.

Например:
«При использовании в информационных системах сертифицированных по требованиям безопасности информации средств защиты информации...»

В российском инфобезе такую конструкцию легко прочитать примерно так:

«Несертифицированные СЗИ использовать можно, но сертифицированные приветствуются больше».

Ну и, конечно, остается мало конкретики в части формирования требований по ИБ для операторов персональных данных.

И в этот виток развития ИБ-комьюнити молчать не стало.

Какой здесь видим плюс?

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

Ну что, продолжаем наблюдать.

#ПрактикаИБ #ИБвзаконе #ЭкспертизаAxxtel

Цифровая западня: когда атакующий сам показывает себя

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

На этом строится сервис «Цифровая западня».

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

Для SOC это дает главное — более качественный сигнал и меньше догадок о том, что происходило внутри инфраструктуры.

То есть задача «Цифровой западни» не заменить SIEM, EDR или другие средства защиты, а добавить еще один уровень обнаружения там, где обычного мониторинга может быть недостаточно.

#ПрактикаИБ #Deception #ЭкспертизаAxxtel

Свой SOC или внешний? А если не выбирать

Собственный SOC кажется самым контролируемым вариантом: команда внутри, процессы свои, инфраструктура под рукой.

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

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

Полностью внешний SOC решает часть этих вопросов, но не всегда дает тот уровень вовлеченности во внутренние процессы, который нужен крупной инфраструктуре.


Поэтому для нас рабочий вариант — гибридный SOC.
В этой модели внешняя команда берет на себя круглосуточный мониторинг, расследование и часть операционной экспертизы, а внутренняя ИБ-команда сохраняет контекст, приоритеты и контроль над своей инфраструктурой.

Но ценность SOC определяется не самим фактом круглосуточного мониторинга.

Гибридный SOC должен помогать развивать сам контур мониторинга:

✔️ закрывать слепые зоны
✔️ приоритизировать источники
✔️ дорабатывать правила корреляции
✔️ улучшать качество данных
✔️ давать рекомендации по донастройке СЗИ
✔️ подключать Threat Hunting и сценарии реагирования там, где это действительно нужно.  

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

При этом контроль и бизнес-контекст остаются внутри компании, а мы подключаемся там, где нужны дополнительные ресурсы, 24/7 и специализированная экспертиза. Чтобы внутренней команде не приходилось закрывать весь этот объем задач своими силами.

#SOC #ПрактикаИБ #ЭкспертизаAxxtel

Когда средство защиты само становится точкой входа

За последние дни сразу два показательных кейса.
Cisco закрыла критическую уязвимость CVE-2026-76504 в Catalyst SD-WAN Manager. Уязвимость позволяла удаленному неаутентифицированному атакующему обходить аутентификацию и получать административный доступ. Cisco подтвердила эксплуатацию в реальных атаках.

Почти одновременно Fortinet сообщила об активной эксплуатации CVE-2026-104286 в FortiMail. Через специально сформированные HTTP/HTTPS-запросы атакующий без аутентификации мог записывать произвольные файлы в систему. Уязвимость также получила оценку CVSS 9.8.

Сами по себе две критические CVE — уже не редкость.

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

А значит, возникает неприятный парадокс:

средство, которое должно снижать риск, само становится привилегированной точкой входа.

Для ИБ-команды это хороший повод проверить не только наличие патчей. Стоит посмотреть шире:

— какие management-интерфейсы доступны извне
— насколько изолирован management plane
— кто и как контролирует актуальность самих средств защиты
— есть ли отдельный процесс emergency patching для таких систем
— видит ли SOC подозрительную активность на ИБ-инфраструктуре
— что произойдет, если уже скомпрометировано именно защитное или управляющее устройство

Проблема здесь не в конкретном Cisco или Fortinet.

Любое средство защиты с высокими привилегиями автоматически становится особенно ценным объектом для атакующего.

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

#ПрактикаИБ #Уязвимости #ЭкспертизаАкстел