Защитник Windows 10 может обнаруживать бэкдоры в инструментах специальных возможностей
Обычно такие взломы осуществляются с помощью параметра debugger для ключа Image File Execution Options.
В техническом смысле, ключ реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options позволяет добавлять инструменты отладки к программе, которые автоматически запускаются при запуске приложения. Обычно данная возможность позволяет разработчикам упростить процесс отладки приложения.
Для этого нужно задать параметр “debugger” в ключе “Image File Execution Options” (IFEO), указав название и путь до отладчика. В примере ниже мы назначили программу Notepad2.exe отладчиком для Notepad.exe. Это приведет к тому, что Notepad2.exe будет запускаться каждый раз, когда открывается Notepad.exe.
Хотя данная функция была первоначально создана для получения отладочной информации, она часто используется для других целей. Например, если вы хотите заменить Notepad.exe на другую программу, например Notepad2, то можете воспользоваться примером выше. Другим примером использования данного ключа является замена Диспетчера задач (Taskmgr.exe) на Process Explorer.
К сожалению, данный ключ представляет интерес и для разработчиков вредоносного ПО, в частности с целью настройки бэкдоров. Ключ IFEO может создаваться вредоносной программой, которая будет запускаться каждый раз, когда пользователь начинает работу с другой надежной программой. Затем зловред запустит исходную безопасную программу, и жертва атаки не заметит ничего необычного.
Image File Execution Options может использоваться для установки бэкдоров в системе, которые можно запустить напрямую с экрана блокировки Windows. Некоторые программы из категории специальных возможностей, в частности Sticky Keys (sethc.exe), можно запустить прямо с экрана блокировки, 5 раз нажав Shift, а Utility Manager (utilman.exe) вызывается с помощью горячих клавиш Windows+U.
Создав ключ IFEO для данных программ и установив C:\Windows\System32\cmd.exe в качестве отладчика, вы получите вполне жизнеспособный бэкдор, который можно легко открыть с экрана блокировки:
Пользователю останется 5 раз нажать Shift на экране блокировки, и откроется командная строка. Также будет иметь место эскалация привилегий, так как командная строка в этом случае будет обладать правами администратора, что позволит злоумышленнику получить полный контроль над компьютером жертвы.

Командная строка бэкдора открыта с помощью залипания клавиш
Чтобы защитить пользователей Windows от данных видов атак, Защитник Windows 10 теперь научился обнаруживать ключи IFEO, которые созданы для закрепления отладчиков cmd.exe или taskmgr.exe к инструментам специальных возможностей, доступных с экрана блокировки.
Данные типы атак будут идентифицироваться как Win32/AccessibilityEscalation. В случае их обнаружения, Защитник Windows автоматически удалит конфликтующий отладчик из ключа реестра. Данный тип обнаружения можно спровоцировать при добавлении средства отладки C:\Windows\System32\cmd.exe к IFEO ключу sethc.exe.

Обнаружение Win32/AccessibilityEscalation в Защитнике Windows 10
В тестах Защитник Windows выполнял мониторинг следующих программ на предмет отладчиков, которые могут использоваться в качестве бэкдоров.
- Переключение дисплеев: C:\Windows\System32\DisplaySwitch.exe
- Экранная клавиатура: C:\Windows\System32\osk.exe
- Экранная лупа: C:\Windows\System32\Magnify.exe
- Экранный диктор: C:\Windows\System32\Narrator.exe
- Горячие клавиши специальных возможностей (залипание клавиш): C:\Windows\System32\sethc.exe
- Менеджер утилит: C:\Windows\System32\utilman.exe
Дальнейшие испытания показали, что обнаружение происходит, если к вышеуказанным программам приписываются следующие инструменты отладки:
Проведенный тест не является исчерпывающим. Скорее всего, другие программы и отладчики также могут спровоцировать обнаружение Защитника Windows.
Перехватываем запуск любого приложения в Windows и пытаемся ничего не сломать
Если вы много занимаетесь отладкой приложений под Windows — вы, возможно, слышали о таком замечательном механизме, как Image File Execution Options (IFEO). Одна из предоставляемых им возможностей позволяет отлаживать приложение в условиях, более приближенных к боевым. Записав в нужное место в реестре специальный ключик, мы можем вместо программы автоматически запускать её отладчик, позволяя ему делать свои отладочные дела. Однако кто сказал, что этот механизм (фактически — перехвата запуска чего угодно) можно использовать только в подобных целях? Эта статья вовсе не об использовании вещей по назначению.
Под катом рассказ о том, как я попытался выжать побольше из этого механизма в своих добрых целях, и какие подводные камни мне встретились на пути. А у меня тут хорошие, отборные камни.
Итак, что мы имеем: мы можем запустить свою программу вместо любой другой наперёд заданной, если заранее пропишем себя в реестре. Причём не особо важно кто, как, и с какими правами будет её запускать.
Не уверен, насколько полезным оказался бы этот механизм, если бы не было возможность его обойти: отладчику-то нужно запустить отлаживаемый процесс. Так что в Image File Execution Options есть одно исключение. Начнём с того, что в пользовательском режиме есть всего два метода запуска процессов: CreateProcess и ShellExecuteEx. Да и то, второй, в конце концов, тоже вызывает CreateProcess, но об этом позже. Так вот, исключение же это заключается в том, что запуски процессов с флагом DEBUG_PROCESS не перехватывается. Это и решает проблему с отладчиками, но, в моём случае, это также означает, что на IFEO нельзя полагаться полностью. И тем не менее, я не знаю ни одной программы (кроме отладчиков, разумеется), которые пользовались бы этим флагом. Нельзя просто поставить этот флаг и наслаждаться: понадобится дополнительный код, чтобы всё заработало.
Регистрация файла в IFEO
Если вы проследите с помощью Process Monitor’а за тем, что происходит при вызове функции CreateProcess — вы, вероятно, найдёте много чего интересного. Помимо коррекции ошибок в имени файла, о которой мы поговорим чуть позже, вы обнаружите обращение в реестр за настройками IFEO. Как это выглядит:

Если этот ключ будет найден, то также будет проверено наличие определённых полей, в том числе строкового поля Debugger. Оно-то нам и нужно. В нём хранится путь к отладчику, или, в нашем случае, к программе, запускаемой вместо данной.
Стоит заметить, что здесь есть свои ограничения:
- Проверяется исключительно имя исполняемого файла. Это значит — никаких масок. Нельзя просто взять, и перехватить вызов *.exe.
- Действие для всех программ с одинаковым именем исполняемого файла будет одинаковым. До тех пор, пока мы не воспользуемся ключом UseFilter. Тогда, да, можно назначать конкретный отладчик для конкретного исполняемого файла, основываясь на его полном пути. Опять же — без масок.
Для использования фильтрации в ветке IFEO\YourExecutable.exe надо создать DWORD поле UseFilter c ненулевым значением. В этом случае, при попытке создания процесса, он обойдёт все под-ключи в данной ветке, и в каждом из них будет сверять значение строкового поля FilterFullPath с полным путём к исполняемому файлу. При совпадении будет запущен найденный в поле Debugger исполняемый файл. Если совпадений не будет найдено — будет запущен Debugger по умолчанию (то есть тот, что использовался бы без всяких фильтров).
Замечание: любой под-ключ без поля FilterFullPath трактуется как совпадение, и все настройки берутся с него и имеют приоритет над теми, что были бы без фильтра.
Назначение стандартных действий
Изначальный смысл этой затеи для меня был в том, что, узнав про IFEO, я решил написать программу, которая предлагала бы пользователю набор типичных действий (реализованных в виде маленьких утилит), назначаемых для других программ. Это было ещё до того, как я решил написать статью, осознав, сколько тут занятных вещей можно рассказать. А потому, используем эти утилиты в качестве наглядного и практического примера для повествования. Итак, на что хватило моего воображения:
- Ask.exe — оповещает пользователя о попытке запуска и спрашивает разрешения;
- Deny.exe — отказывает в запуске. При этом может как оповещать пользователя, так и делать это молча.
Очень удобно, если надо запретить винде запускать какую-нибудь телеметрию - Elevate.exe — всегда запрашивает UAC для повышения прав до Администратора;
- Drop.exe — понижает привилегии процесса. Это просто венец творения. По смыслу аналогичен утилитам DropMyRights и PsExec с флагом -ℓ. Но в сочетании с IFEO — гораздо эффективнее;
- PowerRequest.exe — не даёт компьютеру заснуть / погасить экран до тех пор, пока программа не завершится.

Для регистрации этих действий было написано две версии представленной на скриншоте программы: GUI и консольная. Здесь и рассказывать не о чем. Просто читаем/пишем в реестр.
Как можно догадаться из заголовка, самое интересное — это как подменить чужую программу во время исполнения, и при этом ничего не сломать. Но сперва несколько очевидных, хотя и необходимых вещей. Если уж и запускать перехваченный процесс, то надо как можно лучше воспроизвести те же условия, при которых запустили нас самих. А это значит:
- Точно такая-же структура STARTUPINFO, установка флага bInheritHandles, и такая же рабочая директория;
- Ожидание завершения запускаемого процесса для получения его кода возврата и передачи по цепочке;
- И… ещё один трюк, о котором я расскажу чуть позже.
Хорошо. А как мы узнаем, что запускать-то?
Оценим возможности
Пусть в IFEO в качестве отладчика для программы A.exe прописано следующее:
Если кто-то попытается создать процесс «C:\Folder\A.exe» с параметром -a то будет создан процесс B.exe cо следующей командной строкой:
Поскольку мы сами пишем код для B.exe — мы без проблем разберём командную строку на составляющие части и вполне можем запустить A.exe с теми же параметрами, с каким его хотел запустить этот безымянный кто-то. Здесь-то у нас и появляется полноценная свобода. Хотим — запускаем с другими привилегиями, захотим — сможем и передаваемые параметры поменять.
Любопытно во всём этом вот что: как, по-вашему, реагирует на столь вольное обращение контроль учётных записей? Правильный ответ: а никак. Если в проводнике выбрать «Запуск от имени Администратора» на файле A.exe, то в сообщении UAC будет показываться информация именно о файле A.exe, и именно его цифровая подпись будет определять цвет окна. А то, что вместо него будет запущен B.exe — это дело десятое. Нет, здесь нет особых проблем с безопасностью: запись в IFEO сама требует административных привилегий. Для нас это значит нечто иное: записав наши утилиты в IFEO мы вообще не будем смущать пользователя неверными сообщениями контроля учётных записей. Ведь с его точки зрения — так оно и должно выглядеть.
Как обычно запускают процессы
С появлением контроля учётных записей в Windows Vista запуск процессов стал более сложным. Дело в том, что теперь для запуска некоторых программ вызов CreateProcess может оказаться неудачным по причине недостатка прав. В этом случае GetLastError возвращает ERROR_ELEVATION_REQUIRED . На такой случай в Windows встроено даже специальное исправление проблем с совместимостью, хотя я так и не заметил, чтобы оно хоть что-то исправляло. Современные же программы в ответ на эту ошибку должны вызывать ShellExecuteEx с действием «runas» для запроса повышения привилегий. Это значит, что типичный код создания процесса теперь выглядит так:
Поскольку наши утилиты должны работать всегда, они не будут требовать повышенных привилегий для запуска, а значит тот процесс, который попытается запустить A.exe (и вместо него запустит наш B.exe) никогда не получит ERROR_ELEVATION_REQUIRED. Вроде бы: и ладно, ничего страшного, мы и сами cможем запросить повышение прав для него, если потребуется. А теперь представим себе, что так и произошло. Вот запустил кто-то A.exe, вместо него запустились мы, а поскольку A.exe требователен к привилегиям — мы не можем запустить его CreateProcess’ом, а потому должны использовать ShellExecuteEx. Уже догадались? ShellExecuteEx же всегда перехватывается IFEO, там нет флага DEBUG_PROCESS, который мог бы нас спасти. В результате мы снова запустим самого себя. Правда, на этот раз у нас уже хватит привилегий использовать CreateProcess для запуска A.exe. И всё это без каких-либо видимых следов со стороны UAC! Можно мозг сломать, не правда ли? Я и сам не до конца привык к концепции «почти всеобъемлющего перехвата своих же действий».

По этой причине в утилите Elevate.exe нельзя обойтись одним лишь ShellExecuteEx’ом — мы просто не сможем обойти IFEO. В случае же Ask.exe это добавляет ещё одну проблему. Вот спросили мы пользователя, подтвердил он запуск. А затем ShellExecuteEx’ом в сочетании с IFEO мы запустили снова себя. Что, опять спрашивать будем? Пришлось добавить подавление вторичного вопроса. А ведь это невозможно сделать простым дописыванием специального параметра: куда бы мы его не дописали, мы же всё равно собираемся запускать A.exe, так что он будет неотличим от его собственных параметров. Это весьма неплохое упражнение для ума — попытаться заранее предугадать все эти сложности.
Отличие CreateProcess от ShellExecuteEx
Вы читали документацию на CreateProcess? Там есть один момент, который многие упускают, потенциально создавая некоторую уязвимость в безопасности своих приложений. Это же относится и к устаревшей функции WinExec, являющейся обёрткой над CreateProcess’ом. Два первых параметра функции определяют, что и с какими аргументами будет запускаться. Это lpApplicationName и lpCommandLine. Вот перевод куска текста из MSDN:
Почему люди продолжают забывать ставить кавычки? Так ведь и так работает — в CreateProcess встроен механизм коррекции ошибок. Установим lpApplicationName в NULL и попытаемся запустить программу передав в lpCommandLine имя её исполняемого файла: C:\Program Files\Sub Dir\Program Name. Что будет делать CreateProcess? Искать в строке то, что можно запустить, пока не найдёт, да ещё и подставляя расширение файла:
Если хотите поэкспериментировать — создайте файл C:\Program.exe у себя на компьютере и посмотрите, попадётся ли какая из программ на это. У себя я поймал на этом Process Hacker (fix уже есть в ночной сборке), Punto Switcher (надо бы мне им тоже написать), и один из плагинов к Far Manager. Кстати, проводник Windows тоже знает об этой проблеме:

Возвращаясь к вопросу: а что это значит для нас? Из IFEO мы получаем именно lpCommandLine. Да, мы можем просто передать его в CreateProcess — если там и была такая проблема — она останется, здесь мы бессильны. Но также нам может понадобиться передавать его в ShellExecuteEx, а там, упс, такой коррекции ошибок нету. Там отдельно lpFile и отдельно lpParameters. Придётся самостоятельно разбирать строку по пробелам и искать имя первого существующего исполняемого файла также, как это делает CreateProcess. Супер.
А сейчас мы немного отвлечёмся и поговорим о других любопытных вещах. Я собираюсь рассказать о том, как работает одна из утилит.
Понижая привилегии
Принцип «Запускать любую программу с минимальными необходимыми ей правами» здесь, вероятно, знаком всем. Но вот что делать, если автор понравившейся вам программы об этом принципе не слышал — вопрос уже более сложный. Иногда в таких ситуациях спасают механизмы устранения проблем совместимости:
Это заметно снижает число случаев, когда CreateProcess не сможет запустить программу и вернёт ERROR_ELEVATION_REQUIRED. Но это работает не всегда. Например, над этим методом имеют приоритет *.sdb патчи .
Ещё есть специальные утилиты, которые умеют запускать процессы с Elevated-токеном (т.е. как-бы от имени администратора), но при этом вырезают все соответствующие привилегии . Это DropMyRights, написанная Майклом Ховардом из Microsoft, и PsExec из широко известного комплекта Microsoft Sysinternals, запускаемая с ключом -ℓ. Как ни странно, но эти утилиты добиваются своего разными путями.
Мне больше по душе оказался метод, используемый в DropMyRights. Да и исходники у него открытые. Используется там Windows Safer API, который позволяет буквально в несколько строк кода вычислять токен с урезанными привилегиями, который можно сразу использовать в CreateProcessAsUser. Эх, хотел бы я, чтобы все писатели инсталляторов знали, как это просто, и не запускали программы с максимальными правами по окончании установки…
А теперь объединим оба упомянутых подхода, совместив их с IFEO. В результате получаем автоматическое понижение прав и минимум запросов к контролю учётных записей. Не знаю как вам, но мне это очень нравиться. А поскольку повышение прав путём вызова ShellExecuteEx’а перехватывается всегда, то, насколько я понимаю, у программы, находящейся под действием нашей утилиты, нет шансов самостоятельно выбраться до тех пор, пока пользователь не подтвердит UAC для другого исполняемого файла, находящегося в кооперации с ограничиваемым. Но для действительно серьёзных случаев — пользуйтесь песочницами вроде Sandboxie. Или виртуальными машинами, если на то пошло.
Обход IFEO
Возвратимся к основной теме. Я вот всё говорю, мол, запустим процесс с флагом DEBUG_PROCESS и будет нам счастье, на свои грабли сами не попадёмся. Но для того, чтобы всё заработало, необходимо сделать ещё кое-что. С этим флагом мы запустим процесс под отладкой, а значит, нам будут приходить отладочные события. Если их не обработать — процесс так и останется висеть неподвижно. Для их обработки понадобятся всего две функции: WaitForDebugEvent и ContinueDebugEvent.
Однако не все программы нормально относятся к отладчикам, верно? Не то, чтобы я специально делал исключение ради вирусов, но отсоединение отладчика действительно будет лучшей идеей. Мы ведь здесь не ради написания отладчика собрались. А вот тут, неожиданно, наступает сложность: это действие, вероятно, относится к недокументированным возможностям, ибо на MSDN я его не нашёл. А потому будем пользоваться документацией Process Hacker’a. Итак, нам потребуется функция NtRemoveProcessDebug из ntdll.dll. Ей же нужен DebugObjectHandle, который можно получить с помощью NtQueryInformationProcess, запросив у неё ProcessDebugObjectHandle = 30 в качестве ProcessInformationClass. Вот и всё. Хотя… Лучше не делайте так с чужими процессами: их отладчик может в этот момент ждать отладочное событие, а для них самих может быть включён kill-on-close.
Стоит заметить, что здесь имеется особенность, связанная с разрядностью операционной системы: 32-битный процесс не может запускать 64-битный процесс с флагом DEBUG_PROCESS. Зато 64-битный может запускать кого угодно.
Ах да, вы ещё помните? Выше я обещал рассказать про ещё один трюк, позволяющий добиться чуть лучшей совместимости при последующем запуске перехватываемых процессов.
Магия контроля учётных записей
Я уже говорил, что контроль учётных записей вообще никак не реагирует на происходящее. И если вы ещё тогда задались вопросом «А почему?», то вам точно сюда.
Как работает UAC и каким образом позволяет повышать привилегии? Хорошо ответ на этот вопрос дан в англоязычной статье Vista UAC: The Definitive Guide. Если коротко: ShellExecuteEx, пробиваясь через дебри вызовов COM, обращается к сервису AppInfo. Тот создаёт процесс consent.exe, который и выводит то окно с предложением подтвердить запуск, и, при необходимости, ввести пароль. Само создание процесса, естественно, происходит уже после всего этого. И используется там самый обычный CreateProcessAsUser. Именно на этом этапе срабатывает IFEO, и, перехватывая создание процесса, запускает нас. Именно поэтому контроль учётных записей ничего об этом не знает.
Самые догадливые уже должны были задаться вопросом: если процесс создаётся кем-то другим, то как получается, что его родительским процессом всё равно оказывается инициатор запроса?
- Дескриптор процесса, которого мы делаем новым родителем, должен иметь права PROCESS_CREATE_PROCESS и жить вплоть до вызова DeleteProcThreadAttributeList;
- Следует установить значение поля cb вложенного STARTUPINFO в SizeOf(STARTUPINFOEX).
Часто ли вы при анализе, например, подозрительной активности на компьютере исходите из того, кто какой процесс запустил? О, теперь вы точно не станете так делать.
Тут есть некоторые любопытные особенности. Мне вспоминается шутливая фраза из одного мультика, звучит она примерно так: «да что там, даже при моём рождении не присутствовал ни один из моих родителей…». Как ни странно, но здесь возможно нечто подобное. Если между вызовом OpenProcess’a и самим созданием процесса назначаемый родитель будет завершён — не беда. Просто дочерний процесс будет «как бы» создан родителем после своего завершения. Почему бы и нет.
Всё бы хорошо, но этот трюк не сработает с ShellExecuteEx’ом — там всё просто: кто вызвал, тот и родитель. Однако поскольку у нас включён IFEO — финальное слово всегда остаётся за CreateProcess’ом: без него мы не выберемся из перехвата. Так что, пройдясь по цепочке процессов можно найти того, кто всё это затеял изначально, и назначить его родителем. Возможно, результат теперь не так красиво выглядит в Process Explorer’е и Process Hacker’е, зато с точки зрения чужого процесса всё будет в порядке. Ну, за исключением, разве что, «внебрачных» детей, которые появились при запуске и ожидают кода возврата перехваченного процесса. Тут уж ничего не поделать.
На картинке схема того, как я из Far.exe запускаю nsx.exe, на который назначено действие Ask.exe, и которому для запуска требуются повышенные привилегии.

Если честно, я думал, что идея с подменой родительского процесса — просто ещё одна прикольная возможность, не больше. Однако она действительно исправила несколько проблем. Так, тот же Far Manager может создавать второй процесс для выполнения более привилегированных действий, а при наличии перехвата эта функциональность ломалась. Подмена же родителя вновь починила это.
Чего делать не стоит
Я довольно долго не решался проверить это у себя на компьютере, ибо разворачивать виртуальную машину было лень: что будет, если в качестве запускаемой при перехвате программы установить её же саму? К счастью, ничего страшного. Но дальше я решил проявить благоразумие и не стал у себя на компьютере проверять гипотезы вроде «ой, а если попробовать создать цикл A → B → A…». Также, думаю, не стоит пытался устанавливать перехват важных системных процессов (я встроил их список в утилиту регистрации с подтверждением действия). Хотя, мне и любопытно, что произойдёт. Ибо всё, что я запускал от имени SYSTEM перехватывалось. Так что я добавил подавление всех диалоговых окон в нулевой сессии, ну, чтобы не зависеть в подобных случаях от сервиса UI0Detect.
И последнее: я не рекомендовал бы ставить действия на программы, создающие много однотипных процессов. Одно дело — пара дополнительных процессов, другое — целые полчища. Также не стоит трогать группы процессов, активно взаимодействующих друг с другом. И тех, что используют сложные дополнительные защитные механизмы. В общем, вы поняли: на chrome.exe лучше ничего не назначать. Если обнаружите проблемы совместимости: пишите мне или сразу в исходники на Гитхаб. В программу встроен список подобных проблем для предостережения пользователей.
Нерешённые проблемы
В Windows сосуществуют сразу несколько подсистем для исполняемых файлов. Три самых известных это Native (драйвера), Windows CUI (консольные приложения), и Windows GUI (графические приложения). Поскольку драйвера нас сейчас совершенно не интересуют — нам надо разобраться в различиях между вторым и третьим вариантом, и выбрать как компилировать наши утилиты. Вот здесь и начинаются проблемы — как мы хотим: красиво или удобно? Различия между этими подсистемами не столь велики, поскольку консольное приложение может создавать окна, а графическое — консоль. Да и то, GUI даже не всегда означает взаимодействие с пользователем: фоновые сервисы запускаются в svchost.exe, который работает в подсистеме Windows GUI.
Для нас существенным отличием являются начальные условия при запуске. За исключением особых случаев, приложения из консольной подсистемы при старте уже имеют консоль, притом видимую. Даже если первым делом при старте программы мы её спрячем, то она успеет появиться перед исчезновением. Хотим ли мы пугать неискушённого пользователя такими вещами? Наверное, нет. Я надеялся, что в исправлениях совместимости из Application Compatibility Toolkit найдётся что-то, что сможет исправить эту проблему, но, судя по всему, там нет функции «спрятать консоль по умолчанию». А потому, для себя я выбрал графическую подсистему. Всё бы хорошо, но у неё есть заметный минус. Если вы активно пользуетесь приложениями из консольной подсистемы, то сразу обратите внимание: все консольные программы, на которые назначено какое-либо стандартное действие, создают новую консоль, а не пользуются имеющейся. Это не критично, хотя и не всегда приятно. Если вам вдруг захочется сделать другой выбор в этом вопросе, а Delphi под рукой нет — просто пропатчите нужные файлы, отвечающие за стандартные действия: замените 02 на 03 по смещению 0x15C.
Заключение
Я надеюсь, что этот «экскурс в 1001 любопытный факт о работе Windows» оказался действительно любопытным и даже полезным. Я знаю, не все здесь жалуют Delphi, но уж с почти чистым WinApi, холиваров, надеюсь, не возникнет.
Код получившихся программ и бинарники доступны на Гитхабе. Программа тестировалась на Windows 7 и выше, про Windows Vista — без понятия. Ниже — однозначно нет.
P. S. Если у вас сложилось мнение, что в каком-то вопросе я основательно заблуждаюсь — не кидайтесь помидорами сразу, давайте сперва разрешим это недоразумение, и исправим неточности в статье. Спасибо.
AdwCleaner — программа для удаления тулбаров, adware и другого рекламного мусора. 8.4.0
AdwCleaner — это программа, которая ищет и удаляет Adware, тулбары, потенциально нежелательные программы (PUP) и прочий мусор с вашего компьютера. Используя AdwCleaner вы можете легко удалить многие виды этих программ, повысив удобство работы пользователей на вашем компьютере и при работе в Интернете.
Программы, которые удаляет AdwCleaner, как правило, идут в комплекте с бесплатными программами, которые вы загружаете из интернета. Во многих случаях, когда вы загружаете и устанавливаете программу, если не заметить и не снять во время установки галочку (иногда для этого надо переключиться в режим выборочной установки) на ваш компьютер будут установлены тулбары и другие рекламные модули. AdwCleaner предназначен для поиска и удаления этих программ.
После принятия соглашения появится Информационная панель с одной кнопкой Запустить проверку. Нажмите её и AdwCleaner произведёт поиск вредоносных программ, а затем отобразит все файлы, папки и записи в реестре найденные на вашем компьютере, которые используются рекламными программами.
- "Удалить ключи IFEO" : Удаляет все подразделы из ключа HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options с не нулевыми значениями отладчика.
- "Удалить ключи Tracing " : Удаляет все Tracing ключи. Включено по умолчанию.
- "Удалить файлы Prefetch" : удаляет все .pf файлы из папки C:\Windows\Prefetch
- "Сбросить настройки прокси-сервера" : Сбрасывает все настройки прокси.
- "Сбросить Winsock : Делает сброс всех настроек Winsock для устранения проблем с сетью. Включено по умолчанию.
- "Сбросить настройки TCP/IP" : Сбрасывает настройки TCP/IP: правильные настройки будут восстановлены автоматически, если сеть использует DHCP. В других случаях настройки должны быть восстановлены вручную.
- "Сбросить настройки брандмауэра" : Сбрасывает все правила файрвола Windows.
- "Сбросить IPSec" : Сбрасывает настройки IPSec. Этот протокол используется для установки зашифрованного соединения между хостами. Могут быть проблемы с подключением, вызванные специфическим вредоносным ПО.
- "Сбросить BITS" : Очистка очереди "Фоновой интеллектуальной службы передачи". Она используется для передачи файлов (программ или обновлений) между хостами, но может вызвать проблемы с соединением.
- "Сбросить политики Internet Explorer" : Удаление всех политик Internet Explorer-а и выставление значений по умолчанию.
- "Сбросить политики Chrome" : Удаление всех политик Google Chrome и выставление значений по умолчанию.
- "Сбросить файлы Hosts" : Заменяет текущий Hosts файл эталонным англ. hosts файлом (отличия от русского эталонного, только в том, что в начале файла комментарии на англ. языке).
- "Режим" : Создаёт отчёт C:\AdwCleaner\AdwCleaner_Debug.log, содержащий более подробную информацию о проделанных операциях. Это требуется, чтобы чтобы помочь разобраться если утилита прекращает работу с ошибкой.
- "База данных" : База данных на сервере может быть повреждена (либо повредиться при скачивании) и не пригодна к использованию. Эта опция помогает принудительно использовать локальную базу данных.
Для большей эффективности эти опции должны быть проверены перед выполнением других действий.
Важно также отметить, что в некоторые рекламные программы, такие как Babylon и Delta Search, входит программа, которая предупреждает вас, когда кто-то пытается изменить поиск в Вашем браузере или настройки домашней страницы. При запуске AdwCleaner сбросит настройки поиска на значения по умолчанию (на Microsoft), если обнаружит, что они были изменены рекламным ПО. Если вы видите предупреждение, что AdwCleaner пытается изменить настройки браузера, пожалуйста, позвольте ему сделать это.
Если вы не уверены, что в этой программе можно удалять, а что нет, то создайте тему в разделе Лечение компьютерных вирусов и спросите об этом. А также соберите логи по правилам раздела, заодно комплексно на вирусы проверят.
Друзья. В данной теме только обсуждение работы программы и проблем с нею. При необходимости баг-репорты будут переданы разработчику.
Не надо постить про обновления версии. При запуске программы она сама проверяет наличие новой версии и предлагает её скачать. Информация об обновлениях будет всегда доступна на странице ресурса.
Как удалить PUP.Optional.IFEO
PUP.Optional.IFEO является потенциально Нежелательная программа (пуп). Если программа malwarebytes или adwcleaner для malwarebytes анти-вредоносных программ, обнаруженных вирусом PUP.Optional.IFEO на вашем компьютере, то ваш компьютер заражен с рекламной программы. В большинстве случаев, malwarebytes способен обнаруживать Adware и удалить его для вас. Однако, если вы все еще испытываете объявлений, переадресацию или любое нежелательное домашнюю страницу в вашем браузере, вы должны проверить ваш компьютер с инструментом для удаления вредоносных программ, мы рекомендуем в этой инструкции.
Используйте средство удаления вредоносных программ Spyhunter только для целей обнаружения. Узнайте больше о SpyHunter Spyware Detection Tool и шаги для удаления SpyHunter.
Если ваша защита обнаруживает вирус PUP.Optional.IFEO, он не отмечен для удаления по умолчанию. Он определяется как вредоносный и посоветовал удалить PUP.Optional.IFEO с вашего компьютера.
Это потому, что некоторые пользователи могли установить PUP.Optional.IFEO себя. Много программного обеспечения, загруженного из интернета скачать менеджеры для распространения рекламного знают пользователи во время установки.
Шаг 1: Остановите все PUP.Optional.IFEO процессы в диспетчере задач

- Нажмите и удерживайте Ctrl + Alt + Del, чтобы открыть диспетчер задач
- Перейдите на вкладку Подробности и конец всех связанных с ними процессов PUP.Optional.IFEO (выберите процесс и нажмите кнопку завершить задачу)
Шаг 2: Удалите PUP.Optional.IFEO сопутствующие программы
- Нажмите кнопку Пуск и откройте панель управления
- Выберите удалить программу в разделе программы

- Подозрительного программного обеспечения и нажмите кнопку Удалить/изменить

Шаг 3: Удалите вредоносные PUP.Optional.IFEO записи в системе реестра
- Нажмите Win + R чтобы открыть выполнить, введите «regedit» и нажмите кнопку ОК

- Если контроль учетных записей пользователей, нажмите кнопку ОК
- Однажды в редакторе реестра, удалите все связанные записи PUP.Optional.IFEO

Шаг 4: Устранить вредоносные файлы и папки, связанные с PUP.Optional.IFEO
- Нажмите кнопку Пуск и откройте панель управления
- Нажмите Просмотр, выберите крупные значки и откройте свойства папки

- Перейдите на вкладку Вид, проверить показывать скрытые файлы, папки или драйверы и нажмите кнопку ОК

- Удалить все PUP.Optional.IFEO связанные файлы и папки
%AllUsersProfile%\random.exe
%Temp%\random.exe
%AllUsersProfile%\Application Data\random
Шаг 5: Удаление PUP.Optional.IFEO из вашего браузера
Используйте средство удаления вредоносных программ Spyhunter только для целей обнаружения. Узнайте больше о SpyHunter Spyware Detection Tool и шаги для удаления SpyHunter.
Internet Explorer
- Запуск Internet Explorer, нажмите на значок шестерни → Управление надстройками

- Выбрать раздел панели инструментов и расширения и отключите подозрительные расширения

Используйте средство удаления вредоносных программ Spyhunter только для целей обнаружения. Узнайте больше о SpyHunter Spyware Detection Tool и шаги для удаления SpyHunter.
Mozilla Firefox

- Откройте Mozilla, нажмите сочетание клавиш Ctrl + Shift + A и перейти к расширения
- Выберите и удалите все ненужные расширения
Используйте средство удаления вредоносных программ Spyhunter только для целей обнаружения. Узнайте больше о SpyHunter Spyware Detection Tool и шаги для удаления SpyHunter.
Google Chrome
- Откройте браузер, нажмите меню и выберите инструменты → расширения

- Выберите подозрительные надстройки и нажмите на значок корзины для его удаления

* SpyHunter сканера, опубликованные на этом сайте, предназначен для использования только в качестве средства обнаружения. более подробная информация о SpyHunter. Чтобы использовать функцию удаления, вам нужно будет приобрести полную версию SpyHunter. Если вы хотите удалить SpyHunter, нажмите здесь.