Обнаружение вируса

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

И именно в свете сего немаловажного обстоятельства, в критические моменты встает необходимость уметь собственноручно обнаруживать и удалять вредоносный код, и именно поэтому данная статья будет посвящена изложению методов обнаружения без использования каких-либо антивирусных средств, исключением у нас будут, разве что, небольшие сопутствующие утилиты.
"Все течет, все меняется" (© Гераклит), и операционные системы из этого постулата, конечно же, не исключение. На протяжении всей истории развития операционных систем Windows, идет их постоянное видоизменение, одни системные механизмы перестают эксплуатироваться, долгое время присутствуя в системе в виде рудиментов совместимости и в последствии исчезая, другие же появляются. Происходит бесконечное движение, вирусописатели подстраиваются под эволюционирующую среду, переписывая код, использующий устаревающие механизмы, начинают искать и эксплуатировать другие, обретающие актуальность. Учитывая меняющиеся от версии к версии особенности операционных систем и достаточно большое количество потенциальных точек активации вредоносного кода, статья эта никогда не будет завершена полностью и конечно же не будет претендовать на полное руководство по выбранной тематике. Однако, по мере получения новых знаний, будет время от времени мною дорабатываться в бесконечной попытке соответствовать современным реалиям.
Перед тем как мы начнем работать с довольно сложной темой под названием обнаружение вируса, хотелось бы отдельно сказать вот еще о чем.

Дело в том, что с момента зарождения эры компьютерных вирусов, специалистами по безопасности было введено в оборот такое великое многообразие терминов и определений, что классификация в рамках небольшой статьи выглядела бы, откровенно говоря, излишней, учитывая и тот факт, что в свете характера статьи для нас фактически не так уж и важно, как зовется та или иная разновидность вредоносного кода. В разнообразных материалах, посвященных теме компьютерных вирусов, встречаются оригинальные определения, специалисты по безопасности называют программное обеспечение, которое выполняет деструктивные действия различными именами. На заре операционной системы MS-DOS вирусами называли программы, которые реплицировали собственный код в обнаруживаемые исполняемые модули и загрузочный сектор. С появлением линейки операционных систем Windows, вредоносный код обрел истинное многообразие, на свет появилось большое количество всевозможных алгоритмических отклонений, таких как руткиты (rootkit), трояны (troyan), шпионы (spyware), рекламные программы (adware), вымогатели (ransomware), сетевые черви (worms) и прочее, прочее, прочее. И все эти вариации на вирусную тему имеют различное предназначение. Часто термины ассоциируются неправильно, и вещи называются не своими именами, в дополнение, ко всему этому многообразию применяются второстепенные термины, такие как вредоносный код, зловред, вредонос. Поэтому, дабы не вводить читателя в заблуждение, я буду использовать определение "вирус" применительно к любому вредоносному коду, поэтому встречая в тексте термин вирус, подразумеваем любой вид вредоносного кода.
По каким косвенным признакам пользователь может обнаружить вирус в операционной системе? Дело в том, что какого-то единого, вполне определенного и однозначного симптома заражения системы вирусом не существует, однако общими следствиями вирусной активности могут быть:

• Низкая производительность операционной системы;
• Низкая производительность отдельных приложений;
• Часто возникающие ошибки в приложениях;
• Отображение посторонних информационных окон;
• Блокировка рабочего стола пользователя различными информационными окнами;
• Блокировка страницы (вкладки) браузера различными информационными окнами;
• Блокировка доступа к определенным ресурсам в сети Интернет (например, к сайтам антивирусных лабораторий);
• Автоматический запуск разнообразных программ;
• Отказ в изменении некоторых настроек операционной системы (даже под учетной записью локального администратора);
• Загруженная сеть, наличие интенсивного трафика на интерфейсах в моменты бездействия;
• Иная подозрительная (отклоненная от штатной) активность операционной системы;

Внимательно изучив описанные выше первичные признаки, можно сделать однозначный вывод что зачастую довольно сложно отличить вирусную активность от типовых сбоев, вызванных аппаратными и программными проблемами. Обычно в случае подозрения на аномальную активность, пользователь прибегает к помощи антивирусов, но что же делать ему в ситуации, когда работающий антивирус при сканировании не может детектировать в системе никакой вирусной активности, а "глюки" сохраняются и подозрение на вирус остается?! В этом случае можно попробовать переустановить операционную систему, выбор безусловно за вами, но в этом случае вы теряете уникальную возможность саморазвития, не получаете дополнительных знаний по компьютерным вирусам, исключаете возможность обнаружить новые виды вирусной активности. Может все же стоит попробовать "пройтись по системе" самостоятельно с целью обнаружения вируса, изучив возможные местоположения запуска и модификации? Хорошо, для начала требуется усвоить одно простое правильно:

Большинство вирусов рассчитаны на многократное исполнение, поэтому обычно оставляют свою копию в файловой системе в виде отдельного файла (группы файлов), с целью в дальнейшем иметь возможность запускаться многократно в автоматическом режиме. Применительно к операционной системе Windows, вирус представляется обычно в виде отдельного файла с расширением, идентифицирующим исполняемый различными подсистемами операционной системы код, вот некоторые из этих расширений: .exe, .dll, .sys, .ocx, .js, .ps1, .wht, .com, .bat, .vbs и прч. Некоторые вирусы, активизирующиеся в системе, не оставляют свои запускаемые копии, а просто проводят модификации определенных ключей реестра или ключевых конфигурационных файлов с целью решения собственных задач. Следуя этой логике, в целях обнаружения вируса, мы будем искать наличие подозрительных данных в физических секторах диска, файловой системе, реестре и оперативной памяти. Но ведь не придется же нам парсить полностью все эти компоненты в поисках вирусного кода? Хотя идея и неплоха :) но конечно же нет, мы будем пытаться обнаружить вирус в строго предопределенных местах: в тех расположениях в операционной системе, откуда, по задумке разработчиков, средствами самой системы могут запускаться различные исполняемые модули и где могут находиться важные для системы данные в виде файлов конфигурации различного назначения. Не лишним будет и умение отличать вирусный код от легального, знание о том, какие именно данные являются вполне безобидными, а какие из них подозрительны, то есть с большой вероятностью могут представлять вредоносный код.
Еще одним немаловажным аспектом является наличие сторонней среды, то есть операционной системы, заведомо чистой от различного рода вирусов. Делается это с тем расчетом, что некоторые особо продвинутые вирусы могут маскировать свою активность в системе, перехватывая вызовы различных функций Windows API. Поэтому, с целью получения чистой тестовой среды, мы можем:

• Запуститься в обычном режиме загрузки под учетной записью с правами локального администратора.
• Загрузиться в защищенный режим; Большинство вирусов в защищенном режиме не запускаются.
• Загрузиться с внешнего диска LiveCD, содержащего среду Windows PE (Portable Executable), в состав которой входят средства работы с физическими секторами диска, файловой системой и системным реестром.

Сокращения, используемые далее в данной статье:

В статье я постарался свести максимальное количество известных мне методов загрузки вирусов в операционной системе Windows.

Автозагрузка

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

Автозагрузка в реестре

Windows 7:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  Определяет общесистемную ветку реестра, содержащую записи о программам, запускаемых при входе в систему любого пользователя.
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  Определяет пользовательскую ветку реестра, содержащую записи о программах, запускаемых при входе в систему конкретного пользователя.
• HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
  Определяет общесистемную ветку реестра, содержащую записи о 32-битных программах, загружаемых при входе в 64-битную систему любого пользователя.
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
  Определяет общесистемную ветку реестра, содержащие записи о программам, запускаемых при входе в систему разово, то есть единожды. После единственного запуска ключи программ автоматически удаляются операционной системой из данного раздела.
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
  Определяет ветку реестра конкретного пользователя, содержащую записи о программах, запускаемых при входе в систему конкретного пользователя разово, то есть единожды. После единственного запуска ключи программ автоматически удаляются операционной системой из данного раздела.
• HKEY_USERS\SID_пользователя\Software\Microsoft\Windows\CurrentVersion\Run
  Содержит копию основной ветви автозагрузки для пользователя системы, определяемого конкретным SID-идентификатором. Например HKEY_USERS\S-1-5-21-792320725-696519568-570327587-7793\Software\Microsoft\Windows\CurrentVersion\Run. Если Вы проверяете систему из защищенного режима, либо с LiveCD, то не поленитесь проверить данный раздел для SID пользователя, который, предположительно, подхватил заразу.

Индивидуальные пути Windows 98/98SE/ME:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx

Индивидуальные пути Windows XP:

• HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Run

Автозагрузка групповой политики (в реестре)

В системе присутствуют ключи реестра, которые используются для загрузки программ как части групповой политики компьютера/пользователя. Если политики не заданы, что обычно имеет место быть в случае типовой домашней станции, то подраздел пуст. Записи в нем создаются только по определенным условиям, например при использовании локальной или доменной групповой политики для загрузки программ. Программы из списка автозагрузки с использованием групповой политики не отображаются во вкладке Автозагрузка в утилите msconfig.exe, могу предположить что и другие менеджеры автозагрузки могут не отображать эти записи, по этой то причине с целью обнаружения вируса, стоит заглянуть непосредственно в следующие ключи реестра:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

Автозагрузка в файловой системе

Однако, автозагрузка вовсе не ограничивается ключами реестра. Как мы все прекрасно знаем, в Windows существует еще один (пожалуй основной) способ автоматически загрузить программу при старте операционной системы. В интерфейсе пользователя присутствует раздел Автозагрузка, который аккумулирует списки программ из специализированных расположений в файловой системе: каталогов с именем Startup в профиле конкретного пользователя и профиле пользователя по-умолчанию. Помещая в это расположение ярлык программы либо непосредственно саму программу, можно легко добиться автозагрузки программы на стадии запуска. Меня всегда вот удивляло, почему нельзя универсализировать механизмы реестровой автозагрузки и пользовательской и объединить их? Почему в Windows присутствует именно несколько различных методов загрузки, мало того, что представлены специальные ветви реестра, так еще и предоставили каталоги? Немного поразмыслив, понял, что механизм с реестром позиционируется как "системный", а механизм с автозагрузкой в качестве "пользовательского", чтобы пользователю можно было тривиально, в два клика обеспечить своему приложению автозапуск. Представляете ситуацию объединения этих механизмов.. неподготовленный (рядовой) пользователь получал бы возможность видеть все специализированные утилиты, которые загружаются через реестр и мог бы (не)преднамеренно просто их поудалять. К тому же, не каждая программа способна загрузиться посредством записи в ключах реестра.
Конечно же, и этот механизм не смог обойтись без внимания вирусописателей, и некоторые вирусы используют механизм автозагрузки из каталога для добавления исполняемых модулей при первичном получении управления собственным кодом. Поэтому специалисту не лишним будет проверить следующие местоположения:

Однако описанные местоположения могут быть изменены через ключи реестра.
Для всех пользователей системы:

• ключ HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders,
  параметр Common Startup = %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup

Для текущего пользователя системы:

• ключ HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders,
  параметр Startup = %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

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

Загрузка на ранних стадиях

По задумке разработчиков некоторые сервисные утилиты, к примеру дефрагментаторы, программы проверки дисков, антивирусные сканеры, должны запускаться на раннем этапе процесса загрузки Windows, когда стартовали драйвера этапа загрузки (тип BOOT_START) и этапа системы (тип SYSTEM_START), но еще не инициализирован файл подкачки, переменные среды и не запущены некоторые подсистемы. В данной точке Диспетчер сеансов (Session Manager, smss.exe) только начинает разбирать переменные окружения пользовательского режима, поэтому никаких других процессов, понятное дело, еще не запущено. Однако, на данном этапе возможен запуск специально написанных образов, поддерживающих нативный (native) режим (использующих функции Native API).
Загрузка через Диспетчер сеансов настраивается в ключе реестра:

• ключ HKLM\System\CurrentControlSet\Control\Session Manager,
  параметр BootExecute = autocheck autochk *

Если в данном параметре Вы обнаружили дополнительные образы загрузки, присмотритесь к ним внимательнее, а что если это вирус? Только не удаляйте значение по умолчанию (autocheck autochk *), оно указывает на запуск утилиты проверки диска autochk с модификатором autocheck, которая проверяет значение грязного бита (dirty bit), сообщающего о необходимости проверки раздела диска на наличие ошибок.

Hosts

Файл hosts - это системный конфигурационный (текстовый) файл, содержащий локальную базу доменных имен, используемую системой в процессе сопоставления имени хоста с IP-адресом и предназначающуюся для обеспечения возможности пользовательской настройки адресов отдельных узлов сети. Его еще можно назвать своеобразным локальным DNS-сервером. Предположим, у пользователя или какой-нибудь программы появится необходимость привязать имя домена example.com к IP-адресу 1.2.3.4, то он сможет это сделать именно благодаря внесению изменений в файл hosts. Запрос к записям из файла hosts имеет приоритет перед обращением к прописанным в системе DNS-серверам, что является немаловажным фактором. Надо ли объяснять, что для вирусов это достаточно интересная точка перенаправления трафика и модификация файла вирусом может привести к подмене адреса определенного доверенного узла. Существует категория вирусов, которая модифицирует файл hosts для маршрутизации запросов на фишинговые (поддельные) сайты, в точности эмитирующие страницы оригинальных сайтов [социальных сетей] с целью кражи паролей учетных записей, показа рекламных страниц, либо просто с целью блокировки доступа к определенным ресурсам. Поэтому, обнаружение в файле hosts сторонних записей может свидетельствовать о наличии в системе вредоносного кода, либо о разовой модификации записей вредоносным кодом, что может указывать на существование в системе серьезной уязвимости безопасности. Файл hosts по-умолчанию размещается в папке %SystemRoot%\System32\Drivers\etc\ и оригинальное его содержимое выглядит следующим образом:

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

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

• ключ HKLM\System\CurrentControlSet\Services\Tcpip\Parameters,
  параметр DatabasePath = %SystemRoot%\System32\drivers\etc

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

DNS

DNS (Domain Name System) - распределенная система доменных имен, которая используется для сопоставления IP-адреса с именем хоста (фактически получения IP-адреса на основе заданного имени). Для большинства рабочих окружений на основе операционной системы Windows это основной метод разрешения внешних (по отношению к локальной сети) имен хостов. Конечно же, он имеет меньший приоритет по сравнению с вышеописанным файлом hosts, тем не менее используется очень часто. С помощью (локального|внешнего) сервера DNS разрешаются символические имена узлов (например datadump.ru), к которым Вы обращаетесь в локальной|внешней сети, и которые не были разрешены другими, более приоритетными, методами. Существует категория вирусов, которые преднамеренно модифицируют параметры реестра, относящиеся к настройкам DNS-серверов с целью перенаправления сетевого трафика скомпрометированной машины на собственные сервера имен. В операционной системе Windows настройки DNS-серверов, к которым обращается модуль разрешения имен, хранятся в специальном ключе реестра:

• HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

параметры DhcpNameServer и NameServer которого должны содержать исключительно DNS-сервера, предоставляемые вашим локальным сетевым подключенным сетевым оборудованием (роутером/маршрутизатором), контроллером домена либо провайдером-поставщиком услуг доступа к сети Интернет.
Дополнительно, я бы проверил одноименные параметры для адаптеров и интерфейсов в следующих ключах реестра:

• HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Adapters\{GUID}
• HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}

Для того, чтобы проверить корректность адресов DNS-серверов, Вы должны просто-напросто знать адреса "своих" серверов, обычно это адреса из частных диапазонов подсетей: 192.168.0.0/16, 172.16.0.0/12 и 10.0.0.0/8, но не во всех случаях.
Для того, чтобы можно было посмотреть адреса DNS-серверов, можно выполнить из консоли (cmd) следующую команду:

ipconfig /all

которая сгенерирует вывод информации обо всех сетевых интерфейсах, сконфигурированных в вашей операционной системе:

Для того, чтобы найти в этом огромном потоке информации интересующие нас DNS-сервера, Вы можете найти в выводе тот интерфейс, который "смотрит" у вас в сеть Интернет, и изучить сопоставленные с ним параметры конфигурации. Стоит обратить внимание на значение параметра "DNS-серверы". Если Вы вдруг обнаружили "левые" адреса серверов, принадлежность которых сложно установить, то можете смело их удалять, либо менять на корректные.

Оболочка (Проводник)

С тех давних пор, как мир обленился и основная масса пользователей отказалась от текстового интерфейса в пользу графического, классическое понимание оболочки (shell) определенным образом трансформировалось и в дополнение к своим типичным консольным характеристикам текстового режима приобрело дополнительные особенности в виде графической среды взаимодействия с операционной системой. Графическая оболочка пользовательского интерфейса операционной системы Windows, иначе называемая Проводником и представленная в системе файлом explorer.exe, включает в себя функционал различных элементов интерфейса пользователя, как то: рабочий стол, меню пуск, проводник (файловый менеджер), панель инструментов и некоторые другие элементы взаимодействия. Однако в Windows с целью расширения целевого применения операционной системы в качестве различных однооконных киосков, не стали жестко закреплять "родную" пользовательскую оболочку explorer.exe и дали пользователю свободу конфигурировать альтернативную оболочку посредством ключей реестра, чем и не преминули воспользоваться вирусописатели.
В реестре за настройку пользовательской оболочки отвечает ключ:

• ключ HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon,
  параметр Shell = explorer.exe

Помимо оболочки есть еще параметр userinit, который описывает программы, загружаемые процессом Winlogon на этапе входа пользователя в систему. По умолчанию, Winlogon запускает модуль под названием Userinit.exe, который запускает скрипты стадии загрузки, а уже только затем вызывает оболочку пользовательского интерфейса explorer.exe. Настройка хранится в том же ключе в параметре Userinit:

• ключ HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon,
  параметр Userinit = C:\Windows\system32\userinit.exe,

Обнаружение вируса в данном случае сводится к проверке наличия сторонних записей в данных ключах реестра.

Конфигурационные ini-файлы

Вплоть до современных версий в системе Windows все еще присутствует такой рудимент из прошлого, как конфигурационные ini-файлы. Речь у нас идет о следующих файлах:

• %SystemRoot%\system.ini
• %SystemRoot%\win.ini

В старых версиях Windows ini-файлы активно использовались в качестве основного механизма конфигурации системы, в том числе и для автозагрузки. В современных же версиях Windows система загружает некоторые параметры из указанных ini-файлов в реестр, используя так называемое отображение (сопоставление), задаваемое в следующем ключе реестра:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping
Отображение (маппинг) осуществляется следующим образом:

• Переменные Run и Load из секций [boot], [windows] файла win.ini, проецируются в ключ реестра HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows. Таким образом, данные параметры операционная система обрабатывает как элементы автозагрузки, то есть как если бы они находились в секции [windows] файла win.ini.
• Переменная Shell из файла system.ini проецируется в HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

Отображение используется в целях совместимости с устаревшим программным обеспечением, которое знает про существование ini-файлов, однако не имеет никакого представления о том, что такое реестр. В случае подобного кода, который работает через совместимые функции Win16/Win32 API, функции эти получают информацию не из описанных файлов напрямую, а уже из соответствующих сопоставленных ключей реестра. Как мы можем догадаться, механизм этот оставлен разработчиками исключительно в целях совместимости с устаревшим интерфейсом Win16, который не рекомендуется к использованию в современных реалиях Win32. Но, как говорится, что работает, то может быть использовано, поэтому вирусы иногда задействуют данный механизм.

Фильтры выполнения оболочки

Так называемые фильтры выполнения оболочки (Shell Execute Hooks) предоставляют программный метод, который расширяет функционал системных функций ShellExecute и ShellExecuteEx. Конфигурацию фильтров в реестре можно найти в разделах:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks
• HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks

Записи зачастую содержат идентификаторы CLSID, ссылающиеся на ключи HKLM\SOFTWARE\Classes\CLSID\{CLSID}, в которых в параметрах InprocServer32 содержится информация о конкретном исполняемом модуле фильтра.

Объекты загрузки оболочки

Объекты загрузки оболочки (SSO/Shell Service Object) - это библиотеки, которые в процессе загрузки пользовательского окружения загружаются системной программой оболочки explorer.exe в качестве так называемых собственных расширений проводника. Функционируют в контексте родительского процесса проводника (explorer.exe) и загружаются до авторизации пользователя в системе.
В реестре представлены ключами:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellServiceObjects
• HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\ShellServiceObjects

В дополнение к вышеописанным, имеются еще так называемые объекты отложенной загрузки оболочки (SSODL/Shell Service Object Delay Load), обычно представляющие из себя типичные библиотеки DLL. Описываются ключом реестра:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad

параметры данного раздела - это имена объектов оболочки, которые записываются в форме:
Имя_объекта = CLSID (например: WebCheck = {E6FB5E20-DE35-11CF-9C87-00AA005127ED})
Как мы видим, имена ссылаются на идентификаторы CLSID, которые можно найти в разделе HKLM\SOFTWARE\Classes\CLSID\{CLSID}, где информация о местоположении исполняемого файла оболочки содержится в параметре InprocServer32.

Уведомления оболочки

В Windows имеется механизм под названием Winlogon Notification Packages или Уведомления оболочки. Механизм уведомлений используются для запуска программ при возникновении предопределенных системных событий. События подразделяются на: вход (logon), выход (logoff), запуск (startup), завершение (shutdown), запуск хранителя экрана (startscreensaver) и останов хранителя экрана (stopscreensaver). Когда модуль Winlogon стартует, он проверяет реестр и загружает зарегистрированные пакеты уведомления оболочки (представленные в виде .dll-библиотек). Приведенные события генерируются самим процессом Winlogon.exe на разных стадиях своего функционирования. Когда событие возникает, Winlogon в параметрах ключа Notify ищет функцию обработчика того или иного события. Вирусы обычно загружают себя по событию входа пользователя (logon) в операционную систему.
Ответственный ключ реестра:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify

Модули (библиотеки) инициализации приложений

App Init DLLs - это системный механизм, который позволяет загружать произвольный список библиотек в адресное пространство каждого пользовательского процесса, использующего библиотеку user32.dll (а её функции используют практически все программы). Все начинается с загрузки user32.dll. Поскольку это типовая библиотека, входящая в состав базового набора поддержки подсистемы Win32 API, она загружается стандартным механизмом LoadLibrary. Загрузчик образа вызывает функцию DllEntryPoint библиотеки user32.dll, которая в недрах своего алгоритма содержит процедуру сканирования ключа реестра AppInit_Dll, которая загружает все перечисленные в ключе библиотеки в виртуальное адресное пространство процесса, а затем поочередно вызывает для каждой из них процедуру инициализации. Именно таким образом перечисленные библиотеки получают управление. Этот механизм так же носит название DLL injection, или внедрение динамической библиотеки. Естественно, если какое-либо приложение не использует стандартную библиотеку user32.dll, то никакие библиотеки, описанные в ключе AppInit_Dll в его адресное пространство загружены не будут. Согласитесь, что подобный функционал очень интересен для разнообразного злонамеренного кода. Поэтому, после всех проблем, которые доставил данный механизм в плане безопасности операционной системы, начиная с Windows 7 разработчики решили добавить необходимость подписания кода загружаемых библиотек. А в последствии грозятся и вовсе перейти на загрузку только лишь подписанных библиотек.

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

• для 32-битных DLL, функционирующих в 32-битной системе:
  HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
  параметр AppInit_DLLs
• Для 64-битных DLL, функционирующих в 64-битной системе:
  HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
  параметр AppInit_DLLs
• Для 32-битных DLL, функционирующих в 64-битной системе:
  HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows
  параметр AppInit_DLLs

Параметр содержит множество значений, разделенных пробелом либо запятой, каждое из которых описывает отдельную библиотеку.
Работать с данным ключам надо предельно внимательно, и хорошо себе представлять происходящее. Дело в том, что параметр может содержать модули вполне легальных приложений (антивирусы, клиенты виртуализации и прочее). Поэтому, не стоит спешить с массовым удалением всех присутствующих программ, и следует быть предельно аккуратным с очисткой данного параметра. Я думаю, в самом общем случае, алгоритм обнаружения вируса и очистки должен быть следующим: находим первую запись, определяем [гуглим] принадлежность модуля, если вирус - удаляем, если легальный - оставляем, и так по всем записям списка.

Известные библиотеки

В операционных системах Windows (начиная с Windows 95/NT) присутствует механизм под названием KnownDLL (известные библиотеки), в основном предназначающийся для кеширования часто используемых системных DLL с целью сокращения общего времени загрузки приложений (увеличения производительности). Помимо основного применения, механизм обеспечивает довольно интересный дополнительный функционал, который позиционируется как средство обеспечения безопасности. Оно позволяет предотвращать такой хитрый трюк, как загрузка дубликатов известных системных библиотек непосредственно из директории самого приложения. Поместил злоумышленник, к примеру, свою копию библиотеки wininet.dll в директорию приложения, которое данную библиотеку использует, и по идее данная библиотека должна загрузиться приоритетно, поскольку находится в директории загружаемого приложения, ан нет, механизм KnownDLL загрузит её из %SystemRoot%\System32\wininet.dll. Когда загрузчик образов подготавливает бинарный файл к выполнению, он смотрит в таблицу импорта и перечисляет библиотеки, которые используются загружаемым приложением. Для каждой библиотеки, которую загрузчик находит в таблице импорта, он пытается спроецировать библиотеку в адресное пространство процесса, для того, чтобы сделать функции библиотеки доступными основному приложению. Однако на этом же этапе загрузчик просматривает контейнер системных объектов KnownDLL и ищет в нем объект с именем \KnownDlls\<имя_библиотеки>, в случае существования которого, вместо подгрузки DLL непосредственно из текущего местоположения, загрузчик использует информацию объекта.
Описание секций присутствует в ключе реестра:

• HKLM\System\CurrentControlSet\Control\Session Manager\KnownDLLs

Если Вы внимательно изучите содержимое ключа, то заметите, что все перечисленные в нем DLL не имеют полного пути, поскольку по задумке разработчиков располагаются в директории %SystemRoot%\System32 (задается ключом DllDirectory). Это поднимает уровень безопасности, поскольку теперь чтобы вирусу прикинуться известной библиотекой и использовать механизм KnownDLL, ему потребуются еще и права записи на системную папку. Создание секций \KnownDlls\<имя_библиотеки> для каждой DLL происходит на этапе загрузки операционной системы специализированным кодом, который просматривает описанный выше ключ и создает соответствующие секции. Поэтому, обнаружение вируса, использующего механизм KnownDLL, сводится к просмотру записей о библиотеках в описанном выше ключе и удалении модулей, вызывающих подозрение.

Параметры загрузки образов

Среди множества прочих, в системе реализован механизм под названием параметры загрузки образов (IFEO, Image File Execution Options), позволяющий контролировать некоторые аспекты запуска исполняемых образов (исполняемых файлов). Фактически он предоставлен разработчиками в целях отладки собственных программ. Одной из особенностей данного механизма является возможность перехватывать вызовы к исполняемому образу (программе), что дает неограниченные возможности по полному контролю запускаемого приложения, в том числе подмене его собственным кодом.
Настройки параметров загрузки хранятся в ключах реестра:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options;
• HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options;

Данные разделы реестра содержат подключи, указывающие на имена загружаемых образов, которые, в свою очередь, содержат параметры, описывающие разнообразные опции для запуска той или иной программы. В контексте текущей статьи все параметры описывать нет никакого резона, скажу только, что со стороны вредоносного кода интересным будет использование параметра Debugger, который должен указывать, по версии разработчиков, на отладчик, запускаемый каждый раз, когда описанное приложение будет стартовать. Иными словами, например, если в ключе explorer.exe создать параметр Debugger (типа REG_SZ) и присвоить ему значение myapp.exe, то каждый раз при загрузке системой проводника будет запускаться указанное приложение с параметрами командной строки, указывающими на исходную программы и переданные уже ей параметры. Таким вот незатейливым способом вирусы могут подменять различные ключевые системные модули собственными. В этом случае, подозрительным с точки зрения безопасности будет факт присутствия в каком-либо модуле параметра Debugger, указывающего на подозрительное приложение.

Предзагрузка командного интерпретатора

Если командный интерпретатор (cmd.exe) запускается без параметра командной строки /D, то код интерпретатора вначале проверяет следующие ключи реестра:

• ключ HKLM\Software\Microsoft\Command Processor,
  параметр AutoRun
• ключ HKCU\Software\Microsoft\Command Processor,
  параметр AutoRun

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

Планировщик заданий Windows

Планировщик заданий (Shared Task Scheduler) - системный компонент, предоставляющий возможность планирования выполнения заданий (программ или скриптов) в системе на основе большого количества всевозможных критериев. Другими словами, планировщик заданий отвечает за автоматический запуск пользовательских и системных задач, запланированных по определенным условиям. Подобные задания зачастую связаны с запуском внешних приложений, поэтому не сложно догадаться, что это достаточно интересный механизм для некоторых категорий вирусов. К примеру, код вируса может создать собственную задачу, которая будет с определенной периодичностью подменять системные DNS-сервера (кстати воочию подобное наблюдал).
Для контроля заданий нам потребуется запустить планировщик. Запускается планировщик заданий разными способами, но один из самых универсальных это запуск через цепочку Панель управления - Администрирование - Планировщик заданий. При запуске планировщика в Windows 7 открывается стандартный интерфейс апплета:

Для просмотра сторонних запланированных задач, выделяем пункт Библиотека планировщика заданий 1, затем ставим курсор (выделяем) на пункт задания в области списка заданий 2, смотрим вкладку действия 3 для каждого заинтересовавшего нас задания, с целью выяснить, какие же действия оно выполняет. Откровенно подозрительными обычно являются задания, которые производят запуск исполняемых модулей неизвестного назначения (с невнятными именами) из таких местоположений, как %LOCALAPPDATA% и вложенных подкаталогов (например: C:\Users\<имя_пользователя>\Appdata\Local\wupdate\wupdate.exe). При обнаружении подобного подозрительного или откровенно вредоносного задания, просто удаляем его из списка задач.

Windows Vista+:
Начиная с версии Windows Vista, задачи создаются в виде отдельных файлов формата XML (с расширением .xml). Размещаются планируемые задачи в нескольких местоположениях операционной системы:

• Каталог C:\Windows\System32\Tasks;
• Каталог C:\Windows\Tasks;
• Ключ реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tasks;
• Ключ реестра HKLM\Software\Microsoft\Windows NT\CurrentVersion\Schedule\Taskcache\Tree;

Windows 2000/XP:
В данных версиях операционных систем задачи можно было найти в реестре, в следующей ветви:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskScheduler

Службы [Сервисы] и драйверы

Службы (Сервисы) - это приложения, автоматически или по возникновению определенных событий, запускаемые в фоновом режиме на различных стадиях загрузки операционной системы, обеспечивающие основные функциональные возможности ОС. Как правило, службы (сервисы) не взаимодействуют с графическим интерфейсом пользователя, поэтому говорится, что они не имеют графического интерфейса, и работа их в большинстве случаев не заметна для пользователя. Служба, в зависимости от настроек, может быть запущена автоматически при загрузке операционной системы, поэтому начать функционирование она может до того момента, как пользователем будет произведен вход в Windows. Основная задача по обнаружению вируса, который установил в систему собственную службу, состоит в том, чтобы просмотреть весь список запускаемых служб и детально изучить его на предмет наличия подозрительных сервисов. С этой целью можно использовать знакомую уже многим оснастку Службы, вызвав её следующим образом:
Нажать комбинацию Win + R и вписать в строку services.msc, затем нажать ОК. После этого мы видим примерно следующее:

Для полноты восприятия переключаемся в стандартный вид (1), далее сортируем службы по столбцу "Состояние", просто щелкнув на нём (2), тем самым выстроив сначала службы, которые в данный момент работают. И среди работающих служб начинаем искать те, которые могут показаться нам подозрительными. В случае нахождения подозрительной службы можно попробовать её выделить (3), нажать правую кнопку и попытаться остановить (4), выбрав одноименный пункт меню. После остановки службы можно зайти в "Свойства" и изменить Типа запуска (StartUp Type) на Отключено (Disabled), перезагрузив затем операционную систему.
На самом деле, можно смело утверждать, что практически с нулевой вероятностью "родные" системные сервисы от Microsoft вызовут у нас подозрение, поэтому хорошая практика, в данном случае, состоит в том, чтобы отфильтровать как-либо образом сторонние службы, написанные третьими лицами и вот уже среди них провести проверку. Визуально отличить стороннюю службу (коей обычно и является вирус) от системной можно при наличии определенных знаний, но не у всех они имеются, поэтому существует более надежный и простой способ с участием утилиты msconfig (Конфигурация системы). Из командной строки с правами локального администратора запускаем команду:

msconfig

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

А вот уже среди отфильтрованных (оставшихся) служб можно проводить детальный анализ.

Скрытые службы

На самом деле иногда все бывает гораздо сложнее, поскольку при определенных настройках безопасности службы и применении некоторых других методов, сервисы могут быть "скрыты". Подобные скрытые службы Вы не обнаружите при помощи традиционного инструментария (например: оснастка "Службы"). Исходя из этого более надежным, на мой взгляд, решением видится самостоятельный анализ ветви реестра текущей конфигурации:

• HKLM\SYSTEM\CurrentControlSet\Services

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

• параметр Description - содержит либо осмысленное имя службы/драйвера, либо указание на библиотеку вида @%SystemRoot%\system32\AxInstSV.dll,-104.
• параметр DisplayName - содержит либо осмысленное отображаемое имя службы/драйвера, либо указание на библиотеку.
• параметр DriverPackageId - содержит указание на .inf-файл драйвера.
• параметр ImagePath - содержит полный путь и имя файла образа загрузки для службы/драйвера. Многие службы группируются в рамках единого процесса svchost.exe, в этом случае содержат что-то вроде: %SystemRoot%\system32\svchost.exe -k AxInstSVGroup. Зачастую у драйверов имя файла образа имеет расширение .sys, у служб обычно .exe, но это не обязательное правило.

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

• HKLM\SYSTEM\ControlSet001\Services
• HKLM\SYSTEM\ControlSet002\Services
• HKLM\SYSTEM\ControlSet003\Services

В случае обнаружения службы/драйвера вируса полностью удалить её из системы можно либо удалением соответствующего ключа реестра, либо командой:
sc delete имя_службы

Internet Explorer

Безо всякого сарказма это браузер с мировым именем :) На этой содержательной фразе можно было бы и остановиться, однако даже столь емкий термин не может в полной мере отразить весь тот огромный узел разнородных проблем, которых породили разработчики браузера самим фактом его создания. Пожалуй, можно смело утверждать, что браузер корпорации Microsoft является самой большой дырой в безопасности системы (на 2016 год почти восемь сотен обнаруженных уязвимостей). Восхождение звездного продукта началось с вытеснения в 1997 году конкурента под названием Netscape Navigator. Стратегическое решение было принято в связи со всё возрастающей ролью сети Интернет, и необходимостью более глубокой внутренней интеграцией обозревателя в систему. Вероятно, сама идея была действительно хорошая, поскольку продукт получился весьма функциональным, но как в последствии стало ясно, с очень непродуманной архитектурой. Практически постоянно можно наблюдать обход настроек безопасности, неправильную обработку внешних файлов, спуфинг, неавторизованную установку расширений. Зачастую уязвимости связаны с внешними плагинами типа Flash Player и Java, однако отсутствие изоляции процессов и собственной (встроенной) обработки флеш и явы делает сам браузер беспомощным. Последнее время Microsoft работают над новым браузером, который будет носить название Edge, вот только будет ли он сохранять совместимость?

Подключаемые протоколы

В браузере Internet Explorer есть возможность добавлять так называемые подключаемые протоколы, которые могут быть сконфигурированы пользователем в дополнение к стандартным. Протоколы предназначены для расширения функционала браузера и фактически позволяют определить метод доступа к внешним ресурсам исходя из пользовательских критериев, то есть по вашему собственному протоколу, задавая специфический префикс URL. Протокол сопоставляет поведение браузера и логики работы с символической короткой строкой вида mailto: или http:.

• ветвь HKLM\SOFTWARE\Classes\PROTOCOLS содержит описание специализированных фильтров и обработчиков.
• подветвь HKLM\SOFTWARE\Classes\PROTOCOLS\Handler содержит подключи, описывающие обработчики протоколов. подключи представляют собой имена обработчиков, в которых имеется параметр CLSID, указывающий на соответствующий CLSID обработчика.
• подветвь HKLM\SOFTWARE\Classes\PROTOCOLS\Filter содержит подключи, описывающие фильтры протоколов. подключи представляют собой имена фильтров, в которых содержится параметр CLSID, указываются на соответствующий CLSID фильтра.

Как мы видим, классически все эти указанные в подразделах CLSID указывают на тот же CLSID в ключе HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CLSID}, а вот уже внутри информация о местоположении самого исполняемого модуля содержится в параметре InprocServer32. Обнаружение вируса сводится к просмотру и нахождению подозрительных обработчиков и фильтров.

Элементы управления ActiveX для Internet Explorer

ActiveX - это механизм (дополнение), благодаря которому Internet Explorer может использовать другие системные приложения. При помощи него обеспечивается расширение функциональных возможностей браузера и, тем самым, достигается "лучшее взаимодействие" с веб-ресурсом. Например, через IE онлайновый антивирус посредством собственного ActiveX-компонента сканирует локальные файлы [на машине], сайт Microsoft Update устанавливает через свой ActiveX-компонент обновления безопасности в систему, ресурс может вызывать Windows Media Player для проигрывания звуковых форматов, вызывать QuickTime для воспроизведения анимации и так далее. Конечно же, данной технологией не могли не заинтересоваться вирусописатели, разрабатывающие вредоносные ActiveX-компоненты, которые обычно устанавливаются для последующей загрузки дополнительного программного обеспечения без вашего ведома. Все элементы ActiveX, которые инсталлируются через Internet Explorer, попадают сперва в директорию %Windir%\Downloaded Program Files. Обычно это модули типов .exe, .dll, .ocx, .cab и сопутствующие .inf. Кроме самого исполняемого модуля (или архива), сюда же попадает и .inf-файл, описывающий процесс инсталляции, при участии которого и выполняется установка ActiveX-компонента в систему. Устанавливаемые таким образом элементы могут регистрировать себя в системе в качестве полноценных приложений. Для самостоятельного поиска вируса нам потребуется простой механизм по изучению списка ActiveX-элементов, установленных в системе. Существует ключ реестра, который содержит списки идентификаторов ActiveX, установленных для IE:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\PreApproved

Однако ключ (как всегда) содержит одни лишь голые идентификаторы, поэтому для установления ассоциации с исполняемыми модулями нам (опять) предстоит вручную проверять каждое значение CLSID в другом ключе реестра HKEY_CLASSES_ROOT\CLSID и изучать для каждого CLSID подключ InprocServer32.

Общие параметры сети в Internet Explorer

Разнообразные настройки для сети Интернет можно обнаружить в следующем ключе:

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings

В ключе содержится большое количество параметров, и ниже посмотрим на какие же подключи стоит обратить особое внимание.

Сайты и протоколы Internet Explorer

Сайты и протоколы, добавленные в зону "Надежные узлы" (Trusted Zone). Обычно добавление в данную зону позволяет перечисленным в списке сайтам обходить некоторые виды проверок безопасности, то есть считаться более доверенными.
Используемые ключи реестра:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults

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

Настройки прокси сервера

В ключе:

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings

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

Browser Helper Objects (BHO)

Browser Helper Object (Объект помощи браузеру, помощник браузера) - исполняемый модуль DLL, написанный в виде плагина для браузера Internet Explorer, предназначающийся для обеспечения дополнительного функционала, стандартно не поддерживаемого браузером. Вне зависимости от расширения практически всегда представляют собой обычные DLL библиотеки, которые загружаются вместе с браузером и работают в контексте основного процесса браузера. По этой причине разнообразная подозрительная активность зачастую остается незамеченной некоторыми персональными фаерволами. Вирусы могут инсталлировать BHO, отслеживающие защищенные соединения и мониторящие пароли, либо записывающие активность пользователя при посещении определенных интернет-ресурсов. С точки зрения вируса подключить BHO к браузеру Internet Explorer достаточно просто, для этого достаточно стандартными средствами зарегистрировать класс BHO и прописать ссылку на него в специальном ключе реестра:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects
• HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects

подразделы ключа имеют имя-значение GUID и ссылаются на одноименный компонент.

Плагины Internet Explorer

Плагины Internet Explorer - это небольшие программные модули, загружаемые при старте браузера с целью добавления браузеру определенных функциональных возможностей. Обычно используются для визуализации различного нестандартного контента: проигрывания специфических форматов видео, аудио и прочих.
Используемый ключ реестра:

• HKLM\SOFTWARE\Microsoft\Internet Explorer\Plugins

подразделы описывают различные разделы плагинов.

Панели инструментов Internet Explorer

Панели инструментов Internet Explorer - это дополнения для браузера, которые позволяют создавать и добавлять отдельные пользовательские панели, наборы инструментов или даже отдельностоящие панели рабочего стола в различные местоположения окна браузера: командную строку, строку закладок, меню, системную панель задач, а так же в прочие управляющие элементы. Распространены ситуации, когда панели инструментов создаются установленными в браузер BHO.
Ответственные ключи реестра:

• HKLM\SOFTWARE\Microsoft\Internet Explorer\Toolbar
• HKCU\SOFTWARE\Microsoft\Internet Explorer\Toolbar
• HKLM\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Toolbar

содержит подразделы в виде GUID, которые ссылаются непосредственно на компоненты.

Расширения Internet Explorer

Расширения для Internet Explorer (Addons, Аддоны) - это специальная категория дополнений, которые используются для добавления элементов к пользовательскому интерфейсу браузера. Возможна модификация главной панели инструментов с целью реализации на этой панели разнообразных отдельностоящих кнопок и полноценных меню. Кнопки панели инструментов могут запускать приложение, скрипт или открывать новую панель. Меню (иногда называемые сервисами), могут создавать пользовательское подменю в меню "Сервис" или "Справка" на панели инструментов браузера. Очевидно, что меню (сервисы) и кнопки сами по себе опасности не представляют ровно до того момента, пока не будет задействован их (возможный) деструктивный функционал, например непосредственным нажатием на компонент. Ведь это всего лишь ссылки, но вот после нажатия (активации) ссылка вызывает закрепленную функциональную процедуру, которая не всегда может выполнять легитимные действия.
С определенной версии IE все расширения браузера можно увидеть в подразделе "Панели инструментов и расширения" специализированного апплета Надстройки, до которого можно добраться через "Свойства обозревателя" - "Программы"- "Настроить надстройки":

Другой способ предусматривает запуск браузера Internet Explorer из командной строки с параметром -extoff:

iexplore.exe -extoff

Поскольку при подобном типе запуска браузер позволяет увидеть все без исключения (и нормальные и скрытые) расширения.

Используемые ключи реестра:

• HKLM\SOFTWARE\Microsoft\Internet Explorer\Extensions
• HKCU\SOFTWARE\Microsoft\Internet Explorer\Extensions
• HKLM\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Extensions

Подразделы представляют из себя (традиционно) идентификаторы CLSID, в которых вложенными ключами описываются расширения.

Пункты меню Internet Explorer

Возможно добавить дополнительные пункты в контекстное меню браузера Internet Explorer. Обычно этот тип меню можно увидеть, нажав правую кнопку мыши на какой-либо активной ссылке, расположенной на странице, отображаемой в данный момент в окне браузера.
В реестре настройка меню представлена по следующему пути:

• HKCU\SOFTWARE\Microsoft\Internet Explorer\MenuExt
• HKLM\SOFTWARE\Microsoft\Internet Explorer\MenuExt

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

Дополнительные параметры Internet Explorer

С определенной версии IE существует возможность модифицировать содержимое вкладки Дополнительно в свойствах обозревателя (Свойства обозревателя - Дополнительно), добавив туда новую группу настроек.
Ответственный ключ реестра:

• HKLM\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions

подключи описывают группы параметров во вкладке Дополнительно.

Стартовая страница

Стартовая (начальная) страница отображается в первой (самой левой) стартовой вкладке окна браузера непосредственно после запуска.
Используемые ключи и параметры реестра:

• ключ HKLM\SOFTWARE\Microsoft\Internet Explorer\Main,
  параметр Start Page
• ключ HKCU\SOFTWARE\Microsoft\Internet Explorer\Main,
  параметр Start Page
• ключ HKEY_USERS\SID_пользователя\SOFTWARE\Microsoft\Internet Explorer\Main,
  параметр StartPage

Страница поиска

• HKLM\SOFTWARE\Microsoft\Internet Explorer\Main,
  параметр Search Page
• HKCU\SOFTWARE\Microsoft\Internet Explorer\Main,
  параметр Search Page

Страница по умолчанию

Страница по умолчанию - страница, открываемая при нажатии на пиктограмму с изображением "домика" (располагающуюся справа от строки адреса).
Используемые ключи и параметры реестра:

• HKLM\SOFTWARE\Microsoft\Internet Explorer\Main,
  параметр Default_Page_URL
• HKCU\SOFTWARE\Microsoft\Internet Explorer\Main,
  параметр Default_Page_URL = что-то вроде http://go.microsoft.com/fwlink/p/?LinkId=255141

Префикс по умолчанию

Описывает префикс, который добавляется к адресу при отсутствии явного указания префикса URL пользователем в строке адреса. Обычно в IE используется приставка http://.
Используемый ключ и параметр реестра:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\URL\DefaultPrefix,
  параметр @=http://
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\URL\Prefixes,
  параметры ftp, home, mosaic, www

Трансляция неизвестных адресов

Интерфейс IURLSearchHook раскрывает метод, используемый браузером для трансляции адресов, содержащих неизвестный или не указанный (не конкретизированный) непосредственно протокол. Примером может служить ситуация, когда в адресной строке браузера вводится адрес, не содержащий префикса http://. Для начала Internet Explorer пытается самостоятельно определить протокол используя оригинальный адрес. В ситуации, когда браузер не имеет возможности определить протокол адреса в адресной строке, он вызывает URLSearchHook, создает объекты URL Search Hook (которые зарегистрированы в системе) и вызывает для каждого объекта метод трансляции до тех пор, пока URL не будет оттранслирован или все фильтры не будут обработаны.
Настройка трансляции производится в ключе реестра:

• HKCU\SOFTWARE\Microsoft\Internet Explorer\URLSearchHooks

Параметры имеют имена CLSID, ссылающиеся на ключи HKLM\SOFTWARE\Classes\CLSID\{CLSID}, в которых в параметрах InprocServer32 содержится информация о трансляторе. По-умолчанию это C:\Windows\System32\ieframe.dll.

Устаревшие (необрабатываемые, исключенные) настройки Internet Explorer

Данная группа параметров активно использовалась в устаревших ныне версиях браузера (5/6/7/8) и в современных либо не используется, либо заменена другими механизмами конфигурирования:

• HKLM\SOFTWARE\Microsoft\Internet Explorer\Search,
  параметр SearchAssistant
• HKLM\SOFTWARE\Microsoft\Internet Explorer\Search,
  параметр CustomizeSearch
• HKCU\SOFTWARE\Microsoft\Internet Explorer\Search,
  параметр CustomizeSearch

Передача запроса поисковой системе. Когда в адресной строке браузера IE вводится что-либо, не соответствующее формату типового URL-адреса, то браузер передает строку заданной по умолчанию поисковой системе. Для подобных целей используется ключ реестра:

• HKCU\SOFTWARE\Microsoft\Internet Explorer\SearchURL,
  параметр Default или ((По умолчанию))

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

• HKCU\SOFTWARE\Microsoft\Internet Explorer\Main,
  параметр Window Title

Отображение результатов поиска в главном окне/окне поиска браузера. Еще один устаревший параметр, который позволял изменить стиль отображения результатов поиска:

• HKCU\SOFTWARE\Microsoft\Internet Explorer\Main,
  параметр Search Bar

Ориентировочно до версии IE6 в коде обозревателя присутствовал Мастер подключения к Интернету:

• HKCU\SOFTWARE\Microsoft\Internet Connection Wizard,
  параметр ShellNext

где он теперь?

Локальная групповая политика

Время от времени модификации вредоносным кодом подвергаются файлы локальной групповой политики. В принципе, это достаточно привлекательный системный механизм для вирусописателей, поскольку модифицировав каким-либо образом локальную групповую политику, можно добиться автоматического внесения изменений в реестр. Например, на практике попадались методы заражения, которые подразумевали модификацию локальной групповой политики (а именно файла registry.pol) с целью последующего внесения изменений в те или иные ключи реестра. Например, часть конфигурации локальной групповой политики под названием "локальный компьютер" располагается по пути:

• %SystemRoot%\System32\GroupPolicy\Machine\registry.pol

.. и если вредоносный код добавит туда, скажем, исключения для того же Защитника Windows или брендмауэра, то данные исключения каждый раз при применении групповой политики будут добавляться в соответствующие ключи реестра. Поэтому, лишний раз не поленитесь проверить содержимое файла registry.pol на предмет наличия подозрительных записей, и при обнаружении таковых, можно смело удалять последний.

Многоуровневый поставщик услуг

Winsock LSP (Layered Service Provider) - многоуровневый поставщик услуг, Windows Sockets версии 2.0, предоставляющий возможность пользователю подключать собственные библиотеки DLL для обработки вызовов Windows Sockets API. Обычно поставщик занимается обработкой низкоуровневых задач, связанных с сетевым трафиком. Поставщик обрабатывает данные, передаваемые по протоколу TCP/IP, который используется для связи с локальной сетью и сетью Интернет. В процессе приема/передачи данных по протоколу TCP/IP, информация последовательно проходит по цепочке через все зарегистрированные в стеке TCP/IP поставщики (по структуре обычные DLL-библиотеки, которые используют Winsock API). Каждый поставщик может как угодно модифицировать проходящие данные и адреса. Таким образом, механизм LSP используется для вполне легитимных действий над трафиком и пространством имен, таких как подсчет трафика, антивирусная проверка, фильтрация контента, поэтому, например, многие антивирусы и фаерволы могут на вполне легальных основаниях находиться в стеке TCP/IP в качестве поставщиков услуг. Однако, некоторые вирусы могут добавлять свои модули в цепочку обработки.
Список поставщиков услуг хранится в специальной базе, которую можно найти в реестре в следующем разделе:
HKLM\System\CurrentControlSet\Services\Winsock2\Parameters
Не редка ситуация, когда Вы каким-либо образом нашли и удалили из цепочки модуль вируса, который находился в стеке поставщиков, однако не произвели коррекцию самой цепочки, в этом случае цепочка обработки рвется, и работа по протоколу TCP/IP с локальной сетью и сетью Интернет становится невозможной. Бывают и случаи удаления вредоносной DLL из файловой системы без должной коррекции (отмены регистрации провайдера) базы провайдеров, которые тоже не приводят ни к чему хорошему. Для восстановления (корректировки) цепочки провайдеров существуют утилиты LSP-Fix и AVZ (является полноценным сканером), которые проходят по цепочке разделов реестра Winsock2 и восстанавливают корректные связи.
Конечно, в случае с Windows Sockets 2.0 все далеко не так радужно. Чаще всего, в случае проблем с работоспособностью локальной сети и интернет, выполняют восстановление по заданному системному шаблону, однако этот шаблон надо знать, поскольку неправильные действия с базой поставщиков могут привести к полной неработоспособности сетевого интерфейса.

Компоненты Active Setup

Active Setup (Активная настройка/Набор активирования/Активный набор) - системный механизм, предназначенный для разового выполнения команд на этапе первичного входа пользователя в систему. Команды выполняются единожды, то есть при всех последующих входах пользователя команда исполняться уже не будет. Конфигурация каждого компонента Active Setup делится на машинную и пользовательскую части, которые расположены в разных ветвях реестра. Поэтому, когда пользователь входит в систему, Active Setup проверяет наличие идентификатора GUID каждого [заданного для установки] компонента в пользовательской части соответствующего ключа реестра и если GUID отсутствует, то выполняется команда, ассоциированная с компонентом, а по завершении процесса GUID компонента добавляется в пользовательскую часть реестра. Механизм может производить установку пакетов .msi. Работу механизма Active Setup мы можем, к примеру, лицезреть когда впервые авторизуемся в операционной системе: наблюдаем первичную настройку обозревателя Internet Explorer, проявляющую себя в появлении небольших окон установки в левом верхнем углу рабочего стола пользователя. Механизм может эксплуатироваться вирусами, поэтому поиск вируса в данном случае сводится к проверке машинной части ключей реестра Active Setup. Информация о машинной части размещается в реестре в ключе:

• HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components
• HKLM\SOFTWARE\Wow6432Node\Microsoft\Active Setup\Installed Components

Содержит подключи в виде идентификаторов GUID, которые и описывают (содержат параметры) установленные в системе компоненты. Лечение сводится к обходу всех представленных в ключе идентификаторов и проверке вложенных параметров (таких как stubpath), содержащих полные пути к исполняемым образам компонентов.