Kaspersky фиксирует рост числа атак через Windows Print Spooler

Kaspersky фиксирует рост числа атак через Windows Print Spooler

Kaspersky фиксирует рост числа атак через Windows Print Spooler

В период с июля 2021 года по апрель 2022-го эксперты «Лаборатории Касперского» насчитали около 65 тыс. атак с использованием уязвимостей в диспетчере очереди печати Windows. Почти половина из них (31 тыс.) были зарегистрированы в течение последних четырех месяцев.

Чаще всего такие инциденты происходили в Италии, Турции и Южной Корее. В период с января по апрель повышенная эксплойт-активность, связанная с Windows Print Spooler, наблюдалась в Австрии, Франции и Словении.

В основном злоумышленники пытаются использовать уязвимости службы печати, найденные за последний год. Наиболее известны из них CVE-2021-1675 и CVE-2021-34527 (PrintNightmare) — Microsoft боролась с ними прошлым летом, пытаясь минимизировать ущерб, причиненный публикацией PoC-эксплойтов.

В апреле объявилась CVE-2022-22718, которая тоже позволяла получить доступ к корпоративным ресурсам. По данным Kaspersky, атаки через уязвимости в Windows Print Spooler были в основном нацелены на кражу данных, в том числе с помощью специализированных зловредов. Эксплойт также открывал возможность для внедрения в сеть других вредоносных программ — например, шифровальщиков.

Защититься от атак через Windows Print Spooler, по мнению экспертов, помогут следующие рекомендации:

  • устанавливать патчи по мере выхода и в кратчайшие сроки;
  • регулярно проверять защищенность ИТ-инфраструктуры;
  • установить спецзащиту от фишинга на конечных точках и почтовых серверах — для снижения риска заражения;
  • использовать средства защиты от сложных атак, способные обнаружить и устранить угрозу на ранней стадии (EDR, системы защиты от APT-атак, спецуслуги);
  • предоставить работникам SOC-центра доступ к актуальной информации об угрозах, регулярно проводить для них тренинги.

ChatGPT и DeepSeek пропускают до 50% уязвимостей в софте на Java и Python

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

Эксперты Solar appScreener протестировали шесть LLM на 20 крупных приложениях на Java и Python, каждое объёмом более 100 тысяч строк кода. Для анализа использовали как облачные модели — GigaChat 3 PRO, ChatGPT 5.2 и DeepSeek 3.2, так и локальные решения on-premise, включая ChatGPT OSS, Mistral и специализированные модели DerTriage и DerCodeFix.

Сначала с помощью SAST-анализа в проектах нашли около 12 тысяч уникальных срабатываний, из которых почти 20% пришлись на уязвимости высокой критичности. После этого все модели получили одинаковый промпт с описанием уязвимости, фрагментом кода, трассой достижимости и идентификаторами CWE.

На этапе триажа результаты оказались неровными. В Java-проектах среди облачных моделей лучше всех выступил ChatGPT с точностью 60,9%, а DeepSeek показал лишь 50%. В Python-коде картина поменялась: DeepSeek добрался до 80%+, а ChatGPT показал 52,7%. Но лучший результат среди локальных решений продемонстрировала DerTriage — более 80% точности и для Java, и для Python.

С кодфиксом ситуация похожая. Для Java ChatGPT показал 61,8% точности, DeepSeek — 45,5%. В Python их показатели составили 46,6% и 44,8% соответственно. Локальная модель DerCodeFix снова оказалась впереди: 78,2% точности на Java и 83,1% на Python.

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

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

RSS: Новости на портале Anti-Malware.ru