Вокруг меня часто звучат разговоры о так называемых обходах виртуальных машин нового поколения, обходах онлайн-сандбоксов и техниках обхода отладчиков, о их широком распространении в современной малваре, и как это влияет на автоматическое обнаружение и анализ малвари в наши дни. И я считаю, что факты намного плачевнее. Большинство из этих заявлений не имеют фактических подтверждений, и я рассматриваю их как что-то чуть большее, чем попытка создать FUD (Fear, Uncertainty and Doubt) (F-страшный, U-неопределенный D-сомнительный) (прим. автора). Реальность в том, что после окончания веселых деньков, когда были актуальны IRC боты, которые создавались в большинстве своем для развлечения, многие из коммерческой малвари, в которых были детекты виртуальных машин и отладчиков, не представляли большого интереса. Почему? на этот вопрос я отвечу чуть позже.
Немного ранее я говорил о ТОП 20-ти самых распространенных малварь, по мнению FireEye's. Не одна из этих разновидностей малвари, исключая Conficker (номер 11) не пытались обнаружить виртуальных сред. Что касается ТОП 10 малвари, по мнению Microsoft некоторое время назад? Я могу доказать, что не одна из этих топ 10-ти малвари не пыталась обнаружить виртуальную среду при запуске.
Как много популяций малвари пытаются обнаружить популярные, доступные в паблик-сандбоксы, вроде ThreatExpert? Давайте посмотрим.
Сейчас я продемонстрирую некоторые из причин почему:
1. Большое количество существующей инфраструктуры, предпочитают переходить на виртуализацию. Виртуализация уже больше не только инструмент аналитика, который в одиночку может найти массу реальных средств для работы в виртуальных средах. Авторам малвари хорошо это известно, и они не могут не использовать этих знаний в своих целях.
2. Другая причина не обнаружения виртуальных сред обуславливается в основном потому что, после первой волны малвари, которая детектировала VM (в основном это были IRC боты, вроде Rbot, SDbot/Reptile, Mechbot, SpyBot, AgoBot и др.), авторы последующих поколений малвари поняли, что передовые двигатели поведенчиского анализа (включая FireEye) могут использовать эти техники сокрытия малвари для её же обнаружения. Другими словами для обнаружения легитимных и не легитимных ПО. Как вы думаете, много ли легитимного ПО пытаются обнаружить среду ThreatExpert, в которой были запущенны. И если какая-то программа делает так, это отличный повод приписать её к вредоносной, делая обнаружение малвари проще.
3. Теперь как много различий имеет малварь с способностью обнаружения отладчиков и виртуальных сред? Остановило ли это аналитиков при реверсе Conficker, SDbot и им подобных? В сущности Conficker является одним из наиболее широко распространенным из за его техник обхода. Аналогичным образом все современные отладчики, как например OllyDbg, знают о техниках анти-отладки и могут обходить их с легкостью.
В любом случае давайте завершим эту дискуссию и поговорим об исключениях, которые подтверждают это правило. Недавно я наткнулся на относительно неизвестный сэмпл, который отличался от остальной малвари по различным аспектам. Он использовал собственный обфусцированный CnС протокол, и был оснащен довольно мощным функционалом по краже различной конфиденциальной информации, и т.д.
В основном этот сэмпл использовал множество анти-отладочных техник, далее техники обнаружения виртуальных машин и сандбоксов, которые быстро бросились мне в глаза. Название этой малвари Rebhip, которую мы тут (в FireEye) классифицировали как стилер информации.
Чтобы сохранить краткость этой статьи, и отношение к этой теме, сегодня я поговорю только о техниках препятствующим анализу этой малвари.
Техники, препятствующие анализу Rebhip могут быть разделены на следующие категории.
1. анти сандбоксы
2. анти VM, анти эмуляция
3. анти отладка
4. анти дизассэмблинг
Давайте по порядку:
1. анти сандбоксы
Rebhip способен обнаруживать все популярные виртуальны машины, с возможностью автоматического анализа малвари, подобно ThreatExpert, Anubis, CWSandbox, JoeBox и др. Фактически он способен обнаружить VMWare, Virtual PC и Virtual Box.
1.1 ThreatExpert
Похоже, что ThreatExpert загружает специальную dll с именем dbghelp.dll для каждого процесса, запущенного в виртуальной среде, скорее всего в целях перехвата API. Rebhip определяет, загружена ли эта dll в его процесс, и если да, то мирно завершается.
Заключение:
Время сменить название этой dll, для исправление этого рода уязвимости.
Памятка: Если кто-то из ваших знакомых удивляется, как плохие парни узнали об этой dll.
Простейший ответ, это что кто-то собирает бинарик с целью выявления уязвимостей подобного рода с выходным результатом содержащем информацию о ThreatExpert.
Более того реверс шелл может дать доступ атакующему к виртуальной машине удаленно.
1.2 JoeBox
Обнаружение сандбокса JoeBox осуществляется по средством сравнивания CD-key от Windows внутри сандбокса с константным значением 55274-640-2673064-23950. Если они соответствуют друг другу, то Rebhip распознает, что была запущенна в JoeBox.
Заключение:
Модификация CD-key внутри JoeBox'а на случайный.
1.3 CWSandbox
Аналогично предыдущему, CWSandobox определяется сравниванием на VM product id с 76487-644-3177037-23510.
Заключение:
Модификация CD-key.
1.4 Anubis
Также сравнивание product id применительно и для Anubis. значение для сравнения: 76487-337-8429955-22614.
Заключение
Модификация CD-key.
2. анти VM/анти эмуляция
Я объяснил выше, что Rebhip способен обнаруживать VMWare, Virtual Box и Virtual PC по отдельности, и один общий вариант для обнаружения виртуальных машин вообще.
2.1 Virtual Box
Обнаружение среды Virtual Box осуществляется благодаря проходу по списку запущенных процессов и сравниванию с 'VBoxService.exe'. Этот сервис - часть "Гостевой системы", предоставляемой Virtual box для упрощения таких задач как Drag&Drop, буферу обмена и др.
Решение:
Установка 'гостевой системы' опциональна и я не могу рекомендовать её не устанавливать, т.к. вы потеряете часть удобной функциональности.
2.2 VMWare
Rebhip использует бэкдор ввода\вывода, как способ обнаружения VMware. Если система запущенна под VMware, порт с названием 'VX' будет доступен для обеспечения коммуникации между хостовой системой и гостевой. Информация с этого порта может быть специальными опкодами, к примеру 0x0A служит для получения информации о версии VMware. Успешное считывание с порта характеризует то, что мы под VMware.
2.3 Virtual PC
Virtual PC использует несколько не валидных x86 инструкций для общения с VM ОС и с эмулятором в частности. Когда запущенно внутри основной системы, загрузка этих инструкций вызовет исключение, в то время как внутри Virtual Pc, они обработаются без проблем. Rebhip устанавливает обработчик исключений и проверяет успешность загрузки этих опкод. При срабатывании обработчика Rebhip понимает, что был запущен на реальной ОС, в противном случае диагноз - внутри Virtual PC.
2.4 "Общий метод".
Этот метод основан на предположении, что виртуальная машина слабее по мощности, чем реальная система. И если время, затраченное на серию определенных действий больше определенного значения, то можно предположить что мы внутри VM.
Rebhip делает это так:
1. Отсчитывает количество миллисекунд со старта, используя GetTickCount win32 API.
2. Запускает серию операций, включая вызов списка определенных функций.
4. Снова проверяет количество миллисекунд GetTickCount API.
5. Если затрачено более 5-ти секунд, то мы под эмулятором.
До сих пор неизвестно для меня, как авторы пришли к выводу, что 5 секунд - нужная цифра. Я полагаю, что в некоторых случаях это может привести к ошибке.
3. анти дебаггинг
Rebhip содержит на боту множество техник антиотладки. Некоторые из них носят общий характер и призваны в целом для большинства отладчиков, в то время как другие действуют целенаправленно, подобно техникам против SOFTICE.
3.1 Общая цель
Rebhip исполюзует несколько главных подходов для обнаружения юзермодных отладчиков, подобным OllyDbg и IDA Pro. Первый метод основан на считывании значения из структуры PEB (Process Environment Blocks) - 'BeingDebugged'. Третий байт этого поля всегда установлен в единицу, когда Rebhip находится под отладчиком.
Это выполняется примерно так:
Загружаем в eax память, расположенную по 0x30-му офсету в структуре Thread Information Block (TIB). Пожалуйста обратите внимание, что FS поддерживается для сохранения начальной позиции TIB. Где 0x30-ый офсет содержит линейный адрес PEBа(Process Environment Block).
Копируем третий байт флага PEB->BeingDebugged в EAX. Если значение eax (или al) единица (1), это означает, что Rebhip был запущен под юзермодным отладчиком и она вызывает ExitProcess для предотвращения дальнейшей отладки.
Второй подход, используемый в Rebhip, это использование знаменитой 'IsDebuggerPresent' Win32 API. Если некоторые читающие когда-нибудь пытались анализировать эту апи, они знают, что логика внутри IsDebugPresent практически та же, что описывалось ранее. Какова причина того, что автор два раза использует одну и ту же технологию? Самый вразумительный ответ - для того чтобы усложнить жизнь реверсеру.
Заключение:
В случае, если ваш дебаггер не способен исправить это самостоятельно, перезапишите этот флаг значением в 0 перед началом загрузки.
3.2 Отладчики режима ядра
Rebhip также имеет на своем борту возможность обнаруживать отладчики режима ядра, такие как SOFICE, SYSER и др. Техника использует тот факт, что упомянутые выше отладчики регистрируют различные устройства (объекты драйверов) в системе, как например \\.\NTICE или \\.\SyserDbgMsg и др. Как только Rebhip обнаружил присутствие одного из этих драйверов в системе, он завершается.
Заключение:
Вариант начать использовать случайные имена объектов драйверов.
4. Анти дизассемблирование
Чтож, это не должно быть для вас сюрпризом. Большинство современной малвари используют некоторые из вариантов бинарной обфускации или техник упаковки, для обхода сигнатурного анализа антивирусов. Случай Rebhip - не исключение. Мне выдался шанс проанализировать более десятка сэмплов, и все их них были упакованы различными неизвестными (по мнению PEiD) упаковщиками.
например MD5: a6a8d4d31431fb52c56d8741e0ffb516
Короче говоря все эти техники уклонений от анализаторов и ВМ могут обходиться и использоваться для обнаружения малвари. В общем лучшие шансы для малвари выжить больший период времени, это "находится под радаром" и не особо привлекать аналитиков. Что мы увидим в будущем, это то что большое количество инновационной малвари начнет улучшаться, и тем больше шансов что она начнет привлекать к себе больше ненужного внимания. Как мы увидели в случае с Storm 1.0 с его причудливым P2P протоколом, Conficker'ом с его анти аналитическими/анти-антивирусным подходом, с Licat'ом, с Kraken и т.д. с их алгоритмом автогенерации доменов.
автор статьи: Atif Mushtaq
перевод: by demien
оригинальная статья на английском : тут
p.s. это мой второй перевод забугорной статьи для дл... почему я это делаю? да потому что мне это интересно, да и практика английского понимаете ли...
вообщем кто дочитал до сюда, спасибо за потраченное время, надеюсь было интересно.
Немного ранее я говорил о ТОП 20-ти самых распространенных малварь, по мнению FireEye's. Не одна из этих разновидностей малвари, исключая Conficker (номер 11) не пытались обнаружить виртуальных сред. Что касается ТОП 10 малвари, по мнению Microsoft некоторое время назад? Я могу доказать, что не одна из этих топ 10-ти малвари не пыталась обнаружить виртуальную среду при запуске.
Как много популяций малвари пытаются обнаружить популярные, доступные в паблик-сандбоксы, вроде ThreatExpert? Давайте посмотрим.
Сейчас я продемонстрирую некоторые из причин почему:
1. Большое количество существующей инфраструктуры, предпочитают переходить на виртуализацию. Виртуализация уже больше не только инструмент аналитика, который в одиночку может найти массу реальных средств для работы в виртуальных средах. Авторам малвари хорошо это известно, и они не могут не использовать этих знаний в своих целях.
2. Другая причина не обнаружения виртуальных сред обуславливается в основном потому что, после первой волны малвари, которая детектировала VM (в основном это были IRC боты, вроде Rbot, SDbot/Reptile, Mechbot, SpyBot, AgoBot и др.), авторы последующих поколений малвари поняли, что передовые двигатели поведенчиского анализа (включая FireEye) могут использовать эти техники сокрытия малвари для её же обнаружения. Другими словами для обнаружения легитимных и не легитимных ПО. Как вы думаете, много ли легитимного ПО пытаются обнаружить среду ThreatExpert, в которой были запущенны. И если какая-то программа делает так, это отличный повод приписать её к вредоносной, делая обнаружение малвари проще.
3. Теперь как много различий имеет малварь с способностью обнаружения отладчиков и виртуальных сред? Остановило ли это аналитиков при реверсе Conficker, SDbot и им подобных? В сущности Conficker является одним из наиболее широко распространенным из за его техник обхода. Аналогичным образом все современные отладчики, как например OllyDbg, знают о техниках анти-отладки и могут обходить их с легкостью.
В любом случае давайте завершим эту дискуссию и поговорим об исключениях, которые подтверждают это правило. Недавно я наткнулся на относительно неизвестный сэмпл, который отличался от остальной малвари по различным аспектам. Он использовал собственный обфусцированный CnС протокол, и был оснащен довольно мощным функционалом по краже различной конфиденциальной информации, и т.д.
В основном этот сэмпл использовал множество анти-отладочных техник, далее техники обнаружения виртуальных машин и сандбоксов, которые быстро бросились мне в глаза. Название этой малвари Rebhip, которую мы тут (в FireEye) классифицировали как стилер информации.
Чтобы сохранить краткость этой статьи, и отношение к этой теме, сегодня я поговорю только о техниках препятствующим анализу этой малвари.
Техники, препятствующие анализу Rebhip могут быть разделены на следующие категории.
1. анти сандбоксы
2. анти VM, анти эмуляция
3. анти отладка
4. анти дизассэмблинг
Давайте по порядку:
1. анти сандбоксы
Rebhip способен обнаруживать все популярные виртуальны машины, с возможностью автоматического анализа малвари, подобно ThreatExpert, Anubis, CWSandbox, JoeBox и др. Фактически он способен обнаружить VMWare, Virtual PC и Virtual Box.
1.1 ThreatExpert
Похоже, что ThreatExpert загружает специальную dll с именем dbghelp.dll для каждого процесса, запущенного в виртуальной среде, скорее всего в целях перехвата API. Rebhip определяет, загружена ли эта dll в его процесс, и если да, то мирно завершается.
Код:
push offset aDbghelp_dll; "dbghelp.dll"
call GetModuleHandleA
test eax, eax
jz short loc_405323
mov bl, 1Заключение:
Время сменить название этой dll, для исправление этого рода уязвимости.
Памятка: Если кто-то из ваших знакомых удивляется, как плохие парни узнали об этой dll.
Простейший ответ, это что кто-то собирает бинарик с целью выявления уязвимостей подобного рода с выходным результатом содержащем информацию о ThreatExpert.
Более того реверс шелл может дать доступ атакующему к виртуальной машине удаленно.
1.2 JoeBox
Обнаружение сандбокса JoeBox осуществляется по средством сравнивания CD-key от Windows внутри сандбокса с константным значением 55274-640-2673064-23950. Если они соответствуют друг другу, то Rebhip распознает, что была запущенна в JoeBox.
Код:
push ebx
add esp, 0FFFFFEF4h
xor ebx, ebx
push esp ; phkResult
push 1 ; samDesired
push 0 ; ulOptions
push offset SubKey ; "Software\\Microsoft\\Windows\\CurrentVersi"...
push 80000002h ; hKey
call RegOpenKeyExA
test eax, eax
jnz short loc_405387
mov [esp+110h+cbData], 101h
lea eax, [esp+110h+cbData]
push eax ; lpcbData
lea eax, [esp+114h+Data]
push eax ; lpData
push 0 ; lpType
push 0 ; lpReserved
push offset ValueName; "ProductId"
mov eax, [esp+124h+hKey]
push eax ; hKey
call RegQueryValueExA
lea eax, [esp+110h+Data]
cmp eax, offset a55274640267306; "55274-640-2673064-23950"
jnz short loc_405387
mov bl, 1Заключение:
Модификация CD-key внутри JoeBox'а на случайный.
1.3 CWSandbox
Аналогично предыдущему, CWSandobox определяется сравниванием на VM product id с 76487-644-3177037-23510.
Заключение:
Модификация CD-key.
1.4 Anubis
Также сравнивание product id применительно и для Anubis. значение для сравнения: 76487-337-8429955-22614.
Заключение
Модификация CD-key.
2. анти VM/анти эмуляция
Я объяснил выше, что Rebhip способен обнаруживать VMWare, Virtual Box и Virtual PC по отдельности, и один общий вариант для обнаружения виртуальных машин вообще.
2.1 Virtual Box
Обнаружение среды Virtual Box осуществляется благодаря проходу по списку запущенных процессов и сравниванию с 'VBoxService.exe'. Этот сервис - часть "Гостевой системы", предоставляемой Virtual box для упрощения таких задач как Drag&Drop, буферу обмена и др.
Решение:
Установка 'гостевой системы' опциональна и я не могу рекомендовать её не устанавливать, т.к. вы потеряете часть удобной функциональности.
2.2 VMWare
Rebhip использует бэкдор ввода\вывода, как способ обнаружения VMware. Если система запущенна под VMware, порт с названием 'VX' будет доступен для обеспечения коммуникации между хостовой системой и гостевой. Информация с этого порта может быть специальными опкодами, к примеру 0x0A служит для получения информации о версии VMware. Успешное считывание с порта характеризует то, что мы под VMware.
Код:
mov eax, 'VMXh'
mov ebx, 3C6CF712h
mov ecx, 10
mov dx, 'VX'
in eax, dx
mov eax, 12.3 Virtual PC
Virtual PC использует несколько не валидных x86 инструкций для общения с VM ОС и с эмулятором в частности. Когда запущенно внутри основной системы, загрузка этих инструкций вызовет исключение, в то время как внутри Virtual Pc, они обработаются без проблем. Rebhip устанавливает обработчик исключений и проверяет успешность загрузки этих опкод. При срабатывании обработчика Rebhip понимает, что был запущен на реальной ОС, в противном случае диагноз - внутри Virtual PC.
2.4 "Общий метод".
Этот метод основан на предположении, что виртуальная машина слабее по мощности, чем реальная система. И если время, затраченное на серию определенных действий больше определенного значения, то можно предположить что мы внутри VM.
Rebhip делает это так:
1. Отсчитывает количество миллисекунд со старта, используя GetTickCount win32 API.
2. Запускает серию операций, включая вызов списка определенных функций.
4. Снова проверяет количество миллисекунд GetTickCount API.
5. Если затрачено более 5-ти секунд, то мы под эмулятором.
До сих пор неизвестно для меня, как авторы пришли к выводу, что 5 секунд - нужная цифра. Я полагаю, что в некоторых случаях это может привести к ошибке.
3. анти дебаггинг
Rebhip содержит на боту множество техник антиотладки. Некоторые из них носят общий характер и призваны в целом для большинства отладчиков, в то время как другие действуют целенаправленно, подобно техникам против SOFTICE.
3.1 Общая цель
Rebhip исполюзует несколько главных подходов для обнаружения юзермодных отладчиков, подобным OllyDbg и IDA Pro. Первый метод основан на считывании значения из структуры PEB (Process Environment Blocks) - 'BeingDebugged'. Третий байт этого поля всегда установлен в единицу, когда Rebhip находится под отладчиком.
Это выполняется примерно так:
Код:
mov eax, large fs:30hЗагружаем в eax память, расположенную по 0x30-му офсету в структуре Thread Information Block (TIB). Пожалуйста обратите внимание, что FS поддерживается для сохранения начальной позиции TIB. Где 0x30-ый офсет содержит линейный адрес PEBа(Process Environment Block).
Код:
movzx eax, byte ptr [eax+2]Копируем третий байт флага PEB->BeingDebugged в EAX. Если значение eax (или al) единица (1), это означает, что Rebhip был запущен под юзермодным отладчиком и она вызывает ExitProcess для предотвращения дальнейшей отладки.
Второй подход, используемый в Rebhip, это использование знаменитой 'IsDebuggerPresent' Win32 API. Если некоторые читающие когда-нибудь пытались анализировать эту апи, они знают, что логика внутри IsDebugPresent практически та же, что описывалось ранее. Какова причина того, что автор два раза использует одну и ту же технологию? Самый вразумительный ответ - для того чтобы усложнить жизнь реверсеру.
Заключение:
В случае, если ваш дебаггер не способен исправить это самостоятельно, перезапишите этот флаг значением в 0 перед началом загрузки.
3.2 Отладчики режима ядра
Rebhip также имеет на своем борту возможность обнаруживать отладчики режима ядра, такие как SOFICE, SYSER и др. Техника использует тот факт, что упомянутые выше отладчики регистрируют различные устройства (объекты драйверов) в системе, как например \\.\NTICE или \\.\SyserDbgMsg и др. Как только Rebhip обнаружил присутствие одного из этих драйверов в системе, он завершается.
Заключение:
Вариант начать использовать случайные имена объектов драйверов.
4. Анти дизассемблирование
Чтож, это не должно быть для вас сюрпризом. Большинство современной малвари используют некоторые из вариантов бинарной обфускации или техник упаковки, для обхода сигнатурного анализа антивирусов. Случай Rebhip - не исключение. Мне выдался шанс проанализировать более десятка сэмплов, и все их них были упакованы различными неизвестными (по мнению PEiD) упаковщиками.
например MD5: a6a8d4d31431fb52c56d8741e0ffb516
Короче говоря все эти техники уклонений от анализаторов и ВМ могут обходиться и использоваться для обнаружения малвари. В общем лучшие шансы для малвари выжить больший период времени, это "находится под радаром" и не особо привлекать аналитиков. Что мы увидим в будущем, это то что большое количество инновационной малвари начнет улучшаться, и тем больше шансов что она начнет привлекать к себе больше ненужного внимания. Как мы увидели в случае с Storm 1.0 с его причудливым P2P протоколом, Conficker'ом с его анти аналитическими/анти-антивирусным подходом, с Licat'ом, с Kraken и т.д. с их алгоритмом автогенерации доменов.
автор статьи: Atif Mushtaq
перевод: by demien
оригинальная статья на английском : тут
p.s. это мой второй перевод забугорной статьи для дл... почему я это делаю? да потому что мне это интересно, да и практика английского понимаете ли...
вообщем кто дочитал до сюда, спасибо за потраченное время, надеюсь было интересно.
