«Лаборатория Касперского» о неуловимом рутките
В декабре 2006 года в некоторых кругах исследователей проблемы руткитов (как blackhat, так и whitehat) стали циркулировать слухи о том, что кем-то создан и выпущен в свет «абсолютно неуловимый руткит» — Rustock.С, — который при активном заражении не способно обнаружить ни одно из существующих антивирусных или антируткит-решений.
Длительные поиски «мифического руткита» не увенчались успехом. Это привело к тому, что любая информация о «Rustock.С» стала восприниматься в около-исследовательских кругах как шутка. Такое положение вещей сохранялось вплоть до мая 2008 года.
Диагноз «Доктора«
В начале мая антивирусная индустрия услышала от российской компании «Доктор Веб» неприятную и сенсационную новость — ее специалистами был обнаружен руткит Ntldrbot, он же Rustock.С.
Согласно заявлению представителей «Доктор Веб», этот руткит с октября 2007 года оставался неуловимым для всех антивирусных компаний. Выдвигалось предположение, что при помощи Rustock.C была создана одна из самых мощных на сегодняшний момент зомби-сетей, предназначенная для спам-рассылок.
Приводились и ссылки на результаты исследования компании Secure Works, согласно которым бот-сеть, созданная Rustock, стоит на третьем месте среди крупнейших бот-сетей и способна рассылать ежедневно до 30 миллиардов спам-сообщений. Отметим, что вряд ли оценки Secure Works имели какое-то отношение к найденному руткиту, поскольку он фактически был неизвестен до мая 2008 года. Скорее всего, эксперты Secure Works имели в виду сеть, созданную ранними вариантами Rustock — А и B (по классификации «Лаборатории Касперского» — 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.С не существовало. Он был создан уже после своеобразного «PR» в кругах исследователей руткитов — возможно, как реакция на истерию с его поисками. Косвенно этот вывод может подтверждаться и тем фактом, что код руткита содержит самоназвание «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. Именно эта модификация была исследована специалистами «Доктор Веб» и представлена другим антивирусным компаниям.
Вариант С2 относится к 26 сентября. Имеет размер 158 432 — 158 464 байт.
Варианты C3 и С4 относятся к 9-10 октября 2007 года. Их размер варьирует в пределах 158 400 — 158 496 байт.
Несмотря на то, что модификация С1 отличается от последующих почти на 100кб, принципиальных различий между ними нет. Автор лишь несколько оптимизировал алгоритм обфускации тела руткита. Все варианты имеют незначительные отличия, касающиеся изменений в коде DLL (спам-бота).
Спамбот
В течение 5 дней исследований нами был проведен анализ руткита, руткит был полностью распакован и запущен на виртуальных машинах (без наличия у нас «дроппера»). Это позволило получить доступ и к коду DLL (спам-бота), существование и защита которой является основной целью Rustock.С.
В ходе своей работы руткит извлекает DLL из себя и исполняет ее в системной памяти, внедряя в процесс winlogon.exe. Данная DLL никогда не существует в виде файла на диске и присутствует только в памяти компьютера. Ее задача — рассылка спама с зараженного компьютера. Для выполнения этой задачи она обращается к серверу 208.66.194.215 и получает оттуда шаблоны писем для рассылки. IP-адрес принадлежит американскому хостинг-провайдеру MCCOLO, на ресурсах которого уже довольно давно размещаются и вредоносные программы, и сайты киберпреступных группировок.
Детектирование и лечение
Несмотря на примененные автором средства защиты тела Rustock.С (протектор, криптор, ключ шифрования), с точки зрения добавления детектирования данного руткита в антивирусные базы «Лаборатории Касперского» не было никаких проблем. Складывается впечатление, что автор был настолько уверен в эффективности шифрования своего творения, что не придавал большого значения методам противодействия антивирусным продуктам. Его целью было максимально осложнить и отсрочить анализ кода (как антивирусными компаниями, так и представителями вирусописательских кругов) — именно на это были нацелены все криптотехнологии руткита.
Чуть сложнее обстоит дело с лечением зараженных руткитом системных файлов. Принцип действия руткита основан на заражении только драйверов Windows, созданных Microsoft и загружающихся при старте операционной системы. Именно таким образом он получал управление и успешно скрывал свое присутствие в системе. Оригинальный зараженный драйвер хранился в последней секции тела руткита и также был зашифрован.
Алгоритм, которым руткит шифровал тело зараженного драйвера, оказался довольно простым и не зависел от аппаратной части зараженного компьютера. Это позволило нам реализовать детектирование и полноценное лечение зараженных файлов.
Руткит был классифицирован как Virus.Win32.Rustock.a. Именно как вирус — поскольку Rustock является полноценным файловым вирусом, работающим в режиме ядра операционной системы.
Процедуры детектирования и лечения зараженных файлов были выпущены «Лабораторией Касперского» 20 мая 2008 года (через восемь дней после начала исследования).
Возможность детектирования активного руткита в зараженной системе и лечения зараженных файлов полностью реализована в новой версии нашего антивируса — KAVKIS 2009. Пользователи других версий могут проверить свои компьютеры на наличие Rustock при помощи Rescue Disk с любой версией нашего антивируса. Они также могут обнаружить и вылечить подозрительные файлы при отсутствии активного заражения.
Вопросы и ответы
Казалось бы, задача решена — руткит повержен, и его жертвы могут получить надежное решение для выявления и устранения проблемы. Однако специалисты «Лаборатории Касперского» не собирались останавливаться на достигнутом.
По-прежнему оставались открытыми главные вопросы — как распространялся Rustock, и действительно ли он находится в «дикой природе»? Найти ответы на эти вопросы и расставить все недостающие точки над i, было для нас делом чести.
Распространение Rustock
В течение нескольких дней все имеющиеся у нас файлы руткита подвергались детальному анализу на предмет установления их «аппаратных настроек». Это могло дать хотя бы приблизительное представление о масштабах распространения Rustock. Все данные сопоставлялись с датами обнаружения самплов.
Выяснилось, что 590 из 599 самплов попали в наши ловушки с 10 сентября по 23 ноября 2007 года. И только девять — в период с 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), которую многие эксперты также связывают с этим городом.
За четыре года существования группа создала одну из мощнейших систем распространения вредоносных программ. Ее ботнет, основанный на миллионах зараженных различными загрузчиками (в первую очередь 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-адресом.
Вот именно таким способом и происходило распространение «неуловимого» Rustock.
ЗаключениеЗ
Реконструкция событий, выполненная нашими экспертами, доказывает факт активного распространения данного руткита в сентябре-ноябре 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 года.
Просто совпадение?
Возможно, мы когда-нибудь узнаем ответ и на этот вопрос