Что это там был за Wiper?

В апреле 2012 года было опубликовано несколько сообщений о таинственной атаке с использованием вредоносного ПО, которая привела к отказу компьютерных систем в компаниях по всему Ирану.

В нескольких статьях говорилось, что ответственность за атаки лежит на вирусе под названием Wiper (в переводе — чистильщик). Однако не было найдено ни одного образца вредоносной программы, использованной в этих атаках, что заставило многих усомниться в точности сведений, содержащихся в этих сообщениях.

После этих инцидентов Международный союз электросвязи (МСЭ) обратился к ‘Лаборатории Касперского’ с просьбой провести расследование данных инцидентов и определить потенциальные деструктивные последствия активности этого нового вредоносного ПО.

Спустя несколько недель после начала расследования нам так и не удалось найти файлы вредоносного ПО, свойства которого совпадали бы с известными характеристиками Wiper. Однако мы обнаружили проводимую на государственном уровне кампанию по кибершпионажу, известную сегодня как Flame, а позднее — еще одну систему кибершпионажа, получившую название Gauss.

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

Итак, несколько месяцев спустя мы по-прежнему задаемся вопросом: Wiper — что же это было такое?

.redfont{color:#980000;font-weight:bold}

Wiper выходит на сцену

В процессе расследования таинственной апрельской вредоносной атаки нам удалось получить и проанализировать образы нескольких жестких дисков, атакованных Wiper. Мы можем с уверенностью утверждать, что инциденты действительно имели место, и что вредоносная программа, использованная в этих атаках, существовала в апреле 2012 года. Кроме того, нам известно о нескольких очень похожих инцидентах, имевших место с декабря 2011 года.

В основном атаки происходили в последнюю декаду месяца (в период с 21 по 30 число), однако мы не можем утверждать, что причина этого кроется в специальной функции, активируемой при наступлении определенной даты.

Создатели Wiper сделали все возможное, чтобы уничтожить абсолютно все данные, которые можно было бы использовать для анализа инцидентов. Поэтому в каждом из случаев, которые мы проанализировали, после активации Wiper от вредоносной программы не оставалось почти никаких следов. Здесь важно подчеркнуть, что именно ‘почти никаких’, потому что кое-какие следы все же остались, и они позволили нам лучше понять, как осуществлялись эти атаки.

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

Интересно, что 22 апреля, непосредственно перед тем, как система отказала, был создан, а затем удален один конкретный ключ реестра. Этот ключ ссылался на службу под названием RAHDAUD64. Он указывал на файл ~DF78.tmp в папке C:WINDOWSTEMP на диске.

Увидев это, мы сразу же вспомнили Duqu, который использовал имена файлов в таком же формате. Кстати, название Duqu было придумано венгерским экспертом Boldizsar Bencsath из лаборатории CrySyS, потому что червь создавал файлы, имена которых имели формат ~dqXX.tmp (см. здесь).

Мы попытались восстановить файл ~DF78.tmp, но обнаружили, что физическое пространство на диске, где он ранее находился, заполнено мусором.

Мы обнаружили, что аналогичная схема была использована для ‘затирания’ данных еще в нескольких из проанализированных нами систем: служба под названием RAHDAUD64, удаленная непосредственно перед уничтожением содержимого диска, причем область, занимаемая ее файлом, была заполнена мусором. В этих системах ключ RAHDAUD64 указывал на файлы с различными именами, такими как ~DF11.tmp и ~DF3C.tmp. Не исключено, что имена файлов генерировались случайным образом.

Еще одна особенность процесса затирания содержимого диска — это паттерн, использованный для перезаписи файлов на диске мусором:

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

Основываясь на известном паттерне, которым были перезаписаны файлы, мы собрали в Kaspersky Security Network (KSN) статистику о том, какие файлы подверглись уничтожению.

Попытки реконструкции алгоритма действия Wiper привели нас к следующей схеме:

1. Поиск и перезапись файлов по их расширению.
   Список расширений файлов:

   accdb	cdx	dmp	H	js	pnf	rom	tif	wmdb
   acl	cfg	doc	hlp	json	png	rpt	tiff	wmv
   acm	chk	docx	hpi	lnk	pps	rsp	tlb	xdr
   amr	com	dot	htm	log	ppt	sam	tmp	xls
   apln	cpl	drv	html	lst	pptx	scp	tsp	xlsx
   asp	cpx	dwg	hxx	m4a	pro	scr	txt	xml
   avi	dat	eml	ico	mid	psd	sdb	vbs	xsd
   ax	db	exe	inc	nls	rar	sig	wab	zip
   bak	dbf	ext	Ini	one	rar	sql	wab~
   bin	dbx	fdb	jar	pdf	rdf	sqlite	wav
   bmp	dll	gif	jpg	pip	resources	theme	wma

2. Поиск и перезапись всех файлов в определенных каталогах (например, в Documents and Settings, Windows, Program Files) и на всех доступных подключенных USB-дисках.
3. Перезапись секторов диска (возможно, с использованием bootkit-модуля).

   На перезапись содержимого диска размером в несколько сотен гигабайт могут уйти часы. Поэтому создатели вредоносной программы постарались выбрать максимально эффективные алгоритмы перезаписи. Рассмотрим для примера следующий диск, содержимое которого было перезаписано Wiper. Мы использовали статистическое представление (энтропия Шеннона с блоками размером 256 Кб) для отображения энтропии на диске. Более светлые участки имеют более высокую энтропию, более темные — более низкую. Красные области имеют очень высокую энтропию (т.е. в них записаны данные с высокой степенью случайности).

   

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

   Другое представление можно получить, отобразив секторы, заполненные известным паттерном %PNG / iHDR. Красным цветом отмечены блоки секторов, перезаписанных данным паттерном:

   

   Как видите, более трех четвертей всего диска затронуто Wiper, причем почти все данные безвозвратно утрачены.

   В некоторых случаях Wiper давал осечку — например, мы столкнулись с одной 64-битной системой, в которой Wiper не сработал. В этом случае мы обнаружили два файла в папке %TEMP%, которые были перезаписаны знакомым паттерном PNG/iHDR, но диск при этом остался цел:

   

   Мы предполагаем, что именно эти два файла из тысяч, находившихся в папке %TEMP%, были уничтожены потому, что они содержали данные, которые были важны для атаки Wiper. В другой проанализированной нами системе кроме этих файлов размером примерно по 20 Кб мы обнаружили два файла размером 512 байтов с именами ~DF820A.tmp и ~DF9FAF.tmp. Эти файлы также были перезаписаны без возможности восстановления.

   Интересно, что в некоторых системах мы обнаружили, что все файлы с расширением PNF в подпапке INF папки Windows были перезаписаны с более высоким приоритетом, чем другие файлы. Это еще один признак родства Wiper с Duqu и Stuxnet, которые хранили свое основное тело в зашифрованных файлах .PNF.

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

   Связи с Flame

   В поисках этой неуловимой вредоносной программы мы обнаружили кое-что другое. Мы подозревали, что Wiper использует такие имена файлов, как ~DF*.tmp или ~DE*.tmp в папке TEMP, поэтому стали искать подобные имена с помощью KSN. В процессе поиска мы заметили, что файл под названием ~DEB93D.tmp встречается на необычно большом числе машин в регионе Ближнего Востока:

   

   Имя файла выглядело как неплохой показатель принадлежности к платформе Tilded и связи с Duqu и Stuxnet. Файл выглядел зашифрованным, но мы быстро кое-что обнаружили:

   Duqu (Nov 3, 2010):
   00: ED 6F C8 DA 30 EE D5 01

   ~DEB93D:
   00: 6F C8 FA AA 40 C5 03 B8

   Совершенно случайно мы обратили внимание на то, что этот файл начинался с байтов 6F C8. Они также присутствовали в начале PNF-файла, содержащего зашифрованное основное тело Duqu, которое загружалось драйвером, скомпилированным 3 ноября 2010 г. Если бы не это, возможно, мы бы и не обратили внимания на файл ~DEB93D.tmp, поскольку его содержимое было, на первый взгляд, мусорным.

   Алгоритм шифрования оказался слабым, и мы обнаружили, что один и тот же паттерн повторяется каждые 4096 байтов. Благодаря слабости алгоритма шифрования нам удалось расшифровать файл с помощью методов статистического криптоанализа, которые часто применяются для расшифровки файлов в процессе анализа вредоносных программ. Расшифровав файл, мы обнаружили нечто, напоминающее логи сниффера. Это заставило нас искать дальше, и мы обнаружили другие файлы, измененные в тот же день, с такими именами, как mssecmgr.ocx, EF_trace.log и to961.tmp. Остальное, как говорится, уже история: Именно так мы обнаружили Flame.

   Так что же представлял собой Wiper?

   Нет никакого сомнения в том, что существовала вредоносная программа, известная как Wiper, которая атаковала компьютерные системы в Иране (и, возможно, в других частях света) до конца апреля 2012 года.

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

   Выводы:

   • Не исключено, что мы никогда не узнаем, что представлял собой Wiper, однако, исходя из всего нашего опыта, мы в разумной степени уверены, что эта программа существовала, и что она не связана с Flame.
   • Возможно, что где-то существуют компьютеры, на которых вредоносная программа каким-то образом избежала перезаписи, но если это и так, то нам эти машины найти не удалось.
   • Возможно, существует связь между Wiper с одной стороны и Duqu и Stuxnet с другой, учитывая одинаковые схемы именования файлов, однако этого нельзя утверждать наверняка.
   • Что известно точно — так это то, что программа Wiper работала исключительно эффективно и даже послужила концептом для возможных имитаций, таких как Shamoon.
   • Тот факт, что применение Wiper привело к обнаружению проводившейся на протяжении 4-5 лет кампании по кибершпионажу под названием Flame, вызывает один серьезный вопрос. Если те же, кто создал Duqu/Stuxnet/Flame, являются также создателями Wiper, то стоило ли срывать завесу тайны с такой сложной кампании по кибершпионажу, как Flame, только ради того, чтобы уничтожить несколько компьютерных систем?