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

Насколько вообще оправдано [...]]]> Ни для кого не секрет, что в некоторых легальных продуктах используются руткит-технологии.

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

Насколько вообще оправдано использование руткит-технологий в легальном программном обеспечении? Насколько при использовании таких технологий в легальных продуктах велик риск компрометации операционной системы и пользовательских данных? Насколько тонка грань между легальными и киберкриминальными методами?

Дальше

Если эти строки вы читаете, борясь с желанием закрыть окно браузера оттого, что далеко не уверены, будет ли сказано далее что-то для вас новое [...]]]> Ниже пойдет речь исключительно об OllyDbg и плагинах к ней, но описанный подход и сами идеи при определенных навыках вы сможете использовать применительно и к другим утилитам такого класса.

Если эти строки вы читаете, борясь с желанием закрыть окно браузера оттого, что далеко не уверены, будет ли сказано далее что-то для вас новое и оригинальное, то ответьте для себя на следующие вопросы:

Как работает функция IsDebuggerPresent? Если ее не вызывать из kernel32, а реализовать ее функционал в своем коде, то получится ли обмануть анти-антиотладку? Как плагин скрывает процесс отладчика (чтобы его подопытная программа не завершила по имени или не прекратила свою работу)?

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

Сам процесс антиотладки и противодействия оной, достаточно автоматизирован — существует приличное количество навесных защит на файлы и специальных анти-антиотладочных плагинов к дебаггерам.

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

На тему противодействия отладке написано немало статей, как хороших, так и «ни о чем». У меня нет ни малейшего желания изобретать колесо и разжевывать то, что было с успехом сделано и до меня, поэтому если что-то в статье вам покажется непонятным, то запрос «антиотладка» в яндекс/гугл, думаю, все расставит по своим местам.

Все антиотладочные приемы условно можно разделить на две группы:

• Усложнение возможной отладки. Сюда можно отнести обфускацию кода, паковку/криптовку, использование исключений, разделение кода на потоки/библиотеки, мусорные функции и т.д.
• Обнаружение отладки. Название говорит само за себя — так или иначе происходит обнаружение самого факта исследования: через созданные для этого функции или через нахождения окна/процесса отладчика, нахождение брекпоинтов (CC, проверка атрибутов доступа и др.), замеры времени и т.д.

Как, наверное, уже понял читатель, наш метод относится ко второй группе. Использовать полученное знание можно по-разному. Про это писалось много, но вкратце сказать об этом все же необходимо: обнаружив отладчик, конечно, можно сразу радостно выкинуть алерт типа «debugger detected» и завершить работу, а можно затаиться и потихонечку портить жизнь взломщику — сбить значения пары переменных, изменить логику работы программы, использовать флаги обнаружения отладчика как слагаемые при вычислении относительного адреса и т.д. Совершенно очевидно, что второй способ способен очень сильно затруднить жизнь исследователю, но все эти возможности оставляю вашей фантазии с базированием на других статья на эту тему, я же только постараюсь показать новые методы обнаружения отладки, а как вы это будете применять далее уже не мое дело.

Ниже будут рассмотрены способы защиты от некоторых антиотладочных приемов следующими популярными плагинами для OllyDbg:

• Olly Advanced 1.26 Beta 12
• Hide Debugger v1.2.4 (by Asterix)
• HideOD v0.12 (pеdiy.соm)

ZwQueryInformationProcess (InfoClass = 7)

Olly Advanced модифицирует данную функцию так, что после ее отработки она сама же зануляет четырехбайтовый буфер и вместо законных FFFFFFFF там будет абсолютный ноль.

HideOD работает более жестко. Функцию он модифицирует так, что она, по сути, и не работает (вызова в ядро не происходит). При этом значение регистра есх остается преждним, хотя нормальная функция его бы изменила, значение edx также остается постоянным или меняется на 00320000 (в зависимости от выбора метода в настройках).

А в Hide Debugger такой функционал не заложен.

GetTickCount

Защиту от этого метода предлагает только Olly Advanced, причем двумя методами. При выборе первого варианта защиты, происходит просто обнуление возвращаемого значения (при любых обстоятельствах данная функция вернет 0), а второй возвращает небольшое значени и при повторных вызовах функции прибавляет к счетчику единицу. Реализованы они по принципу «перехвати себя сам» — код функции изменяется так, что как надо она не работает. В любом случае значения счетчиков выходят до безобразия маленькие, чем можно воспользоваться. Вот самый простой пример:

call GetTickCount
push eax
invoke Sleep, 1000d ; 3e8h
call GetTickCount
pop ecx
sub eax, ecx

В итоге если в eax ноль или единица, а не законный минимум 3E8, то значит, поработал плагин…
Данная функция состоит из четырех строк и не делает каких-либо глубинных вызовов по относительным адресам, поэтому никаких сложностей собственной ее реализации быть не должно:

MOV EDX,7FFE0000
MOV EAX,[DWORD DS:EDX]
MUL [DWORD DS:EDX+4]
SHRD EAX,EDX,18
PUSH EAX
PUSH 3E8                    ; Timeout = 1000. ms
CALL   ; Sleep
MOV EDX,7FFE0000
MOV EAX,[DWORD DS:EDX]
MUL [DWORD DS:EDX+4]
SHRD EAX,EDX,18
POP ECX
SUB EAX,ECX

Чтобы не бросаться в глаза можно обойтись и без Sleep’a, просто проверить один раз использовать код GetTickCount и проверить еах на близость к нулю, и если на данном участке программы такое небольшое значение невозможно, то значит плагин детектед…

Process32Next

Теперь рассмотрим что за жуткую зиродей руткит-технологию используют плагины для сокрытия процесса ollydbg от подопытной программы.
Olly Advanced в этом плане решил не заморачиваться и просто обнуляет еах в функции Process32NextW, на чем, собственно, все листание процессов и заканчивается: Process32First отрабатывает как положено, а процессов next оказывается в системе не существует, ну, на нет и суда нет, видимо юзер так оптимизировал систему убрав ненужные процессы ;)

Кстати, помимо того, что в реальной системе процессов чуть побольше чем один, так и при завершении листания всех процессов, Process32Next помимо выдачи нуля в eax еще и LastError, установленный в ERROR_NO_MORE_FILES, обеспечит…

HideOD работает точно также и обсуждать его посему незачем.

В Hide Debugger такой функционал не замечен, конечно, может там названо это иначе, например защитой от убийства процесса (галочка напротив TerminateProcess), но какого-либо результата от установки этой защиты добиться не удалось, подопытной утилите ничто не помешало пролистать процессы, найти процесс олли и благополучно его прибить, после этого у меня пропало всякое желание исследовать, почему так происходит в этом плагине. К слову сказать, защита от TerminateProcess в Olly Advanced работает как топор — просто и надежно: в самое начало функции поставлен ret.

Теперь, после знакомства с некоторыми принципами работы анти-антиотладочных плагинов можно перейти к выводам. Некоторые из них уже были вкратце озвучены выше, а до каких-то нужно еще дойти посредством мыслительной деятельности — размышляя какие слабости у таких методов реализации защиты отладчика от агрессивно настроенных программ:

• Поиск аномалий
  • Различия в изменениях регистров. Исследовав работу чистой функции и с плагином можно выявить различия.
  • Используя функцию GetLastError (или самостоятельно находя значение в блоке окружения) после антиотладочных функций (выше есть пример) проверить правильность ее работы. Если функция в случае неудачи возвращает 0 и msdn советует вызывать GetLastError, которая клянется, что все ОК, то это повод задуматься…
  • Можно обнаружить сплайсинг путем поиска опкода jmp в первых байтах функции. Вызвав GetProcAddress, можно не только использовать его для вызова, но и незаметно сохранить первые его байты, а потом в спокойной остановке исследовать.
  • Правдоподобность. Один процесс в системе это похоже на истину? Нет. Вот и ответ.
• Рыба ищет, где глубже…
  • Использовать NativeAPI. Конечно, в некоторых случаях перехвачены и они, но ведь это общая рекомендация и из примеров выше видно на каком уровне что изменяется.
  • sysenter. В этом случае за собой придется таскать массив номеров системных вызовов, т.к от системы к системе они меняются.
  • Серединный вызов api-функций. На самом деле это не так сложно как кажется и таскать за собой километры кода функций не требуется, достаточно вызывать с $+5, т.к зачастую именно в первых пяти байтах содержится jmp, тем более не стоит забывать о распространенном пятибайтовом прологе.
• Ищем плагин. Если сам отладчик может быть замаскирован как бревно в собственном глазу (т. е найти почти нереально), то плагин может и не скрываться совсем. Например, CommandBar светится классом окна ComboLBox.

Казалось бы, что о user-mode руткитах уже все давно сказано, и добавить тут нечего. С распространением зловредных драйверов все внимание антивирусных специалистов и хакеров переключилось туда, поэтому ring-3, по крайней мере, на три года остался практически без внимания… [...]]]> Публикую статью автора priv8v. Мнение редакции может не совпадать с мнением автора и т.д. и т.п.

Казалось бы, что о user-mode руткитах уже все давно сказано, и добавить тут нечего. С распространением зловредных драйверов все внимание антивирусных специалистов и хакеров переключилось туда, поэтому ring-3, по крайней мере, на три года остался практически без внимания… А зря. Появились новые технологии, новые методы защиты и нападения. Если задуматься, то изменились даже некоторые цели у конкретных технологий, поменялось поведение зловредов на компьютере, изменился и их внешний облик — теперь некоторые из них имеют красивые кнопочки и «ищут вирусы». На этой ноте стоит прекратить ностальгировать и приступить непосредственно к изложению темы.

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

• зачем применять сегодня user-mode руткиты?
• целесообразно ли это?
• а они часом не вымерли?

Применять их можно для скрытия чего-либо на компьютере пользователя и при отсутствии сигнатурного детекта со стороны антивируса, есть возможность оставаться незамеченным сколь угодно долгое время, даже если пользователь является продвинутым и знает что такое антируткит – о том, как этого добиться далее и пойдет речь.

Для начала необходимо кое о чем договориться и сделать некоторые допущения:

• в статье не будет рассмотрен обход эмуляторов и поведенческих анализаторов;
• обход антивирусного эвристического/сигнатурного детекта также не рассматривается;
• основное внимание будет уделено сплайсингу;
• в статье будет использована анти-script-киддис защита;
• панды бамбук не курят, они им питаются;

При разговоре о руткитах просто нельзя ничего не сказать о драйверах, тем более, когда не планируешь уделить им даже строки. Создание и использование Kernel-mode руткита сопряжено с определенными трудностями, из-за которых они не смогли полностью вытеснить с рынка собратьев на два кольца выше:

Сложность написания

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

Обход HIPS

Каждая вторая антивирусная компания под «HIPS» понимает что-то свое (несмотря на то, что расшифровка аббревиатуры у всех одинаковая). У кого-то вообще этой технологии нет, у кого-то есть только галочка в настройках (типа «Да, по умолчанию использовать эту супер-HIPS»), но у многих эта технология присутствует и включает в себя анализ поведения и эмуляцию кода. Говоря простым языком, могут быть проблемы с установкой драйвера, т.к некоторые комбайны спрашивают совета у пользователя даже если драйвер пытается ставить доверенное приложение. Если вы не найдете какого-нибудь неведомого способа установки драйвера, то ядра вам не видать как своих ушей (и зеркало при проникновении в ring-0 не поможет). Хотя в последнее время и наблюдается некий мнимый упадок технологий в этой области, связанный с прогибом антивирусов под знания среднего юзера.

«Бельмо на глазу»

Если вы будете использовать какие-то давно известные и проверенные rootkit-технологии, то обязательно будете обнаружены даже простеньким антируткитом (например, пандой). Поэтому без чего-то нового наедятся скрыться от Gmer’a, или AVZ с его километровым логом, просто бессмысленно.

Права на установку драйвера

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

Различия систем

Прежде всего, это связано с увеличением популярности Windows 7 и х64-систем.

Современные антируткиты можно условно разделить на две категории:

• Рассчитанные на продвинутых пользователей. Это целые комбайны для убийства и извращений. Они показывают перехваты с подробной информацией о них, позволяют их снимать, могут работать с реестром, файловой системой, причем сами делают их разбор. В качестве примера можно привести Gmer или XueTr.
• Рассчитанные на User Classic — как правило, имеют пять кнопок, включая «выход» и «справка», еще две это «найти» и «уничтожить», а пятая кнопка не всегда и имеется. Подобные утилиты ничего не показывают пользователю, просто ищут скрытые на их взгляд файлы/ключи/процессы и предлагают их прибить. Образчиком этой категории может быть антируткит от Panda.

Пару слов необходимо сказать пару общих слов о том, какой антируткит, где ищет и что отображает пользователю: Rootkit Unhooker и Gmer просматривают на предмет хуков все процессы в системе и ищут перехваты во всех функциях (хотя могли бы проверять только критичные) – находят даже перехват MessageBox’a. Идентифицируют тип перехвата достаточно четко (…Jump, PushRet и т.д) и указывают полный путь до библиотеки с кодом перехватчика. С помощью XueTr можно получить аналогичную информацию, только метод перехвата будет описан не столь подробно (inline, и все тут…).

Но анализировать перехваты в ring-3 умеют не все антируткиты (зачем руки-то марать?), к примеру, Vba32 AntiRootKit является одним из лучших на сегодняшний день антируткитов и находит хитрые заковырки в ядре, но в ring3 не видит ничего. Аналогично и DwShark.

Для начала зададимся вопросом о том, как скрыть или замаскировать перехваты от тех немногих программ, которые их все-таки показывают, и рассмотрим несколько способов:

1) Антируткит, как правило, не может распознать какой перехват «хороший», а какой нет. Под «хорошим» имеется в виду перехват, установленный каким-либо вполне законным приложением (например, антивирус). И весь груз ответственности за вынесения вердикта свой/чужой остается на долю пользователя, который это делает либо сам, либо с помощью коллективного разума на форуме. Именно поэтому имеет право на жизнь такой глупый способ маскировки как расположение внедренной dll по похожему на лигитимный пути, а не в папку темп или в system32 с рандомным названием. Чем плохо: C:\Program Files\Agnitum\нормальное_имя.dll – подсмотреть пути, подсмотреть названия и все. При этом к библиотеке можно даже через редактор ресурсов прилепить описание и в отчете антируткита будет видно именно оно.

2) Перехват можно сделать целевым – в определенном процессе/процессах. Или наоборот – внедряться во все процессы, кроме строго определенных. Благодаря этому про какие-то скрытые объекты антируткит не будет и знать – если в его приложение-дразнилку ничего не внедрено и не перехвачено, то и отличий от того, что спущено свыше (с уровня ядра, хотя правильнее будет сказать «сниже», но такого слова нет) с уровня ядра не будет, то есть в системе все будет видно со всех уровней, а раз ничего антируткит не нашел скрытого, то и панику поднимать не будет. Естественно, не защита от всех антируткитов, Gmer’а этим не смутить.

3) На всех компьютерах с защитным ПО обязательно будут какие-то перехваты, и практически всегда, хоть небольшая часть из них (для разных целей) зиждется на ring-3 перехватчике. Поэтому будет просто некультурно не воспользоваться этим. Идея в маскировке наших перехватов под перехваты библиотеки антивируса, а там попробуй, разберись какие функции и зачем какой антивирус перехватывает. Поэтому свой jmp мы будем ставить не на свою библиотеку, а на хорошую библиотеку ав-продукта, а уже в ней будет стоять jmp на код в нашей библиотеке.

Перехватываемая API-функция: jmp good_library.address

good_library.address: jmp our_evil_library.address

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

4) Насколько много приложений работает с системой не прямыми вызовами API-функций, а, используя функции языка программирования, на котором они написаны? Много. Вызов API-функции несомненно будет, но не сразу, поэтому и перехват можно делать в этой самой надстройке. Наиболее наглядный пример можно привести из языка С: при перехвате функции printf в библиотеке msvcrt.dll перехват не углядел ни Gmer, ни Rootkit Unhooker, при этом XueTr гордо опознал перехват и даже имя перехваченной функции. Надеюсь, что данная мысль понятна без дальнейших примеров с другими языками.

5) Для лучшего понимания следующего способа сокрытия перехватов необходимо рассмотреть то, как их обнаруживают.

Антируткит делает допущение, что лежащая на диске в system32 библиотека оригинальна, а так как все модификации ее функций находятся исключительно в памяти процессов, то механизм работы в упрощенном виде выглядит так: прочитать библиотеку с диска, принять ее за эталон чистоты и, перебирая процессы сравнивать код библиотеки в адресном пространстве с эталоном и при обнаружении отличий пытаться опознать в них метод перехвата, адрес куда ведет перехват и приложение, в которое перехват привел, таким образом антируткит покажет расхождение между оригиналом и тем, что в памяти (перехват) и куда совершается прыжок (перехватчик).

Как вы уже догадались, вектор атаки будет направлен как раз на сделанное допущение:

• Библиотека патчится не только в памяти, но и на диске (предварительно скопированная).
• После отключения WFP оригинал заменяется патченной. В зависимости от того, как будет реализовано отключение WFP и как выполнен перехват (в скольких процессах, как сделана обработка и т.д) библиотека заменяется на патченную или только на время работы антируткита, или на относительно вечно (здесь можно послать привет установке глобальных перехватов в user-mode).

6) Если jmp отодвинуть от начала функции, к примеру, байт на 30, то Gmer все равно будет видеть перехват и правильно его отображать. Rootkit Unhooker перехват также будет видеть, но имя функции не отображает (будет показывать dll_name.dll+xxx).
Следует помнить, что Gmer ругается даже при изменении одного байта в функции.

7) Замаскировать перехватчик. Если адрес нашего обработчика на начале функции класть в стек, а потом выполнять ret или просто поставить на него jmp, то не стоит удивляться, если антируткит покажет, куда ведет перехват, но если адрес немного обработать (прибавить, отнять, поболтать по регистрам), то это даст результат – перехватчик не будет определен.

Выше были рассмотрено пассивное противодействие антируткитам, но известно, что лучшая защита это нападение…

Философия примерно такая: в зависимости от способа противодействия собирается информация о популярных антируткитах (имена исполняемых файлов/библиотек/драйверов, классы/имена окон и т.д), затем пишется функция обнаружения руткит-детекторов в системе и разработка методов борьбы с ними.

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

Рассмотрим пару приемов этого противостояния.

Блокировка запуска и работы

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

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

Так что все достаточно интересно.

Прекращение работы

Как правило, все достаточно банально — процесс находится и завершается. Процесс поиска процесса аналогичен предыдущему методу (нахождение по характерным признакам). Это может хорошо продемонстрировать следующий исходный код, на котором можно еще пояснить и некоторые аспекты грубого/тонкого противодействия.

int HideXueTr = 0; // флаг было ли уже скрыто окно или нет
  // ..... code.... 
if (!HideXueTr) {
  HWND XueTr = FindWindow (NULL, "XuеTr 0.39");
    if (XueTr) {
                  MessаgeBox (0, "XueTr найден и будет скрыт!", "OK", MB_OK);
                  ShоwWindow (XueTr, SW_HIDE); // скрываем окно
                  HideXueTr = 1; // взводим флаг
               }
      }

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

При глюках обычно тянет на философию, чем и предлагаю заняться. Поразмышляем…

В логике работы всех антируткитов присутствует следующая аксиома: если скрытый — значит руткит. Соответственно найденный скрытый объект выделяется всеми цветами радуги (в данном случае для меня все цвета это красный) и уведомляет пользователя о том, что руткит найден. Далее в работе антируткитов имеется небольшая, но существенная разница, о которой мы уже говорили выше, а именно подробность отчета. Те утилиты, которые дают подробный отчет, покажут все что смогут (перехваты, перехватчик) и сам скрытый объект выделят, а те, что попроще в общении с пользователем просто покажут руткит и на выбор предложат: «Удавить его? Утопить его? Стереть в порошок?». В целом, подход, конечно, правильный, но при большом желании и везении можно использовать его слабое место, ведь не все то золото, что блестит — не все то руткит, что скрывается, тем более в данном случае между словами «скрывается» и «скрыт» нет никакой разницы. По сути, руткиту (назовем так код, который что-то скрывает) нет никакой разницы, что скрывать — что ему сказали прятать, то он и прячет. Скажут скрывать readme.txt, и будет это делать. К чему это? А все к тому… В расчете на применение антируткита или при нахождении его активности (например, процесса) в системе, можно скрыть что-то специально для него. Возьмем и легким движением руки сделаем процесс/файл антивируса злостным руткитом, причем сам антивирус будет сильно удивлен, если вдруг прознает это, а вот антируткит будет этому только рад. Раз руткит — приговор «Расстрел!». Особым цинизмом будет скрытие процесса/файла самого антируткита от него же. McAfee Rootkit Detective при обнаружении скрытого процесса предлагает только два способа борьбы с ним — завершить или переименовать. При скрытии его самого, прекрасно себя переименовывает. Панда также не ожидает, что ему подложат такую свинью и предлагает два варианта: удалять руткит и не удалять руткит. При выборе первого варианта мишка с успехом самовыпиливается: после перезагрузки бамбуковый мишка начинает использовать бамбук по назначению.

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

Закончить статью хотелось бы пожеланиями разработчикам антируткитов:

1) Еще больше рандомизировать (а тем, у кого этого нет — сделать) имена файлов/путей/окон/размера/и т.д.

2) Сделать более читабельной информацию об установленном перехвате:

• улучшить распознавание имен функций;
• информацию о перехвате выводить не только набором байт, но и мнемоникой вида jmp xxx, а при невозможности определить четко перехватчик, выводить мнемоникой весь код установленного перехвата, например:

xor eax, eax
mov eax, xxx
push eax
ret

3) Выполнять сравнение библиотек в system32 и в dllcache. Для повышения точности определения чистоты библиотеки можно носить с собой в массиве т.н базу чистых — хэш суммы проверяемых библиотек с разных систем (хотя бы популярных). Размер базы будет следующим: количество_проверяемых_в_системе_библиотек * количество_популярных_систем.

4) Выполнять поиск перехватов не только в своем процессе/некоторых, а во всех.

5) Научиться (тем, кто не умеет) опознавать перехваты, установленные антивирусными программами. Тут, собственно, три основных пути:

• иметь на борту базу чистых;
• проверять подписи (хотя в свете последних событий тут следует быть осторожным);
• подгружать базу чистых из «облака»;

6) Для получения слепка файлов/процессов/ключей из user-mode для последующего сравнения со списком из ядра, пользоваться не консольной программой, а чем-то имитирующим обычную программу — нужно хотя бы user32.dll подгружать…

Для дальнейшего понимания сути поста надо запомнить [...]]]> Пришлось мне тут анализировать один элементарный руткит, никак не срасталось у нашего анти-руткита кое-что с ним. Ерунда в принципе, бага не критичная, но разобраться все-таки стоило. В последнее время не часто выпадает возможность проанализировать что-либо, но тут повезло, можно немного отвлечься от процесса исследования/кодинга.

Для дальнейшего понимания сути поста надо запомнить то, что дата компиляции дроппера — 27 февраля 2011 года, т.е. сэмпл далеко не старый.

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

Вот такой код я обнаружил в драйвере:

char __cdecl IsDebug()
{
  UNICODE_STRING DestinationString; // [sp+4h] [bp-Ch]@4
  PVOID Object; // [sp+Ch] [bp-4h]@4
 
  if ( KdDebuggerEnabledAddr && *(_BYTE *)KdDebuggerEnabledAddr )
    return 1;
  RtlInitUnicodeString(&DestinationString, L"\\Driver\\NTICE");
  if ( !ObReferenceObjectByName(&DestinationString, 0x40u, 0, 0x1F01FFu, IoDriverObjectType, 0, 0, &Object) )
  {
    ObfDereferenceObject(Object);
    return 1;
  }
  return 0;
}

Способ, основанный на проверке переменной KdDebuggerEnabled, известен очень давно, однако, проверка на наличие в системе активного отладчика Soft(Win)Ice (наличие драйвера NTICE) — это что-то из ряда вон выходящее. Неужели авторы думают, что антивирусные лаборатории до сих пор используют этот устаревший инструмент?

Что ж, живы еще олдскул разработчики в родных селениях!

Оригинал

P.S. Спасибо vaber за предоставленную ссылку.

Номер Новость