Вредоносный JavaScript из тулкита Parrot TDS обнаружен на 70 000 сайтов

Вредоносный JavaScript из тулкита Parrot TDS обнаружен на 70 000 сайтов

Вредоносный JavaScript из тулкита Parrot TDS обнаружен на 70 000 сайтов

Масштабы TDS-системы Parrot, используемой киберкриминалом, оказались намного больше, чем сообщалось ранее. В 2021 году эксперты Sucuri выявили свыше 61 тыс. зараженных сайтов, работающих как шлюзы в рамках редирект-сервиса, в этом году — уже более 11 тысяч.

О появлении новой системы распределения трафика, которую в Avast нарекли Parrot TDS, стало известно в начале апреля. Ее функционирование обеспечивают скрипты, скрытно устанавливаемые на сайты WordPress и Joomla. Как оказалось, такие заражения в Sucuri отслеживают с февраля 2019 года — под именем NDSW/NDSX. По итогам прошлого года набор вредоносных скриптов, используемый в этой киберкампании, вошел в топ угроз для сайтов, выявленных экспертами.

Атака NDSW/NDSX начинается с JavaScript-инъекций. Вредоносный код внедряется во все файлы .js или добавляется к скриптам, встроенным в HTML-страницы; В редких случаях такой довесок можно обнаружить в базе данных, кешированной каким-нибудь плагином.

Подавляющее большинство вредоносных JavaScript-кодов содержат инструкцию if(ndsw===undefined), поэтому данный компонент тулкита исследователи условно назвали NDSW. Встречаются также варианты скриптов, использующие другую переменную — ndsj.

Основным назначением этих сценариев является запуск второй стадии атаки — доставка и выполнение JavaScript из внешнего источника. Для персонализации этой полезной нагрузки на скомпрометированный сервер обычно внедряется PHP-скрипт (в произвольную папку, но чаще всего — как /wp-admin/css/colors/blue/blue.php).

Этот прокси-компонент кодирует информацию о посетителе сайта (IP-адрес, браузер, реферер) и отправляет их на сервер TDS Parrot. Если ответ содержит ключевое слово «ndsx», происходит JavaScript-инъекция в зараженную веб-страницу — полезная нагрузка при этом выполняется на лету как встраиваемый сценарий. Поскольку скрипт, использующий переменную ndsx, загружается на стороне сервера, его источник невозможно выявить ни мониторингом трафика, ни статическим анализом на уровне клиента.

При отработке NDSX-скрипт скачивает со стороннего сайта финальную полезную нагрузку — откуда и какую, зависит от ранее составленного цифрового отпечатка жертвы. На Windows-компьютеры, по данным Sucuri, чаще всего доставляется JavaScript-загрузчик FakeUpdates, он же SocGholish, о котором в связи с Parrot сообщала Avast. Чтобы не направлять трафик на ресурсы, попавшие в черные списки, операторы TDS-системы часто меняют URL целевых зловредов.

В 2021 году Sucuri очистила от кодов Parrot TDS почти 20 млн JavaScript-файлов, найденных на зараженных сайтах; PHP-компонент был удален более 5400 раз. В этом году неприятных находок пока меньше — в первом случае 1,64 млн, во втором — 2900. Многие их этих сайтов вдобавок содержали бэкдоры, скрипты для черной оптимизации, японоязычный спам, JavaScript-редиректы, используемые в рамках недавно запущенной мошеннической кампании, а также уязвимые или устаревшие плагины и темы.

Взлом серверов для внедрения тулкита Parrot TDS в основном осуществляется с помощью эксплойтов, которых у злоумышленников, по всей видимости, много; этот арсенал постоянно обновляется, в том числе за счет 0-day. Получив доступ, взломщики закрепляют его путем установки бэкдоров и создания учетных записей админа CMS.

Сценарий вредоносных инъекций зависит от используемой уязвимости и уровня доступа, который она обеспечивает. Так, в тех случаях, когда уязвимость позволяет получить админ-доступ к сайту WordPress, хакеры обычно устанавливают фальшивый плагин wp-sp, wp-sps, wp-pimple или wp-dumpme, который создает PHP-прокси и открывает бэкдор, позволяющий выполнить любой код PHP на взломанном сайте.

Поскольку атаки на сайты в рамках текущей кампании NDSW/NDSX разнятся, Sucuri смогла дать лишь общие рекомендации по очистке от инфекции и усилению защиты:

  1. Смените пароль администратора CMS и удостоверьтесь, что все пользователи с админ-привилегиями вам известны.
  2. Проверьте все темы, плагины и другие сторонние компоненты на сайте, удалите незнакомые и неиспользуемые.
  3. Найдите и очистите все зараженные файлы и записи базы данных; их могут быть тысячи, поэтому придется использовать систему мониторинга целостности и бэкап — или как-то иначе автоматизировать этот процесс.
  4. Удостоверьтесь в актуальности CMS и всех компонентов сторонней разработки.
  5. Рассмотрите возможность использования WAF, который будет защищать сайт от большинства известных атак и сдерживать эксплойт, пока ваш софт ожидает обновления.

Сотрудники против: 52% компаний буксуют с переходом на тонкие клиенты

Переход на тонкие клиенты в российских компаниях чаще всего тормозит вовсе не техника, а люди. По данным опроса среди зрителей и участников эфира AM Live «Тонкий клиент: инструмент создания цифровых корпоративных рабочих мест», 52% компаний не могут полноценно перейти на такую модель из-за сопротивления сотрудников, привыкших к обычным компьютерам.

На этом фоне особенно показательно выглядит другая цифра: только 25% компаний уже используют удалённые рабочие места через десктопы или тонкие клиенты.

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

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

Впрочем, дело не только в привычках. Второй по популярности барьер — поддержка периферии, на неё пожаловались 46% опрошенных. Дальше причины идут уже с заметным отрывом: 32% считают проблемой высокую стоимость внедрения, 28% говорят о несовместимости приложений, 26% — о нехватке экспертизы у ИТ-команд, ещё 22% упомянули ограничения сети и каналов связи.

Некоторых экспертов такой высокий результат у пункта с периферией удивил, но в «Лаборатории Касперского» ничего необычного в этом не увидели. Старший менеджер по продукту Kaspersky Thin Client Михаил Левинский объяснил, что вопрос здесь упирается не только в сами устройства, но и в зрелость поддержки: у кого-то может быть старый монитор или нестандартная периферия, и важно, насколько быстро вендор готов на такие запросы реагировать. При этом, по его словам, сами операционные системы, конечно, должны нормально поддерживать проброс периферийных устройств.

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

При этом в обсуждении прозвучала и осторожно позитивная нота. Генеральный директор «АМ Медиа» Илья Шабанов заметил, что заметно сократилась доля тех, кто считает главным препятствием именно стоимость внедрения. Это может говорить о том, что рынок таких решений в России постепенно взрослеет, а сами технологии перестают восприниматься как что-то слишком дорогое и экзотическое.

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