C:\myapplication\myapplication.exe
      C:\myapp\subfolder\myapp.exe
      C:\SoftwareCompany\software.exe
      C:\myapplication\myapplication.dll
      C:\myapp\subfolder\myapp.dll
      C:\SoftwareCompany\software.dll
           

**実用的なメンタルモデルは次のとおりです:**

プロセスが libeay32.dll をロードする

→ プロセスが OPENSSL_config(NULL) を呼び出す

→ OpenSSL が openssl.cnf を読み取る

→ engine セクションが、指定された dll のロード試行を引き起こす

→ Windows ローダーが dll とその依存関係を受け入れる

***いずれかのステップが欠けていると、あなたの DLL はロードされません。***

デバッグ中に使える最小限のルール:

プロセスが libeay32.dll をロードするだけでは不十分です。
OpenSSL の設定読み込みも呼び出し、それを無効にしていない必要があります。

- 動作させるには OPENSSL_config を呼び出すべき、または
- CONF_modules_load_file、または
- OPENSSL_no_config が設定されていないこと。


署名チェックなし。検証なし。プロセスが OPENSSL_config を呼び出せば、指定された任意の DLL がロードされます。
テストをさらに進めるために、OpenSSL に関連する典型的な DLL 名をクエリして、可能性のあるアプリケーションを列挙できます。確認したいのは DLL の OPENSSLDIR と、そのプロセスが OpenSSL_conf を呼び出しているかどうかです。
OpenSSLDIR は、このリポジトリ内のリストとファイルハッシュを照合して確認するか、crypto 関連の dll のコピーを取得して、その cryptodll (libeay32.dll など) に対して openssldir_check を実行するだけで確認できます。
また ProcMon を使って、そのプロセスが openssl.cnf を呼び出しているかどうかを確認することもできます。ProcMon で openssl.cnf が見えれば、そのアプリケーションがそれを呼び出していると確実に分かります。他の方法で取得したいのは、バージョン情報 (event.code 7 のフィールド内) と、このリポジトリ内のリストとファイルハッシュを照合して openssl.cnf ファイルをどのパスからロードしているか、同じ DLL のコピーを取得して手動チェックを行うことです。


**openssldir_check.exe を実行したときの例**

`openssldir_check32.exe libeay32.dll`

`openssldir_check v1.0 by 0xm1rch`

**出力:**

`SSLeay_version() returned OpenSSL 1.0.1g 7 Apr 2014`

`SSLeay_version() returned OPENSSLDIR: "/usr/local/ssl"`

- ref https://github.com/mirchr/openssldir_check
> このリポジトリでプリコンパイルされている、カスタム修正版 openssldir_check でも同様の出力になります。

> 出力から OpenSSL バージョン 1.0.1g であり、OpenSSLDIR が **/usr/local/ssl** に設定されていることが分かります。これは **非常に興味深いです!**

> **Sysmon event.code 7** は、ロードされた OpenSSL DLL と、file.pe.file_version フィールド内の dll のバージョン情報も提供します。


#### 昇格シナリオ
1. サービスが **SYSTEM** として実行され、OpenSSL を使用している
2. OpenSSL DLL が起動時に openssl_conf を呼び出し、`C:\usr\local\ssl\openssl.cnf` を読み取るが、そのファイルは編集可能または存在しない
3. 低権限ユーザーがそのフォルダに書き込める場合、次のことが可能:
   - 悪意のある `openssl.cnf` を配置する
   - 自身の DLL を配置する
   - サービスの再起動を待つ
   - コードが **SYSTEM** として実行される

> 結果: アプリケーションの openssl dll がロードする openssl.cnf を配置し、最終的にカスタムの「悪意のある」dll をロードさせることによるローカル権限昇格。



### NSIS インストーラー/アンインストーラーの脆弱性

NSIS は広く使われている Windows インストーラーフレームワークです。ここで説明する問題は、NSIS インストーラーまたはアンインストーラーが昇格された権限で実行されるとき、C:\Windows\Temp 配下の一時ディレクトリを通常のローカルユーザーが干渉できる形で使用する可能性があることです。

実際には、低権限の攻撃者が、インストーラーが信頼するファイル (一時的なプラグインファイルやアンインストーラーファイルなど) を掌握し、それを SYSTEM としてのコード実行に変えることができるということです。言い換えれば、弱点は「インストーラーが管理者として実行される」ことではなく、インストーラーの一時ファイル処理によって、非特権ユーザーが昇格されたインストールまたはアンインストールのフローをハイジャックできることです。

#### NSIS インストーラーでよく見られる DLL

> 注: これらの一部は **公式の NSIS プラグイン** ですが、その他は NSIS インストーラーでよく使われる **一般的なサードパーティ製プラグイン** です。  
> これらの DLL のいずれかが見つかることは手がかりになりますが、インストーラーが NSIS を使用している絶対的な証拠ではありません。`C:\Windows\Temp\*.tmp\*.dll` というファイルパスは強い指標です。

| DLL | 典型的な用途 | 種類 | 備考 |
|---|---|---|---|
| `System.dll` | NSIS スクリプトから Win32 API や外部 DLL 関数を呼び出す | 公式 NSIS プラグイン | NSIS の最も強い指標の一つ |
| `nsDialogs.dll` | カスタムインストーラーダイアログとコントロールを構築する | 公式 NSIS プラグイン | 現代の NSIS インストーラーで一般的 |
| `nsExec.dll` | コンソールコマンドを実行し出力をキャプチャする | 公式 NSIS プラグイン | サイレントなヘルパーコマンドによく使われる |
| `StartMenu.dll` | ユーザーにスタートメニューフォルダを選択させる | 公式 NSIS プラグイン | クラシックなインストーラーで一般的 |
| `LangDLL.dll` | 言語選択ダイアログを表示する | 公式 NSIS プラグイン | 多言語インストーラーでよく現れる |
| `Banner.dll` | インストール手順中にバナー/進捗 UI を表示する | 公式 NSIS プラグイン | 主に見た目用 |
| `InstallOptions.dll` | INI 定義から旧式のカスタムページを作成する | 公式 NSIS プラグイン | 大部分は `nsDialogs.dll` に置き換えられた |
| `UserInfo.dll` | 現在のユーザー/アカウントに関する情報を取得する | 公式 NSIS プラグイン | 権限やアカウントのチェックに使用 |
| `Dialer.dll` | ダイヤルアップ/ネットワーク接続の動作を管理する | 公式 NSIS プラグイン | 主にレガシー |
| `Math.dll` | NSIS スクリプト向けの算術ヘルパーを提供する | 公式 NSIS プラグイン | 新しいスクリプトでは必要とされることが少ない |
| `NSISdl.dll` | インターネットからファイルをダウンロードする | 公式 NSIS プラグイン | 古いダウンロードプラグイン。しばしば `inetc.dll` に置き換えられる |
| `Splash.dll` | スプラッシュ画面を表示する | 公式 NSIS プラグイン | 主にレガシー/見た目用 |
| `AdvSplash.dll` | より高度なスプラッシュ画面を表示する | 一般的な NSIS プラグイン | `Splash.dll` と同様の役割 |
| `BgImage.dll` | インストーラー UI に背景画像を表示する | 公式/一般的な NSIS プラグイン | 主に見た目用 |
| `inetc.dll` | HTTP/FTP 経由でファイルをダウンロードする | 一般的なサードパーティ製 NSIS プラグイン | Web インストーラーで非常に一般的 |
| `InetLoad.dll` | インターネットからファイルをダウンロードする | 一般的なサードパーティ製 NSIS プラグイン | `NSISdl.dll` / `inetc.dll` の代替 |
| `UAC.dll` | 昇格と UAC 関連の動作を処理する | 一般的なサードパーティ製 NSIS プラグイン | NSIS 関連の強い手がかり |
| `AccessControl.dll` | ファイル/フォルダの ACL と権限を変更する | 一般的なサードパーティ製 NSIS プラグイン | 管理者権限に敏感なインストールで使用 |
| `Registry.dll` | 高度な Windows レジストリ操作 | 一般的なサードパーティ製 NSIS プラグイン | 場合によっては組み込みのレジストリコマンドより高機能 |
| `ShellLink.dll` | Windows ショートカット (`.lnk`) ファイルを作成または編集する | 一般的なサードパーティ製 NSIS プラグイン | ショートカット管理ヘルパー |
| `SimpleFC.dll` | ファイルを比較したりファイル差分をチェックする | 一般的なサードパーティ製 NSIS プラグイン | ユーティリティ/ヘルパープラグイン |
| `FindProcDLL.dll` | プロセスが実行中かどうかを検出する | 一般的なサードパーティ製 NSIS プラグイン | アップグレード前によく使われる |
| `KillProcDLL.dll` | 実行中のプロセスを終了させる | 一般的なサードパーティ製 NSIS プラグイン | アンインストーラー/アップデーターで一般的 |
| `NScurl.dll` | curl 風の機能を使ってデータをダウンロード/転送する | 一般的なサードパーティ製 NSIS プラグイン | より新しく高機能なネットワークヘルパー |
| `ZipDLL.dll` | ZIP アーカイブの展開または作成を処理する | 一般的なサードパーティ製 NSIS プラグイン | アーカイブユーティリティ |
| `unzipdll.dll` | ZIP アーカイブを展開する | 一般的なサードパーティ製 NSIS プラグイン | 古いアーカイブプラグイン |
| `untgz.dll` | `.tar.gz` アーカイブを展開する | 一般的なサードパーティ製 NSIS プラグイン | あまり一般的ではないが、一部のパッケージで見られる |
| `VPatch.dll` | バイナリパッチ/更新を適用する | 一般的な NSIS 関連プラグイン | パッチインストーラーでよく使われる |
| `CabDLL.dll` | CAB アーカイブを扱う | 一般的な NSIS 関連プラグイン | 主に古いパッケージングワークフローで見られる |
| `nsJSON.dll` | JSON データを解析または生成する | 一般的なサードパーティ製 NSIS プラグイン | 現代のスクリプト化されたインストーラーでより一般的 |
| `StdUtils.dll` | NSIS 向けの汎用ヘルパーユーティリティ | 一般的なサードパーティ製 NSIS プラグイン | OS/バージョン/パスのヘルパーによく使われる |
| `ExecDos.dll` | I/O と待機をより細かく制御してコマンドを実行する | 一般的なサードパーティ製 NSIS プラグイン | `nsExec.dll` の代替/拡張 |

#### より強い NSIS 指標

以下の DLL は特に NSIS を強く示唆します:

- `System.dll`
- `nsDialogs.dll`
- `nsExec.dll`
- `LangDLL.dll`
- `StartMenu.dll`
- `NSISdl.dll`
- `inetc.dll`
- `UAC.dll`

#### 注意

一部のインストーラーはこれらの DLL を次のようなフォルダに一時的に展開します:

- `$PLUGINSDIR`

そのため、ディスク上のインストーラー実行ファイルの隣ではなく、実行時にのみ現れることがあります。


### DotLocal リダイレクション脆弱性
**DotLocal リダイレクションの悪用は、書き込み可能なアプリフォルダによって攻撃者が正規プログラムに悪意のある DLL を先にロードさせる Windows DLL ハイジャック問題です**

DotLocal リダイレクション脆弱性は、Windows 組み込みの .local / DotLocal DLL リダイレクション機能を悪用します。Windows は App.exe.local のような名前のファイルまたはフォルダを尊重することで DLL リダイレクションをサポートします。それが存在する場合、ローダーは DLL を探す際に実行ファイルのフォルダまたはその .local フォルダを最初にチェックし、これは完全な DLL パスが指定されている場合でも適用されることがあります。Microsoft はこれを DLL ロードをリダイレクトするための正規の機能として文書化しています。

なぜ脆弱性になるのか: 攻撃者が実行ファイルのディレクトリ (ユーザー書き込み可能なパス)、または特権プロセスが使用する一時展開ディレクトリに書き込める場合、Target.exe.local フォルダを作成し、Windows が優先する場所に悪意のある DLL を配置できます。これによりこの機能は DLL ハイジャックに変わり、信頼されたプロセスが意図されたライブラリではなく攻撃者のライブラリをロードします。

#### 手動制御
世界中から書き込み可能なパスにある高権限プロセスを特定し、DotLocal リダイレクションに対して脆弱かどうかを調査すべきです。それらをクエリしてアプリケーションを見つけた場合。ProcMon を使って最後の制御を行い、そのプロセスが作成された .exe.local フォルダからライブラリをロードしようとするかどうかを確認します。完全なファイルパスを特定するには GetSxsPath ツールを使用できます。脆弱であれば、Procmon は .exe.local ディレクトリを指す NAME NOT FOUND / PATH NOT FOUND イベントを表示するはずです。公開報告に基づくと、アプリケーションはインストールプロセス中に特に脆弱です。

**経験則として:**
ProcMon は .local の探索の証拠を提供できますが、目に見える .exe.local のミスが存在しないことは、そのアプリが影響を受けないことを証明するものではありません。特に comctl32.dll については、トレースはしばしば単純なアプリフォルダの DLL 検索ではなく、マニフェスト/SxS バインディングを反映しています。


#### プログラムが次をロードする場合:

`C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

#### これをチェック:

`C:\Path\To\Application.exe.local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.19041.1110_none_60b5254171f9507e\comctl32.dll`

**SxS DotLocal DLL ハイジャックのリダイレクションパスを特定する** - https://gist.github.com/rxwx/1717e95e5ec11bea12d33e93a3832508

#### DotLocal Wiz インストーラー
**WiX Burn EXE ブートストラッパー** 影響を受けるバージョン >= 4, < 4.0.4 < 3.14.0。これは WiX インストーラーフレームワークでビルドされたあらゆるインストーラーに影響します。
WiX では、作者がデフォルトのアイコンを置き換え、標準の WixStdBA UI またはカスタムブートストラッパーアプリケーションのいずれかを使用できるため、EXE は「WiX」ではなくベンダーのように見せるブランディングが可能です。

##### 詳細
バンドルが管理者として実行されない場合、システムの TEMP フォルダではなくユーザーの TEMP フォルダが使用されます。ユーティリティはユーザーの TEMP フォルダの変更を監視し、.be フォルダが作成された直後に自身の DLL を .be/.Local フォルダに配置できます。burn エンジンが昇格すると、悪意のある DLL が昇格された権限を受け取ります。

> **Ref** https://github.com/wixtoolset/issues/security/advisories/GHSA-7wh2-wxc7-9ph5

「別個の wixstdba.exe プロセスは WiX Burn の良い指紋ですが、影響を受けるバージョンの最も強い指標は Burn エンジンのバージョン自体です: <3.14.0 または 4.0.0～4.0.3 と識別される場合は脆弱です。」


## 前提条件
関心のあるイベント (ユーザー書き込み可能なパスと前述のレジストリハイブに対する event.code 1、7、11、13 など) を捕捉するための適切に構成された SYSMON 設定。
 - https://github.com/SwiftOnSecurity/sysmon-config
 - https://github.com/olafhartong/sysmon-modular

一部の Windows イベントに対して有効化された高度な監査。

Event ID 4688 (プロセス作成) は、新しく作成されたプロセスをログに記録するために明示的に有効化する必要があります。
デフォルトでは、プロセスの起動に使用されたコマンドラインをキャプチャしません。この機能はセキュリティポリシーで明示的に有効化する必要があります。

スケジュールタスク - 4698 はデフォルトでは有効化されていません。


## ACL ⭐
### 🔹 ログイン中のユーザーをカバーする一般的な ACL プリンシパル

| プリンシパル               | 説明                                                                 |
|--------------------------|-----------------------------------------------------------------------------|
| **Everyone**             | すべてのユーザー (Guest を含む。古い Windows バージョンでは Anonymous Logon も含む)。非常に広範で、通常は読み取りアクセスに制限される。 |
| **Authenticated Users**  | 正常にログインした任意のアカウント (ローカルまたはドメイン)。匿名ユーザーは除外される。 |
| **BUILTIN\Users**        | マシン上のローカル **Users** グループ。すべての標準 (非管理者) ローカルアカウントを含む。 |
| **INTERACTIVE**          | **コンソールでローカルに** ログインした任意のユーザー (キーボード/セッション)。ローカルアクセスとリモートアクセスを区別するのに便利。 |
| **COMPUTERNAME\\Username** | そのコンピューター上の特定の **ローカルアカウント** (例: `LAPTOP01\Bob`)。権限はそのユーザーがローカルにログオンしたときにのみ適用される。 |
| **DOMAIN\\Username**     | 特定の **ドメインアカウント** (例: `CORP\Alice`)。権限はすべてのドメイン参加マシンでそのユーザーに追随する。 |


### 📑 ACL 属性 (注目すべきものの一部)

アクセス制御リスト (ACL) 属性は、ユーザーまたはグループがファイルやフォルダに対して実行できるアクションを定義します。  
以下は注目に値する主要なものです:

| 属性 | 名前 / 意味           | なぜ興味深いか                                                                 |
|-----------|--------------------------|--------------------------------------------------------------------------------------|
| **F**     | フルアクセス              | **すべての可能な権限** (読み取り、書き込み、実行、削除、権限変更、所有権取得) を付与する。「オーナーレベル」の制御に相当。 |
| **M**     | 変更アクセス            | ファイル/フォルダの読み取り、書き込み、削除を許可するが、**ACL や所有権の変更は不可**。通常ユーザーにとって最も一般的。 |
| **W**     | 書き込み専用アクセス        | ユーザーは **コンテンツを作成または変更** できるが、読み戻すことはできない。稀だが、「ドロップボックス」シナリオ (例: 安全なファイル提出) で有用。 |
| **WD**    | データ書き込み / ファイル追加    | 特に **ディレクトリ内のファイルの作成または書き込み** を許可する。フォルダ内にファイルを追加または上書きできるために不可欠。 |
| **AD**    | データ追加 / サブディレクトリ追加 | ファイルの場合: ファイルの末尾にデータを追加する (上書きは不可)。フォルダの場合: 内部に新しいサブディレクトリを作成する。 |


## 誤検知
#### クエリを実行し、それらを微調整し、最終的にそれらからアラートを作成してください。 
いくつかのホワイトリスト登録が必要になる場合があります (ProgramData の典型的なパスについては以下を参照)。考え方は、典型的なユーザー書き込み可能なパスをクエリすることですが、(ファイルやフォルダの) ACL が正しく設定されていることがあります。攻撃的思考で権限昇格できない場合は、それらをホワイトリストに登録してください。
あまり興味深くないものをフィルタリングします: 正しい ACL を持つもの、ランダム化されたファイル名 (フォルダをフィルタリングする)。ノイズを減らし、ベースラインを持つことが目的です。これが脆弱性ではないことを検証した後に行うことが重要です。そうすれば、すべてのクライアントで脆弱なスケジュールタスクを見逃すことがありません。


## ホワイトリスト登録
おそらくクエリをホワイトリストに登録する必要があります。ハントを行い、クエリを微調整し、まだ調査していない新しいイベントを捕捉するためにそれらからアラートを作成してください。
##### おそらくホワイトリスト登録が必要:
      C:\ProgramData\Microsoft
      C:\ProgramData\Package Cache
      C:\ProgramData\Packages
      など。

ホワイトリスト登録が必要になる可能性があるその他のものは、一般的である可能性があり、ハードウェア関連のドライバーや、ランダム化された名前を持つ類似のものです。
      

## 方法論
「ログ保持期間」のタイムスパンでクエリすることを忘れないでください。
良い方法論は、最初に短い時間枠でクエリし、それを徐々に増やしていくことです。
1) 1 日
2) 1 週間
3) 2 週間
4) 1 か月
5) 2 か月
6) など..

ハントを行い、興味深いものをチェックし、微調整とホワイトリスト登録を行います。最終的にそれらからアラートを作成し、新しいイベントを捕捉します。

## ヒントとコツ
正しい ACL のためにバイナリ置換が不可能な場合。フォルダの権限をチェックし、ファイルを書き込む権限があるかどうかを確認します。
実行ファイルが存在しない dll をロードしようとするかどうかを確認します。もしそうなら、それらを作成すればコード実行が得られます。実行中のプロセスのためにバイナリ置換が不可能な場合。可能な DLL サイドローディングをチェックするか、通常ユーザーとしてサービス自体を再起動する権限があるかどうかを確認します。別の方法は、通常ユーザーとして「シャットダウン」を実行し、最後の瞬間に脱出できるかどうかを確認することです。シャットダウンの開始はプロセスを停止し、そこから脱出できれば、終了したプロセスのバイナリを置換できる可能性があります。サービスが自動起動モードで、サービスを開始/停止する権限がない場合、確認できるのは SeShutdownPrivilege を持っているかどうかであり、もしそうなら shutdown /r /t 0 で再起動を開始します。

サービスがプロセスを生成しており、バイナリを置換することが不可能で、そのバイナリが存在しない DLL をロードしようとしない場合。諦めないでください - おそらくパスが引用符で囲まれておらず、書き込み権限があり、それを利用できるかもしれません?

クエリをレイヤーごとに構築します。つまり、サービス/スケジュールタスクの作成をチェックし、親がサービスまたはスケジュールタスク関連プロセス (Schedule 引数付きの svchost.exe) であるプロセス作成をチェックします。一部のシステムがサービスやスケジュールタスクを作成するが、バイナリパスなどが存在せず、プロセス作成が決して起こらない可能性があります。しかし脆弱性は依然として存在し、それに関連するさまざまなイベントが作成される可能性があります。

クエリ負荷 (パフォーマンス) とおそらくホワイトリスト登録を減らすために、クライアント/サーバー用にクエリを分離するのが良い考えかもしれません。つまり、クライアントエンドポイント専用のクエリセットと、サーバーエンドポイント用の同じセットです。

SYSTEM による一般的なプロセス作成は価値の高いクエリです。多くのシナリオを捕捉します。サービスや schtask が子プロセスを生成する以外に、msiexec.exe が子プロセスを生成するのも捕捉します。また、c:\windows\ccmcache からの実行ファイルがユーザー書き込み可能なパスから子プロセスを生成している場合もキャッシュします。脆弱性で実行ファイルを順序付けるなら、services.exe はソフトウェアの設定ミスに関連し、schtasks はより管理者の設定ミスであると言えるでしょう。

すべてのクエリを試して成功しなかった場合。より深くハントし、もう少し作業を行いたいなら - 場所に関係なく、services.exe と schtasks (Schedule 引数付きの svchost.exe) のすべての子プロセスを対象にします。エンタープライズを列挙し、典型的な管理者保護パス (Program Files & Program Files (x86)) にあるものも探します。ソフトウェアベンダーが典型的な保護パスでも ACL を台無しにすることは、思っているより一般的です。プロセス作成イベントと、サービスおよびスケジュールタスクのイベントを使用します。スケジュールタスクについては、すべての Command フィールドと Argument フィールドをクエリします。引数フィールドはユーザー書き込み可能なパスや C ルートのスクリプトファイルを指している可能性があります。コマンドフィールドは安全でない ACL を持つバイナリを指している可能性があります。C:\PROGRA~3 も調べることができます。これは C:\ProgramData の 8.3 短縮名 (DOS) 表現です。

## アンインストールプロセス
ユーザーがインストールをトリガーできるなら、アンインストールもトリガーできる可能性が高いです。アンインストールプロセスは、ファイルパスがどこであっても関心の対象です。
ACL が正しくない場合、バイナリ置換はおそらく問題を引き起こします。
Sysmon event.code:11 を使用して、典型的なアンインストールファイルのファイル作成もクエリします。
これは、プロセス作成イベントを信頼せずにすべてのアンインストーラーを捕捉するために行いたいことです。なぜなら、ユーザーがインストールされたアプリケーションのアンインストールを実際に行うことは一般的ではないからです。彼らはそれを気にしないので、存在するが決してトリガーされない一部のアンインストールイベントを見逃しやすくなります。

### アンインストールプロセス名の例
#### 一般的な汎用名uninstall.exe – 最も汎用的で広く使われている。
          unins000.exe、unins001.exe – Inno Setup インストーラーで一般的。
          unwise.exe – 古い Wise Installer パッケージでよく使われる。
          uninst.exe – 短縮版で、レガシーソフトウェアによく見られる。
          uninstaller.exe – やや長い、説明的な変種。
          remove.exe – 最小限のインストーラーで使われることがある。
          setup.exe (/uninstall または /remove パラメータ付き) – 一部のアプリはアンインストールにインストーラー実行ファイルを再利用する。
          appname_uninstall.exe (例: chrome_uninstall.exe)
          update.exe (--uninstall 付き) – Slack や Discord など Squirrel インストーラーを使うアプリで見られる。

#### 考慮すべきパターン

          *_uninstall.exe – 多くのアプリはアプリ名を先頭に付ける。例: teams_uninstall.exe、zoom_uninstall.exe。
          *_cleanup.exe – 削除ツールには cleanup 変種がよくある。例: driver_cleanup.exe。
          *_remover.exe – もう一つの一般的な AV/ベンダーの命名スタイル。


## ロード時にコード実行される PE / バイナリファイル
### リスト内のものについて windows/sysmon ログと procmon ログの両方でクエリすることを検討する
| 拡張子 | PE タイプ | ロード時にコード実行? | エントリポイント / メカニズム | 備考 |
|-----------|---------|--------------------------|-------------------------|-------|
| `.exe` | PE 実行ファイル | はい | PE `AddressOfEntryPoint` | 実行ファイルが起動されるとコードが開始される |
| `.dll` | PE DLL | はい | `DllMain` / TLS コールバック | DLL がプロセスにロードされるとコードが実行され得る |
| `.sys` | PE カーネルドライバー | はい | `DriverEntry` | ドライバーがロードされるとドライバー初期化コードが実行される |
| `.scr` | PE 実行ファイル | はい | PE `AddressOfEntryPoint` | 本質的には実行ファイル; `.scr` は主に慣習 |
| `.cpl` | PE DLL | はい | `DllMain` + `CPlApplet` | コントロールパネル基盤によってロードされる |
| `.ocx` | PE DLL / ActiveX | はい | `DllMain` + COM/ActiveX エントリポイント | ロード時に DLL 初期化が発生する |
| `.drv` | PE DLL / レガシードライバー | 通常は | `DllMain` またはドライバー固有のエントリポイント | 特定の `.drv` タイプに依存する |
| `.efi` | PE/COFF EFI バイナリ | はい | EFI エントリポイント | UEFI によってロードされるとコードが実行される |
| `.ax` | PE DLL | はい | `DllMain` + DirectShow インターフェース | ロード時に DLL 初期化が発生する |
| `.acm` | PE DLL | はい | `DllMain` + ACM エントリポイント | Audio Compression Manager コーデックとしてロードされる |
| `.ime` | PE DLL | はい | `DllMain` + IME エントリポイント | ロード時に DLL 初期化が発生する |
| `.tsp` | PE DLL | はい | `DllMain` + TAPI エントリポイント | ロード時に DLL 初期化が発生する |
| `.pyd` | PE DLL | はい | `DllMain` + Python モジュール初期化 | ネイティブ Python 拡張 |
| `.node` | PE DLL | はい | `DllMain` + Node.js アドオン初期化 | ネイティブ Node.js アドオン |
| `.xll` | PE DLL | はい | `DllMain` + Excel XLL エントリポイント | `EXCEL.EXE` によってロードされる |
| `.wll` | PE DLL | はい | `DllMain` + Word アドインのロード | `WINWORD.EXE` によってロードされる |



## スクリプトファイル
### リスト内のものについてクエリすることを検討する
| 拡張子 | 言語 / タイプ           | 目的 / 用途                                         | 実行コンテキスト                                          |
|-----------|---------------------------|---------------------------------------------------------|------------------------------------------------------------|
| .bat      | バッチスクリプト               | レガシーなコマンドライン自動化タスク、単純なスクリプト     | `cmd.exe` (コマンドプロンプト)                                  |
| .cmd      | バッチスクリプト (NT スタイル)    | `.bat` に類似、NT ベースのシステムで好まれる         | `cmd.exe` (コマンドプロンプト)                                  |
| .vbs      | VBScript                   | 自動化タスク、ログオンスクリプト、管理スクリプト           | Windows Script Host (`wscript.exe`、`cscript.exe`)          |
| .vbe      | VBScript (エンコード済み)         | 難読化のための `.vbs` のエンコード版              | Windows Script Host (`wscript.exe`、`cscript.exe`)          |
| .ps1      | PowerShell スクリプト          | モダンな Windows の自動化および構成タスク       | PowerShell (`powershell.exe`、`pwsh.exe`)                   |
| .js       | JScript                    | WSH タスク向けの Microsoft 版 JavaScript          | Windows Script Host (`wscript.exe`、`cscript.exe`)          |
| .jse      | JScript (エンコード済み)          | 難読化のための `.js` の暗号化版               | Windows Script Host (`wscript.exe`、`cscript.exe`)          |
| .wsf      | Windows Script File (XML)  | VBScript、JScript、その他のスクリプトを XML 形式で混在させる       | Windows Script Host (`wscript.exe`、`cscript.exe`)          |
| .wsh      | Windows Script Host Settings | WSH スクリプトの構成設定                  | Windows Script Host (`wscript.exe`、`cscript.exe`)          |
| .jar      | Java Archive               | 単一ファイルとしてパッケージ化された Java アプリケーション             | `java.exe` (コンソール) / `javaw.exe` (コンソールウィンドウなし)       |
| .hta      | HTML Application (HTA)     | HTML、CSS、JScript/VBScript を使った GUI ベースの Windows スクリプト | `mshta.exe` (Microsoft HTML Application Host)          |
| .com      | MS-DOS アプリケーション / DOS 実行ファイル | レガシーな実行プログラム、小さなコマンドラインユーティリティ | プログラムとして直接実行される; モダン Windows では、クラシックな 16 ビット .com プログラムは 32 ビット Windows の NTVDM を通じて実行され、x64/ARM Windows ではネイティブにサポートされない |
| .chm     | コンパイル済み HTML ヘルプ          | Windows プログラム用のオフラインヘルプ/ドキュメントファイル   | `hh.exe` (Microsoft HTML Help Viewer)                           |

## スタートアップ/ログオンスクリプト

スタートアップおよびログオンスクリプト (およびシャットダウンまたはログオフ) は、ドメイン参加コンピューター上またはユーザーのサインイン時に自動的に実行される (gpscript.exe) 自動化スクリプトであり、Windows Active Directory 環境のドメインコントローラーからグループポリシーオブジェクト (GPO) を使用して展開されるのが一般的である。

スタートアップ/シャットダウン
- 実行アカウント: Local System アカウント (高い権限)。

ログオン/ログオフ
- 実行アカウント: 現在のユーザー (管理者の場合は高い権限)。
### 一般的な用途:
- すべてのユーザー向けのネットワークドライブのマッピング
- ソフトウェアのインストール
- システム全体の設定の適用
- サービスの開始または構成
- スクリプトまたは実行ファイルの実行

### 影響を受けるレジストリハイブ

GPO 経由でスタートアップ/ログオンスクリプトが実行されると:

| ハイブ / パス | 目的 |
|-------------|---------|
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logon | ユーザーログオンスクリプト、その実行順序、ステータス、最終実行時刻、パラメータを追跡する。 |
| HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Logoff | ログオフスクリプトについて同様の追跡を行う。 |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Startup | スタートアップスクリプト (すべてのユーザーに適用) の追跡情報。 |
| HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown | シャットダウンスクリプトの情報。 |

#### gpscript.exe の子プロセス内でスクリプトおよび実行ファイルのユーザー書き込み可能なパス、または書き込み可能なネットワーク共有や genereic (SYSVOL) を探す。 
実行されるスクリプトを読み、他のユーザー書き込み可能なパスや存在しないパス、機密情報などの設定ミスがないか確認する。使用されている可能性のあるパスワード (net use z: \\server\share /user:domain\username password) やその他の機密情報を探す。 

**ログオンスクリプトの設定ミスカテゴリ**
- SS1 – 平文の資格情報
- SS2 – 安全でないアクセス許可 (一般ユーザーが変更可能なログオンスクリプト)
- SS3 – 存在しない共有 (一般ユーザーが作成可能な場合がある)
- SS4 - ログオンスクリプトを持つ管理者

**ログオンスクリプトの設定ミス**

1. SS1 - ログオンスクリプト内の平文の資格情報
2. SS2 - 安全でない共有アクセス許可
3. SS2 - 安全でないファイルアクセス許可
4. SS2 - 安全でない NETLOGON/SYSVOL アクセス許可
5. SS2 - 安全でないログオンスクリプトのアクセス許可
6. SS2 - 安全でない GPO ログオンスクリプトのアクセス許可
7. SS3 - 存在しない共有
8. SS4 - ログオンスクリプトを持つ管理者
9. SS4 - 存在しない共有からマップされたログオンスクリプトを持つ管理者



## MSIExec / MSI 修復
##### 我々のテストでは、edge を起動して cmd プロンプトに脱出できるシナリオで権限昇格の結果は得られなかった。これはおそらく、chromium ベースのブラウザがユーザーを偽装し/レンダリングプロセスを SYSTEM として実行するよう制限しており、internet explorer/edge が SYSTEM ユーザーとして cmd やその他のプロセスを起動することを許可していないためである。chromium ベースでないブラウザ (firefox など) または古いバージョンがインストールされている場合、そのようなプロセスを起動してコマンドプロンプトに脱出できれば、権限昇格が可能であると考えられる。

これに関連する可能性のあるイベントを列挙したい場合は、親プロセスとして msiexec.exe を持ち、子プロセスとして cmd.exe または conhost.exe または powershell.exe または pwsh.exe を持つものをクエリする。
クエリで結果が得られたユーザーに連絡し、何をインストール/修復したかを尋ねる。また、event.provider: "MsiInstaller" および event.code: (1033 OR 11707) または類似のものを確認して、同じタイムスタンプ付近でどの msi インストーラーがインストールされたかについてより多くのコンテキストを得ることもできる。
Software Center で自分でこれを試し、アプリケーションをインストールして、ウィンドウ内のセクションをマークすることで消える前に一時停止できるコマンドプロンプトを探すこともできる。その後、以下のリンクで言及されているのと同じテクニックを使って脱出する。



##### クエリ例```
(event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1 AND winlog.event_data.IntegrityLevel: System AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))
OR
(event.provider: Microsoft-Windows-Security-Auditing AND event.code: 4688 AND winlog.event_data.TokenElevationType: "%%1936" AND winlog.event_data.MandatoryLabel: "S-1-16-16384" AND process.parent.name: msiexec.exe AND process.name: (cmd.exe OR conhost.exe OR powershell.exe OR pwsh.exe))