Александр ПивневЭксперт

В сертификации Platform V SynGX интересен не сам факт «ещё один продукт получил сертификат».

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

4 августа СберТех сообщил, что Platform V SynGX получил сертификат ФСТЭК России по 4 уровню доверия. В новости отдельно указано, что продукт может применяться для защиты информации ограниченного доступа в ГИС, ИСПДн, объектах КИИ и АСУ ТП до 1-го класса защиты.

Сам продукт описывается как производительный веб- и обратный прокси-сервер для нагруженных сайтов и сервисов, основанный на Nginx. В функциональности заявлены метрики мониторинга, active health checks, интеграция с хранилищем секретов, балансировка нагрузки и возможность настраивать собственную логику обработки запросов.

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

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

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

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

Источники: СберТех, 4 августа 2026; IT-World, 4 августа 2026; СберТех о Platform V SynGX Community Edition, 3 апреля 2026

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

Check Point 11 августа описала новую волну Operation Dream Job. Сценарий знакомый: под видом рекрутера жертве дают открыть материалы по вакансии. В этой кампании фигурировал SecurityPDF — изменённый PDF-просмотрщик, который открывал подготовленные документы и запускал новый бэкдор Troy.

Дальше начиналась уже не история про фишинг. Атакующие использовали CVE-2026-68820 в AFD.sys — это Windows-драйвер ядра, через который работают сетевые сокеты WinSock. Уязвимость давала локальное повышение привилегий до SYSTEM. Microsoft закрыла её в августовском Patch Tuesday 11 августа 2026 года.

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

Поэтому я бы смотрел на этот кейс не только как на пункт в списке обновлений Windows. Для практики здесь два слоя проверки.

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

Второй — расследовательский: были ли в последние недели странные «просмотрщики PDF», job offer-документы, неожиданные переходы процессов в SYSTEM, попытки отключить видимость EDR, новые сервисы или следы DLL sideloading. Если машина уже успела попасть в цепочку до патча, одно обновление не доказывает, что инцидент закончился.

Здесь хороший практический вывод: social engineering и kernel LPE не живут в разных папках. Для атакующего это одна цепочка. Один человек открыл «вакансию», а разбирать потом приходится уже уровень ядра.

Источники: Check Point Research, 11 августа 2026; MSRC, CVE-2026-68820; NVD, CVE-2026-68820

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

Свежий пример — Langflow. Это визуальный конструктор для AI-агентов и workflow: блоки, связи, вызовы API, куски Python-кода, интеграции с моделями и внутренними сервисами. Для разработки удобно. Для атакующего тоже, если такой сервис торчит в сеть и живёт на дефолтной конфигурации.

IBM описала CVE-2026-9198 в Langflow OSS 1.0.0–1.10.0. Цепочка выглядит грубо, но показательно: один endpoint выдавал superuser bearer token сетевому клиенту без аутентификации, другой endpoint для проверки кода выполнял переданный Python. В итоге на дефолтных развёртываниях получалось удалённое выполнение кода. CVSS — 9.8, исправление — переход на 1.10.1.

На этой неделе CISA добавила эту уязвимость в Known Exploited Vulnerabilities catalog: то есть речь уже не только о теоретическом баге из бюллетеня, а об эксплуатации вживую.

Что здесь важно для практики. Langflow и похожие low-code/AI-конструкторы часто появляются не через классический ввод системы в эксплуатацию, а как «мы быстро попробуем». Их запускают в Docker, на VM, в облаке, иногда с доступом к токенам, базам, внутренним API и файловым шарам. В инвентаризации ИБ такой узел может не светиться как критичный, хотя фактически он умеет выполнять код рядом с данными.

Я бы проверил не только наличие Langflow по названию. Имеет смысл посмотреть лабораторные серверы, dev/stage, контейнеры у команд разработки, внешние reverse proxy и правила доступа. Если Langflow есть — версия, доступность REST API, включён ли auto-login, какие секреты лежат в окружении, и были ли обращения к /api/v1/auto_login и /api/v1/validate/code.

AI-инструмент не становится безопасным от того, что его поставили «для эксперимента». Если он принимает запросы из сети и может запускать код, это уже сервер с последствиями.

Источники: IBM Security Bulletin, CVE-2026-9198; NVD, CVE-2026-9198; CISA KEV, CVE-2026-9198

RMM-консоль в плохой день превращается не в «ещё один сервер», а в пульт управления чужой инфраструктурой.

Свежий пример — N-able N-central. Это платформа для удалённого мониторинга и управления: через неё MSP и ИТ-команды видят машины клиентов, ставят патчи, запускают задачи и подключаются к рабочим станциям и серверам.

2 августа N-able выпустила hotfix 2026.3.1.7 для CVE-2026-18577. По описанию вендора, уязвимость затрагивала N-central до 2026.3.1.7 и позволяла удалённо получить административный доступ. Дальше атакующие использовали функцию Take Control, заходили на управляемые системы и в одном из сценариев регистрировали сервис Cloudflare tunnel, чтобы сохранить доступ уже после отзыва доступа к N-central.

Это неприятно именно из-за роли продукта. Когда ломают обычный сервер, масштаб понятен. Когда ломают RMM, под рукой оказываются скрипты, задания, удалённые сессии и доверие со стороны десятков или сотен endpoint'ов.

Я бы не ограничивался фразой «поставили хотфикс». Надо отдельно посмотреть, где стоит N-central, доступен ли он извне, кто мог логиниться в последние дни, были ли странные Take Control-сессии, особенно к доменным контроллерам и файловым серверам, и не появились ли неожиданные сервисы/туннели на управляемых машинах.

Для тех, у кого self-hosted, это ещё и вопрос дисциплины: hosted-инстансы вендор обновляет сам, а свой сервер остаётся на совести команды. Huntress 3 августа писала, что среди reachable self-hosted N-central ещё оставались непатченные серверы.

Хорошая RMM-система экономит часы работы. Но в модели угроз она должна жить как высокопривилегированный инструмент, а не как удобная веб-админка «для техподдержки».

Источники: N-able, 2 августа 2026; Huntress, обновление 3 августа 2026

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

Proofpoint 29 июля написал про новую волну эксплуатации CVE-2026-42897 в Outlook Web Access. OWA — это веб-почта Exchange, тот самый доступ к почте через браузер в on-prem средах.

Суть не в том, что пользователь скачал вложение или перешёл по ссылке. Проблема в обработке HTML внутри письма: при открытии сообщения в OWA может выполниться JavaScript в контексте уже авторизованной веб-почты.

Дальше история становится совсем неудобной. В кампании, которую описывает Proofpoint, цепочка заканчивалась OWAReaper — браузерным имплантом внутри OWA. Он не выглядит как обычный файл на рабочей станции, поэтому переустановка ноутбука или смена пароля сами по себе не обязательно решают проблему, если след остался на стороне Exchange.

Меня здесь цепляет простая вещь: корпоративную почту часто воспринимают как канал доставки атаки. А в таких сценариях сама веб-почта становится местом исполнения. Это уже не только задача антиспама.

Я бы смотрел на это спокойно, но без отмахивания: есть ли ещё on-prem Exchange с OWA наружу, включены ли emergency mitigations Microsoft, применены ли актуальные обновления, и видны ли в логах странные действия именно в OWA, а не только на конечных устройствах.

Фраза «открыл письмо» звучит слишком буднично. Но для старого или плохо обслуживаемого веб-доступа к почте этого иногда уже хватает.

Источники: Proofpoint, 29 июля 2026; NVD, CVE-2026-42897

История со SmartConsole у Check Point неприятна не потому, что это ещё один громкий CVE.

SmartConsole — это админская консоль, через которую управляют политиками Check Point: правилами firewall, объектами, шлюзами, публикацией изменений. Проще говоря, пульт от охраны периметра.

22 июля Check Point выпустила Jumbo Hotfix для Security Management и Multi-Domain Management. Внутри — CVE-2026-16232: обход аутентификации в логине SmartConsole через application token.

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

Check Point пишет, что такие атаки уже видели у небольшого числа клиентов. Smart-1 Cloud, по словам вендора, уже закрыт.

Вот почему я не люблю, когда management-интерфейсы живут «где удобно». У firewall может быть хорошая политика, но если наружу смотрит консоль, через которую эту политику меняют, периметр держится на честном слове.

Я бы здесь без героизма проверил три вещи: где стоит Management Server, кто реально может подключаться к SmartConsole, и нет ли в Audit Logs входов через application token. А потом — hotfix, если его ещё не поставили.

Это не красивая теория про management plane. Это обычная хозяйственная вещь: пульт от защиты не должен лежать у двери.

Источники: Check Point, 22 июля 2026; BleepingComputer, 23 июля 2026

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

Поэтому история с CVE-2026-6875 неприятна не только из-за оценки 9.5. NVD описывает её как удалённое выполнение кода в ServiceNow AI Platform: при определённых условиях неаутентифицированный пользователь может выполнить код внутри платформы. ServiceNow пишет, что обновления для hosted-инстансов уже развернуты, а self-hosted-клиентам и партнёрам выданы патчи. При этом исследователи Defused сообщили о попытках эксплуатации; ServiceNow отдельно уточняет, что пока не видит подтверждения эксплуатации hosted-инстансов.

Практический вывод простой: SaaS, ITSM и low-code-платформы нельзя относить к категории «это где-то у вендора, нас не касается». Если через систему идут права, процессы и интеграции, она становится частью контура безопасности.

Что я бы проверил в такой ситуации:

• кто реально владеет платформой со стороны ИБ, а не только со стороны эксплуатации;
• какие инстансы hosted, self-hosted или партнёрские;
• применены ли нужные патчи и на какой версии сейчас система;
• какие интеграции имеют доступ к AD, почте, SIEM, Jira, Git и внутренним API;
• есть ли логи подозрительных запросов и изменений после даты раскрытия уязвимости.

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

Источники: NVD, CVE-2026-6875; BleepingComputer, 20 июля 2026

Самое сложное в больших обновлениях — не нажать «установить всё».

В июльском Patch Tuesday Microsoft закрыла рекордный набор уязвимостей. BleepingComputer пишет о 570 исправлениях, среди них 59 критических, 145 уязвимостей удалённого выполнения кода и три zero-day. Две из этих zero-day уже использовались в атаках.

Когда в одном выпуске сотни CVE, главный риск для компании — утонуть в списке и отложить всё «до нормального окна». На практике так обычно и появляется хвост из уязвимых серверов, забытых рабочих мест и систем, которые никто не решается перезагрузить.

Я бы смотрел на такой выпуск не как на новость про рекорд, а как на проверку процесса обновлений.

Минимальный порядок действий:
• отделить реально эксплуатируемые уязвимости от просто важных;
• проверить, есть ли в контуре затронутые роли: AD, SharePoint, SQL Server, RDP, DHCP, WSUS и внешние сервисы;
• согласовать короткое окно для критичных узлов, а не ждать общего планового обслуживания;
• после установки проверить факт обновления, а не только «задача закрыта»;
• отдельно посмотреть системы, которые давно не перезагружались или выпали из WSUS/EDR.

Большой Patch Tuesday — это не повод для паники. Это хороший тест: есть ли у компании инвентаризация, приоритизация и человек, который отвечает за доведение обновлений до конца.

Источник: BleepingComputer, 14 июля 2026; Microsoft Security Update Guide

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

SonicWall предупредила об активной эксплуатации двух уязвимостей в SMA1000: CVE-2026-15409 и CVE-2026-15410. Первая — критическая SSRF в интерфейсе Work Place, вторая — инъекция команд в консоли управления после аутентификации администратора.

Здесь важен не только конкретный вендор. Логика шире: внешние шлюзы, VPN, админ-панели и другие точки входа нельзя патчить «когда дойдёт очередь». Для них нужен отдельный короткий цикл: быстро проверить применимость, поставить hotfix, посмотреть признаки компрометации и только потом закрывать задачу. В этой истории обходных мер, кроме hotfix, нет.

На практике я бы смотрел на такие вещи:
• какие VPN и внешние панели реально торчат наружу;
• кто владелец каждого узла и кто принимает решение о простое;
• есть ли тестовый путь для срочных hotfix;
• проверяются ли логи и IOC после установки исправления;
• меняются ли пароли и токены, если есть признаки компрометации.

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

Источник: BleepingComputer, 14 июля 2026

Технические каналы утечки — это не музейная тема из старых методичек. Свежий пример: исследователи разобрали TEMPEST-сценарий для интерфейса бразильской системы электронного голосования.

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

Дала.

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

Источник: arXiv, 31 мая 2026

Фишинг стал выглядеть как обычная деловая переписка.

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

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

Дальше цепочка развивалась незаметно:
• запускался установщик и показывался отвлекающий PDF;
• на устройство загружались дополнительные файлы;
• устанавливался портативный AnyDesk;
• удалённый доступ настраивался для подключения без подтверждения пользователя;
• конфигурация AnyDesk отправлялась злоумышленникам;
• закрепление выполнялось через задачу в планировщике;
• временные файлы удалялись, чтобы усложнить расследование.

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

Что стоит проверить компаниям:
• кто и зачем использует AnyDesk, TeamViewer и похожие инструменты;
• есть ли неожиданные задачи в планировщике Windows;
• открывают ли сотрудники запароленные архивы из писем;
• ограничена ли установка программ без согласования с ИТ;
• есть ли контроль исходящей почты и подозрительных SMTP-подключений.

Если письмо выглядит как счёт, это ещё не значит, что оно безопасно.

Источник: Seqrite, 7 июля 2026

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

Свежая тема — HalluSquatting. Смысл атаки простой: модель придумывает несуществующий репозиторий, пакет или skill, а злоумышленник заранее регистрирует такое имя и кладёт туда свой код.

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

Здесь настораживает не сама фантазия модели. Модели ошибались и будут ошибаться. Настораживает другое: мы всё чаще даём ИИ-инструментам доступ к рабочей среде, токенам, репозиториям, CI/CD и локальным файлам, а проверку источников оставляем на доверии.

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

Хороший ИИ-помощник ускоряет работу. Но если он уверенно идёт по выдуманной ссылке, атакующему остаётся только занять эту ссылку раньше нас.

Источник: The Hacker News

Пятничный срез по ИБ: неделя снова напомнила про промышленность

На этой неделе зацепила одна цифра: по данным «Лаборатории Касперского», в первом полугодии 2026 года число обнаруженных и предотвращённых ИБ-инцидентов в российской промышленности выросло на 31%.

А в транспортно-логистическом секторе рост ещё заметнее — 75%.

Почему это важно?

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

И атакующие это прекрасно понимают.

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

Отдельно показательно, что среди угроз растут шифровальщики, шпионское ПО, бэкдоры, кейлоггеры и вредоносное ПО для AutoCAD. То есть интерес не только в том, чтобы остановить работу. Интерес ещё и в документации, процессах, схемах, маршрутах, доступах и коммерческой информации.

Вывод простой: промышленная безопасность давно перестала быть темой только для инженеров АСУ ТП.

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

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

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

Пятничный вывод такой: если бизнес зависит от производства или логистики, кибербезопасность уже нельзя воспринимать как отдельную ИТ-задачу. Это часть устойчивости бизнеса.

Источник: «Лаборатория Касперского», 7 июля 2026