Описание вредоносного ПО

Rustock и все-все-все

«Неуловимый» руткит

В декабре 2006 года в некоторых кругах исследователей проблемы руткитов (как blackhat, так и whitehat) стали циркулировать слухи о том, что кем-то создан и выпущен в свет «абсолютно неуловимый руткит» — Rustock.С, — который при активном заражении не способно обнаружить ни одно из существующих антивирусных или антируткит-решений.

Длительные поиски «мифического руткита» не увенчались успехом. Это привело к тому, что любая информация о «Rustock.С» стала восприниматься в околоисследовательских кругах как шутка. Так продолжалось вплоть до мая 2008 года.

Диагноз «Доктора»

В начале мая российская компания «Доктор Веб» заявила антивирусной общественности, что ее специалистами был обнаружен руткит Ntldrbot, он же Rustock.С. Новость столь же неприятная, сколь и сенсационная.

Согласно заявлению представителей «Доктора Веба», этот руткит с октября 2007 года оставался неуловимым для всех антивирусных компаний. Выдвигалось предположение, что при помощи Rustock.C была создана одна из самых мощных на сегодняшний момент зомби-сетей, предназначенная для спам-рассылок. Приводились и ссылки на результаты исследования компании Secure Works, согласно которым бот-сеть, созданная Rustock, стоит на третьем месте среди крупнейших бот-сетей и способна рассылать ежедневно до 30 миллиардов спам-сообщений. Однако вряд ли оценки Secure Works могли иметь какое-либо отношение к найденному руткиту, поскольку он фактически был неизвестен до мая 2008 года. Скорее всего, эксперты Secure Works имели в виду сеть, созданную ранними вариантами Rustock – А и B (по классификации «Лаборатории Касперского» — Trojan-Clicker.Win32.Costrat и SpamTool.Win32.Mailbot).

Судя по опубликованной «Доктором Вебом» информации, образец настоящего Rustock.С попал в руки специалистов компании в конце марта 2008 года, а на анализ кода руткита, создание и выпуск средств его детектирования и лечения им потребовалось более месяца. Только после этого о находке были извещены и другие антивирусные компании.

В описании руткита, сделанном «Доктором Вебом», оставалось слишком много белых пятен. И, в первую очередь, было абсолютно непонятно, каким способом и когда распространялся этот руткит и почему с октября 2007 года он не был никем обнаружен.

Образец тела руткита, распространенный сотрудниками «Доктора Веба», представлял собой драйвер операционной системы Windows размером 244 448 байт.

К сожалению, отсутствовал так называемый «дроппер» — файл, который производит установку руткита в систему. Он мог бы значительно облегчить работу других антивирусных лабораторий при анализе и добавлении собственных процедур обнаружения и лечения Rustock.С, а также помог бы ответить на вопрос о способах изначального распространения руткита.

Отсутствовала также какая бы то ни было достоверная информация о наличии данного руткита «в дикой природе». Оставалась вероятность того, что Rustock.С является исключительно «коллекционной» разработкой и не имеет широкого распространения в мире – в таком случае был бы оправдан столь долгий период его поисков.

Лабораторный анализ

«Лаборатория Касперского» приступила к детальному анализу кода руткита 12 мая. Задача, стоявшая перед нашими экспертами, была действительно сложной. Код руткита был полностью зашифрован неизвестным способом и не поддавался обычным методам анализа упакованного кода и эмуляции. Проблема осложнялась еще и тем, что каждый файл руткита имел некую привязку к аппаратной части зараженного компьютера и не мог быть запущен и проанализирован на других компьютерах и виртуальных машинах.

Однако нашим специалистам удалось за два дня справиться с этими сложностями и, подобрав «ключ», расшифровать значительную часть тела руткита. Вечером 14 мая нам открылись участки настоящего кода Rustock.С.

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

В результате проведенного исследования нами было обнаружено 599 файлов Rustock.С. Часть их представляла собой так называемое «чистое тело» руткита, а часть являлась зараженными системными драйверами. Фактически все файлы были результатом полиморфного изменения одного и того же кода.

Когда был создан руткит

Итак, у нас было шесть сотен файлов, которые отличались размерами и датами поступления в наши ловушки-сборщики файлов. Все найденные файлы попали в ловушки в период с 10 сентября 2007 года по 14 мая 2008 года. Забегая вперед, скажу, что в итоге ни одного образца Rustock.С, созданного ранее сентября 2007 года, нами так и не было обнаружено. Не исключено, что до этого момента действительно могли появляться какие-то более ранние его варианты — тестовые разработки и «пробы пера» автора. Но то, что «Доктор Веб» окрестил Ntldrbot, имеет совершенно четкую дату рождения – сентябрь 2007 года.

Как же быть с пресловутыми слухами о Rustock.С, относящимися еще к концу 2006 года? Мы считаем, что в то время никакого Rustock.С не существовало. Он был создан уже после своеобразного пиара в кругах исследователей руткитов – возможно, как реакция на истерию с его поисками. Косвенно этот вывод может подтверждаться и тем фактом, что в код руткита вписано имя вредоносной программы – «Rustock.С», что не соответствует тому названию, которое ранее автор давал вариантам Rustock.A и B («spambot» и номера версий). Название «Rustock» было дано компанией Symantec первым вариантам руткита, датированным 2005 и 2006 годами. Именно оно было принято в среде исследователей проблемы руткитов, и по аналогии с уже известными ранее вариантами Rustock.A и .B «неуловимый» руткит именовался Rustock.С. Так что назвать свой новый руткит именно так автор мог в подтверждение слухов о его существовании.

Так или иначе, первые «рабочие» образцы Rustock.С появились в сентябре 2007 года, а его разработка, очевидно, началась за несколько месяцев до этого.

Модификации

Анализ 599 файлов выявил много интересных деталей, которые ранее не были известны.

Нами было выделено 4 модификации Rustock.С.

Вариант С1 — мы датируем его создание 10-м сентября 2007 года. «Чистое тело» руткита имеет размер 244 440 — 244 512 байт и содержит драйвер и DLL. Именно эта модификация была исследована специалистами DrWeb и представлена другим антивирусным компаниям.

Вариант С2 относится к 26 сентября. Имеет размер 158 432 — 158 464 байт.

Варианты C3 и С4 относятся к 9-10 октября 2007 года. Их размер варьирует в пределах 158 400 — 158 496 байт.

Несмотря на то что модификация С1 отличается от последующих почти на 100кб, принципиальных различий между ними нет. Автор лишь несколько оптимизировал алгоритм обфускации тела руткита. Все варианты имеют незначительные отличия, касающиеся изменений в коде DLL (спам-бота).

Спам-бот

В течение пяти дней мы проводили анализ руткита: руткит был полностью распакован и запущен на виртуальных машинах (несмотря на отсутствие у нас «дроппера»). Это позволило получить доступ и к коду DLL (спам-бота), обеспечение существования и защита которой является основной целью Rustock.С.

В ходе своей работы руткит извлекает DLL из себя и исполняет ее в системной памяти, внедряя в процесс winlogon.exe. Эта DLL никогда не существует в виде файла на диске и присутствует только в памяти компьютера. Ее задача – рассылка спама с зараженного компьютера. Для выполнения этой задачи она обращается к серверу 208.66.194.215 и получает оттуда шаблоны писем для рассылки. IP-адрес принадлежит американскому хостинг-провайдеру MCCOLO, на ресурсах которого уже довольно давно размещаются и вредоносные программы, и сайты киберпреступных группировок.

Детектирование и лечение

Несмотря на примененные автором средства защиты тела Rustock.С (протектор, криптор, ключ шифрования), с точки зрения добавления детектирования данного руткита в антивирусные базы «Лаборатории Касперского» не было никаких проблем. Складывается впечатление, что автор был настолько уверен в эффективности шифрования своего творения, что не придавал большого значения методам противодействия антивирусным продуктам. Его целью было максимально усложнить и отсрочить анализ кода (как антивирусными компаниями, так и вирусописателями) – именно на это были нацелены все криптотехнологии руткита.

Чуть сложнее обстоит дело с лечением зараженных руткитом системных файлов. Принцип действия руткита основан на заражении только драйверов Windows, созданных Microsoft и загружающихся при старте операционной системы. Именно таким образом руткит получал управление и успешно скрывал свое присутствие в системе. Оригинальный зараженный драйвер хранился в последней секции тела руткита и также был зашифрован.

Алгоритм, с помощью которого руткит шифровал тело зараженного драйвера, оказался довольно простым и не зависел от аппаратной части зараженного компьютера. Это позволило нам реализовать детектирование и полноценное лечение зараженных файлов.

Руткит был классифицирован как Virus.Win32.Rustock.a. Именно как вирус — поскольку Rustock является полноценным файловым вирусом, работающим в режиме ядра операционной системы.

Процедуры детектирования и лечения зараженных файлов были выпущены «Лабораторией Касперского» 20 мая 2008 года (через 8 дней после начала исследования).

Возможность детектирования активного руткита в зараженной системе и лечения зараженных файлов полностью реализована в новой версии нашего антивируса — KAVKIS 2009. Пользователи других версий могут проверить свои компьютеры на наличие Rustock при помощи Rescue Disk с любой версией нашего антивируса. Они также могут обнаружить и вылечить подозрительные файлы при отсутствии активного заражения.

Вопросы и ответы

Казалось бы, задача решена – руткит повержен, и его жертвы получили надежное решение для выявления и устранения проблемы. Однако по-прежнему оставались открытыми главные вопросы: как распространялся Rustock, и действительно ли он существует «в дикой природе»? Найти ответы на эти вопросы и расставить все точки над i было для нас делом чести.

Распространение Rustock

В течение нескольких дней все имеющиеся у нас самплы руткита подвергались детальному анализу на предмет установления их «аппаратных настроек». Это могло дать хотя бы приблизительное представление о масштабах распространения Rustock. Все данные сопоставлялись с датами обнаружения самплов.

Выяснилось, что 590 из 599 самплов попали в наши ловушки с 10 сентября по 23 ноября 2007 года. И только 9 — в период с 23 ноября 2007 года до середины мая 2008 года.

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

Картина получилась следующая:

Варианты Дата обнаружения Периоды появления Количество файлов
C1 10.09.2007 10-13 сентября 2007 года 321
C2 26.09.2007 27 сентября — 9 октября 2007 года;
12 ноября — 22 ноября 2007
199
C3 9-10 октября 2007 9-17 октября 2007 года;
12 ноября — 22 ноября 2007
31
C4 9-10 октября 2007 9-17 октября 2007 года;
12 ноября — 22 ноября 2007
48

С 17 октября по 12 ноября 2007 года не было зафиксировано ни одного случая появления Rustock. Однако с 12 ноября по 22 ноября отмечен новый всплеск активности, причем в основном относящийся именно к варианту C2 (от 26 сентября) с незначительными добавлениями вариантов C3 и C4.

С 23 ноября 2007 года наступает долгий, на несколько месяцев, период затишья (или «смерти»?) Rustock.

Данные были весьма интересны, но масштабы и способы распространения Rustock по-прежнему оставались неизвестными. Несмотря на все усилия, так и не был обнаружен «дроппер» руткита.

Но в конце концов удача нам улыбнулась. Было обнаружено еще более 500 файлов руткита, и именно они дали нам все недостающие звенья цепи.

Ботнет

Наши выводы о том, что активное распространение Rustock началось 10 сентября 2007 года, полностью подтвердились. Теперь мы знаем в деталях, как, с каких серверов он загружался и как устанавливался в системы. Есть у нас и ответы на вопросы «А где же дроппер?» и «Действительно ли пользователи антивирусных продуктов были беззащитны перед «неуловимым» руткитом, который распространялся минимум три месяца?».

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

CoolWebSearch / IFrameBiz / Trafficadvance / LoadAdv.

Да, мы в очередной раз столкнулись с одной из самых известных киберпреступных группировок в Интернете, с которой ассоциируются эти названия. Все они относятся к их сайтам и их вредоносным программам. Банда существует как минимум с начала 2004 года и активна в настоящий момент. Самыми известными и получившими широкое распространение творениями группировки были такие троянцы, как Harnig, Tibs, Femad, LoadAdv и различные модификации Trojan-Downloader.Agent и Small, а также троянец Inject.

Эти умельцы всегда оказывались в авангарде всех вирусных новшеств: в свое время именно они первыми стали массово использовать троянские загрузчики в chm-файлах, именно на их серверах были обнаружены первые варианты эксплоитов уязвимостей в обработке ANI- и ICO-файлов. Они использовали троянские программы, написанные на Java (Trojan-Downloader.Java.ClassLoader), и они же задали моду на использование скриптовых загрузчиков.

«Фирменным» признаком группировки IFrameBiz долгое время были домены в зоне .biz и имена файлов вида loadadv*.exe.

Следы этой группы ведут в Россию. Большинство ее членов, несомненно, проживает именно здесь. На ранних стадиях своего существования группа активно использовала хостинг-ресурсы в Санкт-Петербурге. Также было отмечено ее взаимодействие с печально известной сетью RBN (Russia Business Network), которую многие эксперты также связывают с этим городом.

За 4 года существования группа создала одну из мощнейших систем распространения вредоносных программ. Ее ботнет, основанный на миллионах зараженных различными загрузчиками (в первую очередь Tibs и Femad) компьютеров, способен загрузить на инфицированные машины любую новую вредоносную программу в течение короткого периода времени. Именно такой способ сейчас является эффективной альтернативой рассылкам вредоносного кода по электронной почте, с которыми антивирусная индустрия давно научилась бороться.

Ботнет IFrameBiz активно используется как плацдарм для распространения новых вредоносных программ. Заказчик оплачивает период времени, в течение которого его троянская программа будет распространяться при помощи ботнета. После чего и начинается ее «заливка». Зачастую один и тот же загрузчик (например, Tibs) устанавливает сразу несколько троянцев от разных заказчиков. Услуга пользуется спросом, и даже такое одновременное выполнение нескольких заказов у клиентов не вызывает протеста.

К услугам IFrameBiz прибегали и прибегают как создатели множества Adware-программ, так и желающие создать свой собственный ботнет, спамеры, организаторы DDoS-атак и так далее. Если проводить параллели все с той же RBN, то можно сказать, что RBN — это аппаратная и техническая часть бизнеса вирусописателей, а IFrameBiz — программная начинка и пусковая кнопка для великого множества современных вредоносных программ.

Именно к IFrameBiz и обратились летом 2007 года авторы руткита Rustock с заказом на его распространение. Однако либо троянцы IframeBiz были неспособны незаметно активировать Rustock в системах, либо авторы руткита не хотели давать в руки исполнителей заказа сам код руткита, опасаясь кражи идей и технологий. Для «заливки» по каналам IFrameBiz был создан совершенно отдельный модуль!

Реконструкция событий

Рассмотрим на конкретном примере, что и как происходило в конце сентября 2007 года на одном из зараженных компьютеров, входящих в ботнет IFrameBiz.

Установленный в систему загрузчик (вероятно Tibs) обращается к одному из серверов ботнета в зоне .hk (Хорватия — домены в этой зоне стали использоваться группой в 2007 году) и пытается загрузить файл loadadv351.exe.

Данный файл является усовершенствованным модулем все того же ботнета. По классификации «Лаборатории Касперского», это Trojan.Win32.Inject.mt. Название отражает суть действий вредоносной программы — она внедряет («инжектирует») себя в процесс Explorer.exe, обходя таким образом многие сетевые экраны, и получает возможность для бесконтрольной загрузки файлов в систему.

Троянец отсылает на серверы IFrameBiz информацию об успешной установке и получает приказы — какие файлы и откуда ему следует загружать. Так работает своеобразная система статистики ботнета, позволяющая его владельцам вести учет успешных загрузок вредоносных программ и предоставлять заказчикам отчеты.

Троянец загружает в систему несколько файлов с разных серверов — либо принадлежащих заказчикам, либо с используемых ими ресурсов на серверах IFrameBiz. В рассматриваемом случае файлы загружаются с ресурсов клиентов, арендованных ими у IFrameBiz (http:// *.biz/progs/*). Одновременно производится сбор и отправка данных о зараженном компьютере — операционной системе, жестком диске и прочее. Эти данные нужны для учета состояния бот-сети, ее географического распределения и так далее.

Итак, в системе появляются еще несколько файлов, из которых нас интересуют два — назовем их «1.exe» и «2.exe». Сейчас наше внимание будет направленно на 1.exe (к файлу 2.exe мы вернемся позже).

Это еще один загрузчик, однако весьма необычный. Первый его образец был обнаружен «Лабораторией Касперского» 10 сентября 2007 года — в тот же день, когда появились первые варианты Rustock. Это совпадение уже не кажется удивительным, не правда ли? С того же дня этот загрузчик детектировался нами как Trojan-Downloader.Win32.Agent.ddl.

Эта вредоносная программа содержит в себе драйвер, который загружается в ядро операционной системы (фактически мы уже имеем дело с руткитом!). Код драйвера зашифрован с использованием сложного алгоритма шифрования, очень напоминающего алгоритм, использованный при шифровании Rustock.

Снятие всех слоев защиты с драйвера приводит нас к интересному выводу: эта программа – загрузчик Rustock.

Недостающее звено

Если про руткит слухи ходили еще с декабря 2006 года, то первое и единственное упоминание о загрузчике и самом факте его существования относится к концу октября 2007 года — спустя почти два месяца после того, как он был обнаружен и добавлен в наши антивирусные базы. Стоит ли говорить о том, что по причине «неуловимости» к тому моменту самого Rustock.C никто и не задумывался о существовании его программы-загрузчика.

Однако даже после детектирования Rustock.С, когда следовало найти его «дроппер», некоторые антивирусные компании остановились на достигнутом, ограничившись детектированием руткита. Они не стали тратить время на выяснение того, как руткит попадал на компьютеры и действительно ли пользователи были беззащитны перед «неуловимым руткитом».

Наше исследование дало нам ответ на эти два вопроса. Начиная с 10 сентября 2007 года, с первого же дня распространения через ботнет IFrameBiz руткита Rustock.С, «Антивирус Касперского» детектировал его «разносчика» — Trojan-Downloader.Win32.Agent.ddl. Позже детектирование этого троянца появилось еще у целого ряда антивирусных компаний.

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

К сожалению, даже в настоящее время (начало июня 2008 года) некоторые антивирусные продукты по-прежнему не ловят Agent.ddl.

Загрузчик

Как было отмечено выше, троянец состоит из двух компонентов – основного тела и драйвера. Драйвер собирает информацию о системе: идентификаторы производителя и модель устройств на материнской плате, дату установки и точную версию операционной системы. Затем эта информация зашифровывается и пересылается на сервер автора (или заказчиков) Rustock: 208.66.194.215.

Содержимое буфера, передаваемого на сервер в зашифрованном (TEA) виде:

TSC, Bridge0, Bridge1, InstallDate, Version, ProductID.

Сервер, на который идет отправка данных (208.66.194.215), тот же, который мы уже видели в DLL (спам-боте) руткита — именно оттуда Rustock получает письма для рассылки. Однако метод взаимодействия драйвера загрузчика с сервером отличается от метода, использованного в спам-боте.

Драйвер Agent.ddl работает с виртуальным устройством TCP/IP напрямую из нулевого кольца, в результате чего исходящий с машины трафик при активном заражении невозможно обнаружить с помощью некоторых снифферов/межсетевых экранов. Agent.ddl устанавливает соединение на 443-й порт, пытаясь замаскировать данные под пакеты протокола HTTPS. В результате исследователь, даже перехватив трафик на шлюзе, не сразу поймет, что это никакой не HTTPS, а просто зашифрованные данные, собранные на зараженном компьютере.

Вот пример пакета с зараженной машины, который выдавался за HTTPS-данные:

При этом ключ шифрования изменяется при каждом новом запуске драйвера. Сложность обнаружения достигается тем, что внешний наблюдатель не знает алгоритма и ключа шифрования.

Следует отметить что авторы троянца-загрузчика явно старались максимально усложнить жизнь исследователям кода драйвера.

IP-адрес центрального сервера, как и порт, по которому будет обращаться драйвер, зашиты в тело программы, так чтобы скрыть их явное представление:

push 00000BB01 ; порт — 443
push 0E00C04E1
sub d,[esp],00849C211; Разность равна 0xD7C242D0, т.е. IP-адресу 208.66.194.215

Авторы поработали и над обфускацией кода. Например, простая операция

mov [eax], ecx

после обфускации выглядит так:

push ebx
mov ebx, 0x03451b8c
sub ebx,eax
sub ebx, 0x03451b8c
neg ebx
mov [ebx], ecx
pop ebx

Одна инструкция заменялась на семь. Можно вообразить, что из себя представляют остальные «внутренности» драйвера!

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

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

Сгенерированный файл руткита, «чистое тело», загружается на компьютер-жертву, где Agent.ddl производит его активацию в системе. Rustock.C заражает свой первый системный драйвер, и еще одним компьютером в новом спам-ботнете становится больше.

В настоящее время сервер заблокирован. Все пакеты, идущие к нему, фильтруются сетевыми маршрутизаторами. Должно быть, компетентные органы уже заинтересовались упомянутым IP-адресом.

Заключение

Реконструкция событий, выполненная нашими экспертами, доказывает факт активного распространения данного руткита в сентябре-ноябре 2007 года. С одной стороны, использованная для этого сеть IFrameBiz могла обеспечить ему действительно широкое распространение. С другой стороны, приведенные факты показывают, что «неуловимость» руткита была вызвана исключительно высоким уровнем шифрования его кода и использованием множества антиотладочных приемов, затруднявших его анализ для большинства экспертов.

Руткит был у антивирусных компаний со дня его появления «в дикой природе». Его активность при установке в систему и компоненты, отвечавшие за его установку и распространение, столь же давно и успешно обнаруживались почти всеми антивирусными продуктами, за редким исключением. Его появление в системе могло быть перехвачено на самой ранней стадии при помощи несложных средств мониторинга изменений файловой системы.

Все это происходило с Rustock десятки раз, но детальный анализ его кода был сделан только в мае 2008 года.

Rustock.С действительно существует, и это не миф. А вот его «неуловимость» – миф, основанный не на каких-то реализованных в рутките сверхъестественных принципах сокрытия себя в системе, а все на тех же слухах, появившихся еще в конце 2006 года и играющих на руку только авторам вредоносной программы.

Любой руткит, создаваемый с учетом существующих средств детектирования, будет обходить защиту, которую эти средства обеспечивают. Война на уровне ядра операционной системы в конечном итоге сводится к решению одного вопроса: кто раньше получит управление — руткит или антируткит.

Целью автора Rustock было не создание недетектируемого в принципе руткита, а максимальное усложнение процесса анализа руткита после того, как он будет обнаружен. Именно это могло обеспечить некий временной выигрыш между периодом распространения и началом детектирования вредоносной программы.

Остается неясным только один вопрос: почему автор Rustock прекратил в середине октября 2007 года совершенствование руткита и выпуск его новых версий? Не означает ли это, что он занялся созданием нового проекта, и, возможно, где-то уже существует «Rustock.D»?

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

До тех пор, пока в Интернете продолжают существовать IframeBiz и аналогичные ей группы, ответственные за ежедневное распространение сотен новых вредоносных программ, за многочисленные взломы веб-сайтов и десятки эпидемий, праздновать успех в одной локальной победе никак нельзя.

P.S. Выше мы писали о том, что Trojan.Win32.Inject.mt устанавливал в систему два файла — 1.exe и 2.exe. Мы не рассказали о том, чем же был второй файл.

Он был очередным вариантом троянца-шпиона Sinowal. Тем самым Sinowal, который спустя пару месяцев после описываемых событий стал еще одной головной болью для антивирусных компаний и вошел в историю как «буткит».

И Rustock, и Sinowal распространялись одновременно и через один и тот же ботнет. Новые версии Rustock перестали появляться в середине октября 2007 года. Первые образцы «буткита» были обнаружены спустя месяц — в ноябре 2007 года.

Просто совпадение?

Возможно, мы когда-нибудь узнаем ответ и на этот вопрос.

Rustock и все-все-все

Ваш e-mail не будет опубликован. Обязательные поля помечены *

 

Отчеты

StripedFly: двуликий и незаметный

Разбираем фреймворк StripedFly для целевых атак, использовавший собственную версию эксплойта EternalBlue и успешно прикрывавшийся майнером.

Азиатские APT-группировки: тактики, техники и процедуры

Делимся с сообществом подходами, которые используют азиатские APT-группировки при взломе инфраструктуры, и подробной информацией о тактиках, техниках и процедурах (TTPs) злоумышленников, основанной на методологии MITRE ATT&CK.

Как поймать «Триангуляцию»

Эксперты «Лаборатории Касперского» смогли получить все этапы «Операции Триангуляция»: эксплойты нулевого дня для iOS, валидаторы, имплант TriangleDB и дополнительные модули.

Подпишитесь на еженедельную рассылку

Самая актуальная аналитика – в вашем почтовом ящике