Как вредонос узнает разницу между виртуальным и реальным миром?
Ни для кого не секрет, что отрасль информационной безопасности использует преимущества виртуализации программного обеспечения для того, чтобы исследовать угрозы безопасности. 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
Наличие
Жесткий водитель диск (VMware):
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)
Например: 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 файл и добавить следующее.:
Теперь, что если после всего этого ваша фрагмент вредоносной программы по-прежнему обнаруживает, что в настоящее время работают в виртуальной машине? Я бы прошел код, найти, где виртуальная машина проверки выполняются и патч-кода с НОП (0x90).
Наконец, если это слишком трудно, или невозможно по каким-либо причинам, управлять вашими образца на родной системы! :-) (Вы всегда можете использовать системы резервного копирования и восстановления ПО, чтобы быстро вернуть машину в исходное состояние без переустановки ОС)
Следующий шаг заключается в редактировании ваших 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 вредоносного ПО, чем раньше.
Я укажу, что:
Я укажу, что:
- monitor_control.disable_directexec = "TRUE" , как правило, сорвать таблицы дескрипторов регистрирует чеки. Эта настройка сделает VMware интерпретировать каждый инструкция по сборке вместо выполнения их непосредственно на процессоре. Поэтому результат SIDT команда не будет адрес в 0xffXXXXXX диапазоне, можно было бы получить без этой настройки.
- isolation.tools.getVersion.disable = "TRUE" сорвет бэкдор I / O проверить.
Теперь, что если после всего этого ваша фрагмент вредоносной программы по-прежнему обнаруживает, что в настоящее время работают в виртуальной машине? Я бы прошел код, найти, где виртуальная машина проверки выполняются и патч-кода с НОП (0x90).
Наконец, если это слишком трудно, или невозможно по каким-либо причинам, управлять вашими образца на родной системы! :-) (Вы всегда можете использовать системы резервного копирования и восстановления ПО, чтобы быстро вернуть машину в исходное состояние без переустановки ОС)
Я лично ставлю данный пакет в инсключительных случаях, для сервер считаю оно немного излишне, потомучто, консоль оставить очень сложно, на консоль можно попасть только через пити и только зная пароль, а если знаеш пароль то и смысл в sudo? а если злоумышлиник попал на сервер через дырку в php ему тоже не поможет sudo. Вобщем несколько бесмыслено для удаленого сервера ИХМО.
