Новый сетевой червь распространяется через протокол Windows RDP

Новый сетевой червь распространяется через протокол Windows RDP

Специалисты по антивирусной безопасности отмечают появление довольно редкого образца среди вредоносных кодов. Новый интернет-червь Morto использует для распространения протокол Windows RDP (Remote Desktop Protocol). Антивирусная компания F-Secure сообщает, что червь для своего распространения использует трафик на порту 3389/TCP.



Согласно данным анализа F-Secure, после того, как червь вошел в сеть, он начинает искать машины, на которых открыт порт 3389 и запущена служба RDP. Уязвимые машины, которые удалось обнаружить Morto, червь использует для проникновения и размещения на их жестких дисках как dll-файл. После размещения на машине жертве, червь начинает создавать на ней прочие вредоносные файлы, передает cybersecurity.

В американской исследовательской сети SANS говорят, что на протяжении минувших выходных они зафиксировали резкий рост объемов RDP-трафика и именно этот индикатор побудил их проверить системы на наличие вредоносных кодов. По итогам проверки выяснилось, что перед данным червем уязвимы как серверы, так и рабочие станции под управлением Windows.

В сообщении F-Secure также говорится, что в большинстве случае в качестве удаленного контроллера червя Morto используются серверы в доменах jaifr.com и qfsl.net.

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

Заблокировали по ошибке: как Монета добилась исправления правил ТСПУ

Когда клиенты перестали подключаться к серверам «Монеты», проверка собственной инфраструктуры не объяснила проблему. Одновременно стали недоступны сайты клиентов, а уведомления о платежах перестали доходить на Pay URL. Причину пришлось искать за пределами серверной.

DevOps-инженер компании Евгений описал на Хабре случай ошибочной фильтрации на технических средствах противодействия угрозам — ТСПУ.

Доступ удалось вернуть после диагностики и корректировки правил специалистами ДЦОА. Менять хостинг и IP-адрес не потребовалось.

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

Следующий этап — заявка через личный кабинет взаимодействия с техническими средствами. Но даже статус «Частично принята» не гарантирует восстановления доступа.

Для дальнейшей проверки потребовался номер площадки ТСПУ. Попытки получить помощь через операторов связи результата не дали; нужный идентификатор удалось запросить напрямую через ЦМУ ССОП.

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

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

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