как узнать имя службы windows

Управляем службами Windows с помощью PowerShell

ПОЛУЧАЕМ СТАТУС СЛУЖБЫ

Давайте начнем с того, что просто получим статус всех служб, запущенных на локальном компьютере. Используем для этого командлет Get-Service.

PowerShell, как правило, не чувствителен к регистру. Вывод приведен на скриншоте ниже.

Каждая строка представляет собой объект службы (service object).Каждый сервисный объект, как правило, имеет свои свойства. Вы можете открыть их, просто передав эти объекты в другую команду, Get-Member.

Результаты приведены на скриншоте ниже.

Параметр Typename сверху говорит о том, что за объект перед нами; в данном случае это System.ServiceProcess.ServiceController. На скриншоте также обведены свойства объекта. Это атрибуты, которые описывают этот тип объекта. Хотя большинство из них не используются при отображении по умолчанию, вы можете использовать их, если вы их знаете.
Например, нам интересно посмотреть информацию только о Windows Update. Через Get-Service получим информацию только о некоторых ее свойствах.

Как я узнал, что могу напечатать имя службы? Посмотрел с помощью Get-Service.
PS C:\> help get-service

Вы можете получить полную справочную информацию, напечатав:

Информацию о службе можно получить по ее имени или даже начальным буквам имени.

Или если вам удобнее работать с отображаемыми именами, используйте параметр –Displayname.

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

Параметр –Name можно не печатать.

ПОЛУЧАЕМ СТАТУС СЛУЖБЫ НА УДАЛЕННЫХ КОМПЬЮТЕРАХ

До этого нас интересовало получение информации о статусе служб на локальном компьютере. Однако управление службами осуществляется на удаленных компьютерах. Если посмотреть справку по Get-Service, то можно увидеть наличие у этого командлета параметра –Computername. В данном случае подключение к удаленным компьютерам осуществляется без включения функции удаленного управления PowerShell. Если вы можете управлять службами, используя инструменты командной строки (sc.exe или консоль управления Service Manager), вы можете использовать PowerShell. Давайте взглянем на пример:

Любая команда, которую я демонстрировал, можно использовать для передачи удаленному компьютеру. Даже нескольким компьютерам, если у вас есть соответствующие права на удаленном компьютере. Если вы используете PowerShell v3, то можно легко выбрать одну службу на множестве компьютеров.

Для наглядности представления отформатируем вывод.

Тот же самый результат, но в PowerShell v2.

ОСУЩЕСТВЛЯЕМ ФИЛЬТРАЦИЮ (ИСПОЛЬЗУЯ WHERE-OBJECT)

Фильтрация служб осуществляется с помощью командлета Where-Object (where – сокращение для командлета). Все, что нам нужно от PowerShell в этом случае, так это получить только те службы, у которых статус равен “stopped”.

PowerShell получает информацию обо всех службах и передает их (с помощью “|”) в следующую команду, которая осуществляет просмотр каждого объекта. Если свойство статуса объекта равно “stopped”, она остается в конвейере (pipeline), в противном случае она из него исключается. В конце выражение PowerShell отображает те объекты, которые остались в конвейере.
Результаты приведены ниже.

Теперь давайте попробуем найти одну службу на нескольких машинах. Вывод отформатируем в таблицу.

Мы даже можем комбинировать запрос отдельных служб с их фильтрацией.

Эта команда находит все службы на компьютере CHI-DC03, которые начинаются с ‘WIN’, но отображает только те, которые запущены.
Также можно сгруппировать объекты по свойству статуса (status property).

Свойство Group представляет собой коллекцию связанных служб.

Написанное выше проще понять, если взглянуть на скриншот.

Что касается меня, то я бы предпочел использовать хеш-таблицу.

Теперь каждое имя представляет собой свойство в хеш-таблице. Если у вас имеется опыт работы с PoweShell, вы, возможно, подумываете сделать сделующее:

В чем суть параметра –AsString, на мой взгляд, достаточно очевидно. Теперь работать с хеш-таблицей стало проще.

Следующей задачей на повестке дня является проверка зависимостей сервера (server dependencies).

Требуемые службы

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

Параметр –RequiredServices передаст объект в конвейер для каждой требуемой службы. Вы можете даже пойти дальше и проверить требуемые службы для работы данной службы.

Параметр –Computername командлета Get-Service возьмет вывод, но только для тех объектов, у которых есть объект свойство Computername – именно поэтому я использую хеш-таблицу с Select-Object. Как мы видим проблем со службой DNS на компьютере CHI-DC03 нет.

ЗАВИСИМЫЕ СЛУЖБЫ

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

Требуемые и зависимые службы также являются частью каждого объекта службы.

А пока Вы можете получить все зависимости для всех служб, следующая команда

Это не даст вам особо полезную информацию, поэтому я рекомендую осуществлять запрос по конкретным службам. Команда работает гораздо лучше PowerShell v3.

Результаты видны на скриншоте ниже.

Чтобы получить подобные результаты в PowerShell v2, вам придется передать имена компьютеров (computernames) в Get-Service.

В следующей статье будет рассмотрен запуск, остановка и перезапуск служб.
Конец перевода.

Источник

StavPr.ru

Блог ленивого админа

Как узнать краткое имя службы для запуска её из консоли

Недавно мне понадобилось писать скрипт, запускающий и перенастраивающий парочку служб. И возник вопрос — как называются службы в консоли. Знаю точно что Диспетчер очереди печати зовется просто spooler, а вот с остальными именами возник вопрос.

Первый и самый простой способ:

На скриншоте видно, что служба Центр обновления Windows зовется «wuauserv».

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

Таким несложным образом можно узнать имя службы и запускать её из консоли.

Стоит помнить что имя службы может отличаться от Windows NT 4.0 до Windows 2000. Например в Windows 2000, службой маршрутизации и удаленного доступа отображение называется «Маршрутизация и удаленный доступ» с коротким именем «Удаленного доступа». В Windows NT 4.0 отображаемое имя — это «Маршрутизации и удаленного доступа» с коротким именем «Маршрутизатор».

One thought on “ Как узнать краткое имя службы для запуска её из консоли ”

Вообще-то команда для этого есть. Выдаёт все имена списком.
sc query type= service

Источник

Как определить отображаемое имя службы Windows по ее «короткому» имени?

Средство просмотра событий Windows обычно регистрирует только сокращенное имя службы, но консоль служб перечисляет службы в алфавитном порядке по их полному «отображаемому имени».

Если «сокращенное имя» не очевидно из сокращенного имени службы, как мне определить, что такое служба по ее короткому имени? Очевидно, я мог бы открыть страницу свойств каждого сервиса в консоли Сервисов, но должен быть лучший способ.

6 ответов 6

Попробуйте в командной строке:

и посмотрите через это. Вы можете> перенаправить в файл, так:

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

Бонус: если у вас установлена версия grep, либо из cygwin, либо из unxutils, либо где угодно, попробуйте:

Чтобы создать хороший список, вы можете использовать

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

Если вы хотите один сервис:

Более простой и прямой путь из командной строки:

пример

Windows XP

В Windows XP это приводит к (вывод в одну строку):

[SC] GetServiceDisplayName SUCCESS Name = Автоматическое обновление

Окно 7

В Windows 7 это приводит к (вывод в две строки):

[SC] GetServiceDisplayName УСПЕХ
Имя = Центр обновления Windows

Обратите внимание, что имя консоли службы в этом случае отличается для Windows XP и Windows 7 («Автоматическое обновление» и «Центр обновления Windows»).

Источник

Как управлять службами в Powershell командлетами Service

Для управления службами в Powershell есть восемь команд с помощью которых мы можем контролировать весь процесс работы сервисов и создавать новые. Что бы увидеть весь список команд созданных в PS для работы с сервисами нужно выполнить:

Мы увидим следующие командлеты:

Учитывайте, что в виде команд делается не полное управление сервисами. Например удаление делается через WMI, которое тоже будут рассмотрены.

Навигация по посту

Получение списка служб

Узнать статус всех служб можно так:

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

Возможно вывести только имена, статус и тип запуска:

Или выведем информацию по одному сервису:

У сервисов есть короткое имя и отображаемое. Так мы выведем оба:

В именах мы можем использовать маски, а это значит что мы можем не знать полное название и использовать знак * в том месте, где не уверены в названии или написании:

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

Кроме этого есть два ключа, которые тоже поддерживают маски:

Можно сравнить разницу с прошлым примером:

У сервисов несколько статусов:

По каждому из них мы можем отфильтровать результат:

Кроме этого есть 3 типа запуска:

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

Службы могут быть зависимы от других и для проверки этих свойств есть два параметра:

Аналогично параметрам команды выше есть свойства DependentServices и ServicesDependedOn (RequiredServices). Они выводят одно и то же.

Эти свойства так же можно увидеть в GUI. В командлете ниже я использую алиас gsv (короткое имя Get-Service):

Каждая команда PS, где присутствует параметр ComuterName, может быть выполнена удаленно. Для удаленного управления в Powershell нужны дополнительные настройки, которые уже описывались в предыдущей статье.

Имена всех компьютеров, с которых мы хотим получить имена сервисов, можно указать через запятую:

Как отослать сообщение через Powershell

Остановка, перезапуск и запуск служб

Чтобы в Powershell запустить службу и остановить достаточно указать только имя. Причем можно указывать как короткое и отображаемое имя:

Можно выполнить получение, остановку и запуск в одну команду:

В запуске и остановке так же можно использовать параметры фильтрации, которые вы видели при получении статусов выше. Будьте осторожны перед выполнением так как вы можете остановить все службы:

Если с сервисом работает другой сервис, то мы не завершим его работу и нужно указать дополнительный ключ Force:

Если он не стоит появится ошибка:

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

Перезапуск сервисов работает так же со всеми параметрами:

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

Восстановление и приостановка работ служб

Не каждую службу можно приостановить (Pause) и восстанавливть. Что бы увидеть все службы, у которых есть такая возможность, выполните:

Командой ниже мы получи, нажмем паузу и восстановим работу сервиса Winmgmt:

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

В этих командах так же можно использовать параметры Include и Exclude, с масками.

На скрипте ниже показана проверка возможности приостановки сервиса, если у него есть такая возможность. Если ее нет, то сервис остановит свою работу:

Изменение с Set-Service

Командлетом ниже я изменил тип запуска сервиса с отключенного на автоматический:

В случае изменения сервисов нельзя использовать маски *.

В документации Microsoft говориться про возможность изменения на четыре режима со следующими названиями:

Во первых половина называется иначе и изменение не срабатывает. Возможно изменение не срабатывает из-за багов Windows Server 2019,может из-за зависимостей (в GUI все работает), но скорее всего дело в PS. При работе с WMI все срабатывает. Реальные варианты запуска такие:

Через эту команду можно так же выполнить запуск и остановку:

Все возможные значения:

Можно изменить описание сервиса:

Команды изменения можно выполнять удаленно:

Создание сервисов с New-Service

В PS 5.1 не предусмотрена команда удаления, она появилась в версии 6.1, которая устанавливается отдельно и может работать иначе. Для удаления сервисов, а так же частичного изменения, используется WMI. Указывайте все возможные параметры, что бы в последующем не лезть в WMI.

Параметры, которые в последующем нельзя будет изменить через PS:

Кроме этого есть параметры, которые возможно изменить через команды выше:

Получение с помощью WMI класса

За работу со службами в WMI отвечает класс win32_service. Преимущества такого подхода в том, что тут можно посмотреть и изменить все детали работы сервисов. Более подробно WMI в Powershell мы уже рассматривали.

Что бы получить список аналогичный Get-Service выполните:

В классе WMI можно увидеть больше свойств, которые можно использовать:

Одно из преимуществ использования в WMI это то, что мы можем увидеть идентификатор процесса под которым работает сервис. Если сервис остановлен, то его идентификатор 0. Так мы увидим идентификатор процесса с именем WinRM и получим всю информацию по процессу:

О том как работать с процессами в Powershell мы писали в прошлой статье.

С помощью WMI мы можем вернуть имя аккаунта, под которым запущена служба и ее описание. Используя параметр ComputerName это можно сделать удаленно на множестве компьютеров:

Изменение с помощью WMI класса

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

Удалим сервис, который создавался через New-Service:

Для изменения паролей нужно использовать следующую конструкцию. После выполнения команды сервис нужно перезапустить:

Источник

Руководство по инструментарию управления Windows (WMI): основные сведения о WMI-атаках

Инструментарий управления Windows (WMI) — это подсистема PowerShell, которая обеспечивает администраторам доступ к мощным инструментам системного мониторинга. Этот инструментарий задумывался как быстрое и эффективное средство системного администрирования, однако далеко не все используют его с благими целями: с его помощью злоумышленники-инсайдеры могут шпионить за другими сотрудниками. Знание этой уязвимости WMI ощутимым образом упрощает обнаружение внутренних угроз и борьбу с ними.
В этой статье мы рассмотрим, что такое инструментарий WMI, для чего он нужен и как его можно использовать для отслеживания инсайдерской деятельности в системе. Мы также составили более подробное руководство, посвященное событиям WMI и инсайдерскому шпионажу, которое вы можете скачать бесплатно.

Краткий обзор: что такое WMI и для чего он нужен?

Приведем конкретный пример. С помощью WMI вы можете запросить, например, все большие файлы Excel, находящиеся в том или ином каталоге, а затем получать уведомление каждый раз при создании файла с заданным размером, например 1 Мб. Командлет Register-WmiEvent позволяет сделать все это с помощью одной не слишком сложной строки в PowerShell.

В хороших руках WMI может послужить многим благим целям, но точно так же он может стать инструментом вредоносной инсайдерской деятельности. Можно легко представить, как некий сотрудник с повадками Эдварда Сноудена использует WMI, чтобы шпионить за своими коллегами. Для этого ему даже не понадобятся особые технические знания.

Предположим, наш гипотетический инсайдер «случайно» подсмотрел, что его коллега Лекс периодически скачивает большие файлы Excel, содержащие номера социального страхования и другие личные данные клиентов. В этом случае наш незаметный инсайдер может соорудить нечто подобное:

Этот код запрашивает объект CIM_DataFile для получения доступа к информации о создании файла Excel в указанном каталоге, а затем запускает выполнение блока сценария. Ближе к концу этой статьи мы рассмотрим подробнее, как может выглядеть этот блок сценария в случае с нашим гипотетическим инсайдером.

Для чего используется инструментарий управления Windows

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

Архитектура инструментария управления Windows

Инструментарий WMI является частью операционной системы Windows, и он предварительно установлен на всех операционных системах, начиная с Windows 2000. WMI состоит из следующих компонентов:

Выполнение запросов WMI

Самым простым способом выполнения запроса WMI является запуск WMIC в стандартной командной строке Windows. Выполните следующие действия, чтобы получить информацию о процессоре, используемом на локальном компьютере:

Практикум по использованию событий WMI для наблюдения за системой

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

Использование функциональности wmiexec из Impacket

В WMI можно выполнять разные функции, помимо управления событиями. В нем можно запускать процессы и выполнять команды в окнах Windows как на локальных, так и на удаленных компьютерах. Ради интереса попробуйте ввести команду wmic process call create ‘notepad.exe’ в сеансе PowerShell, чтобы открыть старый текстовый редактор Microsoft. При этом используется замечательный инструмент командной строки wmic, входящий в состав WMI. Здорово, правда?

Если бы я добавил параметр /Node:, а затем имя удаленного компьютера Windows, то смог бы запустить Блокнот на нем, при условии что у меня есть соответствующие разрешения. Совершенно ясно, что на практическом уровне wmic является незаменимым помощником для системных администраторов.

Прежде чем вы начнете возмущаться: я знаю, что существуют эквивалентные командлеты PowerShell. Однако я считаю, что синтаксис wmic легче запомнить.
Было бы здорово, если бы я мог с помощью WMI создать простую и незаметную псевдооболочку.

Скрытая псевдооболочка, созданная с помощью wmiexec

К моему везению, это можно сделать в Impacket. В тестовой среде Amazon я использовал свой любимый wmiexec для доступа к WMI через виртуальную машину Linux. В wmiexec предусмотрена возможность создания псевдооболочки: каждый раз, когда на стороне клиента вводится команда, на целевом компьютере создается отдельная оболочка для выполнения этой команды.
И в psexec, и в smbexec для запуска команд в удаленной системе используются службы Windows. Работа smbexec протекает незаметнее, так как он быстро создает, а затем удаляет службу, а psexec, наоборот, оставляет ее на виду.

Инструмент wmiexec напрямую запускает cmd.exe для удаленного выполнения команды. Созданную команду можно найти в средстве просмотра событий. Обратите внимание, что мы избежали привлекающих внимание служб Windows

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

Использование событий WMI для наблюдения за пользователями

Пока я тешил себя мыслью, что я один такой умный и занимаюсь экспериментами с WMI, оказалось, что ребята, занимающиеся тестами на проникновение, уже давно поняли, как все работает. Вам обязательно нужно прочитать потрясающую презентацию Мэтта Грэбера (Matt Graeber) с конференции Black Hat 2015 года, где он рассказывает, как злоумышленники могут превратить WMI и весь его арсенал для работы с событиями в инструмент для взломов.

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

Помимо файловых объектов, есть еще один интересный класс объектов, который можно изучить с помощью WMI, — win32_LogOnSession. Запрос этого базового объекта Windows позволяет найти пользователей, которые в данный момент находятся в системе. Затем можно использовать блок сценария действий Register-WmiEvent для запуска сценария PowerShell при удаленном входе нового пользователя в систему. Уловили суть? Злоумышленник может получать уведомления каждый раз, когда пользователь, за которым он следит, входит в целевую систему.

Вот что я набросал:

Следующий вопрос — как запрограммировать выполнение блока сценария. Загадочного инсайдера из моих фантазий интересует конкретный пользователь — Круэлла. Наш злодей потихоньку шпионил за Круэллой и теперь планирует использовать собранную информацию, чтобы взломать ее рабочую учетную запись.

Задача блока сценария — проверить, кто вошел в систему, и определить, была ли это Круэлла. Я написал несколько строк кода PowerShell для этой цели, но это явно не самый лучший способ. Я никак не использую информацию о событии, передаваемую в блок сценария, а именно сведения о новом пользователе. Я наталкиваюсь на препятствия, причины которых я не могу понять в данный момент. Для этого нужно больше технических знаний, чем наш гипотетический инсайдер имеет или готов приобрести.

Вместо этого я просто перебрал список пользователей, возвращаемых gwmi Win32_Process (попробуйте запустить этот командлет в сеансе PowerShell), и сопоставил их с параметром «Круэлла». Можете полюбоваться на мое финальное решение:

Register-WmiEvent позволяет сохранять скрытность, поскольку он запускается только при новом входе в систему, вместо того чтобы регулярно запрашивать объект Win32_Process, что может быть довольно заметным.

Помните, что наш инсайдер старается не привлекать к себе внимания. У нее есть доступ к удаленной системе через psexec, smbexec или wmiexec (самый незаметный способ). Однако ей не нужно постоянно бродить туда-сюда по системе жертвы.

В этом и прелесть использования событий WMI. Вы можете дождаться уведомления от Register-WmiEvent, а затем спокойно сделать свой ход.

Интеграция Netcat и WMI

Но каким образом сценарий возвращает горячую новость о том, что Круэлла вошла в систему на целевом компьютере?

Если вы заметили, что я использовал команды Netcat выше, можете поставить себе плюсик. Netcat — известная и универсальная утилита, позволяющая устанавливать соединения (необязательно для вредоносного ПО). С помощью нее можно выполнять обратное подключение или просто передавать сообщения по сети. Я воспользовался этой второй возможностью.

Приведенный выше сценарий отправляет сообщение Netcat в режиме ожидания и отображает надпись «Круэлла вошла в систему». Миссия выполнена.

Вы можете представить себе, как наш мошенник затем сбрасывает хеши с помощью инструмента secretsdump Impacket, взламывает хеш учетных данных Круэллы, после чего запускает wmiexec, используя разрешения Круэллы, для поиска более ценных данных.

Код Register-WmiEvent можно запустить напрямую. Обратите внимание на отображаемый идентификатор события

Устранение недочетов в механизме наблюдения WMI

В рамках этого примера я хотел удаленно запустить (используя wmiexec) полезную программу, которая будет предупреждать меня, когда конкретный пользователь, то есть Круэлла, входит в систему. После этого я мог спокойно сбросить и взломать ее учетные данные. Это был бы самый незаметный способ — удаленный доступ и никаких файлов. Единственная проблема, как мне поначалу казалось, заключалась во временном характере событий WMI.

Поэтому мне нужно было заключить мое непристойно длинное Register-WMIEvent (ниже) в командную строку PowerShell с параметром –noexit, обеспечивающим сохранение сеанса PowerShell после выполнения Register-Event, а значит, и сохранение события.

Она выглядела многообещающе и, казалось, работала правильно, если верить журналу событий Windows в целевой системе. Однако, присмотревшись, я понял, что она не работает. Я уверен, что в итоге смог бы привести ее в нужный вид, но для этого мне потребовалось бы время и кофе, много кофе. Есть и другой вариант, чуть менее незаметный и совсем не бесфайловый: можно использовать smbclient для переноса сценария, а затем запустить его напрямую на целевом компьютере.

Удаленное выполнение сложного командлета Register-Event казалось мне абсолютно правильным. Но оно не работало. Ну и ладно

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

Почему при наблюдении нужно использовать постоянные события?

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

Соглашусь, что для обычного сотрудника, который вдруг решил стать злобным хакером, это выглядит слишком круто. Ради интереса я почитал разные форумы и увидел, что многие люди безуспешно бьются над тем, чтобы заставить постоянные события WMI работать. Однако это вовсе не выходит за рамки возможностей нашего «Сноудена» и других сообразительных системных администраторов, которые решили перейти на темную сторону.

Постоянные события: советы для ИТ-администраторов

Эти методы не предназначены для обучения потенциальных хакеров или обиженных сотрудников, которые хотят отомстить работодателю. Все, чего я хочу, — это помочь ИТ-специалистам понять образ мысли хакера, чтобы они могли внедрить соответствующую защиту от атак на проникновение. Для них я показываю, как настроить фильтр и объекты потребителя с помощью командлета Set-WmiInstance:

Ваше домашнее задание — придумать код PowerShell, который свяжет эти два компонента воедино.

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

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

Например, код PowerShell для потребителя события может выступать как средство запуска и скачивать вредоносное ПО, хранящееся на удаленном сервере, с помощью DownloadString. Великолепная презентация Мэтта Грэбера на конференции Black Hat содержит много информации о вредоносном потенциале постоянных событий WMI.

Если вы специалист по безопасности, то как вы будете работать с событиями WMI с точки зрения их потенциального вредоносного использования?

Удача на вашей стороне: с помощью командлета Get-WmiObject (псевдоним gwmi) можно создать список фильтров событий, потребителей и связывающих объектов:

Вы перечисляете постоянные события WMI с помощью Get-WMIObject и устанавливаете соответствующие параметры. Обратите внимание на отсутствие отметки о времени создания.

Теперь, если фильтр (или потребитель) постоянного события покажется им подозрительным, ИТ-специалисты могут отключить его путем удаления с помощью конвейера PowerShell и командлета WMI-RemoveObject:

Удаление постоянных событий WMI включает использование конвейера PowerShell

Обратите внимание, что здесь не указано ни время создания события, ни имя злонамеренного пользователя. Для получения этой криминалистической информации потребуется обратиться к журналам событий Windows. Подробнее об этом ниже.

Можно ли отключить постоянные события WMI?

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

Можно попробовать отключить службу Winmgmt, которая запускает WMI. На практике это не так уж просто. В ходе моих собственных тестов я так и не смог отключить эту службу: она автоматически запускалась снова и снова.

Предположим, что вам все же удалось отключить ее. Административное программное обеспечение Windows во многом зависит от WMI и не будет работать, если Winmgmt недоступна. По всему Интернету форумы наполнены сообщениями, предостерегающими от отключения WMI. Советую к ним прислушаться и помиловать ваш WMI.

Выявление событий WMI, представляющих угрозу, с помощью Sysmon и SIEM

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

Знакомьтесь, Sysmon! Я не буду вдаваться в подробности, рассказывая об этой бесплатной утилите Windows, которую можно загрузить здесь, в этой статье. Скажу лишь, что она позволяет получать очень полезную информацию для анализа в одном месте, вместо того чтобы просматривать каждый журнал событий Windows по отдельности. Пользователям Windows 7 и более поздних версий возможности Sysmon могут не понадобиться, поскольку в новых системах Windows используются более совершенные механизмы ведения стандартных журналов.

Sysmon — удобная и понятная утилита для регистрации событий от Microsoft

Вы не хотите открывать средство просмотра событий вручную, чтобы отслеживать постоянные события WMI, которые могут быть признаком хакерской активности. Мы знаем, как вам помочь.
Почему бы не создать фильтр постоянных событий WMI для мониторинга создания (догадались?) постоянного события WMI?

На GitHub есть небольшой проект, где вы найдете код для настройки этой операции. Вот фрагмент кода для фильтра событий WMI, который позволяет отслеживать создание… да-да, фильтра событий WMI:

Очевидно, что здесь нам понадобится помощь средств по управлению информационной безопасностью и событиями безопасности (SIEM), поскольку улики погребены в завалах журналов. Я думаю, вы понимаете, к чему все идет. Вам понадобится решение для мониторинга безопасности, объединяющее функции SIEM с анализом других угроз для обнаружения и устранения угроз, связанных с постоянными событиями WMI.

Часто задаваемые вопросы об инструментарии управления Windows

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

WMI объявлен устаревшим?

Сам WMI не устарел, но была объявлена устаревшей WMIC, что вводит многих людей в заблуждение. Для доступа к функциям, ранее обеспечиваемым WMIC, теперь используется PowerShell.

Какие порты использует WMI?

WMI использует TCP-порт 135 и ряд динамических портов: 49152-65535 (динамические порты RPC: Windows Vista, 2008 и выше), TCP 1024-65535 (динамические порты RPC: Windows NT4, Windows 2000, Windows 2003). Вы также можете настроить для WMI пользовательский диапазон портов.

WMI использует WimRM?

Данная конфигурация не является стандартной, однако вы можете использовать WMI для получения данных с помощью сценариев или приложений, использующих WinRM Scripting API, или с помощью инструмента командной строки Winrm. WinRM может использовать WMI для сбора данных о ресурсах или для управления ресурсами в операционной системе Windows.

Заключение

Как мы увидели, WMI предоставляет администраторам мощный инструмент для мониторинга удаленных процессов и компьютеров и может использоваться при разработке соглашений о мониторинге конечных пользователей (EUMA) для автоматического оповещения о подозрительной активности. Это делает его отличным инструментом для обнаружения и устранения внутренних угроз, предотвращения попыток обойти политики безопасности, а также наблюдения за тем, как используются ваши системы.

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

Источник