Ботнет Emotet вновь решил подрасти — зафиксирован новый всплеск аттач-спама

Ботнет Emotet вновь решил подрасти — зафиксирован новый всплеск аттач-спама

Ботнет Emotet вновь решил подрасти — зафиксирован новый всплеск аттач-спама

Эксперты предупреждают о новых вредоносных рассылках с ботнета Emotet. Одноименный троян, загружаемый при открытии вложения, не приводит с собой дополнительных зловредов — видимо, целью имейл-кампании является наращивание потенциала бот-сети.

Согласно наблюдениям Cryptolaemus , рассылка спама, нацеленного на дальнейшее распространение Emotet, стартовала в восемь утра 2 ноября UTC (около 11 утра по Москве). Вредоносные письма содержат вложение — документ XLS или запароленный архив с XLS-файлом.

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

Текущая Emotet-кампания также использует новый шаблон вложения Excel: вредоносный документ содержит инструкции, согласно которым получатель должен скопировать файл в папку «Шаблоны» Microsoft Office и вызвать его оттуда. Такой трюк помогает обойти режим защищенного просмотра Microsoft, при котором блокируется исполнение макросов.

Дело в том, что при загрузке файлов из интернета Windows выставляет флаг MoTW, руководствуясь которым, Microsoft Office открывает документ в Protected View. Папки Templates считаются доверенными, и подобные ограничения на них не распространяются — даже если файл помечен MoTW. Копирование в эти папки возможно только с разрешения админа, и попытка вызовет системное предупреждение, но злоумышленники, видимо, надеются, что жертва нажмет кнопку «Продолжить».

 

При открытии вредоносного файла в полнофункциональном редакторе выполняется встроенный макрос, загружающий Emotet (KLyt.dll). Для сохранения в каталоге %UserProfile%\AppData\Local создается папка с произвольным именем, затем DLL запускается на исполнение с помощью regsvr32.exe.

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

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