Как вредонос узнает разницу между виртуальным и реальным миром?

Как вредонос узнает разницу между виртуальным и реальным миром?

Ни для кого не секрет, что отрасль информационной безопасности использует преимущества виртуализации программного обеспечения для того, чтобы исследовать угрозы безопасности. VMWare, Sandboxie, Virtual PC, Анубис, CWSandbox, JoeBox, VirtualBox, Parallels, QEMU просто только немногих из этих виртуальных машин. Рог изобилия виртуальных средах дает специалист по безопасности возможность наблюдать и анализировать вредоносного программного обеспечения в удобном и легко воспроизводимым образом. Это создает проблемы для вирусописателей и из-за этого, они часто включают в их коде двоичные файлы, чтобы сделать его более трудным для специалистов по компьютерной безопасности, чтобы проанализировать их исполняемые файлы в этих виртуальных средах. Вот некоторые из наиболее часто анти-методы виртуализации:

Проверьте наличие виртуализированного оборудования:

Виртуальные среды имеют виртуальные сетевые интерфейсы. Как и любой сетевой интерфейс, они присвоен уникальный адрес MAC, который обычно включает в себя идентификационный номер изготовителя. Например, сетевой интерфейс для VMware Workstation будет иметь адрес MAC, который начинается с 00:50:56 или 00:0 C: 29 (VMware имеет более одного организационно уникальный идентификатор или OUI). Вредоносные программы могут проверить на наличие определенных OUIs и выбрать для себя по-другому или не отображать любое злокачественное поведение вообще в виртуальной машине.

Кроме того, можно проверить на наличие GUID, которые отдают на то, что это время работы в виртуальной среде. Например: MD5: 0151c5afde070a7b194f492d26e9b3ef (Trojan.Agent-124243 от ClamAV):

 

.text:004012EA     jz      short loc_40130E
.text:004012EC     push    104h            ; size_t
.text:004012F1     push    offset a76487644317703 ; "76487-644-3177037-23510"
.text:004012F6     lea     ecx, [ebp+var_104]
.text:004012FC     push    ecx             ; char *
.text:004012FD     call    _strncmp
.text:00401302     add     esp, 0Ch
.text:00401305     test    eax, eax
.text:00401307     jnz     short loc_40130E

 Наличие HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProductId 76487-644-3177037-23510 показывает, что машина имеет CWSandbox.

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

Жесткий водитель диск (VMware):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskVMware_Virtual_IDE_Hard_

Drive___________00000001\3030303030303030303030303030303030303130\FriendlyName VMware Virtual IDE Hard Drive

Видео драйвер (VMware):
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\DriverDesc VMware SVGA II

Драйвер мыши (VMware):
%WINDIR%\system32\drivers\vmmouse.sys

Любой из них может быть использована вредоносных писателем, чтобы обнаружить присутствие в виртуальной машине.

 

Таблица дескрипторов Регистры проверки:

Существует только один регистр дескрипторной таблицы прерываний (IDTR), один Глобальная таблица дескрипторов регистр (GDTR) и один местный таблицы дескрипторов регистр (LDTR) на процессор. Поскольку существует два операционных систем, работающих в то же время (хозяин и гость), виртуальная машина должна переехать IDTR, GDTR и LDTR для гостевой ОС в другое место, чтобы избежать конфликтов. Это приведет к тому несоответствия между значениями этих регистров в виртуальную машину и на родной машине. Инструкции SIDT, SGDT и SLDT являются инструкции по сборке, которые могут соответственно быть использованы для извлечь значения IDTR, GDTR и LDTR.

Например: MD5: b27d73bfcbaec49a95f23b45e9cf9310 (W32.Virut-54 по ClamAV)

UPX2:3142A03A loc_3142A03A:              ; CODE XREF: sub_3142A02E+2 j
UPX2:3142A03A                 push    eax
UPX2:3142A03B                 sidt    fword ptr [esp+var_6+4]
UPX2:3142A040                 pop     eax
UPX2:3142A041                 mov     eax, [eax+6]
UPX2:3142A044                 shl     eax, 10h
UPX2:3142A047                 jns     short sub_3142A021

IDT по адресу:

0x80ffffff in Windows
0xe8XXXXXX in Virtual PC
0xffXXXXXX in VMware

Backdoor портов ввода / вывода:

 VMware использует порт ввода / вывода 0x5658 ("VX" в ASCII) для взаимодействия с виртуальной машиной. Вредоносная программа может обнаружить присутствие этого порта, выполнив следующие действия:

mov EAX, 564D5868h ; VMXh
xor EBX, EBX  ; set EBX to anything but 0x564D5868 (in this case 0)
mov CX, 0Ah   ; Backdoor command. 10: Get VMware version
mov DX, 5658h  ; VX
in EAX, DX  ; Read from port VX into EAX
cmp EBX, 564D5868h ; EBX should have the magic number VX is VMware is present. If not, EBX=0

 

В основном, это магическое число 0×564D5868 ("VMXh") копируется в EAX и EBX в любое положение, но 0x564D5868 . Бэкдор команда загружается в СХ и, наконец, порт ввода / вывода число 0x5658 ("VX") загружается в DX. Тогда "в" Инструкции используется для чтения из порта 0x5658 в EAX. Вне VMware (на родном хост), привилегия ошибка. Под VMware, магическое число 0x564D5868 возвращается EBX (да, в этом случае EBX влияет в EAX, DX), следовательно, инструкция CMP. 

Выход, если отлаживается:

Хотя это не является, по сути, анти-виртуализации техники, он остается популярным аа проверки произведенных вредоносной программой, чтобы увидеть, если пользователь-Land отладчик присутствует в операционной системе. Это потому, что чаще всего отладчика будет установлен в виртуальном изображение, используемое для анализа вредоносного.

Например: MD5: 74ab05d1ebdba509fd68711b360c1235 (Trojan.IRCBot-3475 по ClamAV) 

.text:004050F8     push    offset aZwquerysystemi ; "ZwQuerySystemInformation"
.text:004050FD     push    [ebp+hModule]   ; hModule
.text:00405100     call    ds:GetProcAddress
.text:00405106     mov     [ebp+var_4], eax
.text:00405109     push    offset aZwqueryinforma ; "ZwQueryInformationProcess"
.text:0040510E     push    [ebp+hModule]   ; hModule
.text:00405111     call    ds:GetProcAddress
.text:00405117     mov     [ebp+var_14], eax
.text:0040511A     cmp     [ebp+var_4], 0
.text:0040511E     jz      short loc_405147

.text:00405120     push    0
.text:00405122     push    2   ; SystemInformationLength
.text:00405124     lea     eax, [ebp+var_8]
.text:00405127     push    eax ; SystemKernelDebuggerInformation
.text:00405128     push    23h
.text:0040512A     call    [ebp+var_4] ; ZwQueryInformationProcess
.text:0040512D     test    eax, eax
.text:0040512F     jnz     short loc_405147 ; process is being debugged

Для функции ZwQuerySystemInformation Windows API, установив значение SystemInfoClass до 2 (SystemKernelDebuggerInformation) извлекает информационной системы на присутствие в пространстве пользователя отладчика.

NTSTATUS WINAPI ZwQuerySystemInformation(
__in       SYSTEM_INFORMATION_CLASS SystemInformationClass,
__inout    PVOID SystemInformation,
__in       ULONG SystemInformationLength,
__out_opt  PULONG ReturnLength
);

Для Windows API функции ZwQueryInformationProcess, установив значение ProcessInformationClass до 7 (ProcessDebugPort) возвращает номер порта для отладки процесса. Значение, отличное от 0 указывает, что процесс был запущен через пользователем земли отладчика.

NTSTATUS WINAPI ZwQueryInformationProcess(
__in       HANDLE ProcessHandle,
__in       PROCESSINFOCLASS ProcessInformationClass,
__out      PVOID ProcessInformation,
__in       ULONG ProcessInformationLength,
__out_opt  PULONG ReturnLength
);

Для начала, не устанавливайте инструментов, предоставляемых виртуальной машины в гостевой ОС. Например, VMware предоставляет набор инструментов под названием VMware Tools, который усиливает общее впечатление пользователя с гостевой ОС. Недостатком является то, что при установке VMware Tools в гостевой ОС Windows оставят много подсказок легко обнаружить с помощью кусочка вредоносных программ, которые он в настоящее время работают в виртуальной машине.

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

isolation.tools.getVersion.disable = "TRUE"
isolation.tools.getPtrLocation.disable = "TRUE"
isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
monitor_control.disable_directexec = "TRUE"
monitor_control.disable_chksimd = "TRUE"
monitor_control.disable_ntreloc = "TRUE"
monitor_control.disable_selfmod = "TRUE"
monitor_control.disable_reloc = "TRUE"
monitor_control.disable_btinout = "TRUE"
monitor_control.disable_btmemspace = "TRUE"
monitor_control.disable_btpriv = "TRUE"
monitor_control.disable_btseg = "TRUE"

Теперь запустите вашу виртуальную машину. Это позволит запускать (с очень небольшим усилием) более VMware-Aware вредоносного ПО, чем раньше.

Я укажу, что:

1. monitor_control.disable_directexec = "TRUE" , как правило, сорвать таблицы дескрипторов регистрирует чеки. Эта настройка сделает VMware интерпретировать каждый инструкция по сборке вместо выполнения их непосредственно на процессоре. Поэтому результат SIDT команда не будет адрес в 0xffXXXXXX диапазоне, можно было бы получить без этой настройки. 
2. isolation.tools.getVersion.disable = "TRUE" сорвет бэкдор I / O проверить.

Теперь, что если после всего этого ваша фрагмент вредоносной программы по-прежнему обнаруживает, что в настоящее время работают в виртуальной машине? Я бы прошел код, найти, где виртуальная машина проверки выполняются и патч-кода с НОП (0x90).

Наконец, если это слишком трудно, или невозможно по каким-либо причинам, управлять вашими образца на родной системы! :-) (Вы всегда можете использовать системы резервного копирования и восстановления ПО, чтобы быстро вернуть машину в исходное состояние без переустановки ОС)

отсюда