Подставной апдейт Emotet прибьет зловреда на машинах жертв 25 апреля

Подставной апдейт Emotet прибьет зловреда на машинах жертв 25 апреля

Подставной апдейт Emotet прибьет зловреда на машинах жертв 25 апреля

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

О перехвате контроля над инфраструктурой Emotet — результате совместных усилий правоохранительных органов разных стран — стало известно 27 января. Резидентные боты были перенаправлены на подставные C2-серверы и перестали получать команды. Информация, найденная на серверах ботоводов, позволяет идентифицировать очаги заражения и приступить к очистке.

Два таких контроллера находились на территории Нидерландов, 17 — в Германии. Для переадресации ботов на sinkhole-серверы германские специалисты создали обновление, которое резидентный зловред уже начал скачивать в соответствии со своим графиком.

Как оказалось, подложный апдейт также содержит модуль, выполняющий удаление Emotet после определенной даты. Ранее сообщалось, что этот дедлайн наступит 25 марта, однако анализ кода EmotetLoader.dll, проведенный в Malwarebytes, показал, что подпрограмма деинсталляции заработает с 25 апреля (значение поля tm_mon — месяц —указано как 3 при возможных вариантах от 0 до 11).

 

В результате такого обновления будут удалены Windows-службы, ассоциированные с Emotet, и ключ реестра, созданный им для обеспечения автозапуска.

Причины отложенного старта деинсталляции ботов по-прежнему неизвестны. Эксперты BleepingComputer попытались их выяснить, обратившись в Федеральное ведомство Германии по уголовным делам (Bundeskriminalamt, BKA), но получили отказ — правоохранители сослались на незаконченное расследование. 

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

Подпишитесь на новости

1,8 ТБ и вагон ошибок: как выгрузка с Яндекс Диска превратилась в квест

Пользователь «Яндекс Диска» решил сделать резервную копию 1,8 ТБ файлов, а также примерно 160 ГБ фотографий и получил приключение с ошибками API, зависшими загрузками и собственными скриптами.

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

Подробности инженер Сергей Терёхин, известный как KenGuru66, описал  в собственном разборе на Хабре.

План был такой: rclone, сервер в Нидерландах, копия в Google Drive. Но стандартная аутентификация позволяла получить сведения о диске, а обращения к файлам возвращали ошибку 410. Доступ удалось наладить с другим OAuth-токеном.

Фотографии из безлимитной автозагрузки добавили веселья: для копирования через выбранный API их пришлось переместить в обычную папку. После этого они начали занимать место в тарифе. Более 30 тысяч снимков переносились около шести часов.

В выборке из 300 случайных файлов автор смог получить начало только 146. По важной папке с документами он скопировал и проверил по MD5 2315 файлов; ещё 3079 на момент публикации оставались недоступны.

Потерю данных автор не утверждает, он продолжает повторные загрузки. Скрипты опубликованы на GitHub.

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