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

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

А в подавляющем большинстве случаев системные утечки — это процесс, управляемый извне. И ключ к расследованию, минимизации ущерба и построению защиты лежит в детектировании инфраструктуры Command & Control (C2). Без понимания того, как работает C2, SOC превращается в пожарную команду, тушащую искры, но не видящую самого пожара.

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

Громкой новостью прошлой недели стал взлом библиотеки LiteLLM, используемой в качестве посредника для коммуникации с большим количеством языковых моделей (сообщение от разработчиков, новость на Хабре). Через другое вредоносное приложение на Python была взломана учетная запись мейнтейнера проекта, после чего сразу две версии LiteLLM (1.82.7 и 1.82.8) с вредоносными модулями были загружены в репозиторий PyPI. Отчет с анализом вредоносного кода опубликовали эксперты «Лаборатории Касперского».

В версии 1.82.7 вредоносный код был встроен в файл proxy_server.py. В версии 1.82.8 дополнительно появился .pth-файл, благодаря которому вредоносный код выполнялся при каждом запуске интерпретатора, даже если зараженная библиотека не использовалась. После запуска зараженный скрипт начинал рекурсивный обход рабочих директорий в системе жертвы. В каждой директории скрипт просматривал содержимое файлов, которое выводил в буфер stdout и сохранял в файл для последующей отправки на командный сервер злоумышленников. Далее скрипт собирал информацию о системе и также сохранял в файл. После этого он переходил к поиску конфиденциальных данных, включая следующие типы: 

Недавно я почитал про будущих ИИ-хакеров (ИИ-агенты на базе рассуждающих моделей, натренированные для взлома систем) и понял, что проблема намного больше, чем «станет больше кибератак». Это уже не выглядит фантазией. OpenAI прямо пишет, что готовится к моделям уровня, способного создавать рабочие zero-day-эксплойты против хорошо защищённых систем или существенно помогать в сложных скрытных вторжениях и уже показывает оборонительную версию той же идеи: их agentic security researcher Aardvark ищет уязвимости в кодовых базах, предлагает патчи и уже находил новые CVE. Anthropic и другие лидеры отрасли также ведут работу в этом направлении и уже демонстрируют сильные результаты по части обнаружения уязвимостей в кодовых базах.

Главная проблема тут не в том, что ИИ начнёт взламывать лучше человека. Главная проблема в другом: он почти обнулит стоимость ещё одной попытки атаки.

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

ИИ меняет именно это.

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

Исследования IBM, ReliaQuest и Resilience показывают, что ИИ сделал киберпреступность гораздо эффективней. У злоумышленников стало меньше барьеров для входа, больше возможностей для масштабирования. При этом главные слабые места остаются прежними: слабые процедуры help desk, плохая видимость устройств, ошибки в управлении доступом, компрометация почты и мошеннические переводы. Искусственный интеллект ускорил старые схемы, удешевил их и масштабировал. Теперь черные страшные хакеры используют генеративные модели для правдоподобного фишинга, социальной инженерии и ускорения вторжений, а окно на реакцию у светлой стороны силы — старых добрых безопасников — резко сжалось до нескольких минут. Попробуй успей… 

Разберем основные тезисы отчета Cyber Risk Report 2025, выпущенного компанией Resilience совместно с ее аналитическим подразделением ROC (Resilience Risk Operations Center).

BIP39 вместо номера телефона, ECDH P-256 + AES-256-GCM, non-extractable CryptoKey, трафик неотличимый от HTTPS. Как это устроено, что сломалось в процессе и почему некоторые решения были болезненными.

Представьте, что вы не знаете, какие устройства подключены к вашей сети, как они настроены и что там происходит. Страшно? Ещё бы! Многие компании как раз так и живут — не уделяют внимания аудиту сетевого оборудования. А зря. Без такой инвентаризации невозможно ни нормально управлять ИТ-инфраструктурой, ни защититься от угроз.

Мы наблюдаем в инфраструктуре клиентов это так часто, что поняли – нужно выдать базу. Мы – это руководитель практики развития MaxPatrol Carbon Константин Маньяков и эксперт центра безопасности (PT ESC) Данил Зарипов, и в этой статье мы будем разбираться в ключевых аспектах аудита сетевых устройств, его роли в построении эффективного управления активами и повышении уровня защищенности ИТ-инфраструктуры.

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

Утечка информации: мы не знаем, какие данные LLM передаёт в облако

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

Для этого есть специальные инструменты мониторинга. Например, Tokentap (бывший Sherlock) отслеживает использование токенов для LLM CLI в реальном времени на панели в консоли. Такой MitM-прокси полезен для информационной безопасности и просто для учёта расходов.

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

Как и многие я ищу идеальную формулу: минимум вложений → максимум защиты. Не «купить всё и сразу», не «внедрить SOC за 10 миллионов в год», а именно базовую базу по ИТ и ИБ, которая закрывает 80% рисков и не требует армии сотрудников для ее поддержания.

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

ИБ‑гигиена — это не SOC, не «киберщит» и не магический короб. Это несколько приземлённых вещей: MFA, антивирус, бэкапы, ролевая модель и обучение людей. Всё это стоит сильно дешевле одного серьёзного инцидента.

Всё началось с простой задачи: нужно было безопасно передавать файлы на обычных USB-флешках. Существующие решения либо создавали контейнеры (VeraCrypt), что неудобно для быстрого доступа к отдельным файлам на разных ОС, либо работали слишком сложно для конечного пользователя.

Мне нужно было решение уровня «вставил флешку -> ввел пароль -> файлы зашифрованы». Но главное требование — безопасность данных даже при сбое питания. Если выдернуть флешку посередине шифрования, данные не должны превратиться в кашу.

Так появился crypto_engine. Это не попытка изобрести свою криптографию (мы используем стандартные AES-GCM и ChaCha20), а инженерная работа над тем, как безопасно управлять ключами в памяти, обрабатывать гигабайтные файлы без переполнения RAM и гарантировать целостность данных.

Ниже представлен алгоритм построения архитектуры информационной безопасности (ИБ) при использовании технологии виртуализации на основе документа РС БР ИББС-2.8-2015.

Алгоритм построен по принципу разветвляющейся блок-схемы, аналогичной приведённому примеру. Он учитывает ключевые требования: разделение контуров безопасности, изоляцию, сертификацию средств защиты информации (СЗИ) и разграничение ролей.

О метаданных файлов изображений мы уже говорили и не секрет, что их тоже можно редактировать, в том же Exif-pilot, например. Как распознать фейк, если метаданные на изображении корректные? Кэп очевидность утверждает, что только анализом контента. Логично.

— Возьмем какой-нибудь файл с зачищенными метаданными и проанализируем его на предмет манипуляций в Фотошопе или еще каком-нибудь редакторе. В том же Пейнте :-)

Закинем его на уже упоминавшийся https://29a.ch/photo-forensics и посмотрим, что он нам расскажет. Самый верхний пункт меню — Magnifier/ Увеличилка, чтобы можно было глазками прошерстить картиночку и пальчиком везде потыкать: вдруг кто‑то неаккуратненько подработал. Но такое можно не только тут.

Нас интересует другая опция в меню: Clone Detection — детектор клонов показывает применение инструмента типа «штамп» при обработке, он выделяет клонированные участки розовым светом. Как видно, тут этого добра преизрядно.

Небольшая инструкция по установке VPN (протокол VLESS), на роутер с операционной системой OpenWRT с использованием пакета Passwall

Разбираем Приказ ФСТЭК России № 117, который вступил в силу с 1 марта 2026 года и заменил действовавший более десяти лет Приказ № 17. В статье подробно рассматриваются новые требования к защите информации в государственных информационных системах, включая введение показателей Кзи и Пзи, переход к процессной модели управления безопасностью, ужесточение требований к кадровому составу и обязательность внедрения современных средств защиты.

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

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

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

Мошенники адаптировались к ограничениям работы мессенджеров. С февраля пользователям многочисленных мессенджеров, включая MAX, Telegram и WhatsApp (принадлежит экстремистской организации Meta, запрещённой на территории РФ) всё чаще приходят сообщения от ранее взломанных контактов. В посланиях эмоциональный текст, ссылки на каналы в Telegram или вредоносные сайты. Потенциальную жертву активно убеждают установить приложение на телефон, ведь только так она сможет увидеть фотографии и видео, опознать знакомых.

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

По смыслу это та же схема «Мамонт», но с учётом новых реалий.

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

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

Мы – команда Инфобеза Inline Telecom Solutions и мы точно знаем, насколько это сложно, ведь мы разобрались. Теперь поможем тебе, поехали.

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

Статистика выглядит однозначно: по данным Solar, до 37 % инцидентов связаны с компрометацией учетных записей; Kaspersky фиксирует, что 29 % первичных проникновений начинаются именно с похищенных учетных данных, а BI.ZONE указывает, что 35 % критичных инцидентов связаны с привилегированными аккаунтами. Международная картина еще показательнее: Microsoft заявляет, что 61 % атак включает использование привилегированных учетных записей, Google отмечает, что около 50 % успешных атак стартуют с компрометации учетных данных. ФСТЭК прямо указывает на слабые пароли и однофакторную аутентификацию как ключевые причины успешных атак. 

В первой части я рассказал, как ханипот поймал сканер MCP-серверов — новый вектор разведки, нацеленный на AI-инфраструктуру. Сегодня — про другую сторону: что происходит, когда атакующий находит открытый Ollama.

Статья документирует реальные сессии злоупотребления открытыми LLM-инстансами: кто подключается, какие промпты шлёт, какие модели запрашивает. Данные собраны с трёх ханипотов (DE, US, RU) за март 2026.

Чтобы автоматизированно проверять и централизованно обрабатывать огромное количество событий о происходящем в инфраструктуре, используется SIEM –– класс решений информационной безопасности, призванный анализировать события ИБ, собираемые c устройств инфраструктуры, выявлять подозрения на инциденты.

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

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

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

Сегодня веб-приложения остаются основой для функционирования бизнеса. Их стабильность влияет как на финансовую, так и репутационную составляющие организации. Но также внешние ресурсы компаний являются привлекательной целью для злоумышленников. По данным представителей сервиса WAF ГК «Солар», за 2025 год общее количество кибератак на веб-приложения выросло на 89% в сравнении с 2024 годом. Учитывалась статистика по организациям из разных сфер, в том числе госсектора, логистики и транспорта, ритейла, финансов, промышленности.

Успешность такой кибератаки зависит в том числе от наличия уязвимостей в веб-приложениях. Ими злоумышленники могут пользоваться, чтоб получить доступ к системе, а затем ее компрометировать. Компания «Анлим», центр компетенций по информационной безопасности, не первый год специализируется на пентесте (от англ. penetration test). За время многочисленных проектов по взлому ИТ-инфраструктуры специалисты компании «Анлим» назвали три наиболее распространенных уязвимости, а также рассказали о способах их устранения.