Глава 3. Исследование целей с помощью сценариев PowerShell
Содержание
Эта глава выйдет за пределы команд в одну строку и конвейеров чтобы создавать реальные сценарии PowerShell. Сценарии PowerShell предоставляют возможность автоматизации повторяющихся заданий, которые требуют особых CmdLet, Конвейеров, Переменных,Структур и тому подобного. Иным простым способом описания сценариев PowerShell является то, что они позволяют вам создавать новые и более мощные и целенаправленные CmdLet для решения особых проблем. Раз уж вы разработали некую команду, которая делает в точности то что вам требуется, будет достаточно полезным создать некий сценарий, который заключает в себя или абстрагирует имеющуюся в данной команде сложность.
В этой главе мы ознакомимся с двумя примерами. Один будет состоять в создании некого специфического и в конечном счёте полезного сценария расследования, который будет получать и обрабатывать журналы системных событий. Второй пример будет сценарием, в котором мы изучаем применение устройств USB.
Прежде чем мы начнём, вот основные факты относительно сценариев PowerShell:
-
Сценарии это просто текстовый файл, который содержит последовательности команд PowerShell.
-
Для предотвращения злонамеренных сценариев PowerShell принуждает к некой политике исполнения, которая по умолчанию установлена в "restricted" (ограниченную), такую, при которой сценарии PowerShell НЕ будут исполняться по умолчанию. Таким образом, вам следует настраивать значение политики для разрешения исполнения вашего сценария.
-
Для выполнения некого сценария PowerShell вы либо должны исполнять его из ISE PowerShell и предоставлять полный путь к исполняемому сценарию, либо содержащий этот сценарий каталог должен содержаться в вашем пути (path) Windows.
Получение данных из журналов событий является обычной практикой в ходе криминалистических расследований и действий по реагированию на происшествия. Это также полезное занятие для системных администраторов для повседневного исполнения.
Сбор существенных данных из файлов журналов, которые, скорее всего, распределены по всей среде изысканий, может занимать много времени, а если оно не будет сделано последовательно и в полном объёме, это приведёт к проблемам. Следовательно разработка целевого сценария PowerShell для выполнения этой операции принесёт значительную пользу исследователям.
Естественно, PowerShell уже содержит CmdlLet общего назначения , которые предназначены для основного сбора данных из журналов событий; такими образом, первым шагом является идентификация и выбор одного из доступных CmdLet. Для того чтобы сделать это давайте вернёмся снова к встроенной справочной системе PowerShell. Запрос подсказки с применением ключевого слова EventLog возвращает перечень CmdLet, отображённых на Рисунке 3-1.
После просмотра полученного конспекта, кажется что Get-EventLog будет подходящим целевым CmdLet для получения событий из журналов событий.
Рисунок 3-2 отображает основную справочную информацию и подсказку о применении, связанные с таким CmdLet Get-EventLog.
Рисунок 3-3
отображает различные примеры применения. Каждый из них указывает различные файлы журналов и запросы самых новых 20 событий.
Отметим, что если запрашивается журнал событий security (безопасности),
вам следует иметь полномочия администратора для доступа к нему.
Рисунок 3-4 отображает результаты после исполнения Get-EventLog.
Get-EventLog -logName system -Newest 20
На основании изучения нами в Главе 2 того, что относится к конвейеризации PowerShell, мы можем осуществить более конкретное или более направленное получение данных журнала событий. Например, что если мы желаем видеть лишь события с типом error или warning и выполнять фильтрацию всех общих информационных событий?
Принимая во внимание выдержку из своего результата Get-Help Get-EventLog, показанную на Рисунке 3-5, перечислим возможные EntryTypes:
-
Error
-
Information
-
FailureAudit
-
SuccessAudit
-
Warning
Основываясь на этом, можно создать более точную команду, которая будет выделять в точности только события warning или error изадать особые свойства, связанные с подлежащим отображению журналом событий.
Get-Eventlog -LogName system -Newest 20 | Select-Object -Property TimeGenerated, Source, EntryType, Message | where {$_.EntryType -eq "warning" -or $_.EntryType -eq "error"}
Эта команда приносит результат, отображённый на Рисунке 3-6.
Основываясь на таком базовом понимании Get-EventLog, давайте определим некое задание для решения.
Первый этап: Постановка задачи
Прежде чем вы напишите свой сценарий, рассмотрим что составляет основные проблемы, с которыми сталкиваются исследователи при выборке из журналов событий и как можно разработать некий сценарий PowerShell, разрешающий эти вызовы. Спросите себя:
-
Какие журналы событий следует собирать? Основываясь на изысканиях, какие конкретно журналы стобытий требуется опрашивать?
-
С какого компьютера или компьютеров следует собирать имеющиеся файлы журналов?
-
Сколько самых последних записей следует собирать?
-
Будет ли полезной некая необязательная фильтрация на основе
EventType? -
Какие конкретно поля следует вырабатывать из определённого журнала событий?
-
Применяя Get-Member мы можем увидеть все представляюш=щие интерес общие свойства: Category, EntryType, EventID, MachineName, Message, Source, TimeGenerated, TimeWritten и UserName.
-
-
Куда следует вырабатывать получаемый вывод, то есть, назначение стандартного вывода в некий файл?
-
Как будут применять этот сценарий прочие пользователи?
-
Следует ли нам предоставлять подсказку?
-
Как они будут вводить знаения параметров?
-
После того как вы сформулировали вопросы и способны ответить на них, вы теперь должны проработать определения своего сценария можете переходить к этапу два.
Второй этап: Пошаговая разработка сценария
Основываясь на том определении, которе создано на Этапе 1, вот конкретные параметры, необходимые для определения в нашем сценарии:
-
TargetLog
-
TargetComputer
-
TargetCount
-
TargetEntryType
-
ReportTitle
Листинг 3-1 показывает наш сценарий EventProcessor целиком. Я также показываю результаты Get-Help, сам пример исполнения и полученный отчёт о результатах после всего.
Листинг 3-1. Сценарий EventProcessor
<#
.synopsis
EventProcessor EventLog Capture Automation Version 1.0
- Пользователь задаёт целевой EventLog
- Пользователь задаёт значение числа новейших записей Журнала для отчёта
- Пользователь задаёт значение Entry Type для цели, например, warning, error, information и т.д.
- Пользователь задаёт целевой компьютер или компьютеры для выделения журналов
- Пользователь задаёт the HTML Report Title
Этот сценарий произведёт некий файл вывода HTML, содержащий подробности всех полученных EventLog.
.Description
Этот сценарий автоматизирует процесс выделения информации из предписанных файлов журналов
.parameter targetLogName
Определяет название подлежащего обработке файла журнала
.parameter eventCount
Определяет значение максимального числа новейших событий для рассмотрения в поиске
.parameter eventType
Определите представляющий интерес eventType
.parameter targetComputer
Задайте компьютер или компьютеры для получения с них журналов
.parameter reportTitle
Определите заголовок отчёта HTML
.example
EventProcessor
Исполнение EventProcessor без параметров применяет установленные по умолчанию настройки:
eventLog system
eventType warning
eventCount 20
targetComputer тот компьютер, который исполняет данный сценарий
.example
EventProcessor -targetLogName security
Данный пример определяет значением цели eventLog security и применяет значения параметров по умолчанию
eventType warning
eventCount 20
targetComputer тот компьютер, который исполняет данный сценарий
.example
EventProcessor -reporTitle "Ежедневный отчёт журналов событий ACME Computer"
Данный пример предоставляет индивидуальный заголовок отчёта
.example
EventProcessor -targetLogName security -eventCount 20 -entryType warning -targetComputer Python-3
Этот пример определяет все необходимые параметры, targetLogName, eventCount, entryType и targetComputer
#>
# Раздел определения параметров
param(
[string]$targetLogName = "system",
[int]$eventCount = 20,
[string]$eventType="Error",
[string]$reportTitle="Event Log Daily Report",
[string[]]$targetComputer=$env:COMPUTERNAME
)
# Получение текущих даты и времени
$rptDate=Get-Date
$epoch=([DateTimeOffset]$rptDate).ToUnixTimeSeconds()
# Создание раздела заголовка HTML
$Header = @"
<style>
TABLE {border-width: 1px; border-style: solid; border-color: black; border-collapse: collapse;}
TD {border-width: 1px; padding: 3px; border-style: solid; border-color: black;}
</style>
<p>
<b> $reportTitle $rptDate </b>
<p>
Выбор Event Log: <b>$targetLogName </b>
<p>
Выбор целевого компьютера (компьютеров): <b> $targetComputer </b>
<p>
Фильтр типа событий: <b> $eventType </b>
<p>
"@
# Создание отчёта Filename
$ReportFile = ".\Report-"+$epoch+".HTML"
# исполнение CmdLet Pipeline
Get-Eventlog -ComputerName $targetComputer -LogName $targetLogName -Newest $eventCount -EntryType $eventType |
ConvertTo-HTML -Head $Header -Property TimeGenerated, EntryType, Message |
Out-File $ReportFile
Наш сценарий EventProcessor подразделяется на четыре основных раздела. Для своей завершённости наша разработка сценариев PowerShell должна содержать каждый из этих четырёх разделов.
-
Заголовок сценария (в том числе Подсказку и примеры)
-
Определение параметров
-
Определение локальных переменных
-
Исполнение CmdLet с применением параметров и локальных переменных
Давайте поглубже рассмотрим саму конструкцию сценария.
![[Замечание]](/common/images/admon/note.png) | Замечание |
|---|---|
|
Вы можете применять данный пример в качестве основного образца, так как он производит хорошие стандартные условия для некого сценария PowerShell. |
Заголовок сценария
Данный заголовок сценария содержит ключевую информацию, используемую для определения самого сценария и приведения в соответствие к некому строгому формату для предоставления подробностей подсказки при обработке соответствующим CmdLet Get-Help.
Раздел .Synopsis
Этот раздел .synopsis предоставляет быстрый обзор основной цели данного сценария и того что ожидает от него пользователь (Листинг 3-2).
Листинг 3-2. Раздел .Synopsis
<#
.synopsis
EventProcessor EventLog Capture Automation Version 1.0
- Пользователь задаёт целевой EventLog
- Пользователь задаёт значение числа новейших записей Журнала для отчёта
- Пользователь задаёт значение Entry Type для цели, например, warning, error, information и т.д.
- Пользователь задаёт целевой компьютер или компьютеры для выделения журналов
- Пользователь задаёт the HTML Report Title
Этот сценарий произведёт некий файл вывода HTML, содержащий подробности всех полученных EventLog.
Раздел .Description
Имеющийся раздел .description предоставляет некое сжатое определение своего сценария (Листинг 3-3).
Листинг 3-3. Раздел .Description
.Description
Этот сценарий автоматизирует процесс выделения информации из предписанных файлов журналов
Раздел .Parameters
Данный раздел подробно определяет все параметры командной строки, используемые нашим сценарием (Листинг 3-4).
Листинг 3-4. Раздел .Parameters
.parameter targetLogName
Определяет название подлежащего обработке файла журнала
.parameter eventCount
Определяет значение максимального числа новейших событий для рассмотрения в поиске
.parameter eventType
Определите представляющий интерес eventType
.parameter targetComputer
Задайте компьютер или компьютеры для получения с них журналов
.parameter reportTitle
Определите заголовок отчёта HTML
Отметим, что в данном сценарии все параметры не обязательные, так как согласно определению, как это вы обнаружите позднее, для каждого из параметров предоставляются установленными по умолчанию значения. Это делает возможным для пользователя исполнение данного сценария простым набором:
.\EventProcessor
Раздел .Examples
В этом разделе предоставляются некоторые простые образцы выполнения сценария в командной строке совместно с неким определением того что предоставляет каждый из вариантов (Листинг 3-5).
Листинг 3-5. Раздел .Examples
.example
EventProcessor
Исполнение EventProcessor без параметров применяет установленные по умолчанию настройки:
eventLog system
eventType warning
eventCount 20
targetComputer тот компьютер, который исполняет данный сценарий
.example
EventProcessor -targetLogName security
Данный пример определяет значением цели eventLog security
и применяет значения параметров по умолчанию
eventType warning
eventCount 20
targetComputer тот компьютер, который исполняет данный сценарий
.example
EventProcessor -reporTitle "Ежедневный отчёт журналов событий ACME Computer"
Данный пример предоставляет индивидуальный заголовок отчёта
.example
EventProcessor -targetLogName security -eventCount 20 -entryType warning -targetComputer Python-3
Этот пример определяет все необходимые параметры, targetLogName, eventCount, entryType и targetComputer
#>
Определение параметров
Данный раздел определения параметров нашего сценария определяет подробности каждого из доступных параметров для данного сценария (Листинг 3-6).
Листинг 3-6. Раздел определения параметров
# Раздел определения параметров
param(
[string]$targetLogName = "system",
[int]$eventCount = 20,
[string]$eventType="Error",
[string]$reportTitle="Event Log Daily Report",
[string[]]$targetComputer=$env:COMPUTERNAME
)
Каждый параметр имеет некие тип, название и назначаемое по усолчанию значение. Например:
-
Значением параметра $reportTitle является тип string и он имеет устанавливаемым по умолчанию значение "Event Log Daily Report".
-
Значением параметра $targetComputer также является тип string, однако возможно некое множество значений. Иными словами, определённый пользователь может вводить множество названий компьютеров, причём каждый из них отделяется запятой. Он также содержит устанавливаемое по умолчанию значение. А именно: это автоматическая переменная PowerShell, которая определяет название того компьютера, на котором исполняется данный сценарий.
-
Значение параметра $targetLogName определяет тот журнал событий, который будет выступать в качестве целевого. Отметим, что так же как и в случае с $targetComputer, он может быть определён с неким перечнем названий журналов. Однако наш стандартный CmdLet Get-EventLog поддерживает лишь единственный целевой журнал. Для поддержки списка наш CmdLet Get-EventLog следует исполнять множество раз, по одному для каждого из указанных журналов. Это сделало бы наш сценарий слегка более сложным, но потенциально даже более полезным.
-
Значение параметра $EventType позволяет определять какой именно тип событий должен содержать наш отчёт. Иными словами, фильтруя лишь желательные типы событий.
-
Наконец, значение параметра $eventCount определяется как некое целое значение. Оно определяет максимальное число записей журнала для отображения, которое соответствует задаваемому критерию.
Определение локальных переменных
Этот раздел локальных переменных служит для создания нескольких локальных переменных, необходимых для данного сценария (Листинг 3-7)
Листинг 3-7. Раздел определения локальных переменных
# Получение текущих даты и времени
$rptDate=Get-Date
$epoch=([DateTimeOffset]$rptDate).ToUnixTimeSeconds()
# Создание раздела заголовка HTML
$Header = @"
<style>
TABLE {border-width: 1px; border-style: solid; border-color: black; border-collapse: collapse;}
TD {border-width: 1px; padding: 3px; border-style: solid; border-color: black;}
</style>
<p>
<b> $reportTitle $rptDate </b>
<p>
Выбор Event Log: <b>$targetLogName </b>
<p>
Выбор целевого компьютера (компьютеров): <b> $targetComputer </b>
<p>
Фильтр типа событий: <b> $eventType </b>
<p>
"@
# Создание отчёта Filename
$ReportFile = ".\Report-"+$epoch+".HTML"
Нашими локальными переменными являются:
-
$ReportDate: Получает значение текущей системной даты, которое следует использовать в окончательном отчёте.
-
$epoch: Получает значение числа секунд, которые прошли начиная с текущей эпохи. Отметим что оно отличается для каждой операционной системы. Данная переменная будет применяться для создания некого уникального названия файла HTML.
-
$Header: Определяет некий стандартный раздел заголовка HTML для его применения при выработке получаемого в результате файла HTML. Заметим, что эта переменная использует значение параметра ReportTitle для индивидуализации самого заголовка отчёта.
-
$ReportFile: Данная переменная объединяет значение строки "Report-" со значением эпохи и значением расширения ".html".
Выполнение конвейера CmdLet
Сердцевину нашего сценария составляет собственно исполнение CmdLet Get-EventLog с применением конвейера для включения предписанных параметров (Листинг 3-8).
Листинг 3-8. Выполнение конвейера CmdLet
# исполнение CmdLet Pipeline
Get-Eventlog -ComputerName $targetComputer -LogName $targetLogName -Newest $eventCount -EntryType $eventType |
ConvertTo-HTML -Head $Header -Property TimeGenerated, EntryType, Message |
Out-File $ReportFile
Данный конвейер имеет орпеделённые ключевые компоненты и переходы:
-
Сам CmdLet Get-EventLog задаёт -ComputerName, -LogName, -Newest и -EntryType с помощью значений параметров $targetComputer, $targetLogName, $eventCount и $eventType.
-
Вывод данного CmdLet Get-EventLog направляется конвейером в CmdLet ConvertTo-html, который применяет значение локальной переменной $Header и те свойства, которые передаются из CmdLet Get-EventLog: TimeGenerated, EntryType и Message для формирования значений колонок в получаемом отчёте HTML.
-
Наконец, получаемый от ConvertTo-html вывод отправляется конвейером в CmdLet Out-File , который применяет значение локальной переменной $ReportFile в качестве того имени файла, в который и записываются результаты.
Так как данный сценарий содержит раздел подробностей заголовка, имеется возможность воспользоваться CmdLet Get-Help для предоставления справки тем, кто будет применять наш только что созданный сценарий. Приводимый далее пример предоставляет получаемый от CmdLet Get-Help вывод с применением параметра -Full, который предоставляет все подробности и примеры (Листинг 3-9).
Листинг 3-9. Get-Help EventProcessor
PS C:\PS> Get-Help .\EventProcessor.ps1 -Full
NAME
C:\PS\EventProcessor.ps1
SYNOPSIS
EventLog Automation Version 1.0
Step One
- Пользователь задаёт целевой EventLog
- Пользователь задаёт значение числа новейших записей Журнала для отчёта
- Пользователь задаёт значение Entry Type для цели, например, warning, error, information и т.д.
- Пользователь задаёт целевой компьютер или компьютеры для выделения журналов
- Пользователь задаёт the HTML Report Title
SYNTAX
C:\PS\EventProcessor.ps1 [[-targetLogName] <String>] [[-eventCount] <Int32>] [[-eventType] <String>] [[-reportTitle]
<String>] [[-targetComputer] <String[]>] [<CommonParameters>]
DESCRIPTION
Этот сценарий автоматизирует процесс выделения информации из предписанных файлов журналов
PARAMETERS
-targetLogName <String>
Определяет название подлежащего обработке файла журнала
Required? false
Position? 1
Default value system
Accept pipeline input? false
Accept wildcard characters? false
-eventCount <Int32>
Определяет значение максимального числа новейших событий для рассмотрения в поиске
Required?
false
Position? 2
Default value 20
Accept pipeline input? false
Accept wildcard characters? false
-eventType <String>
Определите представляющий интерес eventType
Required? false
Position? 3
Default value Error
Accept pipeline input? false
Accept wildcard characters? false
-reportTitle <String>
Определите заголовок отчёта HTML
Required? false
Position? 4
Default value Event Log Daily Report
Accept pipeline input? false
Accept wildcard characters? false
-targetComputer <String[]>
Задайте компьютер или компьютеры для получения с них журналов
Required? false
Position? 5
Default value $env:COMPUTERNAME
Accept pipeline input? false
Accept wildcard characters? false
<CommonParameters>
This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction,
WarningVariable, OutBuffer, PipelineVariable, and OutVariable. For more information, see about_Common
Parameters (https:/go.microsoft.com/fwlink/?LinkID=113216).
INPUTS
OUTPUTS
------------------------ EXAMPLE 1 ------------------------
PS C:\>EventProcessor
Исполнение EventProcessor без параметров применяет установленные по умолчанию настройки:
eventLog system
eventType warning
eventCount 20
targetComputer the computer running the script
------------------------ EXAMPLE 2 ------------------------
PS C:\>EventProcessor -targetLogName security
Данный пример определяет значением цели eventLog security и применяет значения параметров по умолчанию
eventType warning
eventCount 20
targetComputer the computer running the script
------------------------ EXAMPLE 3 ------------------------
PS C:\>EventProcessor -reporTitle "ACME Computer Daily Event Log Report"
Данный пример предоставляет индивидуальный заголовок отчёта
------------------------ EXAMPLE 4 ------------------------
PS C:\>EventProcessor -targetLogName security -eventCount 20 -entryType warning -targetComputer Python-3
Этот пример определяет все необходимые параметры, targetLogName, eventCount, entryType и targetComputer
Чтобы проиллюстрировать выполнение данного сценария, здесь предоставлены некий пример команды и результатов:
PS C:\PS> .\EventProcessor.ps1 -reportTitle "Python Forensics Daily Log Report" -eventCount 100 -eventType error
Как это и было спроектировано, наш сценарий произвёл некий файл отчёта HTML с вставкой в окончание его названия значения эпохи для обозначения того, когда этот файл был выполнен (см. Рисунок 3-7). Так как было добавлено расширение .html, наша файловая система подобающим образом определяет полученный в результате файл как некий HTML документ Google Chrome.
Изцчение полученного файла отчёта Report-1544369607 при помощи браузера предоставляет простые результаты исполнения нашего сценария PowerShell. Данный вывод содержит определённый нами заголовок отчёта, все выбранные нами события журнала, название целевого компьютера и значение типа события, которое было выбрано совместно со значениями 100 последних событий с неким типом ошибки. Отметим, что для краткости полученные результаты усечены.
|
| Замечание |
|---|---|
|
Настройка доступа к удалённым системам при помощи значения параметра -Computername (который доступен во многих CmdLet) может оказаться сложным в настройке для рабочей группы (workgroup). Это сделать намного проще когда представлен какой- то Контроллер Домена, либо ваша среда применяет Active Directory. Поэтому проконсультируйтесь, пожалуйста, со своим системным администратором когда попробуете применять соответствующий параметр -Computername в Cmdlet. |
Существует самый простой способ, который может предоставлять даже большую гибкость и является более безопасным. Этот метод служит для создания некого удалённого сеанса PowerShell с применением вашей целевой машины. После установления такого сеанса, все те команды, которые вы вводите в PowerShell или ISE PowerShell исполняются в такой удалённо подключённой машине. Основное преимущество состоит не только в упрощении, но также и в том, что это делает возможным исполнение любого CmdLet, даже такого, который не поддерживает -ComputerName в качестве параметра.
Вот некий простейший пример, который создаёт какой- то сеанс PowerShell с машиной из моей локальной сетевой среды, имеющей название Levovo-Upstairs. Чтобы создать необходимый сеанс, вы должны предоставить необходимые полномочия для пользователя в этой удалённой машине с правами Администратора. Данная команды выдаст всплывающий блок диалога, запрашивающий пароль для предписанной учётной записи, как это отбражено на Рисунке 3-9.
После установления необходимого соединения, вы можете заметить,что ваше приглашение PowerShell изменилось:
[Lenovo-Upstairs]: PS C:\Users\Remote-Admin\Documents>
На данный момент набираемые команды PowerShell исполняются в вашем удалённом компьютере Lenovo-Upstairs, а не в вашей локальной машине. В отображённом на Рисунке 3-10 примере были получены из машины Lenovo-Upstairs 20 самых последних сообщений с предупреждением, содержащихся в её системном журнале событий.
Для выхода из удалённого сеанса вызывается CmdLet Exit-PSSession и PowerShell теперь снова возвращается обратно к работе со своей локальной машиной. Это показано на Рисунке 3-10.
Получение самых последних применявшихся USB устройств несомненно может бытьважным при криминалистических изысканиях или в качестве ответных действий при происшествиях. Это может либо помочб в определении того что информация была отфильтрована из вашей системы, либо когда восставление USB могло бы вызвать проникновение злонамеренного программного обеспечения.
Самая первая часть данного процесса состоит в определении того какие именно USB устройства были выявлены. В системах Microsoft Windows имеющийся реестр представляет историю подключавшихся устройств через изучение подробностей, сохраняющихся в HKEY_Local_Machine. Рисунок 3-11 показывает значения особых ключей USBSTOR, обнаруженных в моей машине.
|
| Замечание |
|---|---|
|
В различных версиях windows представляющие интерес ключи реестра могут отличаться. Если это так, вам потребуется изменить значение определений ключа реестра, применяемого в данном примере. |
Теперь когда нам понятны действия, давайе пройдём вновь через свои два этапа по созданию необходимого нам сценария.
Первый этап: Активность последних доступов к USB
Основной вопрос состоит в том как мы можем собирать свидетельства активности USB при помощи PowerShell? А к тому же, можем ли мы разработать некий сценарий,который будет агрегировать применение USB в нашей сетевой среде?
Давайте начнём с доступа к имеющемуся реестру и USBSTOR в некой локальной машине. PowerShell предоставляет CmdLet общего назначения, который можно применять для многих элементов, включая сам реестр: это CmdLet Get-ItemProperty. На Листинге 3-10 показан Get-Help для Get-ItemProperty.
Листинг 3-10. Get-Help Get-ItemProperty
PS C:\PS> Get-Help Get-ItemProperty
NAME
Get-ItemProperty
SYNOPSIS
Получает значения свойств заданного элемента.
SYNTAX
Get-ItemProperty [[-Name] <String[]>] [-Credential <PSCredential>] [-Exclude <String[]>] [-Filter <String>] [-Include
<String[]>] -LiteralPath <String[]> [-UseTransaction] [<CommonParameters>]
Get-ItemProperty [-Path] <String[]> [[-Name] <String[]>] [-Credential <PSCredential>] [-Exclude <String[]>] [-Filter
<String>] [-Include <String[]>] [-UseTransaction] [<CommonParameters>]
DESCRIPTION
Cmdlet Get-ItemProperty cmdlet получает свойства заданных ему элементов. Например, вы можете применять данный cmdlet для получения текущего значения
свойства LastAccessTime для объекта файла. Вы также можете применять данный cmdlet для просмотра элементов реестра и их значений.
RELATED LINKS
Online Version: http://go.microsoft.com/fwlink/?LinkId=821588
Clear-ItemProperty
Copy-ItemProperty
Move-ItemProperty
New-ItemProperty
Remove-ItemProperty
Rename-ItemProperty
Set-ItemProperty
REMARKS
Для просмотра данного примера наберите "get-help Get-ItemProperty -examples".
Для дополнительной информации наберите: "get-help Get-ItemProperty -detailed".
Для получения технических сведений введите: "get-help Get-ItemProperty -full".
Для интернет подсказки наберите: "get-help Get-ItemProperty -online"
Применение данного CmdLet для извлечения последней активности USB может быть осуществлено следующим образом. Чтобы это было проще понимать, для данного примера будут извлекаться свойства Freandly Name" устройств USB. Будьте любезны просмотреть Рисунке 3-12.
PS C:\PS> Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR\*\* | Select FriendlyName
Применяя метод Удалённого доступа мы теперь вытащим активноть USB из своего удалённого компьютера Lenovo-Upstairs. Для этого применяются методы PSSession Enter и Exit, а сама команда исполняется в этом удалённом компьютере. Как вы можете видеть, и в локальном и в удалённом компьютерах было выявлено USB устройство SanDisk Cruzer.
CmdLet PowerShell Invoke-Command
В тех случаях, когда требуется выполить лишь единственную удалённую команду, это можно сделать при помощи CmdLet PowerShell Invoke-Command, вместо того чтобы устанавливать некий удалённый сеанс PowerShell. Это может оказаться полезным при разработке сценариев, которые собирают свидетельства со множество компьютеров. Как и обычно, применение Get-Help предоставит необходимые подробности того как использовать CmdLet Invoke-Command (Листинг 3-11).
Листинг 3-11. Invoke-Command
PS C:\PS> Get-Help Invoke-Command
NAME
Invoke-Command
SYNOPSIS
Исполняет команды в локальном или удалённом компьютерах.
SYNTAX
Invoke-Command [[-ConnectionUri] <Uri[]>] [-ScriptBlock] <ScriptBlock> [-AllowRedirection] [-ArgumentList <Object[]>] [-AsJob]
[-Authentication {Default | Basic | Negotiate | NegotiateWithImplicitCredential | Credssp | Digest | Kerberos}] [-CertificateThumbprint
<String>] [-ConfigurationName <String>] [-Credential <PSCredential>] [-EnableNetworkAccess] [-HideComputerName] [-InDisconnectedSession]
[-InputObject <PSObject>] [-JobName <String>] [-SessionOption <PSSessionOption>] [-ThrottleLimit <Int32>] [<CommonParameters>]
Invoke-Command [[-ConnectionUri] <Uri[]>] [-FilePath] <String> [-AllowRedirection] [-ArgumentList <Object[]>] [-AsJob] [-Authentication
{Default | Basic | Negotiate | NegotiateWithImplicitCredential | Credssp | Digest | Kerberos}] [-ConfigurationName <String>] [-Credential
<PSCredential>] [-EnableNetworkAccess] [-HideComputerName] [-InDisconnectedSession] [-InputObject <PSObject>] [-JobName <String>]
[-SessionOption <PSSessionOption>] [-ThrottleLimit <Int32>] [<CommonParameters>]
Invoke-Command [[-ComputerName] <String[]>] [-ScriptBlock] <ScriptBlock> [-ApplicationName <String>] [-ArgumentList <Object[]>] [-AsJob]
[-Authentication {Default | Basic | Negotiate | NegotiateWithImplicitCredential | Credssp | Digest | Kerberos}] [-CertificateThumbprint
<String>] [-ConfigurationName <String>] [-Credential <PSCredential>] [-EnableNetworkAccess] [-HideComputerName] [-InDisconnectedSession]
[-InputObject <PSObject>] [-JobName <String>] [-Port <Int32>] [-SessionName <String[]>] [-SessionOption <PSSessionOption>] [-ThrottleLimit
<Int32>] [-UseSSL] [<CommonParameters>]
Invoke-Command [[-ComputerName] <String[]>] [-FilePath] <String> [-ApplicationName <String>] [-ArgumentList <Object[]>] [-AsJob]
[-Authentication {Default | Basic | Negotiate | NegotiateWithImplicitCredential | Credssp | Digest | Kerberos}] [-ConfigurationName
<String>] [-Credential <PSCredential>] [-EnableNetworkAccess] [-HideComputerName] [-InDisconnectedSession] [-InputObject <PSObject>]
[-JobName <String>] [-Port <Int32>] [-SessionName <String[]>] [-SessionOption <PSSessionOption>] [-ThrottleLimit <Int32>] [-UseSSL]
[<CommonParameters>]
Invoke-Command [[-Session] <PSSession[]>] [-ScriptBlock] <ScriptBlock> [-ArgumentList <Object[]>] [-AsJob] [-HideComputerName]
[-InputObject <PSObject>] [-JobName <String>] [-ThrottleLimit <Int32>] [<CommonParameters>]
Invoke-Command [[-Session] <PSSession[]>] [-FilePath] <String> [-ArgumentList <Object[]>] [-AsJob] [-HideComputerName] [-InputObject
<PSObject>] [-JobName <String>] [-ThrottleLimit <Int32>] [<CommonParameters>]
Invoke-Command [-VMId] <Guid[]> [-ScriptBlock] <ScriptBlock> [-ArgumentList <Object[]>] [-AsJob] [-ConfigurationName <String>] -Credential
<PSCredential> [-HideComputerName] [-InputObject <PSObject>] [-ThrottleLimit <Int32>] [<CommonParameters>]
Invoke-Command [-ScriptBlock] <ScriptBlock> [-ArgumentList <Object[]>] [-AsJob] [-ConfigurationName <String>] -Credential <PSCredential>
[-HideComputerName] [-InputObject <PSObject>] [-ThrottleLimit <Int32>] -VMName <String[]> [<CommonParameters>]
Invoke-Command [-VMId] <Guid[]> [-FilePath] <String> [-ArgumentList <Object[]>] [-AsJob] [-ConfigurationName <String>] -Credential
<PSCredential> [-HideComputerName] [-InputObject <PSObject>] [-ThrottleLimit <Int32>] [<CommonParameters>]
Invoke-Command [-FilePath] <String> [-ArgumentList <Object[]>] [-AsJob] [-ConfigurationName <String>] -Credential <PSCredential>
[-HideComputerName] [-InputObject <PSObject>] [-ThrottleLimit <Int32>] -VMName <String[]> [<CommonParameters>]
Invoke-Command [-ScriptBlock] <ScriptBlock> [-ArgumentList <Object[]>] [-AsJob] [-ConfigurationName <String>] -ContainerId <String[]>
[-HideComputerName] [-InputObject <PSObject>] [-JobName <String>] [-RunAsAdministrator] [-ThrottleLimit <Int32>] [<CommonParameters>]
Invoke-Command [-FilePath] <String> [-ArgumentList <Object[]>] [-AsJob] [-ConfigurationName <String>] -ContainerId <String[]>
[-HideComputerName] [-InputObject <PSObject>] [-JobName <String>] [-RunAsAdministrator] [-ThrottleLimit <Int32>] [<CommonParameters>]
Invoke-Command [-ScriptBlock] <ScriptBlock> [-ArgumentList <Object[]>] [-InputObject <PSObject>] [-NoNewScope] [<CommonParameters>]
DESCRIPTION
Сmdlet Invoke-Command исполняет команды в локальном или удалённом компьютерах и возвращает весь вывод от этих команд, включая ошибки. Применяя отдельную команду Invoke-Command,
вы способны исполнять команды на множестве компьютеров.
Для исполнения отдельной команды в неком удалённом компьютере воспользуйтесь парметром ComputerName. Для исполнения последовательности связанных комманд, овместно использующих данные, примените cmdlet New-PSSession для создания
PSSession (некого сохраняемого подключения) в этом удалённом компьютере и затем воспользуйтесь параметром Session Invoke-Command для исполнения
этой команды в данном PSSession. Для исполнения некой команды в отключённом сеансе применяйте параметр InDisconnectedSession. Для исполнения команды в неком фоновом задании
применяйте параметр AsJob.
Вы также можете применять Invoke-Command в неком локальном компьютере для оценки или исполения некой строки в качестве блока сценария в качестве команды. Windows PowerShell преобразует этот блок сценария в некую команду
и немедленно выполнит эту команду в текущей среде вместо того чтобы просто передавать в качетчве echo данную строку в командную строку.
Для запуска интерактивного сеанса в неком удалённом компьютере применяйте cmdlet Enter-PSSession. Для установления постоянного подключения к некому удалённому компьютеру воспользуйтесь
cmdlet New-PSSession.
Перед применением Invoke-Command для исполнения команд в неком удалённом компьютере, ознакомьтесь с about_Remote.
RELATED LINKS
Online Version: http://go.microsoft.com/fwlink/?LinkId=821493
Enter-PSSession
Exit-PSSession
Get-PSSession
New-PSSession
Remove-PSSession
Применяя в качестве отправной точки данный метод получения активности USB, наш метод Invoke-Command модет применяться для удалённого исполения этой команды. В данном примере вначале в качестве переменных создаются цель и пользователь. Эта команда встраивается в -ScriptBlock. Как и ранее, наш пользователь обязан ввести полномочия Администратора для данного удалённого компьютера (Рисунок 3-14).
Получаемые результаты выполненной команды Invoke показаны на Рисунке 3-15.
Второй этап: Активность последних доступов к USB
Теперь, когда у нас имеется исключительный метод, можно создать некий прсотейший сценарий PowerShell для выполнения данной операции нам с предоставлением названия необходимого пользователя нащего целевого компьютера и самого пользвоателя с правами Администратора. Весь сценарий приводится в Листинге 3-12. Также позднее я покажу результат и примера исполнения.
Листинг 3-12. Сценарий USBAcquire
<#
.synopsis
Собирает активность USB в указанном компьютере
- Пользователь указывет компьютер назначения
Этот сценарий воспроизведёт подробности активности USB
в неком заданном компьютере назначения
.Description
Этот сценарий собирает активность USB в указанных компьютерах
.parameter targetComputer
Определяет тот компьютер, в которм собирать активность USB
.parameter UserName
Определяет имя пользователя с правами Администратора в Целевом компьютере
.example
USBAcquire ComputerName
Собирает имеющуюся активность USB в заланном целевом Компьютере
#>
# Раздел определения параметра
param(
[string]$User,
[string]$targetComputer
)
Invoke-Command -ComputerName $targetComputer -Credential $User -ScriptBlock {Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR\*\* | Select FriendlyName}
Как вы можете видеть, USBAcquire имеет те же самые четыре основных раздела, как и сценарий EventProcessor из Примера 1: определение параметра заголовка сценария, определение локальных переменных, а также исполнение cmdlet с применением параметров и локальных переменных. Если вам требуется освежить это в своей памяти, обратитесь назад к началу этого раздела.
Собственно исполнение и результаты данного сценария демонстрируются на Рисунке 3-16 и Рисунке 3-17.
PS C:\PS> .\USBAcquire.ps1 -targetComputer PYTHON-3 -user PYTHON-3\USER-NAME-HIDDEN
Наш сценарий содержит надлежащим образом сформированный раздел заголовка; тем самым, может быть получена справка для пользователя при помощи CmdLet Get-Help, отображаемая в Листинге 3-13.
Листинг 3-13. Get-Help USBAcquire
PS C:\PS> Get-Help .\USBAcquire.ps1
NAME
C:\PS\USBAcquire.ps1
SYNOPSIS
Собирает активность USB в указанном компьютере
- Пользователь указывет компьютер назначения
Этот сценарий воспроизведёт подробности активности USB
в неком заданном компьютере назначения
SYNTAX
C:\PS\USBAcquire.ps1 [[-User] <String>] [[-targetComputer] <String>] [<CommonParameters>]
DESCRIPTION
Этот сценарий собирает активность USB в указанных компьютерах
RELATED LINKS
REMARKS
To see the examples, type: "get-help C:\PS\USBAcquire.ps1 -examples".
For more information, type: "get-help C:\PS\USBAcquire.ps1 -detailed".
For technical information, type: "get-help C:\PS\USBAcquire.ps1 -full".
Основываясь на том что вы изучили относительно PowerShell и методов Удалённого доступа, вам предлагаются вызов для углубления этих знаний решением приводимой далее задачи.
Разработайте некий сценарий PowerShell, который создаст некий учёт детализации компьютера по всем обнаруженным каталогам. Этот сценарий позволит вашему пользователю определять:
-
Целевой компьютер
-
Начальный каталог
-
Файл вывода
Ваш сценарий должен вырабатывать некий файл HTML, который содержит следующую ниформацию:
-
Каталог
-
Имя файла
-
Размер файла
-
Время последней записи
-
Владельца
-
Атрибуты (т.е. ReadOnly, Hidden, System, Archive)
Этот сценарий будет рекурсией по всем папкам, начинающимся с Начального каталога.
![[Совет]](/common/images/admon/tip.png) | Совет |
|---|---|
|
Вы можете сосредоточиться на CmdLet get-Childitem. |
Наконец, ваш сценарий будет содержать всю справочную информацию. Пример решения приводится в Приложении A. Решения сформулированных задач и в www.apress.com/9781484245033.
Данная глава сосредоточена на построении сценариев PowerShell, которые можно применять исследователям для получения информации из журналов событий, а также относительно последних действий с USB. На наших выборках данных были сосредоточены CmdLet Get-EventLog и Get-ItemProperty.
Кроме того, в качестве дополнительного метода получения свидетельств с удалённых компьютеров было рассмотрено создание удалённых сеансов PowerShell, когда надлежащие полномочия доступны с применением CmdLet Enter-PSSession. Кроме того, был рассмотрен CmdLet PowerShell Invoke-Command, который позволяет исполнение отдельной команды или обособленного сценария без создания постоянного сеанса.
Глава 4 выполнит введение, сравнение и приведёт отличия PowerShell и Python, а также начнёт процесс сочетания этих двух мощных языков сценариев.