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

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

В мире операционных систем Windows NT фундаментом взаимодействия программ является системный интерфейс Windows API, который включает в себя тысячи функций. Использование измененных системных функций подобно взгляду в кривое зеркало, и именно эту особенность используют rootkit для скрытия своего присутствия. Количество Троянов-невидимок непрерывно растет, что связанно, во-первых, со сложностями обнаружения rootkit, а, следовательно, невозможностью противостояния со стороны классических антивирусных программ, во-вторых, с тем, что написание rootkit является достаточно прибыльным способом зарабатывания денег для троянописателей. Некоторые разработчики современного защитного программного обеспечения обещают нам гарантированное выявление всех rootkit пользовательского режима и режима ядра, предлагая специализированное программное обеспечение для этой цели. Этот обзор не претендует на полноту изложения, но в тоже время сделаем попытку дать справедливую оценку возможностям наиболее известных программ для поиска rootkit. Итак, приступим.

Rootkit, поселившийся на компьютере пользователя, должен оставлять следы своей деятельности - ключи реестра и файлы на диске, которые ему необходимо скрывать, чтобы избежать выявления. Поскольку программы отображают информацию о наличии файлов и ключей реестра, используя интерфейс системных функций (Windows API), скрытие будет заключаться в этом случае в перехвате этих функций и фильтрации значений, которые получит программа. С целью выявления скрытых ключей реестра и файлов Марком Руссиновичем была создана программа - RootkitRevealer. Ее принцип работы такой: после запуска создается и запускается во временном каталоге исполняемый файл со случайно выбранным именем. В свою очередь, этот исполняемый файл при запуске извлекает и запускает из своей секции ресурсов драйвер ring-0 (RKREVEAL150.SYS). Для поиска скрытых ключей реестра RootkitRevealer осуществляет обработку файлов, полученных путем дампа веток реестра (полученных через ZwSaveKey). В этом можно убедиться, проведя небольшое исследование.

Далее эти файлы обрабатываются и сравниваются со списком, полученным через Windows API. Также осуществляется поиск ключей, содержащих т.н. embedded-null characters (например, такой прием использован в примере от Марка Руссиновича - RegHide). Поиск скрытых файлов осуществляется путем сравнения списка файлов полученного путем вызова API функций со списком файлов полученных через командный интерпретатор с использованием команды DIR. Казалось бы, что обмануть такую проверку из пользовательского режима не так уж просто: например, чтобы избежать обнаружения скрытых ключей реестра, необходимо перехватывать низкоуровневую функцию ZwSaveKey и обрабатывать возвращаемый результат. Однако существует способ более простой :).  Дело в том, что программ-детекторов скрытых файлов и ключей реестра совсем немного. И совсем несложно составить список таких программ, как RootkitRevealer. Обратите внимание на одну особенность: RootkitRevealer отображает только скрытые файлы и ключи реестра, это и есть главный недостаток. В качестве примера рассмотрим не очень сложный vanquish rootkit. Этот rootkit пользовательского режима внедряет в каждый создаваемый процесс свою динамическую библиотеку, которая путем сплайсинга (англ. splicing - соединение внахлест) нужных API функций осуществляет их перехват в контексте каждого процесса.

Таким образом, каждый процесс при вызове функций API, которые используются для получения ключей реестра и файлов (напр. FindFirstFile, FindNextFile) будет вызывать обработчик из внедренной динамической библиотеки, где будет вызываться настоящая системная функция и отфильтровываться результат, возвращаемый программе. Это позволит скрыть нужные файлы и ключи реестра от всех программ, например explorer, regedit32, кроме rootkit детекторов! Т.е. если обработчик перехваченной функции получает управление в контексте процесса rootkit детектора, например, RootkitRevealer-а, не составит труда сделать таким образом, что rootkit не будет скрывать никаких файлов и ключей, и rootkit детектор, соответственно, не сможет ничего обнаружить! Это очень распространенная ошибка разработчиков rootkit детекторов. В подобных программах необходимо предпринимать дополнительные меры для предотвращения такой ситуации. Видимо, для затруднения своего обнаружения RootkitRevealer создает процесс с произвольно выбранным именем, кроме этого, каждый раз меняется размер исполняемого файла. Однако этого не достаточно, поскольку процесс RootkitRevealer–а можно обнаружить, например, по характерной для него сигнатуре или по таблице импортируемых функций, можно придумать и множество других способов.

AVZ, антивирус Зайцева

По словам разработчиков, программа способна выявлять перехватчики режима ядра и пользовательского режима. AVZ действительно способен находить перехватчики API функций, однако неискушенный пользователь не знает, что существует множество способов этого самого перехвата. Стоит напомнить, что для перехвата может осуществляться модификация таблиц IAT/EAT,  перезапись кода функции системной библиотеки в ее начале (сплайсинг), производиться модификация системных таблиц SSDT, IDT; rootkit может перезаписывать также код системных сервисов режима ядра, вписывая в их начало команду безусловного перехода на собственный обработчик, кроме того может устанавливаться брейкпоинт (опкод CC) в начало перехватываемой функции с перенаправлением отладочного прерывания int 3 на собственный обработчик. Для перехвата могут также использоваться отладочные DRx регистры процессора. Из всех вышеперечисленных методик AVZ определяет только те, которые чаще всего используют легитимные приложения (антивирусы, firewall и др.), например, перехват через SSDT легко обнаружить, поэтому современный rootkit врядли воспользуется этой техникой. В тоже время такой перехват осуществляет множество программного обеспечения – от драйверов эмуляторов типа Alcohol 120% до антивирусов и HIPS, например, Kaspersky Internet Security 2006, проактивная система защиты Safe’n’Sec®. AVZ не обнаружит перехват, использующий отладочные регистры, или перезапись в режиме ядра кода системного сервиса. Следовательно, программа только запутает пользователя, указывая на перехват системных функций, осуществленный легитимными приложениями.

Process hunter by Ms-Rem

Алгоритм работы программы - сравнение списка процессов, полученных различными способами; если находятся отличия - процессу присваивается статус hidden (скрытый). Программа действительно очень хорошо детектирует скрытые процессы, например, для обнаружения FU rootkit достаточно установить флажок «List Handles». Cкрыть процесс от Process hunter очень сложно, но нужно ли это? На самом деле, в последнее время rootkit не создают своего собственного процесса. В качестве примера можно привести все тот же vanquish rootkit, который представляет собой динамическую библиотеку, которая подгружается в адресное пространство каждого вновь создаваемого процесса. Нередко также происходит заражение системных библиотек, драйверов со скрытием следов (что осуществляется перехватом API функций и подменой результатов проверки подписей и чтения системных файлов). В подобном случае ни один детектор скрытых процессов не сможет ничего обнаружить.

F-Secure BlackLight Rootkit Eliminator, UnHackMe

Данные программы практически ничем не превосходят по своим возможностям RootkitRevealer и Process Hunter, и имеют схожее назначение - поиск скрытых файлов, ключей реестра и процессов. Несмотря на то, что эти программы детектирует большую часть свободно доступных demo-rootkit, подробно рассматривать их обход не имеет смысла, поскольку, как и в случае с RootkitRevealer выводится список только скрытых ключей реестра и файлов. Даже в случае, если возникнет необходимость скрывать какие-то процессы, файлы или ключи реестра, то все еще можно использовать простой и эффективный способ, как и описанный выше - база программ-антируткитов. Определить процесс F-Secure BlackLight Rootkit Eliminator и UnHackMe еще проще, поскольку здесь не применены даже элементарные приемы, как в RootkitRevealer – произвольно выбранное имя процесса и изменяющийся размер файла. Еще более задача усложнится тем, что даже если будет выводиться полный список процессов (а, как сказано выше, rootkit может ничего не скрывать, чтобы не допустить обнаружения скрытых элементов), имя процесса вредоносной программы может совпадать с именем одного из системных процессов. Тогда в диспетчере процессов антируткита будет сложно отличить системный процесс от фальш-процесса троянской программы, например, в ОС WinXP зачастую несколько процессов svchost.exe, наличие еще одного врядли привлечет внимание пользователя.

На самом деле обнаружить подделку не так уж было бы и сложно - достаточно проверить соответствие кода в памяти процесса его файлу-образу на диске, его расположение, проверив заодно цифровую подпись, но, к сожалению это не реализовывается. Что касается внедрения динамических библиотек и создания удаленных потоков в контексте легитимных процессов, то, несмотря на наличие HIPS (проактивных защит), такая возможность будет до тех пор, пока существуют в системе доверенные процессы и не будет очень жесткого контроля над этими доверенными процессами. Например, часто вредоносному коду достаточно получить управление в контексте системного процесса winlogon, чтобы получить не контролируемый HIPS-системами доступ на запись в адресное пространство всех остальных процессов и получить полный контроль над инфицированной системой. Для этого можно зарегистрировать динамическую библиотеку в реестре: HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows NT\CurrentVersion\Winlogon\Notify. Для обхода контроля записи в реестр можно использовать прямую запись в файл реестра на диске, поскольку доступ к этим файлам заблокирован, осуществлять запись через прямой доступ к диску (используя функцию CreateFile с параметром FileName=\\.\PHYSICALDRIVE0), после чего, используя техники перехвата системных функций скрывать изменения. Фактически, на данном этапе, существующее защитное программное обеспечение необходимого уровня защиты, и контроля над доверенными процессами не обеспечивает.

IceSword

Отличительные особенности: отслеживает и ведет лог создания, завершения процессов, что бывает весьма полезно, особенно в тех случаях, когда троянская программа работает короткое время, также полезная функция - просмотр программ, установивших message hooks - можно просматривать путь к программе-перехватчику и тип перехватываемого сообщения, что полезно при борьбе с кейлоггерами. К недостаткам стоит отнести весьма скудную информацию о загруженных драйверах - нет version info, нет проверки подписей, что затрудняет анализ результатов; то же относится и к информации о перехватчиках режима ядра, не выводится информация, которая поможет отличить специализированный софт от троянской программы. В остальном программа не превосходит по своим возможностям AVZ и обнаруживает далеко не все виды перехвата системных функций.

Windows Defender

Эту программу врядли можно назвать защитником от rootkit. Во-первых, Windows Defender совершенно не способен защищать свой собственный процесс и службу от выгрузки, что под силу обычному вирусу, не говоря про rootkit. Кроме того, можно приостановить процесс программы простым вызовом функции SuspendThread. Последнее еще и навредит пользователю, поскольку при этом заблокируется возможность создания новых процессов. Во-вторых, несмотря на наличие контроля  загрузки драйверов, не контролируется доступ к физической памяти (device\physycalmemory), что позволит троянской программе получить доступ на запись к защищенной памяти ядра, а также выполнить произвольный код в ring-0. Ко всему этому, Windows Defender не предоставляет абсолютно никаких возможностей для поиска скрытых элементов в системе. Единственное достоинство программы – красивый интерфейс. Исходя из этого, Windows Defender можно назвать скорее жертвой, чем защитником.

System Virginity Verifier

Хороший пример от Джоанны Рутковской. Эта программа позволяет определить перехват API функций, как в пользовательском режиме, так и в режиме ядра путем побайтного сравнения системного файла-образа на диске с его копией в памяти. Например, в случае с vanquish rootkit, будет обнаружено следующее:

kernel32.dll         (7c800000 - 7c8f6000)... suspected! (verdict = 5).
module kernel32.dll [0x7c800000 - 0x7c8f6000]:
 0x7c801af1 (section .text) [LoadLibraryExW()+0]   5 byte(s):
  JMPing code (jmp to: 0x1ae34c7)
  address 0x1ae34c7 is inside  module [0x1ae0000-0x1aec000]
  target module path:
  module file is NOT PRESENT!!!
  file   :6a 34 68 88 e2
  memory :e9 d6 19 2e 85
  verdict = 5

 0x7c802332 (section .text) [CreateProcessW()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c31be)
  address 0x3c31be is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 8c 0e bc 83
  verdict = 5

 0x7c802367 (section .text) [CreateProcessA()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c30bb)
  address 0x3c30bb is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 54 0d bc 83
  verdict = 5

 0x7c80aa66 (section .text) [FreeLibrary()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c3da3)
  address 0x3c3da3 is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 3d 93 bb 83
  verdict = 5

 0x7c80ec7d (section .text) [FindFirstFileExW()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c3e5b)
  address 0x3c3e5b is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 de 51 bb 83
  verdict = 5

 0x7c80f13a (section .text) [FindNextFileW()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c3f37)
  address 0x3c3f37 is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :6a 2c 68 38 f2
  memory :e9 fd 4d bb 83
  verdict = 5

module kernel32.dll: end of details
ADVAPI32.dll         (77dc0000 - 77e6c000)... suspected! (verdict = 5).
module ADVAPI32.dll [0x77dc0000 - 0x77e6c000]:
 0x77dc6bf0 (section .text) [RegCloseKey()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c4c1d)
  address 0x3c4c1d is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 2d e0 5f 88
  verdict = 5

 0x77dc79a1 (section .text) [RegEnumKeyExW()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c4d6d)
  address 0x3c4d6d is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 cc d3 5f 88
  verdict = 5

 0x77dc8081 (section .text) [RegEnumValueW()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c4e4f)
  address 0x3c4e4f is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 ce cd 5f 88
  verdict = 5

 0x77dcd649 (section .text) [RegEnumKeyW()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c4c8b)
  address 0x3c4c8b is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 42 76 5f 88
  verdict = 5

 0x77ddaf3f (section .text) [EnumServicesStatusA()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c50ab)
  address 0x3c50ab is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :6a 34 68 c0 af
  memory :e9 6c a1 5e 88
  verdict = 5

 0x77ddcf4a (section .text) [RegEnumValueA()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c4ec0)
  address 0x3c4ec0 is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 76 7f 5e 88
  verdict = 5

 0x77de7775 (section .text) [CreateProcessAsUserW()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c33c4)
  address 0x3c33c4 is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 4f bc 5d 88
  verdict = 5

 0x77dec8c1 (section .text) [RegEnumKeyExA()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c4dde)
  address 0x3c4dde is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 1d 85 5d 88
  verdict = 5

 0x77decac3 (section .text) [RegEnumKeyA()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c4cfc)
  address 0x3c4cfc is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 39 82 5d 88
  verdict = 5

 0x77e00958 (section .text) [CreateProcessAsUserA()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c32c1)
  address 0x3c32c1 is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 69 29 5c 88
  verdict = 5

 0x77e2553b (section .text) [RegQueryMultipleValuesA()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c4fea)
  address 0x3c4fea is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 af fa 59 88
  verdict = 5

 0x77e2589d (section .text) [RegQueryMultipleValuesW()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c4f31)
  address 0x3c4f31 is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 94 f6 59 88
  verdict = 5

 0x77e27b91 (section .text) [EnumServicesStatusW()+0]   5 byte(s):
  JMPing code (jmp to: 0x3c55d2)
  address 0x3c55d2 is inside  module [0x3c0000-0x3cc000]
  target module path:
  module file is NOT PRESENT!!!
  file   :8b ff 55 8b ec
  memory :e9 41 da 59 88
  verdict = 5

module ADVAPI32.dll: end of details

SYSTEM INFECTION LEVEL: 5
    0 - BLUE
    1 - GREEN
    2 - YELLOW
    3 - ORANGE
    4 - RED
--> 5 - DEEPRED

SUSPECTED modifications detected. System is probably infected!

Выполнив команду SVV fix /t 2 можно деактивировать перехват vanquish rootkit, после чего станут видимыми все скрываемые им файлы и ключи реестра. System Virginity Verifier способен выявлять также перехват путем перезаписи кода системных сервисов и установку int 3, и даже модификацию IDT. Однако и здесь могут возникнуть трудности в случае с коммерческими rootkit. Во-первых, обязательно нужно иметь гарантии достоверности информации, полученной при чтении файла-образа системной библиотеки на диске. А для этого необходимо предпринять меры, которые обеспечат чтение и проверку подлинности одного и того же файла на диске, т.е. нужны дополнительные гарантии того, что читается именно тот файл, который прошел проверку подлинности, что является не столь уж простой задачей. Возможно, как альтернативное решение проблемы использование собственной базы хешей системных библиотек. В этом случае проверка подлинности будет осуществляться напрямую программой, без использования таких функций, как WinVerifyTrust. Но в этом случае необходимо оперативно обновлять эту базу данных с каждым обновлением ОС, также учитывать различные версии ОС, т.е. задача усложняется. В противном случае ничто не помешает rootkit осуществить перехват подобных функций проверки подписи файла с подменой результата. Еще одной достаточно существенной проблемой является тот факт, что rootkit совсем необязательно возвращать программе антируткиту правильные данные, как в описанном для RootkitRevealer-a случае, чтобы избежать обнаружения.

Можно просто обеспечить неработоспособность таких программ по базе антируткитов на инфицированной системе. Ведь пользователю трудно будет выяснить причину, по которой антируткит отказался у него запускаться - например, конфликт может быть и с легитимным программным обеспечением. К сожалению, решить данную задачу весьма непросто, для этого необходимо, чтобы у каждого пользователя был индивидуальный экземпляр защитной программы, который будет сложно детектировать троянской программе-невидимке. Не стоит забывать также, что коммерческий rootkit отличается от demo (AFXRootkit, HackerDefender, vanquish), качеством реализации. Подавляющее большинство антируткит-программ тестировалось лишь на demo-rootkit, которые практической пользы не имеют, и врядли применяются в реальности, что еще раз подтверждает неэффективность программного обеспечения для борьбы с rootkit. Один из примеров в пользу вышесказанного такой: для обнаружения скрытых файлов на диске антируткит должен анализировать и обрабатывать информацию с HDD посекторно (чтобы не получить эффект «кривого зеркала»). Осуществить это возможно несколькими способами: самый простой - использование CreateFile (\\.\PHYSICALDRIVE0) и ReadFile для чтения секторов, следующий уровень анализа - использование низкоуровневых функций ZwCreateFile, ZwReadFile. Еще более глубокий уровень анализа - обращение к драйверу диска напрямую, минуя API-функции, формируя IRP-запросы драйверу. Все три способа могут не дать абсолютно никакого результата, так как в первых двух случаях обход для rootkit выльется перехватом соответствующих API-функций, в последнем - IRP hooking. На более глубокий уровень анализа не способен ни один существующий антируткит. Его суть заключается в использовании машинных инструкций in и out для прямого обращения к контроллеру HDD. В этом случае обход возможен только в rootkit, написанном специально для этого случая. Есть еще один альтернативный, и вероятно более надежный вариант: программа антируткит составляет список всех файлов и ключей реестра через Windows API, и записывает их в свой лог-файл, возможно, шифрует эти данные. Далее пользователю предлагается сделать загрузочный диск (не важно - flash, CD и т.д.). После этой операции второй этап проверки осуществить, загрузившись со специально подготовленного диска, и путем анализа HDD опять получить список всех файлов, а путем анализа файлов реестра - список ключей реестра (есть сложность, связанная с тем, что при перезагрузке часть ключей и файлов может измениться, и может возникнуть ложное срабатывание). Путем сравнения двух полученных списков можно обнаружить, что скрывается в недрах системы от пользователя. Но, опять же, все это сработает только в том случае, если rootkit не детектирует сканирующую программу и не выдаст для нее на 1-ом этапе полный список всех файлов и ключей. Но, в этом случае, можно смело выводить пользователю список всех программ из автозапуска - список будет полным, также как и список системных файлов :).

Выводы

Из проведенного обзора следует, что на данный момент не существует многофункциональной программы, позволяющей производить глубокий низкоуровневый анализ системы и выявлять троянские программы - невидимки. Для борьбы с rootkit можно использовать лишь отдельные функции отдельных программ - анализ модификаций системы - System Virginity Verifier от Джоанны Рутковской (особенно радует, что программа анализирует не только перехват через SSDT, но выводит подробный список модификаций кода ядра, включая системные таблицы, MSR SYSENTER, кроме этого доступны исходники программы). Поиск скрытых процессов - Process hunter by Ms-Rem (в котором реализованы наиболее широкие возможности для этого), RootkitRevealer только при условии, что у вас персональная версия программы, скомпилированная специально для вас Марком Руссиновичем, поскольку доступных исходников к ней нет :(. IceSword - для отслеживания кратковременного запуска программ и просмотра установленных перехватчиков сообщений (все это, в общем-то, не дает полной гарантии выявления).