Защита ПК! Форум.

Защита компьютера от вирусов

Партнеры

Создать форум

Кто сейчас на форуме

Сейчас посетителей на форуме: 2, из них зарегистрированных: 0, скрытых: 0 и гостей: 2

Нет


[ Посмотреть весь список ]


Больше всего посетителей (120) здесь было Ср Авг 02, 2017 2:06 pm

RSS-каналы


Yahoo! 
MSN 
AOL 
Netvibes 
Bloglines 

    о вредоносном автозапуске

    Admin
    Admin
    Admin

    Сообщения : 656
    Дата регистрации : 2010-12-25
    Возраст : 51
    Откуда : Киев

    о вредоносном автозапуске Empty о вредоносном автозапуске

    Сообщение  Admin в Чт Мар 10, 2011 1:16 pm

    Учитывая то, что мой роман, Zero Day ,
    будет опубликован через несколько недель и основой повествования в нем
    является использование вредоносного ПО террористами в качестве оружия, я
    решил опубликовать статью, которая рассказывает о борьбе с вредоносным
    ПО средставами утилит Sysinternals. Этот случай начался с того, что в
    службу поддержки Microsoft поступил звонок от клиента, работающего в
    сети большой больницы США, который сообщил о том, что они подверглись
    атаке вируса Marioforever .
    Они обнаружили этот вирус, когда их принтеры стали печатать огромные
    объемы ненужного текста, замедляя работу сети и расходуя бумагу. Их
    антивирусное программное обеспечение обнаружило на одной из машин файл с
    именем Marioforever.exe в папке %SystemRoot%, который отсылал файлы на
    печать, однако удаление этого файла не дало результата – после
    перезагрузки он появлялся вновь. Другие антивирусные программы вообще не
    смогли обнаружить этот файл. Инженер поддержки Microsoft взялся
    исследовать этот случай, начав с поиска других подозрительных файлов в
    папке %SystemRoot% одной из зараженных систем. Один из файлов,
    Nvrsma.dll, недавно открывался и, хотя он имел такое же имя, как
    компонент драйвера видеокарты Nvidia, в рассматриваемом компьютере не
    было установлено адаптера этой фирмы. Когда он попытался удалить или
    переименовать файл, он столкнулся с ошибкой совместного доступа, что
    означало, что некоторый процесс открыл этот файл и препятствовал его
    открытию другими процессами. У Sysinternals есть несколько инструментов,
    которые могут перечислить процессы, у которых есть открытые файлы или
    загруженные библиотеки DLL, в том числе Process Explorer и Handle . Тем не менее, поскольку речь шла о файле DLL, инженер выбрал утилиту Sysinternals Listdlls , которая показала, что данный DLL был загружен одним процессом, Winlogon: о вредоносном автозапуске 8117.clip_5F00_image002_5F00_thumb_5F00_7C317FB5 Winlogon
    – это системный процесс ядра, отвечающий за управление интерактивными
    сеансами входа в систему, и в данном случае он стал хранилищем
    вредоносного DLL. Следующим шагом было определение того, как данный
    DLL-файл был настроен для загрузки в Winlogon. Это должно было быть
    сделано через папку автозагрузки, так что инженер запустил утилиту Autoruns ,
    но там он не нашел никаких следов Nvrsma.dll и все элементы автозапуска
    были либо компонентами Windows, либо доверенными сторонними
    компонентами. Казалось, что это тупик. Если бы он смог понаблюдать за запуском Winlogon с помощью утилиты для работы с файловой системой и реестром, такой как Process Monitor ,
    он смог бы определить причину, почему Winlogon загружает Nvrsma.dll.
    Winlogon запускается во время процесса загрузки, так что ему нужно было
    использовать функцию Process Monitor, которая ведет журнал загрузки
    системы. Когда вы настраиваете Process Monitor для ведения журнала
    активности процесса загрузки, он устанавливает свой драйвер так, чтобы
    он загружался в самом начале и осуществлял мониторинг, записывая
    активность системы в файл с именем %SystemRoot%\Procmon.pmb. Драйвер
    прекращает запись в этот файл либо после того, как кто-то запустит
    утилиту Process Monitor, либо после выключения системы. После
    настройки Process Monitor для регистрации загрузочной активности и
    перезагрузки системы инженер запустил Process Monitor и открыл журнал
    загрузки. Он выполнил поиск строки “nvrsma” и нашел этот запрос Winlogon
    ключа реестра HKLM\Software\Microsoft\Windows
    NT\CurrentVersion\bwpInit_DLLs, который возвращал строку “nvrsma”: о вредоносном автозапуске 1680.clip_5F00_image004_5F00_thumb_5F00_7998282A Инженер
    никогда раньше не видел ключ bwpInit_DLLs, но его название было
    поразительно похоже на точку входа автозапуска, которая была ему
    известная – AppInit_DLLs. Значение AppInit_DLLs считывает главная
    библиотека для управления окнами, User32.dll, при загрузке процесса.
    User32.dll загружает любые DLL, на которые ссылается этот ключ, так что
    любой процесс Windows, у которого есть графический пользовательский
    интерфейс (в противоположность интерфейсу с командной строкой, загружает
    DLL, записанные в этом ключе. Ниже по списку операций он увидел, как
    Winlogon загрузил Nvrsma.dll: о вредоносном автозапуске 6153.clip_5F00_image006_5F00_thumb_5F00_1066D3DA Способность
    загружать DLL в каждом процессе сделала AppInit_DLLs любимой мишенью
    для авторов вредоносных программ. Фактически, это стало настолько
    большой неприятностью, что в Windows 7 политика по умолчанию требует чтобы DLL, перечисленные в данном ключе, имели цифровую подпись. В
    журнале загрузки не было никакой ссылки на AppInit_DLLs, что очевидно
    указывало на то, что вредоносный код каким-то образом принудил
    User32.dll запрашивать альтернативное расположение. Это также объясняло,
    почему эта запись не отображалась в Autoruns. Он задался вопросом,
    почему ни один другой процесс не загружал Nvrsma.dll, однако ниже в
    журнале он увидел, что попытка загрузить эту DLL другим процессом
    привела к той же ошибке совместного доступа, с которой столкнулся он: о вредоносном автозапуске 1185.clip_5F00_image008_5F00_thumb_5F00_6190F56A Простая
    загрузка DLL не заставит обработчик остаться открытым и не вызовет
    такой тип ошибки, так что он стал искать другие операции CreateFile в
    этой DLL, которым не соответствовали операции CloseFile. Последняя такая
    операция перед возникновением ошибки совместного доступа была выполнена
    Winlogon: о вредоносном автозапуске 7558.clip_5F00_image010_5F00_thumb_5F00_4C231A35 Стек
    этой операции, который он открыл, дважды кликнув на строке операции для
    открытия диалогового окна Properties и переключившись на вкладку Stack,
    показал, что файл Nvrsma.dll открыл себя сам, защищаясь тем самым от
    удаления и загрузки другими процессами: о вредоносном автозапуске 5417.clip_5F00_image012_5F00_thumb_5F00_1D0092C4 Теперь
    он должен был определить, как была атакована User32.dll. User32.dll –
    одна из доверенных системных DLL. Это означает, что поскольку для
    оптимизации производительности Windows во время загрузки создается
    отображение файлов, которое может использоваться любым процессом,
    который загружает DLL. Эти доверенные DLL перечислены в ключе реестра,
    который Autoruns вывод во вкладке KnownDLLs, так что инженер вернулся к
    Autoruns, чтобы более внимательно просмотреть результаты сканирования.
    Самый эффективный способ определить потенциальное вредоносное ПО с
    помощью Autoruns – запустить его с набором опций Verify Code Signatures,
    с помощью которых Autoruns проверяет цифровые подписи образов, которые
    он находит. После более пристального просмотра инженер обратил внимание
    на то, что User32.dll, в отличие от остальных доверенных DLL, не имел
    достоверной цифровой подписи: о вредоносном автозапуске 6740.clip_5F00_image014_5F00_thumb_5F00_5F03AFAD Поддельный
    User32.dll вел себя практически идентично настоящему User32.dll, иначе
    бы приложения с графическим пользовательским интерфейсом завершались бы с
    ошибкой, однако он запрашивал альтернативное значение в системном
    реестре. Чтобы проверить это, инженер запустил утилиту Sysinternals Sigcheck
    на измененной копии и на одной из незараженных систем, на которой
    работал тот же выпуск Windows. Сравнение результатов запуска утилиты,
    включающих в себя хэши MD5, SHA-1 и SHA-256 файла, подтвердило, что они
    различались: о вредоносном автозапуске 7357.clip_5F00_image016_5F00_thumb_5F00_7913A76A В
    качестве финальной проверки того, эти отличия были ответственны за
    различия в поведении файлов, инженер решил просмотреть код DLL. Любые
    ключи реестра и их значения, так же как и имена файлов, используемые
    исполняемым файлом, сохраняются в файле образа исполняемого файла и
    видны из утилиты для сканирования строк кода. Он попытался использовать
    утилиту Sysinsternals Strings ,
    но ошибка совместного доступа не дала Strings открыть измененный
    User32.dll, так что он обратился к Process Explorer. Когда вы открываете
    просмотр DLL для процесса и ��ткрываете свойства этой DLL, Process
    Explorer показывает печатные строки во вкладке Strings. Результат,
    который показал измененную строку APPInit_DLLs, подтвердил правильность
    этой теории: о вредоносном автозапуске 0005.clip_5F00_image018_5F00_thumb_5F00_07EAB0B8 о вредоносном автозапуске 2677.clip_5F00_image020_5F00_thumb_5F00_0846BDE0 Зная
    то, как активируются первичные DLL вредоносного кода, он принялся за
    очистку от них целевой системы. Поскольку User32.dll блокировался
    вредоносным ПО всякий раз при запуске Windows (иначе вы могли бы
    переименовать файл и заменить его, что и сделала вредоносная программа в
    данном случае), он загрузил Windows Preinstallation Environment (WinPE)
    с CD и оттуда скопировал чистый User32.dll поверх вредоносной версии.
    Затем он удалил связанные с вирусной программой файлы, которые обнаружил
    во время своего исследования. После этого он перезагрузил систему и
    проверил, очистилась ли она от вируса. Он закрыл это случай, дав
    администраторам сети больницы подробное описание шагов по очистке
    системы, которые он проделал и предоставил данное вредоносное ПО в
    команду Microsoft, занимающуюся решением проблем безопасности, чтобы они
    могли включить автоматический процесс очистки системы в Forefront и
    Malicious Software Removal Toolkit. Он нашел решение, казалось бы,
    неразрешимой задачи, используя несколько утилит Sysinternals, и помог
    больнице вернуться к нормальному режиму работы.

      Текущее время Вт Сен 29, 2020 9:42 am

      Яндекс.Метрика