Маленький запрос — большой ответ
Исследователи из нескольких университетов обнаружили два новых способа DDoS-атак, которые используют «перевод» трафика между разными версиями HTTP. Атаки получили название CDN Tsunami и позволяют усилить входящий поток запросов от атакующего до 350 раз против атакуемого сервера. Проблема затрагивает шесть крупных CDN-провайдеров: Alibaba, Baidu, Tencent, Amazon CloudFront, Cloudflare и Fastly.
Суть в том, что CDN общается с браузером пользователя на современном протоколе HTTP/3, а с сайтом за ним на старом HTTP/1.1. Эту разницу и используют две техники:
HTTP/3 Bandwidth Amplification (HBA) использует сжатие заголовков в HTTP/3. Атакующий отправляет крошечный запрос с индексом, а CDN вынужден развернут» его в огромный HTTP/1.1-заголовок. При этом трафик атакующего не превышает 500 Кбит/с, а трафик на сервере жертвы превышает 100 Мбит/с. Максимальный коэффициент усиления в 350 раз достигается у Alibaba, Baidu и Tencent благодаря поддержке динамической таблицы QPACK.
HTTP/3 Connection Amplification (HCA) атакует не пропускную способность, а количество соединений. Одно HTTP/3-соединение может открыть множество параллельных потоков, каждый из которых заставляет CDN открывать новое TCP-соединение к серверу жертвы. Отправляя данные очень медленно, атакующий удерживает эти соединения открытыми, исчерпывая лимиты сервера. Четыре HTTP/3-соединения с 96 потоками каждое могут создать 384 бекенд-соединения.
Исследователи просканировали 1 млн доменов и нашли 151,6 тыс. субдоменов у шести провайдеров, из которых 42,3 тыс. ответили на HTTP/3-запрос и были признаны потенциально уязвимыми. Пока атак в дикой природе не зафиксировано, а CVE-идентификаторы не присвоены. Baidu и Tencent уже внедрили предложенные исправления, остальные провайдеры изучают проблему. Атака будет представлена на конференции SRDS в Риме в конце сентября.
@antiinfosec
«НеИБи» - канал из категории «Другое», подключенный к сервису кросспостинга MaxGate. Публикации канала синхронизируются между Telegram и мессенджером MAX, а на этой странице собраны ссылки на обе версии канала.
Сейчас у канала 344 подписчика суммарно в Telegram и MAX. За последние 30 дней в истории MaxGate учтено 38 публикаций, поэтому перед подпиской можно оценить не только размер аудитории, но и регулярность обновлений.
Чтобы подписаться, используйте кнопки «Открыть в MAX» и «Открыть в Telegram» в верхней части страницы. У отдельных постов ссылка может быть доступна в обоих мессенджерах или только в одном из них, если MaxGate получил такой URL из истории обработки.
Взлом Dahua камер
За 35 дней, с 17 июня по 22 июля 2026 года, один оператор скомпрометировал более 14,5 тыс. IP-камер Dahua. Больше всего взломанных устройств оказалось в Украине и России. Исследователи из Hunt.io обнаружили кампанию случайно — нашли в открытом доступе рабочую директорию самого оператора с 407 МБ данных: исходники, логи, креды, скриншоты с камер, shell-историю. Оператор просто забыл закрыть HTTP-сервер.
Атака шла по трем направлениям одновременно. Первое — это банальный брутфорс порта 37777. Система перебирала логины и пароли, скомпрометировав так 12 324 уникальных IP-адреса. Второй шаг — эксплуатация старых уязвимостей CVE-2021-33044 и CVE-2021-33045 (CVSS 9.8) через инструмент p2pwn — так взломали еще 1 923 камеры. Третьим уровнем стала облачная relay-атака: 283 камеры за NAT были скомпрометированы просто по серийному номеру, без пароля. В 89,4% случаев серийного номера хватало для доступа.
На взломанных камерах оператор оставил постоянный бэкдор-аккаунт p2pwn / p2password. Он хранится независимо от административного пароля и переживает смену пароля, а на большинстве прошивок даже сброс к заводским настройкам. Хуже того, инструментарий генерирует коды восстановления на основе серийного номера камеры через штатный процесс Dahua. Удаление бэкдор-аккаунта не аннулирует эти коды — они остаются рабочими, пока Dahua не изменит логику на стороне сервера.
Рекомендации стандартные, но критичные. Все камеры Dahua, которые были доступны через порт 37777 в период с июня по июль, считайте потенциально скомпрометированными. Проверьте наличие аккаунта p2pwn и удалите его. Установите прошивку SA-2021-0130 или новее. Отключите P2P, если оно не нужно.
@antiinfosec
Ус отклеился
Одно из самых популярных имен, под которые маскируются вредоносные файлы в Windows, — svchost.exe. Десятки легитимных процессов с этим именем постоянно висят в диспетчере задач, и пользователь просто не обратит внимания на очередной. Злоумышленники знают это и не только называют свои файлы похоже, но и активно мимикрируют под системный процесс.
Недавно исследователю попался файл svchost.pyc. На первый взгляд обычный svchost, но на деле скомпилированный Python-байткод с многоступенчатой логикой. Код частично зашифрован через Base85 → XOR → LZMA-декомпрессия, затем exec(). Статический анализ был не прост, но исследователь неплохо поработал.
Внутри классический набор техник: COM Hijacking через scrobj.dll, добавление в исключения Defender, патчинг AMSI и ETW в памяти процесса и внедрение shellcode в другой процесс через VirtualAllocEx → CreateRemoteThread. Процесс маскируется под svchost.exe -k netsvcs через подмену PEB. А еще он помечается как критический для системы (ProcessBreakOnTermination) и защищен двумя вотчдогами через Scheduled Task и WMI.
Если говорить простым языком, то перед нами не просто вредоносный файл, а целая система выживания. Автор позаботился о том, чтобы программа не только запустилась, но и надежно закрепилась в системе, скрылась от глаз защитников, обманула антивирусы и даже мешала себя остановить. Как пишет исследователь этой малвари: «злоумышленник фактически собрал вокруг Python-процесса небольшую систему восстановления и маскировки».
Но расширение .pyc выдало файл с головой. Ус-то и отклеился.
@antiinfosec
Не пробив, а ПРОБИВИЩЕ
Люблинский суд приговорил двух бывших сотрудников офиса МТС к 9 месяцам ограничения свободы. Схема простая: договорились с заказчиком в Telegram, подделали доверенность абонента, выгрузили детализацию звонков и SMS, отдали за деньги. Никакого ИИ, никакого 0-day, никакой APT.
За девять месяцев 2025 года 95,6% утечек, связанных с персоналом российских компаний, пришлись на умышленную кражу данных. В опросе InfoWatch 37% респондентов назвали умышленные действия сотрудников важнейшей причиной инцидентов, ещё 42% указали на случайные. Не «кликнул не туда», а пришёл и вынес.
Рынок DLP в России в 2025 году достиг 17 млрд рублей и в 2026 может вырасти ещё на 40-50%. Инциденты с ИИ-агентами за тот же год затронули 42% организаций против 31% годом ранее. Про второе пишут все, первое считают решённой задачей. Медианная стоимость «пробива» за семь лет наблюдений DLBI выросла в 18,5 раз, мобильный пробив по «большой четвёрке» подорожал в 3,3 раза. Рынок не убит, он подорожал и ушёл глубже. Стоимость атаки выросла, сама атака осталась.
Сотрудник МТС не обходил DLP, SIEM и видеофиксацию. Он работал в рамках полномочий: пришёл «клиент» с доверенностью, оформили запрос, выдали детализацию. Для системы это нормальная транзакция, а не аномалия. Постфактум-анализ сработает тогда, когда данные уже в чужом Telegram. Детализация в рознице стоит несколько тысяч рублей при известно какой зарплате сотрудника офиса продаж. Первый приговор по делу: 6 месяцев ограничения свободы, потом ещё 3 за вскрывшийся эпизод. Санкция ч. 3 ст. 272 УК допускает до 5 лет.
«Несуны» из советских цехов выносили через проходную то, что плохо лежит. Изменился только предмет выноса: вместо деталей теперь детализация. Мотивация, психология и организационная слепота те же. Ну и пока к охраняемым данным есть легитимный доступ у человека с зарплатой ниже стоимости этих данных, самый устойчивый вектор утечки это хакерская атака, а рядовой сотрудник.
@antiinfosec