В ходе расследования одного инцидента был обнаружен целый кластер вредоносной активности, нацеленный на операционную систему Linux, который оставался незамеченным как минимум с 2020 года. Дальнейший анализ показал, что вредоносное программное обеспечение выдавало себя за очень популярный мультиплатформенный менеджер загрузок.
В этой статье я, Леонид Безвершенко, и мой коллега, Георгий Кучерин, — Security Researcher-ы в Глобальном центре исследования и анализа угроз (GReAT) «Лаборатории Касперского» — расскажем о нашем совместном исследовании, позволяющем проследить, как жертвы, сами того не зная, устанавливали себе зараженный Debian-пакет менеджера загрузок с официального сайта.
Наше исследование началось с того, что мы получили образ диска и дамп памяти одного ноутбука на операционной системе Linux. Предполагалось, что этот ноутбук был скомпрометирован. Нашей задачей было опровергнуть это или, наоборот, доказать, поняв, что там вообще произошло.
Чтобы начать работать, мы составили супертаймлайн, который содержал данные о файловой системе машины — когда и какие файлы создавались или модифицировались, какие использовались источники данных, были ли установлены какие-то пакеты и т. п.
Во всем таймлайне мы не обнаружили ничего подозрительного, кроме одного момента — в 45 минут 39 секунд в системе был создан файл /var/tmp/debugm5. Как оказалось, это довольно уникальное имя, и найти его где-то в открытых источниках или в телеметрии мы не смогли.
Через секунду происходит история, похожая на классическую работу стилера, — трогаются файлы с различными конфигурациями, ssh-ключами, а в конце работают такие тулзы, как bunzip2, bzcat и bzip2. То есть стилер отработал, упаковал все в архив и завершил свою активность.
Согласно таймлайну, перед созданием файла debugm5 не происходит ничего интересного. Пользователь серфит по различным форумам в Интернете, никаких подозрительных ссылок не открывает, странных доменов не посещает. Но спустя месяц пользователь в чем-то засомневался и решил погуглить, что такое ssh replace attack. А через 20 минут, как истинный пользователь Linux, понял, что нужно решать проблему самостоятельно — просто взял и удалил подозрительный openssh-клиент:
Помимо данных, дампа диска и образа памяти у нас были DNS-логи, где нас очень заинтересовал домен, который выглядит как большая hex-строка и «u.fdmpkg[.]org».
Это довольно похоже на алгоритм генерации доменов, который иногда используется во вредоносном программном обеспечении. Мы посмотрели, куда резолвится этот домен, и оказалось, что это два IP-адреса — один из них локальный:
Для исследования домена fdmpkg[.]org мы пользуемся определенным мультисканерным сервисом и находим, что помимо поддомена u у него есть поддомен deb, который намекает, что здесь располагается дебиановский репозиторий.
Копаем дальше.
Переходим на домен deb.fdmpkg[.]org — открывается «прекрасный» сайт, на котором сообщается, что это репозиторий Free Download Manager. Там размещена просьба скачивать пакет только с официального сайта (и ссылка на этот официальный сайт — www.freedownloadmanager.org):
Сам deb.fdmpkg[.]org — это действительно Debian-репозиторий. Походив по стандартным для дебиановского репозитория путям, мы видим, что все поля в метаданных пакета заполнены плейсхолдерами в стиле «Your Project Name», также есть дата создания — 26 января 2020 года. Запомним эту дату на будущее:
Переходим по ссылке на легитимный официальный сайт очень популярной мультиплатформенной утилиты для скачивания различных файлов, торрентов и прочего — Free Download Manager.
Предварительно мы забрали подозрительный пакет с deb.fdmpkg[.]org. Его версия — 6.7.0. Довольно старая, поэтому нам пришлось использовать web.archive.org, чтобы найти аналогичную версию Free Download Manager на официальном сайте для сравнения.
Первое, что бросается в глаза, пакеты записывают разные домены в список доступных репозиториев. Подозрительный записывает как раз тот домен, с которого мы его забрали, а легитимный, видимо, указывает настоящий репозиторий Free Download Manager:
Помимо этого, здесь еще идет проверка какого-то файла /etc/cron.d/collect, что тоже подозрительно.
Продолжаем копать.
Нам нужно проверить, был ли у нашего пользователя установлен именно этот вредоносный пакет. Для этого мы выводим содержимое файла /etc/apt/sources.list.d/freedownloadmanager.list утилитой cat:
…и видим тот самый подозрительный домен deb.fdmpkg[.]org.
Начинаем анализировать содержимое пакета и смотрим в постинсталляционный скрипт этого пакета — и обнаруживаем несколько комментариев на русском и украинском языках в начале файла с информацией об изменениях в новых версиях вредоносной программы и заявлениями активистского характера.
В этих комментариях также указаны даты: 20200126 и 20200127 (26 и 27 января 2020 года), что совпадает с упомянутой ранее датой создания подозрительного репозитория.
Сам вредоносный скрипт — это инсталлятор, содержащий в себе две большие base64-строки, которые на самом деле представляют собой два бинарных файла ELF. Помимо этого, здесь есть и закрепление в системе — создание с помощью crond таски на запуск файла /etc/cron.d/collect (существование которого проверялось ранее):
Еще применяется техника таймстомпинга, чтобы затереть все временные метки. Чтобы это не выглядело так, будто файлы трогали.
Анализ ELF-ов показывает, что они упакованы UPX версии 9.99:
В реальности такой версии не существует — злоумышленники ее подделали, возможно, чтобы обойти какие-то сэндбоксы, которые при распаковке опираются на версии UPX. Мы пробовали поискать другое ВПО, которое использует эту же версию 9.99, но не нашли.
Распаковываем. Импортов здесь нет — все функции операционной системы дергаются непосредственно через системные вызовы.
Все взаимодействие с командным сервером идет через DNS-запросы. Формируется hex-строка, которая содержит идентификатор жертвы и u.fdmpkg[.]org. Для полученного домена выполняется DNS-запрос:
Функция getaddrinfo, которая осуществляет этот запрос, у злоумышленников видоизменена. Оригинальная функция берет список DNS-серверов из файла /etc/resolv.conf, а в функции злоумышленников это другой файл в директории /tmp. Содержимое этого файла записывается при первом запуске зловреда — все то же самое, что в /etc/resolv.conf, плюс дополнительный адрес вредоносного DNS-сервера, который и обрабатывает подобные DNS-запросы. Это сделано для того, чтобы пользователь или админ, который посмотрит в файл /etc/resolv.conf, не нашел ничего подозрительного.
В ответ на DNS-запрос приходит два IP-адреса, которые мы видели ранее. В них закодированы дальнейшие действия. В первом указан IP-адрес сервера C2, а во втором, локальном, — порт и тип соединения, которые необходимо использовать. Как можно догадаться, дальше устанавливается соединение с этим IP-адресом и запускается реверс-шелл.
В зависимости от типа соединения, указанного во втором IP-адресе, Reverse Shell может работать по одному из двух вариантов:
Нам стало интересно, что происходит с этим Reverse Shell дальше после обращения на второй сервер, и мы запустили бэкдор crond в «песочнице». Проанализировав трафик, мы увидели, что на sandbox пришел довольно многофункциональный стилер, написанный на bash.
Среди функций этого стилера — кража истории браузеров, паролей, данных Remmina (программы для подключения к удаленному рабочему столу), мессенджера Signal, а также облачных сервисов типа Google Cloud, Amazon и многое другое.
Как только стилер собирает все данные, он их пакует в архив и отправляет на сервер при помощи ELF-аплоадера.
Что еще интересно — у стилера есть захардкоженный список идентификаторов жертв, с которых ничего брать не надо. Возможно, они уже были атакованы ранее.
Отработав, скрипт создает файл /var/tmp/debugm5 — как раз его мы видели на зараженной машине.
Таким образом, у нас есть следующая картина: пользователь установил себе зараженный Free Download Manager, через некоторое время ему на компьютер пришел стилер — секреты были выкачаны.
Однако оставалось непонятным, как линуксоид скачал себе на компьютер этот вредонос?
Вернемся еще раз к таймлайну.
Сначала пользователь загуглил установку Free Download Manager. Через 30 секунд зафиксирован заход на страницу загрузки официального сайта пакета, и еще через полминуты был установлен зараженный Free Download Manager.
Мы проверили последнюю версию Free Download Manager с официального сайта — в ней ничего вредоносного. Далее посмотрели инсталляторы, которые закэшировались в веб-архиве — тот же результат. Зато когда мы начали искать информацию о Free Download Manager в открытых источниках, нашли очень много интересного. Как минимум в десятке различных постов в соцсетях типа Reddit и StackOverflow пользователи жаловались на различные проблемы, которые вызывал Free Download Manager.
Вот один из постов:
В ответ на него автору предложили удалить файлы, созданные Free Download Manager:
/etc/cron.d/collect
/var/tmp/crond
/var/tmp/bs
Но ничего не сказано о том, что они вредоносные (и о том, что просто удалить недостаточно, нужно также в том числе сменить все пароли).
В другом посте на Reddit пользователь рассказывал, что установил Free Download Manager вручную (скопировал файлы из пакета). Он интересовался, надо ли запускать постинсталляционный скрипт следующего содержания:
Ему отвечают, что, возможно, в этом скрипте содержится ВПО, т. е. ручная установка спасла от заражения.
Несмотря на бурные обсуждения вопроса в чате, не было никаких попыток установить, что именно делает postinst-скрипт, а также откуда взялся deb-пакет и заражение.
На Reddit мы также нашли упоминание того, что в 2015 году официальный сайт Free Download Manager раздавал вредоносный код с «лошадьми» — пользователи, которые хотели скачать себе пакет, перенаправлялись на сайт showmehorses[.]com. Эта кампания была много лет назад и с текущим заражением не связана. Но сайт Free Download Manager ранее заражался вредоносными программами — это факт.
Все эти посты даже стали источником мемов. У одного из пользователей была проблема — он не мог выключить компьютер из-за малварной таски /etc/cron.d/collect:
У других пользователей что-то ломалось в Debian-репозитории, и они не могли обновляться.
Все эти посты продолжались три года — с 2020-го по 2022-й. Никаких попыток подтвердить вредоносность или установить, что делает это ВПО, как им заражаются и как от него избавиться, не предпринималось. Линуксоиды думали, что у них технические проблемы, и решали их переустановками ПО.
Помимо слов пользователей форумов, мы также нашли размещенные на YouTube видеоинструкции по установке этой программы на компьютеры под управлением Linux. Во всех этих видео показаны следующие действия:
Мы решили сообщить об этих находках разработчику ПО Free Download Manager. В свою очередь они провели собственное расследование и установили, что вредоносное ПО действительно раздавалось через официальный сайт программы.
А что касается распространяемого вредоносного ПО, то оно — давно забытое старое — представляет собой версию бэкдора Bew. Он был обнаружен в 2013 году. Уже в 2014 году он был подробно описан, а в 2017 году был опубликован отчет об одной из атак, в которой он использовался.
Сравните Bew из 2013 года и атаки, которую мы видели сейчас. Это фрагмент кода, который отвечает за вывод версии бэкдора. Слева — версия 2.31129, справа — 4.0, в коде двух этих образцов в целом видны большие пересечения по коду.
Стилер — тоже история старая. Такой же стилер использовался в 2019 году после эксплуатации почтовых серверов Exim.
Стилеру просто добавили немного функционала — появились новые локации, откуда нужно воровать данные. Плюс поменялся командный сервер. Комментарии «ready to send», «drop source files» и так далее остались в тех же местах.
Подводя итоги, хотим отметить, что:
Если вам интересно участвовать в подобных изысканиях, приходите к нам в «Лабораторию Касперского» в подразделение Threat Research или в команду Security Services, в зависимости от того, с какой стороны вы хотите смотреть на интересные находки, подобные нашей. Будем искать и расследовать инциденты, а также разрабатывать инструменты, позволяющие предотвращать заражения в автоматическом режиме, и заниматься прочими трендами мира киберпреступлений.
В этой статье я, Леонид Безвершенко, и мой коллега, Георгий Кучерин, — Security Researcher-ы в Глобальном центре исследования и анализа угроз (GReAT) «Лаборатории Касперского» — расскажем о нашем совместном исследовании, позволяющем проследить, как жертвы, сами того не зная, устанавливали себе зараженный Debian-пакет менеджера загрузок с официального сайта.
Наше исследование началось с того, что мы получили образ диска и дамп памяти одного ноутбука на операционной системе Linux. Предполагалось, что этот ноутбук был скомпрометирован. Нашей задачей было опровергнуть это или, наоборот, доказать, поняв, что там вообще произошло.
Чтобы начать работать, мы составили супертаймлайн, который содержал данные о файловой системе машины — когда и какие файлы создавались или модифицировались, какие использовались источники данных, были ли установлены какие-то пакеты и т. п.
HH:37:13: Internet browsing…
HH:45:39 (C): /var/tmp/debugm5
HH:45:39 (A): ~/.config/chromium/Default/Login Data
HH:45:39 (A): ~/.config/chromium/Guest Profile /Login Data
HH:45:39 (A): ~/.config/chromium/Profile 1/Login Data
HH:45:40 (A): /bin/bunzip2
HH:45:40 (A): /bin/bzcat
HH:45:40 (A): /bin/bzip2
Во всем таймлайне мы не обнаружили ничего подозрительного, кроме одного момента — в 45 минут 39 секунд в системе был создан файл /var/tmp/debugm5. Как оказалось, это довольно уникальное имя, и найти его где-то в открытых источниках или в телеметрии мы не смогли.
Через секунду происходит история, похожая на классическую работу стилера, — трогаются файлы с различными конфигурациями, ssh-ключами, а в конце работают такие тулзы, как bunzip2, bzcat и bzip2. То есть стилер отработал, упаковал все в архив и завершил свою активность.
Согласно таймлайну, перед созданием файла debugm5 не происходит ничего интересного. Пользователь серфит по различным форумам в Интернете, никаких подозрительных ссылок не открывает, странных доменов не посещает. Но спустя месяц пользователь в чем-то засомневался и решил погуглить, что такое ssh replace attack. А через 20 минут, как истинный пользователь Linux, понял, что нужно решать проблему самостоятельно — просто взял и удалил подозрительный openssh-клиент:
HH:35:26: Googling “ssh replace attack”
HH:55:36: Commandline: apt-get remove opensshclient
Помимо данных, дампа диска и образа памяти у нас были DNS-логи, где нас очень заинтересовал домен, который выглядит как большая hex-строка и «u.fdmpkg[.]org».
2c9bf1811ff428ef9ec999cc7544b43950947b0f.u[.]fdmpkg.org
c6d76b1748b67fbc21ab493281dd1c7a558e3047.u[.]fdmpkg.org
0727bedf5c1f85f58337798a63812aa986448473.u[.]fdmpkg.org
Это довольно похоже на алгоритм генерации доменов, который иногда используется во вредоносном программном обеспечении. Мы посмотрели, куда резолвится этот домен, и оказалось, что это два IP-адреса — один из них локальный:
Resolve to:
172.111.48[.]101
127.1.0.80
Для исследования домена fdmpkg[.]org мы пользуемся определенным мультисканерным сервисом и находим, что помимо поддомена u у него есть поддомен deb, который намекает, что здесь располагается дебиановский репозиторий.
Копаем дальше.
Переходим на домен deb.fdmpkg[.]org — открывается «прекрасный» сайт, на котором сообщается, что это репозиторий Free Download Manager. Там размещена просьба скачивать пакет только с официального сайта (и ссылка на этот официальный сайт — www.freedownloadmanager.org):
Сам deb.fdmpkg[.]org — это действительно Debian-репозиторий. Походив по стандартным для дебиановского репозитория путям, мы видим, что все поля в метаданных пакета заполнены плейсхолдерами в стиле «Your Project Name», также есть дата создания — 26 января 2020 года. Запомним эту дату на будущее:
Переходим по ссылке на легитимный официальный сайт очень популярной мультиплатформенной утилиты для скачивания различных файлов, торрентов и прочего — Free Download Manager.
Предварительно мы забрали подозрительный пакет с deb.fdmpkg[.]org. Его версия — 6.7.0. Довольно старая, поэтому нам пришлось использовать web.archive.org, чтобы найти аналогичную версию Free Download Manager на официальном сайте для сравнения.
Первое, что бросается в глаза, пакеты записывают разные домены в список доступных репозиториев. Подозрительный записывает как раз тот домен, с которого мы его забрали, а легитимный, видимо, указывает настоящий репозиторий Free Download Manager:
Помимо этого, здесь еще идет проверка какого-то файла /etc/cron.d/collect, что тоже подозрительно.
Продолжаем копать.
Нам нужно проверить, был ли у нашего пользователя установлен именно этот вредоносный пакет. Для этого мы выводим содержимое файла /etc/apt/sources.list.d/freedownloadmanager.list утилитой cat:
…и видим тот самый подозрительный домен deb.fdmpkg[.]org.
Начинаем анализировать содержимое пакета и смотрим в постинсталляционный скрипт этого пакета — и обнаруживаем несколько комментариев на русском и украинском языках в начале файла с информацией об изменениях в новых версиях вредоносной программы и заявлениями активистского характера.
В этих комментариях также указаны даты: 20200126 и 20200127 (26 и 27 января 2020 года), что совпадает с упомянутой ранее датой создания подозрительного репозитория.
Сам вредоносный скрипт — это инсталлятор, содержащий в себе две большие base64-строки, которые на самом деле представляют собой два бинарных файла ELF. Помимо этого, здесь есть и закрепление в системе — создание с помощью crond таски на запуск файла /etc/cron.d/collect (существование которого проверялось ранее):
Еще применяется техника таймстомпинга, чтобы затереть все временные метки. Чтобы это не выглядело так, будто файлы трогали.
Анализ ELF-ов показывает, что они упакованы UPX версии 9.99:
В реальности такой версии не существует — злоумышленники ее подделали, возможно, чтобы обойти какие-то сэндбоксы, которые при распаковке опираются на версии UPX. Мы пробовали поискать другое ВПО, которое использует эту же версию 9.99, но не нашли.
Распаковываем. Импортов здесь нет — все функции операционной системы дергаются непосредственно через системные вызовы.
Все взаимодействие с командным сервером идет через DNS-запросы. Формируется hex-строка, которая содержит идентификатор жертвы и u.fdmpkg[.]org. Для полученного домена выполняется DNS-запрос:
Функция getaddrinfo, которая осуществляет этот запрос, у злоумышленников видоизменена. Оригинальная функция берет список DNS-серверов из файла /etc/resolv.conf, а в функции злоумышленников это другой файл в директории /tmp. Содержимое этого файла записывается при первом запуске зловреда — все то же самое, что в /etc/resolv.conf, плюс дополнительный адрес вредоносного DNS-сервера, который и обрабатывает подобные DNS-запросы. Это сделано для того, чтобы пользователь или админ, который посмотрит в файл /etc/resolv.conf, не нашел ничего подозрительного.
В ответ на DNS-запрос приходит два IP-адреса, которые мы видели ранее. В них закодированы дальнейшие действия. В первом указан IP-адрес сервера C2, а во втором, локальном, — порт и тип соединения, которые необходимо использовать. Как можно догадаться, дальше устанавливается соединение с этим IP-адресом и запускается реверс-шелл.
В зависимости от типа соединения, указанного во втором IP-адресе, Reverse Shell может работать по одному из двух вариантов:
- через SSL. В этом случае бэкдор crond, в котором все это выполняется, передает управление бэкдору bs, дропнутому ранее в инсталляторе;
- если нет SSL, работает TCP через сокеты, которые создает сам бэкдор crond.
Нам стало интересно, что происходит с этим Reverse Shell дальше после обращения на второй сервер, и мы запустили бэкдор crond в «песочнице». Проанализировав трафик, мы увидели, что на sandbox пришел довольно многофункциональный стилер, написанный на bash.
Среди функций этого стилера — кража истории браузеров, паролей, данных Remmina (программы для подключения к удаленному рабочему столу), мессенджера Signal, а также облачных сервисов типа Google Cloud, Amazon и многое другое.
Как только стилер собирает все данные, он их пакует в архив и отправляет на сервер при помощи ELF-аплоадера.
Что еще интересно — у стилера есть захардкоженный список идентификаторов жертв, с которых ничего брать не надо. Возможно, они уже были атакованы ранее.
Отработав, скрипт создает файл /var/tmp/debugm5 — как раз его мы видели на зараженной машине.
Таким образом, у нас есть следующая картина: пользователь установил себе зараженный Free Download Manager, через некоторое время ему на компьютер пришел стилер — секреты были выкачаны.
Однако оставалось непонятным, как линуксоид скачал себе на компьютер этот вредонос?
Вернемся еще раз к таймлайну.
Сначала пользователь загуглил установку Free Download Manager. Через 30 секунд зафиксирован заход на страницу загрузки официального сайта пакета, и еще через полминуты был установлен зараженный Free Download Manager.
Мы проверили последнюю версию Free Download Manager с официального сайта — в ней ничего вредоносного. Далее посмотрели инсталляторы, которые закэшировались в веб-архиве — тот же результат. Зато когда мы начали искать информацию о Free Download Manager в открытых источниках, нашли очень много интересного. Как минимум в десятке различных постов в соцсетях типа Reddit и StackOverflow пользователи жаловались на различные проблемы, которые вызывал Free Download Manager.
Вот один из постов:
В ответ на него автору предложили удалить файлы, созданные Free Download Manager:
/etc/cron.d/collect
/var/tmp/crond
/var/tmp/bs
Но ничего не сказано о том, что они вредоносные (и о том, что просто удалить недостаточно, нужно также в том числе сменить все пароли).
В другом посте на Reddit пользователь рассказывал, что установил Free Download Manager вручную (скопировал файлы из пакета). Он интересовался, надо ли запускать постинсталляционный скрипт следующего содержания:
Ему отвечают, что, возможно, в этом скрипте содержится ВПО, т. е. ручная установка спасла от заражения.
Несмотря на бурные обсуждения вопроса в чате, не было никаких попыток установить, что именно делает postinst-скрипт, а также откуда взялся deb-пакет и заражение.
На Reddit мы также нашли упоминание того, что в 2015 году официальный сайт Free Download Manager раздавал вредоносный код с «лошадьми» — пользователи, которые хотели скачать себе пакет, перенаправлялись на сайт showmehorses[.]com. Эта кампания была много лет назад и с текущим заражением не связана. Но сайт Free Download Manager ранее заражался вредоносными программами — это факт.
Все эти посты даже стали источником мемов. У одного из пользователей была проблема — он не мог выключить компьютер из-за малварной таски /etc/cron.d/collect:
У других пользователей что-то ломалось в Debian-репозитории, и они не могли обновляться.
Все эти посты продолжались три года — с 2020-го по 2022-й. Никаких попыток подтвердить вредоносность или установить, что делает это ВПО, как им заражаются и как от него избавиться, не предпринималось. Линуксоиды думали, что у них технические проблемы, и решали их переустановками ПО.
Помимо слов пользователей форумов, мы также нашли размещенные на YouTube видеоинструкции по установке этой программы на компьютеры под управлением Linux. Во всех этих видео показаны следующие действия:
- Создатели видео открывали в браузере легитимный веб-сайт программы Free Download Manager (freedownloadmanager[.]org).
- Затем они нажимали кнопку загрузки версии программы для Linux.
- Это действие перенаправляло их на вредоносный URL-адрес deb.fdmpkg[.]org/freedownloadmanager.deb с зараженной версией Free Download Manager.
Мы решили сообщить об этих находках разработчику ПО Free Download Manager. В свою очередь они провели собственное расследование и установили, что вредоносное ПО действительно раздавалось через официальный сайт программы.
А что касается распространяемого вредоносного ПО, то оно — давно забытое старое — представляет собой версию бэкдора Bew. Он был обнаружен в 2013 году. Уже в 2014 году он был подробно описан, а в 2017 году был опубликован отчет об одной из атак, в которой он использовался.
Сравните Bew из 2013 года и атаки, которую мы видели сейчас. Это фрагмент кода, который отвечает за вывод версии бэкдора. Слева — версия 2.31129, справа — 4.0, в коде двух этих образцов в целом видны большие пересечения по коду.
Стилер — тоже история старая. Такой же стилер использовался в 2019 году после эксплуатации почтовых серверов Exim.
Стилеру просто добавили немного функционала — появились новые локации, откуда нужно воровать данные. Плюс поменялся командный сервер. Комментарии «ready to send», «drop source files» и так далее остались в тех же местах.
Подводя итоги, хотим отметить, что:
- У нас получилось подтвердить факт компрометации ноутбука и определить, каким способом это произошло.
- Все мы привыкли к классическому представлению атаки supply chain, когда таргетируются виндовые машины. Это очень точечные атаки, единицы становятся их жертвами, да и в целом они не так долго происходят. Здесь же история продолжается как минимум три года (и это мы не берем во внимание тот факт, что уже в 2015 году была информация о распространении другого вредоносного ПО с данного сайта). Согласно данным нашей телеметрии, жертвы данной кампании расположены по всему миру, в том числе в Бразилии, Индии и других странах (несмотря на то, что комментарии в коде были только на русском и украинском языках).
- Сложность в том, что для классического линуксового пользователя проблемы в системе вызывают желание что-то решать самостоятельно. Никто даже не думал, что это вредоносное ПО. То есть мы приходим к тому, что даже на линуксовых машинах нужны антивирусные решения.
Если вам интересно участвовать в подобных изысканиях, приходите к нам в «Лабораторию Касперского» в подразделение Threat Research или в команду Security Services, в зависимости от того, с какой стороны вы хотите смотреть на интересные находки, подобные нашей. Будем искать и расследовать инциденты, а также разрабатывать инструменты, позволяющие предотвращать заражения в автоматическом режиме, и заниматься прочими трендами мира киберпреступлений.
