Zeroaccess cfg что это

Microsoft начали охоту за ZeroAccess

Про одну из последних модификаций этой вредоносной программы мы писали в блоге. Современная версия ZAccess использует скрытное заражение системного файла services.exe (aka SCM). Причем вредоносный код имеет в своем арсенале и компоненты для 64-битной версии Windows. Подобный способ обеспечения своего выживания является достаточно эффективным, при этом нужно отметить, что авторы этого вредоносного ПО подходили к его разработке весьма серьезно, так предыдущие версии содержали специальный сложно обнаруживаемый руткит, который глубоко скрывал компоненты вредоносной программы. В прошлом году стало очевидно, что злоумышленники переключились на разработку обновленной версии, которая использует модификацию services.exe. Очевидно это связано с все большим доминированием 64-битных ОС и невозможностью применения 32-битных руткит-технологий на этих ОС ввиду очевидных ограничений.

Несмотря на то, что Microsoft совместно с другими компаниями и ISP ставят перед собой цель очистки компьютеров от вредоносного кода, данная операция направлена не на ликвидацию кода ZeroAccess. Предпринятые меры используются для разрушения инфраструктуры получения прибыли киберпреступниками. Ботнет использует распределенную P2P-архитектуру, что значительно усложняет его устранение в целом.

Компания не разглашает деталей операции, однако известно, что она получила разрешение на блокирование работы компьютеров с идентифицированными IP-адресами, через которые осуществлялись мошеннические схемы в Европе и США. Также благодаря усилиям European Cybercrime Centre был осуществлен физический демонтаж серверов, которые использовались для управления ботнетом.

Как и в случае с Citadel (Zeus-based bot), суд удовлетворил прошение MS о передаче под их контроль доменов, которые использовались злоумышленниками.

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

Источник

Анализ вредоноса ZeroAccess

Троян ZeroAccess (Maxx++, Sierief, Crimeware) поселился на миллионах машин по всему миру и занимает лидирующие позиции в таких областях, как генерация биткоинов и обман партнерских программ с оплатой за клики. Как только троян оказывается в системе, начинается загрузка других вредоносов, каждый из которых может нанести серьезный ущерб как отдельному пользователю, так всей компании.

Троян ZeroAccess (Maxx++, Sierief, Crimeware) поселился на миллионах машин по всему миру и занимает лидирующие позиции в таких областях, как генерация биткоинов и обман партнерских программ с оплатой за клики. Как только троян оказывается в системе, начинается загрузка других вредоносов, каждый из которых может нанести серьезный ущерб как отдельному пользователю, так всей компании.

Основные средства доставки трояна – почтовый спам или паки с эксплоитами. Другие каналы заражения – P2P-сервисы, поддельные кряки и генераторы ключей. Все экземпляры вредоноса объединены в сеть на базе протокола P2P, что значительно затрудняет ликвидацию ботнета в целом.

ZeroAccess использует продвинутые технологии маскировки и полностью невидим для некоторых антивирусов, что в целом крайне затрудняет обнаружение в системе этого трояна. Вредонос не оставляет никаких следов, свидетельствующих о том, что произошла утечка информации. Сетевая активность происходит от имени легитимных системных процессов. Обычно исполняемый файл находится в папке %TEMP% на рабочей станции, а трафик передается посредством HTTP GET- и POST-запросов.

Находясь в системе жертвы, ZeroAccess может выполнять широкий спектр задач, включая:

ZeroAccess можно загрузить с kernelinfo.com. В целях анализа троян был загружен умышленно.

Рисунок 1: Содержимое памяти, имеющее отношение к дропперу

Рисунок 2: Параметры исполняемого файла дроппера

Рисунок 3: Признак того, что используется антиотладочная техника

Рисунок 4: Maxx++ расшифровывает собственный код небольшими порциями

Рисунок 5: Вредонос пытается получить доступ к директории %APPDATA%

Рисунок 6: Подозрительный мьютекс в памяти

Рисунок 7: DLL’ка, инжектированная в память процесса explorer.exe

Рисунок 8: Скрытый модуль ядра

Рисунок 9: Вредоносный драйвер выгружен на диск

Рисунок 10: Троян пытается соединиться с веб-сервером

Рисунок 11: Закодированные запросы к домену internsedive.com

Рисунок 12: Информация о домене internsedive.com

Рисунок 13: Информация об IP-адресе

Рисунок 14: Домен intensedive.com привязан к 3 IP-адресам

Источник

Обнаружена связь между руткитами TDSS и ZeroAccess

Trend Micro обнаружила факты, указывающие на прямую связь между этими семействами вредоносного ПО.

Уже много было сказано о руткитах TDSS и ZeroAccess, а также об их сходстве. Исследователи из Trend Micro обнаружили нечто, что может указывать на прямую связь между этими семействами вредоносного ПО.

Возможности руткитов TDSS и ZeroAccess хорошо задокументированы. Оба вредоноса используют пиринговую связь, а посылаемый ими трафик зашифрован методом кодирования base64 и состоит из «мусорных» символов. Кроме того, обе программы нацелены на осуществление кликфрода.

По словам исследователей, TDSS и ZeroAccess поддерживают пиринговые сети с похожими функциями, но реализованы по-разному. ZeroAccess инфицирует COM-объекты и service.exe, тогда как TDSS поражает MBR. Примечательно то, что, при обнаружении на компьютере жертвы TDSS, ZeroAccess деактивирует его. Из этого можно сделать вывод, что руткиты созданы соперничающими разработчиками и распространяются злоумышленниками, враждующими между собой.

Тем не менее, исследователи обнаружили, что некоторые новые версии TDSS и сравнительно старая версия ZeroAccess одновременно использовали один и тот же домен. Эксперты считают, что модуль, содержащий алгоритм генерации доменного имени, который использовался в более ранней версии ZeroAccess, был адаптирован для новых версий TDSS, в частности, для DGAv14. Однако, по словам исследователей, это не обязательно должно свидетельствовать о сотрудничестве между разработчиками обоих руткитов.

Источник

ZeroAccess это троянский конь компьютер вредоносное ПО это влияет Майкрософт Виндоус операционные системы. Он используется для загрузки других вредоносных программ на зараженную машину с ботнет оставаясь скрытым, используя руткит техники. [1]

Содержание

История и распространение

Ботнет ZeroAccess был обнаружен примерно в мае 2011 года. [2] ZeroAccess руткит ответственный за распространение ботнета, по оценкам, присутствовал как минимум на 9 миллионах систем. [3] Оценки размера ботнета различаются по источникам; поставщик антивируса Sophos оценил размер ботнета примерно в 1 миллион активных и зараженных машин в третьем квартале 2012 года, а компания по безопасности Kindsight оценила 2,2 миллиона зараженных и активных систем. [4] [5]

В декабре 2013 года коалиция во главе с Microsoft предприняла попытку уничтожить сеть управления ботнетом. Однако атака была неэффективной, потому что не все C&C были захвачены, а ее компонент однорангового управления и контроля не был затронут, то есть ботнет все еще мог обновляться по желанию. [8]

Операция

После заражения системы руткитом ZeroAccess она запускает одну из двух основных операций ботнета: биткойн майнинг или же мошенничество с кликами. Машины, участвующие в майнинге биткойнов, генерируют биткойны для их контролера, оценочная стоимость которого составляла 2,7 миллиона долларов США в год в сентябре 2012 года. [9] Машины, используемые для мошенничества с кликами, имитируют клики по рекламе на веб-сайтах, оплаченные платить за клик основание. Ориентировочная прибыль от этой деятельности может достигать 100 000 долларов США в день, [10] [11] обойдется рекламодателям в 900 000 долларов в день за счет мошеннических кликов. [12] Обычно ZeroAccess заражает Главная загрузочная запись (MBR) зараженной машины. В качестве альтернативы он может заразить случайный драйвер в C: Windows System32 Drivers, дав ему полный контроль над Операционная система. [ нужна цитата ] Он также отключает Центр безопасности Windows, Брандмауэр и Защитник Windows из операционной системы. ZeroAccess также подключается к TCP / IP стек, чтобы помочь с мошенничеством с кликами.

Программа также ищет вредоносное ПО Tidserv и удаляет его, если находит. [1]

Источник

Zeroaccess

Опубликовано в журнале Хакер #171 (апрель 2013)

Со временем некоторые вредоносные программы становятся своеобразными брендами в среде киберандеграунда. Как правило, они имеют широкое распространение по сравнению с другими вредоносами и используют различные технологичные фишки. К таковым можно отнести семейства Sality, Conficker, Waledac, Zeus, TDL и множество других. Как бы ни боролись с такими угрозами антивирусные компании, как говорится — иногда они возвращаются. В логичности использования раскрученного имени злоумышленникам не откажешь. Разбирая функционал очередной «зверушки», невольно задаешь себе вопрос — а когда это все началось? И выясняется, что и ни год, и ни два назад. Об одном таком семействе и будет рассказано далее.

История ZeroAccess (aka MAX++) началась в июне в 2009 год. Именно тогда был обнаружен образец вредоносной программы, который использовал путь вида \\?\globalroot\Device\__max++>\[8 digit hex code].dll, а в драйвере ядра имел строку «f:\VC5\release\ZeroAccess.pdb». Так что название ZeroAccess — авторское. Но, как известно, некоторые антивирусные вендоры противятся называть вредоносы согласно задумке авторов, поэтому MAX++ также известен под названиями Smiscer и Sirefef. Версия 2009 года прятала свой бинарный код в альтернативных потоках (Alternate Data Streams — ADS) файловой системы NTFS под названиями win32k.sys:1 и win32k.sys:2, которые прописывались в системе как сервисы. Первый из этих файлов был приманкой, в случае, если антивирусное ПО пыталось получить доступ к нему, ZeroAccess немедленно завершал сканирующий процесс. Впоследствии, использование техники слежения за специально созданными объектами ОС для «убийства» антивирусов, стало его отличительной особенностью.

В январе 2010 создатели ZeroAccess принялись распространять новую версию своего детища. Для этого задействовались ресурсы сети Ecatel компании RBN. Отличительным признаком новой версии ZeroAccess, было явное заимствование идей TDL3, а именно — запуск через заражение драйвера и использование скрытого хранилища для своих компонентов.

Установка в систему начиналась с файла-дроппера, например, с именем keygen.exe. Для нормальной работы необходимы были права администратора, что в условиях маскировки под кейген для любимой игрушки не было особой проблемой. При установке на диск никаких временных рабочих файлов не извлекалось, все манипуляции происходили в памяти. Для старта при загрузке ОС использовалась методика загрузки при помощи функции ZwLoadDriver(). Перво-наперво выбирался существующий в системе драйвер-жертва, подпадающий под несколько необходимых признаков: имя драйвера должно было находится в диапазоне от Ndis.sys до Win32k.sys, размер — более 0x4C10 байт, IMAGE_OPTIONAL_HEADER->Export Table.RVA выставлен в NULL (драйвер ничего не экспортирует). Так же драйвер не должен был запускаться при загрузке системы, это проверялось по флагу Start (0 — не загружать) в ветке реестра services. Выбрав подходящий драйвер, ZeroAccess целиком переписывал его своим кодом, предварительно отключив SFC. Далее создавалась запись в реестре о новом сервисе со случайным именем и параметрами Type = 0x1, Start = 0x3. Хитрость заключалась в том, что ImagePath для сервиса выставлялся в \*, а для \* при помощи функции ZwCreateSymbolicLinkObject() создавался симлинк на перезаписанный драйвер. Указанный сервис и стартовал путем вызова ZwLoadDriver(). Запущенный руткит регистрировался через вызов IoCreateDriver() в качестве драйвера ОС, для перехвата операции ввод/вывода на уровне IRP пакетов драйверов минипорта дисковой подсистемы. Далее создавалось виртуальное устройство с фиксированным именем \??\C2CAD972#4079#4fd3#A68D#AD34CC121074, к которому подмонтировался ранее созданный файл хранилища под именем %system%\Config\[random symbols].sav. Теперь дроппер мог обращаться к своему хранилищу через виртуальное устройство. После форматирования хранилища в сжатый том NTFS при помощи функций библиотеки fmifs.dll, туда сохранялись все остальные компоненты, включая копию чистого драйвера. Структура файлов приведена на рисунке.

Функция руткита заключалась в сокрытии содержимого перезаписанного драйвера, при попытке его чтения, руткит демонстрировал сохраненный исходный файл. Помимо этого руткит инициировал запуск инжектора B48DADF8.sys, который внедрял основной модуль-DLL с именем мax++.00.x86, в адресное пространство браузера посредством APC. Можно заметить, что в ходе работы функции непосредственного запуска вообще не используются, дабы не вызывать срабатываний проактивной защиты антивирусов. Основной модуль имел функции связи с командным центром и подмены поисковой выдачи для перенаправления пользователя на вредоносные сайты, предлагающие загрузить фэйковый антивирус (FakeAV). Параметры подключения брались из файлов в хранилище с названиями, похожими на CLSID, например <49B474EB-92D0-464f-B1DD-1F37AABF9D95>. По информации Symantec между 1 июля 2009 и 30 июня 2010 было произведено около 43 миллионов установок поддельных антивирусов. С учетом стоимости такого «подарка» от 30$ до 100$, вырисовывается, что этот бизнес был достаточно прибыльным.

В 2011 году появилась обновленная версия. Для загрузки руткита использовался все тот же метод запуска через ZwLoadDriver() с небольшими изменениями. Теперь драйвера выбирались из диапазона от classpnp.sys до win32k.sys, размером больше чем 0x7410. В коде дроппера присутствовала проверка на выполнение в 64-разрядной среде, в этом случае выполнение сразу завершалось. Имя устройства для обращения к хранилищу имело вид \\?\ACPI#PNP0303#2&da1a3ff&0 (могло меняться от релиза к релизу). Файл хранилища размером 16 мегабайт %system%\Config\[random symbols] на этот раз не был сжат, а шифровался 128 битным статическим ключом RC4, расшифровка производилась на лету драйвером руткита при обращении к файлам, содержавшимся в хранилище. Появилась ярко выраженная модульная структура,

модули загружались с удаленного сервера. Для связи с командным центром устанавливалось соединение на порт 13620. Сами запросы и ответы передавались в зашифрованном виде.

Работа в x64 и трюки самозащиты

Вплоть до апреля 2011 года 64-разрядные версии ОС не заражались ZeroAccess. В мае это досадное упущение было исправлено, но не сказать, что бы очень технологично. Дело в том, что для x86 алгоритм работы был аналогичен предыдущей версии и руткит работал на уровне ядра. В противовес этому в среде x64 все работало в usermode.

Как известно, в Windows, начиная с Vista, появился UAC — компонент системы, который запрашивает подтверждение действий, требующих прав администратора. UAC конечно несколько повысил уровень безопасности Windows, но, как всегда, злобные хакеры все испортили. В UAC жестко прописаны многие системные программы, как доверенные (например, explorer.exe), поэтому код, который приводит к срабатыванию для других приложений, для них не работает при настройке по умолчанию. Эта особенность была использована в дроппере ZeroAccess для того, что бы поднять свои привилегии в системе до уровня администратора, окно UAC при этом пользователю не показывалось (со временем этот баг был исправлен).

Краткое описание загружаемых из Интернета компонентов:
@00000001 — резервная копия дроппера;
@80000000 — модуль трекинга, предназначен для сбора статистики заражений, информация о зараженной системе отправлялась на counter.yadro.ru;
@800000c0 — поддельная библиотека mswsock.dll для перехвата функций WinSocks, их мониторинг позволял красть пароли и логины FTP, а также производить внедрение JavaScript в HTML страницы;
@000000c0 — модуль внедряет JavaScript для изменения выдачи поисковых запросов и отправляет данные FTP аккаунтов на удаленный сервер;
@800000cb — модуль внедряется в svchost.exe и используется для накрутки посещаемости (click fraud);
@800000cf — модуль связи с командным центром, внедряется в winlogon.exe, а затем в браузер, установленный на компьютере. В адресном пространстве браузера выполняется код, связывающийся по фиксированным IP адресам и порту 13620 с командным центром. Список IP находится в файле с именем, похожим на CLSID.

Интересная фишка данной версии ZeroAccess — использование техники «ловли на живца» для обламывания антивирусов. Кроме своего основного драйвера-руткита, ZeroAccess имел дополнительный драйвер ядра для создания «приманки» — объекта, на который «клевали» антивирусные средств защиты. Этот драйвер создавал устройство \Device\svchost.exe и сохранял подставной PE файл как \Device\svchost.exe\svchost.exe, доступ к которому мониторился руткитом. Если какое-либо приложение пыталось обратиться к нему, то ZeroAccess немедленно завершал его. Для завершения потока приложения, в него методом APC инжектировалось около двухсот байт кода, который вызывал ExitProcess(). Но это было еще не все, что бы предотвратить последующие запуски завершенного приложения, для его исполняемого файла ZeroAccess сбрасывал правила доступа ACL, разрешающие чтение и выполнение файла. Таким образом, один раз попавшись на крючок, антивирус больше не мог запуститься.

С целью повысить живучесть, разработчики стали использовать различные ухищрения. Основной упор был на возможность работы ZeroAccess при любых правах доступа, а так же противодействие блокированию командных центров. При запуске в Windows Vista/Seven происходила попытка повысить свои права. Так как баг с обходом UAC через инжект в explorer.exe был пофикшен, для поднятия прав стал использовался DLL hijacking, его сущность — ОС сначала ищет необходимую DLL в текущей директории, а потом в системной, поэтому, разместив в директории легитимной программы DLL с именем, совпадающим с именем одной из импортируемых библиотек, можно добиться запуска вредоносного кода. Для реализации этого метода на борту дроппера, во внедренном CAB файле,

присутствовал файл fp.exe. Это был легальный онлайн инсталятор Adobe Flash Player, снабженный, к тому же, цифровой подписью VeriSign. Инсталлятор сохранялся под именем FlashPlayerInstaller.exe в каталог temp, в этот же каталог предварительно помещался файл msimg32.dll, имя которого совпадает с одной из импортируемых DLL.

Запуск «X» файла прописывался в параметре Shell ветки HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Таким образом, функционирование ZeroAccess поддерживалось из-под учетной записи с ограниченными правами, пусть даже и без руткит функций.

По данным компании Sophos, активное распространение P2P TCP-based версии началось в сентябре-ноябре 2011, тогда как первые сэмплы появились в конце июля. Антивирусные аналитики отмечают, что данная версия загружала два основных вида полезной нагрузки — click fraud и spambot, которые легко определить по используемым портам (21810, 22292 и 34354, 34355 соответственно).
Bootstrap list содержал 256 значений IP адресов, для каждого из которых указывалась timestamp (POSIX) последнего обращения. Все пакеты P2P сети шифровались по алгоритму RC4 статическим ключом.

Поддерживались следующие типы команд:
«getL» — запрос на получение bootstrap list;
«retL» — ответ с содержимым bootstrap list;
«getF» — запрос на получение файла;
«setF» — ответ с содержимым файла;
«srv?» — запрос на получение списка файлов.
Кстати, тип команды — это не строка, а 4 байтовое слово, их так легче сравнивать. Название файла модуля из восьми HEX символов тоже кодировалось 4 байтами.

Для каждой ноды в текущем bootstrap list, посылалась команда «getL». Удаленный компьютер должен был ответить командой «retL» и переслать свой bootstrap list. Результирующий список, созданный на основе текущего и присланного, содержал ноды с временем обращения, наиболее близким к текущему. В ответ на запрос «srv?» отправлялся список файлов, каждая запись в списке содержала два поля: имя файла из 4 байт и timestamp создания файла. При обнаружении «свежих» файлов, происходило их обновление командами «getF», «setF». Каждый загружаемый модуль должен был содержать в себе ресурс «33333», содержащий цифровую подпись RSA с ключом 512 бит. Подпись проверялась перед запуском файла.

В протоколе P2P имелись некоторые недостатки реализации. Сформировав bootstrap list из 256 IP с заведомо большими значением timestamp, чем текущее время, было возможно «отравить» bootstrap list всех нод, что привело бы к невозможности распространять модули по сети P2P. Если в хранилище поместить произвольный файл (замечание — значение поля milliseconds в структуре time_field фала должно было быть при этом равным нулю), он выкачивался удаленными пирами, хоть его запуск и был невозможен из-за проверки подписи. Это позволяло создать нагрузку на сеть и тем самым привлечь внимание к аномальному сетевому трафику на компьютере с дальнейшим обнаружением и удалением ZeroAccess. Указанные недостатки были исправлены в следующей реализации P2P.

Помаши руткиту ручкой

Май 2012 — вот и кончилось время, когда в составе ZeroAccess был драйвер ядерного уровня, теперь вся работа происходила в usermode. Заглянув в содержимое CAB файла можно обнаружить, что из него исчезли компоненты rtk32 и rtk64, зато добавились w32, w64, e32, e64.

Руткит компонент нет, соответственно драйвер Windows в этой версии не перезаписываются, для запуска при загрузке системы может использоваться один из двух методов — техника COM hijacking, которая использует системный реестр, и модификация файла services.exe.

При помощи COM hijacking запускается на выполнение файл с именем «n» (n32 или n64), который отвечает за работу сети P2P. Дроппером создаются два идентичных файла «n» в следующих двух местах:
%Windir%\installer\[UID];
%UserProfile%\local settings\application data\[UID] (для XP и ниже) или %UserProfile%\AppData\Local\[UID] (для Vista и выше).

Здесь UID — значение, генерируемое дроппером на основе хеша MD5 от времени создания системного диска и отформатированное, что бы выглядеть, как CLSID, например . В указанных каталогах также создаются подкаталоги «U» (для дополнительных модулей) и «L» (для временных файлов), а также файл «@» (s32 или s64).

Один файл «n» использует hijacking COM объекта, ассоциированного с WMI, при этом модифицируется следующий ключ реестра: HKCR\CLSID\\InprocServer32.
Другой файл «n» использует для запуска COM объект в ветке:
HKCU\Software\Classes\clsid\<42aedc87-2188-41fd-b9a3-0c966feabec1>.

Модификация файла services.exe производилась интересным образом: в файл вставлялся небольшой шелл-код (w32 или w64), который вызовом функции ZwQueryEaFile() подгружал «хвост» вредоносного кода (e32 или e64) из Extended Attributes файла, предварительно сохраненного туда при помощи ZwSetEaFile(). Функционал PE файлов в компонентах e32 и e64 был идентичен n32 и n64.
Более поздние версии прячут свои файлы внутри C:\$Recycle.Bin или С:\RECYCLER,

где создавался каталог с именем, соответствующему CLSID пользователя компьютера. Если были права администратора, создавался еще каталог с CLSID S-1-5-18 (LOCAL_SYSTEM). Внутри создавался подкаталог со случайным именем, образованным хэшированием MD5 текущего времени. Для старта каждой из двух копий файла «n» создавались следующие COM объекты:
HKCU\Software\Classes\clsid\ — для пользователя с ограниченными правами;
HKCR\CLSID\ <5839FCA9-774D-42A1-ACDA-D6A79037F57F>— для пользователя с правами администратора.

Алгоритм работы P2P сети претерпел некоторые изменения. В зависимости от разрядности ОС использовались разные порты: 16464 и 16470 для x32, 16465 и 16471 для x64. Таким образом, организовывалось 4 независимых P2P сети, в каждой из которой использовался свой RSA ключ, длина которого была увеличена с 512 до 1024 бит. Как и прежде, существовало разделение по типу полезной нагрузки, порты 16464 и 16465 использовались релизом с click fraud payload, 16470 и 16471 — релизом с bitcoin miner payload.

Если раньше P2P использовал только TCP, то теперь список IP-адресов запрашивался по UDP, а список файлов (модулей) — по ТСР. Команда «retL» теперь возвращала только 16 значений из своего bootstrap list (противодействие «отравлению» bootstrap list), в этом же блоке данных передавались сведения о имеющихся модулях. В bootstrap list теперь указывалось не абсолютное значение timestamp, а разница между текущим временем и временем последнего обращения. Сведения об используемых модулях передавались в виде заголовка, состоящего из полей File name, Timestamp, Size. К заголовку прилагалась цифровая подпись (хэш MD5, зашифрованный закрытым ключом злоумышленников). Подпись проверялась на корректность при загрузке и сохранялась в Extended Attributes файла. Таким образом, криптографическая защита от постороннего вмешательства имелась как на уровне содержимого (как и в предыдущей версии, ресурс «33333», содержащий цифровую подпись), так и на уровне имени, даты создания и размера файла. Сам файл при передаче шифровался RC4 ключом. Для принудительной смены bootstrap list была введена команда NewL, которая могла использоваться при обнаружении злоумышленниками sinkhole антивирусной компании в списке пиров, для восстановления status quo. Все указанные отличия от реализации P2P предыдущей версии были призваны устранить потенциальную возможность нарушить работу ботнета.

Состав загружаемых модулей разнится для разных версий. Например, версия click fraud с портом P2P 16464 обычно выкачивает три файла:
800000cb.@ — модуль click fraud, регистрирует класс с именем z00clicker3;
00000001.@ — dll, используемая в качестве хранилища ресурсов (данные для 800000cb.@);
80000000.@ — модуль трекинга, предназначен для сбора статистики заражений, информация о зараженной системе отправляется на livecounter.co/count.php.

Версия с bitcoin miner использовала несколько иной набор модулей:
000000cb.@ — модуль click fraud;
80000000.@ — модуль трекинга;
80000032.@, 80000064.@ — модуль bitcoin miner (x32 и x64);
00000004.@, 00000008.@ — dll, используемая в качестве хранилища ресурсов (данные для 80000032.@ и 80000064.@).
Кроме указанных, отмечена загрузка модулей перенаправления поисковых запросов, рассылки спама и загрузки произвольных файлов.

Пример ZeroAccess хорошо иллюстрирует принцип бритвы Оккама — не умножайте сущности без надобности, или по-простому — не усложняйте. Начавшись, как технологичная разработка и потеряв в ходе своей эволюции руткит составляющую, ZeroAccess, тем не менее, успешно продолжает существовать, и даже обзавелся такой модной фичей, как P2P.

По оценкам компании Sophos количество заражений компьютеров ботом ZeroAccess на конец августа 2012 составляло более 9 миллионов, а активных ботов около 1 миллиона. В отчете лаборатории Kindsight Security «Malware Report» за 3 квартал 2012 года говорится уже о 2.2 миллионах зараженных систем, из которых 685 тысяч (31 %) находятся в США. По мнению экспертов, ботнет на основе ZeroAccess был самым активным в 2012 году.

В свете этих цифр, думаю, уже не у кого не осталось сомнений, что ZeroAcces — это не ноль без палочки. Пусть Ring-0 уже и не используется, но «Access» к вычислительным мощностям ничего не подозревающих пользователей продолжает приносить злоумышленниками кучу вечнозеленых американских бумажек. А это значит, антивирусным компаниям есть над чем работать. Читателям же хочется в очередной раз напомнить — спасение вашего железного друга от троянской напасти полностью на вашей совести, будьте бдительны.

Источник