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

В поле нашего зрения попал технический доклад Сурила Десай (Suril Desai), вице-президента Acalvio. Выступление было посвящено тому, как создать «ложные активы» для злоумышленников по-суворовски: не числом, а умением. 

Под катом пересказываем доклад со всеми подробностями и нашими инсайтами — всё, как вы любите. Поехали.

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

Меня зовут Максим Мотиков, я аналитик киберугроз в «Гарде». Недавно на анализ мне пришел странный экзешник весом 81,54 МБ. Коллега выцепила его из сетевого трафика, но что внутри было, непонятно. Стиллер? Загрузчик? Что-то новое?

Оказалось, что передо мной вредоносная утилита на Python. Хотя эти зловреды давно существуют и регулярно эксплуатируются, мне задача отреверсить подобную штуку досталась впервые. До «Гарды» я занимался реверсом firmware — встроенного ПО инициализации ПК (BIOS, UEFI) и прошивок микроконтроллеров. Там всё написано на ассемблере и C/C++, ведь код должен напрямую работать с железом, поэтому никакой Python там не встречается.

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

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

Меня зовут Софья Худякова, я руковожу отделом продуктовой аналитики в «Гарде». Занимаюсь аналитикой требований уже почти двадцать лет — сначала как специалист, теперь как руководитель отдела. За это время профессия изменилась настолько, что список компетенций, по которому я нанимаю людей сегодня, почти не похож на тот, с которым я начинала. В этой статье — не про хард-скиллы и технологии (об этом написано достаточно), а про то, как изменился образ мышления, который нужен современному аналитику.

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

Меня зовут Алексей Шмелёв, я руковожу группой аналитики и безопасности данных в «Гарде». Мы занимаемся настройкой «решающих правил» в таких продуктах «Гарды», как DBF и DLP.

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

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

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

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

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

Меня зовут Борис Усков, я руковожу группой сетевой аналитики в «Гарде». В первые часы после развёртывания NDR большая часть событий связана с уязвимостями сетевого трафика и ошибками конфигурации. В инфраструктурах 90% заказчиков мы видим одни и те же проблемы: инфраструктурный долг и теневое ИТ — старые протоколы, забытые сервисные учётные записи, внешние DNS-серверы, нестандартные порты, торрент-трафик и прочая фоновая сетевая активность. Каждая такая находка — это потенциальная возможность для злоумышленника, которая может годами оставаться незаметной в инфраструктуре.

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

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

На связи Станислав Грибанов, я руководитель продукта NDR компании «Гарда», автор блога «Кибербезопасность и продуктовая экспертиза для бизнеса».

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

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

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

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

Есть типовой путь, по которому команды приходят к разочарованию в Threat intelligence. Сначала кто-то в компании слышит, что фиды помогут раньше видеть атаки, быстрее реагировать, меньше пропускать. Потом кто-то другой берет пачку индикаторов из разных источников и по-быстрому заливает их в NGFW, прокси, SIEM или IDS. После СЗИ начинает сходить с ума: сыпятся алерты, в логах всплывают легитимные сервисы, аналитики несколько дней разгребают мусор… 

В итоге всё это счастье переводят в режим «только мониторинг», чтобы ничего не сломать. В результате напрашивается вывод: Threat intelligence — это, конечно, модно, но нам не нужно и вообще больше похоже на дорогую игрушку для крупных SOC. Вот только проблема не в TI, а в том, что сырые фиды никто не должен использовать в проде.

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

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

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

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

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

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

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

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

Все началось с обычного тикета в Jira, из тех, которые выглядят безобидно и даже немного скучно. «Нужно протестировать новый личный кабинет. Разверни тестовую базу». Через несколько месяцев этот тикет аукнулся сорванным релизом, сгоревшим маркетинговым бюджетом и отложенным запуском важнейшего сервиса. А Олег, как всегда, остался крайним.

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

Половина краж с банковских карт в России за последние полгода — дело рук одного семейства троянов. SpyNote и его наследник CraxsRAT заражают Android-устройства, открывают банковские приложения и выводят деньги. Большинство разборов этих вредоносов заканчиваются списком IOC и общими рекомендациями. Эта статья устроена иначе.

Меня зовут Евгения Устинова, я старший аналитик сетевой безопасности в компании «Гарда». Я провела статический разбор нескольких версий трояна (v3.7.1–v7.6, включая форки EagleSpy, VIPRat, RedBat, MedusaRat, DesertRat и утечку исходного кода v6/v7), восстановила полную хронологию атаки по реальному трафику и разобрала протокол до байтов.

Оказалось, что у CraxsRAT есть сетевая активность, которую невозможно отключить, не сломав клиент. Я использовала эти базовые свойства протокола, чтобы построить правила Suricata, которые не устареют завтра, как обычные IOC. Читайте подробное исследование под катом.

На связи Андрей Леодоров, ведущий инженер по автоматизации процессов компании «Гарда». За время работы с Jenkins я видел разные сценарии его использования: от локальных инсталляций под одну команду до масштабируемых инстансов с централизованным сопровождением. Я пришёл к выводу, что Jenkins отлично подходит для использования на уровне продукта — когда команда может сама определять, какие инструменты и ресурсы нужны для организации процессов CI/CD.

Статья — это практический гайд для небольшой команды или отдельного проекта, которому нужен собственный воспроизводимый Jenkins в Kubernetes. Мы развернём Jenkins в Kubernetes, настроим хранение конфигураций как код и зафиксируем версии плагинов. Такой подход позволит разворачивать идентичные среды с нуля, не завися от конкретных версий плагинов. Я также добавил несколько готовых примеров со ссылками на GitHub, которые можно взять за базу и доработать под свои нужды.

На связи Игорь Гиркин, архитектор систем информационной безопасности компании «Гарда».

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

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

За последние пять лет российский рынок дата-центров демонстрирует устойчивый рост. Эксперты прогнозируют дальнейшее удвоение мощностей к 2030 году. Это напрямую усиливает привлекательность ЦОД для злоумышленников. Ведь чем больше сервисов размещается в ЦОД, тем выше потенциальный ущерб от их недоступности. И, действительно, в 2025 году количество DDoS-атак (Distributed Denial of Service) в России выросло более чем в два раза по сравнению 2024 годом. Особенно страдает телекоммуникационная отрасль: с июля 2024 года наблюдается резкий всплеск атак именно на операторов связи. Это также подтверждает наша собственная статистика.

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

Экспертизой в этих вопросах сегодня будут делиться Вадим Солдатенков, руководитель направления продуктов «Гарда Anti-DDoS» компании «Гарда», и Дмитрий Ковалев, технический директор по информационной безопасности интегратора «Инлайн Телеком Солюшнс».

На связи Анастасия Шильникова, менеджер по тестированию компании «Гарда».

Мы регулярно сталкиваемся с ситуациями, когда в Jira к задаче вроде есть какое-то описание, стоит статус «готово», но, чтобы понять, в чем была проблема, что было исправлено, как было проверено, приходится «нырять» в мессенджер или звонить коллегам. Все это съедает время, размывает ответственность между командами и мешает выпускать продукт быстро, качественно, в срок.

Чтобы решить проблему, мы решили внедрить в жизненный цикл разработки концепцию DoR (Definition of Ready) и DoD (Definition of Done). В этой статье я расскажу: чем DoR и DoD отличаются от критериев приемки и почему их важно не путать, как не превратить полезный инструмент в бюрократическую обязаловку, какие узкие места могут возникнуть при внедрении концепции.

На связи Лука Сафонов — бизнес-партнер по инновационному развитию компании «Гарда». В прошлой статье я рассказывал про организацию сетевой безопасности в финтехе, а сегодня хочу поговорить в целом про безопасность веба.

На связи Лука Сафонов, бизнес-партнер по инновационному развитию компании «Гарда».

В 2025 году общее число киберинцидентов на российские компании выросло на 42%, и почти каждая четвертая атака имела серьезные последствия для бизнеса. Финансовый сектор при этом остается в числе пяти наиболее атакуемых отраслей. Несмотря на свою зрелость, он привлекает злоумышленников своей ценностью: здесь сосредоточены данные, деньги и критически важные сервисы.

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

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

Сегодня на связи Дмитрий Ларин, руководитель продуктового направления по защите баз данных, и Анастасия Комарова, менеджер по продуктовому маркетингу компании «Гарда».

Мы регулярно общаемся с ИТ- и ИБ-командами, в том числе на пилотах и в ходе интервью на профильных мероприятиях. Возможно, кто-то из читателей уже отвечал на наши вопросы или участвовал в таких обсуждениях. Со временем по итогам этого диалога скложилась такая картина: в разных компаниях и отраслях специфика отличается, но общий подход к данным почти всегда один. Production закрыт и находится под жестким контролем, а все, что происходит вокруг него, воспринимается как менее критичное. Однако на практике самые неприятные ситуации возникают не в production, а вокруг него. В частности, когда персональные данные начинают жить своей жизнью в тестовых средах, дампах, BI-витринах, песочницах и временных проектах. Если вы работаете с тестовыми базами, скорее всего, уже видели что-то похожее.

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