Shamoon: детали

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

Содержимое самплов

Основная программа (дроппер) содержит 3 ресурса, каждый из которых представляет собой зашифрованную программу. Как мы уже писали, шифрование довольно простое — xor двойным словом (dword).

Ресурс PKCS12:112 содержит исполняемый файл, зашифрованный значением 0xFB5D7F25. Во время исполнения дроппера этот исполняемый файл записывается на диск в каталог %WINDIR%System32 под именем, которое берется из запрограммированного списка. В свою очередь, этот модуль содержит ресурс READONE:101 (ключ xor: 0xF052AF15) — это закодированный драйвер, который сохраняется как:

%WINDIR%System32DriversDRDISK.SYS.

Ресурс PKCS7:113 содержит исполняемый файл, зашифрованный значением 0x00BAD417 и сохраняемый во время исполнения дроппера на диск как:

%WINDIR%System32NETINIT.EXE.

Ресурс X509:116 содержит 64-битную версию основной программы Shamoon (дроппера), зашифрованную xor с ключом 0xBB1AC25C. Он включает в себя практически тот же набор ресурсов, что и 32-битная версия: PKCS12:112 — это 64-битная версия первого исполняемого файла, записываемого на диск, с 64-битной версией драйвера и PKCS7:113 — 64-битная версия программы NETINIT.EXE. Таким образом, ресурсы 112 и 113 закодированы идентичными ключами xor в x86 и AMD64 версиях, но ключи для драйверов отличаются: 64-битная версия зашифрована значением 0x10CAFFA0, тогда как x86 версия — значением 0xF052AF15. Ниже приведена схема, иллюстрирующая сказанное выше:

Содержимое самплов Shamoon

Основная программа Shamoon работает в 3-х режимах:

1. если она запущена как обычная программа в 32-битной ОС (зависит от аргументов);
2. если она запущена в 64-битной ОС;
3. если она запущена как служба в 32-битной ОС

64-битное окружение

В первую очередь программа проверяет, не запущена ли она в 64-битной операционной системе. Если это так, то она извлекает из ресурса X509:116 AMD64 версию основного исполняемого файла и сохраняет его по следующему пути %WINDIR%System32trksrv.exe. После этого создается и запускается служба ‘TrkSvr’ с помощью следующей командной строки:

%WINDIR%System32cmd.exe /c «ping -n 30 127.0.0.1 >nul && sc config TrkSvr binpath= system32trksrv.exe && ping -n 10 127.0.0.1 >nul && sc start TrkSvr «

Эта ветка исполнения приходит к концу, и программа завершает работу.

Давайте посмотрим, что же программа делает, если она запущена обычным образом в 32-битной операционной системе.

32-битное окружение: обычный запуск с аргументами

Оказалось, что программа ожидает на вход аргументы, которые обрабатываются как список IP-адресов. Это IP-адреса компьютеров, которые вредоносная программа попытается заразить. Если первый аргумент представляет собой один символ, то программа пытается заразить компьютеры локальной сети, перебирая последнее значение IP-адреса зараженного компьютера от 1 до 254. Для каждого IP-адреса программа пытается открыть файл по следующим путям:

<IP-address>ADMIN$System32csrss.exe
<IP-address>C$WindowsSystem32csrss.exe
<IP-address>D$WindowsSystem32csrss.exe
<IP-address>E$WindowsSystem32csrss.exe

Другими словами, программа пытается найти компьютеры в локальной (под-) сети (или компьютеры, IP-адреса которых указаны в аргументах), к системному каталогу которых она имеет доступ. Если вредоносная программа удачно открыла такой файл csrss.exe, она попробует создать свою копию на удаленном компьютере в каталоге %WINDIR%System32. Имя для копии будет случайно выбрано из запрограммированного списка:

caclsrv.exe
certutl.exe
clean.exe
ctrl.exe
dfrag.exe
dnslookup.exe
dvdquery.exe
event.exe
findfile.exe
gpget.exe
ipsecure.exe
iissrv.exe
msinit.exe
ntfrsutil.exe
ntdsutl.exe
power.exe
rdsadmin.exe
regsys.exe
sigver.exe
routeman.exe
rrasrv.exe
sacses.exe
sfmsc.exe
smbinit.exe
wcscript.exe
ntnw.exe
netx.exe
fsutl.exe
extract.exe

Запуск проводится путем создания задания (Schedule, Task) на удаленном компьютере. В случае если создать задание не удалось, дроппер попытается запустить свою копию другим способом. Созданная на стадии инициализации задания копия вредоносной программы на заражаемом компьютере копируется под именем ‘trksvr.exe’. Далее проводится попытка создать и запустить на удаленном компьютере службу ‘TrkSvr’ (имя сервиса: ‘Distributed Link Tracking Server’), связанную с этим исполняемым файлом.

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

32-битное окружение: обычный запуск без аргументов

Если программа запущена без аргументов, она устанавливает службу ‘TrkSvr’ (имя сервиса: ‘Distributed Link Tracking Server’) локально (копирует себя под именем %WINDIR%System32trksvr.exe, создает соответствующую службу) и запускает ее.

На этом этапе автор вредоносной программы использовал интересный метод обеспечения запуска программы после перезагрузки системы: программа изменяет настройки службы ‘LanmanWorkstation’ (имя сервиса: ‘Рабочая станция’). Она становится зависимой от службы ‘TrkSvr’. Это означает, что вместе со службой ‘Рабочая станция’ будет запускаться и ‘TrkSvr’. А ‘Рабочая станция’, как правило, стартует автоматически при загрузке операционной системы.

Но существует более простой способ заставить систему запустить службу при загрузке — просто установить соответствующую настройку службы. Более того, сервис ‘TrkSvr’ создается вредоносной программой уже с установленной опцией автоматического запуска. Для чего вирусописатель использовал еще и зависимость служб — непонятно.

32-битное окружение: запуск как служба

Наконец, мы подошли к описанию последнего режима — дроппер запускается как служба. Сначала дроппер сохраняет ресурс PKCS7:113 как %WINDIR%System32netinit.exe и запускает эту программу с аргументом ‘1’ одним из двух способов:

1. создает задание на запуск ‘netinit.exe 1’
2. запускает ‘netinit.exe 1’ напрямую через функцию CreateProcess

В службе ‘TrkSvr’ реализована постоянная проверка того, запущена ли программа netinit.exe, и в случае если в списке работающих процессов она отсутствует, netinit.exe запускается заново.

Вредоносная служба в цикле удаляет указанные в запрограммированном списке (см. выше) файлы в каталоге %WINDIR%System32. В этом же цикле программа проверяет условие для перехода к последней стадии исполнения.

Дроппер проверяет, не наступила ли определенная дата. Дата читается либо из файла ‘%WINDIR%infnetft429.pnf’, либо (если не получилось с файлом) используется вшитое в тело программы значение.

Этот запрограммированный момент времени — 15-е августа 2012-го года 08:08 по всемирному координированному времени (UTC).

Тут выяснилось, что функция проверки времени работает, судя по всему, неправильно. Если задумка была разделить время на ‘до’ и ‘после’ конкретного момента, то автор программы допустил ошибку — при сравнении дат в условии использована неверная логика.

Сравнение дат

Например, если год текущей даты 2013-й, но значение месяца меньше целевого месяца (скажем, февраля), тогда функция вернет результат, как если бы дата в феврале 2013-го предшествовала целевому моменту времени в августе 2012-го, что не соответствует действительности.

Эта ошибка в условии еще раз подтверждает наш изначальный вывод, что вредоносная программа Shamoon не является той вредоносной программой Wiper, которой были атакованы иранские системы. Предполагается, что Wiper — это кибероружие, то есть программа должна быть написана командой профессионалов. А опытные программисты вряд ли напортачили бы в условии сравнения двух дат.

Но как бы то ни было, условие срабатывает (пусть и не во всех задуманных случаях), и дроппер все-таки переходит к финальной стадии своей работы. Единственное значимое действие на этой стадии — сохранение ресурса PKCS12:112 как исполняемого файла в каталоге %WINDIR%System32 под именем, взятым из запрограммированного списка, и запуск сохраненной программы (этот компонент отвечает за деструктивную активность Shamoon).

Помимо этого мы увидели, что на этом этапе программа работает со странным текстом:

‘kijjjjnsnjbnncbknbkjadc
kjsdjbhjsdbhfcbsjkhdf jhg jkhg hjk hjk
slkdfjkhsbdfjbsdf
klsjdfjhsdkufskjdfh’.

Также проверяется, присутствует ли файл ‘c:windowstempout17626867.txt’ в зараженной системе, и пытается загрузить изображение (LoadImage) ‘myimage12767’ из ресурсов программы. Файл ‘out17626867.txt’ не создается самим дроппером, и мы не нашли, чтобы это имя файла использовалось где-нибудь в других компонентах Shamoon. К тому же дроппер не содержит в ресурсах изображение ‘myimage12767’.

Таким образом, мы не знаем, с чем связан этот странный текст, почему программа проверяет .txt файл, и в чем был смысл отсутствующего изображения. Мы не обнаружили какого-либо значимого функционала в этой части кода, которая работает с подозрительным текстом, файлом ‘out17626867.txt’ и изображением ‘myimage12767’.

На этом все об основном исполняемом файле Shamoon. В ближайшее время мы расскажем, как работают остальные компоненты этой вредоносной программы.