Подозрение на вирус

Система Windows 7 64-bit. Потерял осторожность и, по-моему, в системе вирус:

а) при поиске через Проводник на локальном диске С файла winlogon.exe Приложение определяется четыре раза, с иконками на восточный мотив.

б) обнаружены подозрительные файлы

Файл	Описание	Тип
C:\Program Files (x86)\LibreOffice 4\program\unopkg.com	Подозрение эвристического анализа	PE файл с измененным расширением, допускающим запуск (присуще вирусам)(степень опасности 35%)
C:\ProgramData\Microsoft\Windows\Power Efficiency Diagnostics\energy-trace.etl	Подозрение файлового сканера	Подозрение на Trojan.Win32.Agent2.byu ( 1BF4A4D5 1E621768 004D6E44 004D6E44 131072)
C:\Users\1\AppData\Local\Diagnostics\1612347604\2014052710.000\6A51AF10-9CA1-4811-AEB9-DB7C4AD48495.Repair.1.etl	Подозрение файлового сканера	Подозрение на Trojan.Win32.Agent2.byu ( 1BAA238B 1E621768 004D6E44 004D6E44 131072)
C:\Users\1\AppData\Local\Diagnostics\1612347604\2014052714.000\DCA5322C-5A4F-48F7-9F1F-4464BB587441.Repair.1.etl	Подозрение файлового сканера	Подозрение на Trojan.Win32.Agent2.byu ( 1BAB663E 1E621768 004D6E44 004D6E44 131072)
C:\Users\1\AppData\Local\Diagnostics\1612347604\2014052714.001\334C3613-A982-4C15-8F59-CFAC05FEB2FA.Diagnose.0.etl	Подозрение файлового сканера	Подозрение на Trojan.Win32.Agent2.byu ( 1BAC52C5 1E621768 004D6E44 004D6E44 131072)
C:\Users\1\AppData\Local\Diagnostics\1612347604\latest.cab	Подозрение файлового сканера	Подозрение на Trojan.Win32.Agent2.byu ( 1BAC52C5 1E621768 004D6E44 004D6E44 131072)
C:\Users\ЛЮБА.1-ПК\AppData\Local\Diagnostics\460911090\2014040816.000\FC902025-F2C4-467F-94AB-835694F9AC33.Diagnose.0.etl	Подозрение файлового сканера	Подозрение на Trojan.Win32.Agent2.byu ( 1BA90447 1E621768 004D6E44 004D6E44 131072)
C:\Windows\System32\LogFiles\Scm\SCM.EVM.2	Подозрение файлового сканера	Подозрение на Trojan-Downloader.Win32.AutoIt.q ( 1CDA8BC2 1E621768 004D6E44 004D6E44 491520)
C:\Windows\System32\LogFiles\Scm\SCM.EVM.3	Подозрение файлового сканера	Подозрение на Trojan-Downloader.Win32.AutoIt.q ( 1CDD316C 1E621768 004D6E44 004D6E44 491520)
C:\Windows\System32\LogFiles\Scm\SCM.EVM.4	Подозрение файлового сканера	Подозрение на Trojan-Downloader.Win32.AutoIt.q ( 1CDC5339 1E621768 004D6E44 004D6E44 491520)

Антивирус COMODO данные опасности не детектирует.

Windows system32 logfiles scm

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Hi, I’m finding on my Win7 64bit there are dozens of small logfiles being generated by SCM — It seems there’s an average of about one more created per hour — but it’s not an evenly spaced time between them. Inside them there’s hiASCII so I don’t know what data is being stored. I’m cleaning them up — but they’re continually being regenerated.

As they’re only a 1kb filesize but if I don’t clean up for a few days there’s quite a lot of them leftover in the path «C:\windows\System32\Logfiles\scm»

On a win7 32bit there’s a similar behaviour occurring.

My Vista 32bit only seems to produce a couple of them per day, but these range in size from 448k to 1.2Mb — with many system services being recorded there.

Is there some way to allow SCM to do whatever it does — but without generating all these logfiles?

If my post was helpful — give it a Vote. If it helps solve your problem — propose it as Answer. 😉

Вертим логи как хотим ― анализ журналов в системах Windows

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

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

Журналы и командная строка

До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:

Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.

Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:

Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:

Смотрим за ходом обновления Windows.

Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:

Смотрим, кто пытается пролезть на наш дедик.

При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:

Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:

Журналы системы ведутся в формате .evtx, и для работы с ними существуют отдельные командлеты. Для работы с классическими журналами («Приложение», «Система», и т.д.) используется Get-Eventlog. Этот командлет удобен, но не позволяет работать с остальными журналами приложений и служб. Для работы с любыми журналами, включая классические, существует более универсальный вариант ― Get-WinEvent. Остановимся на нем подробнее.

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

Вывод доступных журналов и информации о них.

Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:

Последние записи в журнале System.

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

Для примера получим все события из журнала System с кодом события 1 и 6013.

В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:

• 0 ― всегда записывать;
• 1 ― критический;
• 2 ― ошибка;
• 3 ― предупреждение;
• 4 ― информация;
• 5 ― подробный (Verbose).

Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:

Ошибки и предупреждения журнала System.

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

Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:

PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.

Работаем с журналами посредством запросов SQL

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:

Посмотрим на результат:

Смотрим журнал Windows Firewall.

Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManager\Operational.

Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%\test.evtx.

Данные будем получать таким запросом:

Смотрим, кто и когда подключался к нашему серверу терминалов.

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

В качестве примера посмотрим статистику количества писем по дням таким запросом:

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

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

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

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

Интерфейс Log Parser Studio.

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

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

Приходилось ли вам использовать какие-либо инструменты для перелопачивания логов? Поделитесь в комментариях.