Microsoft Security Research / Microsoft Defender が公開した Sapphire Sleet の macOS 侵入チェーン分析は、Mac セキュリティチームと Threat hunter にとって「どこを監視すべきか」を具体化する材料になります。結論から言えば、この事例で最も重要なのは、未知の脆弱性よりもユーザーに実行させる誘導、AppleScript、curl から osascript への連鎖、TCC データベース操作、LaunchDaemon 永続化、認証情報とウォレット情報の持ち出しを一つの流れとして見ることです。
2026年4月17日時点の更新として注目すべきポイントは、Sapphire Sleet が macOS の正規ツールやユーザー操作の文脈を悪用し、従来の「怪しいマルウェア実行」だけでは見落としやすい侵入経路を組み立てている点です。Microsoft はこのキャンペーンについて、ソフトウェア脆弱性の悪用ではなくソーシャルエンジニアリングを軸に、偽の Zoom SDK 更新ファイル、AppleScript、偽のシステム更新ダイアログ、TCC 回避、バックドア、データ窃取までの流れを詳しく分析しています。 (Microsoft)
Microsoft Security Research / Microsoft Defender の最新動向として見るべき理由
Microsoft Security Research / Microsoft Defender の今回の分析は、単なるマルウェア解説ではありません。防御側が実務で使える形で、初期誘導から侵害完了までの「lure-to-compromise path」を分解している点に価値があります。
特に Mac 環境では、「macOS は比較的安全」「ユーザーが許可しなければ実行されにくい」という前提に頼りすぎると、攻撃者が正規ツールと自然な操作フローを悪用したときに検知が遅れます。今回の事例では、Script Editor、osascript、curl、Finder、LaunchDaemon、TCC.db など、管理者や開発者の端末では日常的に見かける要素が攻撃チェーンに組み込まれています。
Threat hunter が学ぶべきことは、個別の IOC だけを追うことではありません。「なぜそのプロセスが、その親プロセスから、そのタイミングで、そのファイルや通信先にアクセスしたのか」をつなげて見る姿勢です。
Sapphire Sleet の macOS 侵入チェーンの全体像
Microsoft の分析によると、Sapphire Sleet は北朝鮮系の脅威アクターとして追跡されており、暗号資産、金融、ブロックチェーン、ベンチャーキャピタルなど、高価値な資産や技術情報を持つ組織を狙う傾向があります。今回の macOS キャンペーンでは、偽の採用担当者や技術面接を装うソーシャルエンジニアリングにより、ターゲットに「Zoom SDK Update.scpt」のようなファイルを実行させる流れが観測されています。 (Microsoft)
侵入チェーンを防御側の視点で整理すると、次のようになります。
| フェーズ | 攻撃側の動き | 防御側が見るべき観点 |
|---|---|---|
| 誘導 | 求人、面接、会議ツール更新などを装ってファイル実行を促す | 外部接触からソフトウェア導入に誘導されていないか |
| 初期実行 | .scpt ファイルを Script Editor で開かせる | Script Editor から curl、osascript、shell が起動していないか |
| ペイロード取得 | curl で外部から AppleScript や ZIP を取得 | curl の User-Agent、親プロセス、パイプ実行を確認 |
| 認証情報窃取 | 偽の systemupdate.app で macOS パスワード入力を促す | 不自然なパスワードダイアログ、dscl 認証確認を監視 |
| 永続化 | LaunchDaemon や Apple/Google 風の名前でバックドアを配置 | /Library/LaunchDaemons/ とユーザー配下 Library を監査 |
| 権限・回避 | TCC.db を操作して AppleEvents 権限を付与 | TCC データベースのコピー、変更、リネームを検知 |
| 収集・持ち出し | ブラウザ、Keychain、Telegram、SSH、ウォレット、Notes を収集 | ZIP 作成、tmp 配下のステージング、外部アップロードを追跡 |
この表で重要なのは、どのフェーズも単独では「管理者や開発者の通常作業」に見える可能性があることです。たとえば curl、osascript、zip、sqlite3、launchctl は、それぞれ単体では珍しいコマンドではありません。しかし、Script Editor を起点に短時間で連鎖し、TCC.db や Keychain、ブラウザプロファイル、ウォレット関連ディレクトリへアクセスするなら、優先的に調査すべきシグナルになります。
初期侵入で注目すべきは「ファイル名」より「実行文脈」
今回の誘導ファイルは、Zoom SDK 更新を装う AppleScript でした。Microsoft の分析では、ファイルを開くと macOS の Script Editor が既定で起動し、見た目上は正規のアップデート手順のように見えるコメントが表示される一方、実際の悪意ある処理は大量の空白行の下に隠されていたと説明されています。さらに、正規の macOS softwareupdate バイナリを呼び出すことで、ユーザーに「本当にアップデートが動いている」と思わせる工夫も含まれていました。 (Microsoft)
防御側がここから学ぶべき点は、ファイル名や拡張子だけに頼らないことです。Zoom SDK Update.scpt のような名前は一例にすぎません。将来は別の会議ツール、開発 SDK、社内ツール、暗号資産ウォレット、VPN クライアントなどに置き換えられる可能性があります。
実務では、次のような条件を組み合わせて監視すると効果的です。
| 監視条件 | 優先度 | 理由 |
|---|---|---|
| Script Editor から curl、osascript、sh、bash、zsh が起動 | 高 | .scpt を入口にした多段実行を捉えやすい |
ダウンロード直後の .scpt 実行 | 高 | ソーシャルエンジニアリング由来の実行と相性が高い |
| 外部 URL から取得した内容をインタプリタへ渡す | 高 | ディスク上の検体を残さない実行に使われやすい |
| 会議ツール、SDK、更新ファイル風の名前 | 中 | 誘導テーマの手掛かりになるが、名称変更に弱い |
| ユーザーが外部チャットや面接経由で受け取ったファイル | 高 | 技術面接型の侵入で重要なコンテキストになる |
「Zoom だから危険」ではなく、「外部から受け取った更新ファイルを、Script Editor 経由で実行し、さらに外部から追加コードを取得している」ことが危険です。この粒度で検知ロジックを設計すると、攻撃者がファイル名を変えても追跡しやすくなります。
curl から osascript への連鎖は Mac hunting の重要シグナル
Microsoft の分析では、Sapphire Sleet は mac-cur1 から mac-cur5 のような User-Agent を使い分け、AppleScript ペイロードや ZIP アーカイブを段階的に取得していました。mac-cur1 はオーケストレーターとして動作し、偵察、ホスト監視コンポーネント、バックドア、資格情報窃取コンポーネントなどを並行して展開する流れが確認されています。 (Microsoft)
Threat hunter は、特定の User-Agent だけを IOC として追うのではなく、以下のような振る舞いを検知軸にするべきです。
| ハンティング観点 | 確認する内容 |
|---|---|
| 親子プロセス | Script Editor → osascript → curl、または osascript → shell の連鎖 |
| コマンドライン | curl の出力を osascript、sh、bash に渡す実行 |
| User-Agent | 既定の curl ではない独自文字列、不自然に短い識別子 |
| 取得先パス | /version/ や /status/ のように段階別に使い分けられた URL |
| 実行タイミング | ユーザーがファイルを開いた直後に複数の外部通信が発生 |
| 端末属性 | 開発者、暗号資産担当、財務部門など高価値ユーザーの端末 |
Microsoft Defender XDR の Advanced Hunting を使う場合、Microsoft が提示している考え方と同様に、まずは「osascript 実行時に curl が絡むイベント」を起点にします。たとえば、防御目的の調査では次のような観点が有効です。
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName == "osascript" or InitiatingProcessFileName == "osascript"
| where ProcessCommandLine has "curl"
| where ProcessCommandLine has_any ("osascript", "| sh", "| bash")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessCommandLine, InitiatingProcessFileNameこのクエリで見つかったイベントは、すぐに悪性と決めつけるのではなく、次の順で確認します。
- 実行したユーザーが開発者や管理者か、一般ユーザーか
- 実行元が社内スクリプト、MDM、CI/CD、手動実行のどれか
- 外部 URL が既知の業務ドメインか、不明な新規ドメインか
- 実行後に LaunchDaemon、TCC.db、Keychain、ブラウザプロファイルへのアクセスが続いていないか
- 同じ端末で ZIP 作成や外部アップロードが発生していないか
この順序で見ると、誤検知を減らしつつ、侵害チェーンの途中で検知できる可能性が上がります。
偽のパスワードダイアログ対策は「ユーザー教育」だけでは足りない
今回の事例では、systemupdate.app と名付けられた悪意あるアプリが、macOS の正規プロンプトに似たパスワード入力画面を表示し、ユーザーに更新完了のためのパスワード入力だと思わせる流れが観測されています。入力されたパスワードはローカル認証データベースで検証され、正しいことを確認したうえで外部へ送信される構成でした。 (Microsoft)
ここでありがちな失敗は、「怪しいパスワード入力画面に注意しましょう」という教育だけで終わることです。実際の業務では、ユーザーが面接中、会議中、トラブル対応中に急かされていれば、正規の更新画面と偽画面を見分けるのは簡単ではありません。
対策は、教育、技術制御、運用ルールを組み合わせる必要があります。
| 対策 | 実務での実装例 |
|---|---|
| 教育 | 外部の面接、商談、採用連絡で送られたスクリプトやコマンドは実行しないと明文化 |
| 承認フロー | 会議ツールや SDK の更新は公式サイト、MDM、社内ポータル経由に限定 |
| 技術制御 | 未署名アプリ、外部取得 .scpt、不審な Mach-O の実行を制限 |
| 検知 | dscl -authonly の不自然な実行、偽装アプリ名、tmp 配下のアプリ起動を監視 |
| 事後対応 | パスワード入力が疑われたら即時リセット、Keychain とブラウザ保存情報も調査 |
特に暗号資産や財務関連の端末では、OS パスワードが漏れた時点で Keychain、ブラウザ保存パスワード、ウォレット関連データの復号や悪用につながる恐れがあります。単にアカウントのパスワードを変えるだけでなく、ブラウザセッション、SSH キー、ウォレット、API キー、Telegram などのセッションも確認対象に含めるべきです。
TCC.db 操作は macOS 防御で見逃してはいけない
macOS の TCC は、カメラ、マイク、フルディスクアクセス、AppleEvents など、プライバシーや機密データに関わるアクセス許可を管理する仕組みです。今回の攻撃では、Sapphire Sleet がユーザー配下の TCC.db を操作し、osascript が Finder に AppleEvents を送れるようにすることで、ユーザーへの許可プロンプトを出さずに大規模なデータ収集へ進んだと説明されています。 (Microsoft)
Mac セキュリティチームにとって、TCC.db は「侵害後に見る forensic artifact」ではなく、「侵害進行中に検知すべき制御点」です。次のようなイベントは、優先度を上げて調査する価値があります。
| 監視対象 | 調査ポイント |
|---|---|
~/Library/Application Support/com.apple.TCC/TCC.db | 作成、変更、リネーム、コピーの有無 |
| Finder 経由のフォルダ操作 | 通常業務では説明しづらい TCC フォルダ操作 |
| sqlite3 実行 | TCC.db への直接的な書き込みや access テーブル操作 |
| osascript と Finder の組み合わせ | AppleEvents 権限を悪用したファイル操作の可能性 |
| TCC 変更後の大量ファイルアクセス | ブラウザ、Keychain、Notes、Telegram、ウォレットへの展開 |
Microsoft Defender XDR では、TCC.db の変更イベントを起点にハンティングできます。
DeviceFileEvents
| where Timestamp > ago(30d)
| where FolderPath has "com.apple.TCC" and FileName == "TCC.db"
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| project Timestamp, DeviceName, ActionType, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLineこの検知は、単体ではノイズが出る場合があります。OS 更新、MDM、正規のセキュリティ製品が TCC 関連ファイルに触れることもあるためです。重要なのは、TCC.db の変更と同じ時間帯に、osascript、Finder、curl、zip、LaunchDaemon 作成、外部通信が連続していないかを確認することです。
永続化の見方：Apple 風・Google 風の名前に惑わされない
今回の攻撃では、com.apple.cli、services、icloudz、com.google.chromes.updaters、com.google.webkit.service.plist のように、Apple や Google の正規コンポーネントに見える名前が使われています。Microsoft の分析では、LaunchDaemon を使った永続化や、メモリ上で追加ペイロードを読み込む挙動、60秒間隔のビーコンなども説明されています。 (Microsoft)
ここから分かるのは、ファイル名の「それっぽさ」を信用してはいけないということです。Mac の調査では、次の観点で確認します。
| 確認項目 | 見るべきポイント |
|---|---|
| 配置場所 | /Library/LaunchDaemons/、~/Library/Application Support/、~/Library/Google/ など |
| 命名 | com.apple.*、com.google.* 風だが実ベンダーと一致しないもの |
| 署名 | Apple、Google、Microsoft など正規署名の有無 |
| 親プロセス | osascript、zsh、curl、Script Editor から配置されていないか |
| 権限 | sudo、launchctl、所有者変更、実行権限付与の有無 |
| 通信 | 起動後に外部 C2 らしき宛先へ定期通信していないか |
Microsoft が示すハンティング例と同じ考え方で、LaunchDaemon 配下に作成された Apple/Google 風 plist を確認するのは有効です。
DeviceFileEvents
| where Timestamp > ago(30d)
| where FolderPath startswith "/Library/LaunchDaemons/"
| where FileName startswith "com.google." or FileName startswith "com.apple."
| where ActionType == "FileCreated"
| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256ただし、これは「Apple や Google の名前があるから危険」という意味ではありません。正規ソフトも同様の命名規則を使います。署名、インストール元、作成時刻、親プロセス、同時発生イベントを合わせて判断してください。
収集・持ち出しの対象から逆算して防御する
Sapphire Sleet の攻撃チェーンで特に重要なのは、最終的な目的が明確なことです。Microsoft の分析では、Telegram セッション、Chromium 系ブラウザのプロファイル、保存認証情報、Cookie、Keychain、暗号資産ウォレット、SSH キー、shell history、Apple Notes などが収集対象として挙げられています。 (Microsoft)
これは、Mac セキュリティチームが守るべき資産の優先順位を示しています。
| 資産 | リスク | 推奨アクション |
|---|---|---|
| ブラウザ保存パスワード | Cookie や保存認証情報からアカウント乗っ取りに発展 | 重要システムでは保存パスワードを制限し、セッション失効手順を整備 |
| Keychain | OS パスワード窃取後に復号される恐れ | パスワード入力疑いがあれば Keychain 関連も調査 |
| Telegram セッション | 再認証なしでセッション悪用される可能性 | 侵害時は全デバイスからログアウト、2段階認証を確認 |
| SSH キー | 横展開、クラウド環境、開発環境への侵入に悪用 | 鍵のローテーション、利用履歴確認、不要鍵削除 |
| shell history | 内部ホスト名、接続先、運用習慣が漏れる | 履歴に秘密情報を残さない運用を徹底 |
| 暗号資産ウォレット | 直接的な資産流出につながる | ハードウェアウォレット、署名端末分離、承認フローを導入 |
| Apple Notes | パスワード、復旧キー、内部メモが保存されがち | 機密情報を Notes に保存しないルールを明文化 |
「どのマルウェアか」を追うだけではなく、「何を盗られたら事業影響が大きいか」から逆算してログと制御を設計することが重要です。暗号資産、金融、開発、経営層の Mac では、一般従業員端末よりも強い制御が必要になります。
Microsoft Defender で優先して確認したい検知ポイント
Microsoft は今回の分析で、Microsoft Defender Antivirus と Microsoft Defender for Endpoint による検知名や、Microsoft Defender XDR の Advanced Hunting クエリを提示しています。初期アクセス、実行、永続化、TCC 操作、認証情報窃取、収集・持ち出し、C2 通信まで、複数フェーズにまたがる検知カバレッジが示されています。 (Microsoft)
実務では、いきなりすべてのクエリを本番アラートにするより、次の順で進めると失敗しにくくなります。
| 優先度 | 実施内容 | 目的 |
|---|---|---|
| 1 | Script Editor、osascript、curl の連鎖を過去30日で検索 | 初期実行の有無を把握 |
| 2 | TCC.db の変更、LaunchDaemon 作成を確認 | 権限回避と永続化を確認 |
| 3 | tmp 配下 ZIP 作成、curl アップロードを確認 | データ持ち出しの兆候を確認 |
| 4 | Defender の検知名、脅威分析レポート、IOC に照合 | 既知キャンペーンとの一致を確認 |
| 5 | 高リスクユーザー端末を重点的に調査 | 調査工数を重要資産に集中 |
特に Mac 端末では、Windows 端末と比べてログの見方や管理ルールが組織内で成熟していないことがあります。Microsoft Defender for Endpoint on Mac を導入している場合でも、導入だけで安心せず、macOS 固有のプロセス、TCC、LaunchDaemon、ユーザー配下 Library の監視を運用に落とし込むことが大切です。
すぐ使える Mac 向けハンティング観点
今回のケーススタディをもとに、Threat hunter がすぐに確認しやすい観点を整理します。
Script Editor 起点の不審な子プロセス
.scpt ファイルを入口にした攻撃では、Script Editor から外部取得やシェル実行が発生します。通常業務で Script Editor を使う組織でも、親子関係を見れば異常を絞り込めます。
確認すべき組み合わせは、次の通りです。
| 親プロセス | 子プロセス | 判断ポイント |
|---|---|---|
| Script Editor | curl | 外部 URL から追加コードを取得していないか |
| Script Editor | osascript | 多段 AppleScript 実行がないか |
| Script Editor | sh / bash / zsh | 手動実行に見せたシェル起動がないか |
| osascript | curl | 取得したスクリプトを再実行していないか |
| osascript | zip | データ圧縮やステージングがないか |
不審なパスからの Mach-O 実行
今回の事例では、ユーザー配下や一時ディレクトリに配置されたコンポーネントが使われています。管理者は、次のような場所からの実行に注意します。
| パスの例 | 注意すべき理由 |
|---|---|
/private/tmp/ 配下 | 一時展開されたアプリやツールの実行に使われやすい |
~/Library/Application Support/ 配下 | 正規アプリのデータに紛れ込みやすい |
~/Library/Google/ 配下 | Google 関連に見せかけた配置が可能 |
~/Library/Services/ 配下 | ユーザー配下で目立ちにくい |
/Library/LaunchDaemons/ 配下 | 再起動後の永続化に直結する |
データ収集後の圧縮とアップロード
データ持ち出しでは、収集したファイルを一時ディレクトリに集め、ZIP 化してアップロードする流れがよく使われます。今回の事例でも、複数カテゴリのデータが圧縮・アップロード対象になっています。 (Microsoft)
次のような動きが同時に起きていれば、優先的に調査します。
zip、ditto、tarなどによる短時間の大量圧縮/tmp/、/private/tmp/配下へのファイル集約- ブラウザプロファイル、Keychain、Telegram、SSH、Notes への連続アクセス
- 圧縮直後の curl アップロード
- ユーザー操作がない時間帯の大量ファイルアクセス
防御側がやりがちな失敗
IOC だけを登録して終わる
Microsoft が示したドメイン、IP、ファイルハッシュは有用です。ただし、IOC は変わります。攻撃者がインフラやハッシュを変えれば、単純な照合だけでは検知できません。
IOC は「過去に該当がないか」を確認するために使い、継続検知は振る舞いベースに寄せるべきです。たとえば、curl → osascript、TCC.db 操作、LaunchDaemon 作成、Keychain とブラウザデータの連続アクセスといった組み合わせは、IOC より長く使える検知軸になります。
Mac を例外扱いにする
Windows 端末では EDR や SIEM 連携が進んでいても、Mac は開発者や役員向けに例外運用されがちです。これが攻撃者にとって狙い目です。
特に開発者 Mac には、SSH キー、クラウド認証情報、Git 認証情報、API トークン、内部ドキュメント、ブラウザセッションが集まりやすく、侵害時の影響が大きくなります。Mac を「管理しにくい端末」ではなく、「高価値な侵入口」として扱う必要があります。
ユーザー教育を一度きりにする
今回のようなソーシャルエンジニアリングは、技術的に高度なユーザーにも有効です。開発者やセキュリティ担当者でも、採用面接、外部打ち合わせ、PoC、SDK 検証の文脈では、普段より警戒が下がることがあります。
教育では「怪しいリンクに注意」では不十分です。次のように、行動ルールまで具体化します。
| NG 行動 | 推奨ルール |
|---|---|
| 外部チャットで送られたコマンドを貼り付ける | IT またはセキュリティ担当に確認してから実行 |
| 面接相手から受け取った SDK をその場で実行 | 公式サイト、社内検証環境、隔離端末で確認 |
| パスワード入力画面が出たらそのまま入力 | 直前の操作、アプリ名、署名、配布元を確認 |
| 暗号資産ウォレットを業務端末で常用 | 署名端末やハードウェアウォレットで分離 |
| ブラウザに重要認証情報を保存 | パスワードマネージャーと条件付きアクセスを活用 |
Mac セキュリティチームが次に取るべき行動
今回の Microsoft Security Research / Microsoft Defender の分析を読んだあと、Mac セキュリティチームが最初にやるべきことは、長いレポートをそのまま運用に貼り付けることではありません。自社の Mac 環境に合わせて、検知、制御、教育、対応手順に分解することです。
まずは、次の5つを実施してください。
| 優先度 | アクション | 目安 |
|---|---|---|
| 1 | 過去30日分で Script Editor、osascript、curl の連鎖を検索 | すぐ実施 |
| 2 | TCC.db 変更と LaunchDaemon 作成をハンティング | すぐ実施 |
| 3 | 高リスクユーザーの Mac を重点調査 | 暗号資産、財務、開発、役員から開始 |
| 4 | .scpt、未署名 Mach-O、外部取得スクリプトの制御方針を決める | MDM / EDR / 運用で調整 |
| 5 | 外部面接・商談・採用連絡での実行禁止ルールを周知 | 具体例付きで教育 |
Microsoft Defender を利用している組織では、Defender XDR の Advanced Hunting、Defender for Endpoint on Mac、クラウド保護、ネットワーク保護、脅威分析レポートを組み合わせることで、今回のような攻撃チェーンを複数フェーズで捉えやすくなります。Microsoft は、Defender for Endpoint on Mac、クラウド提供の保護、自動サンプル送信、PUA 保護、ネットワーク保護などの利用も推奨しています。 (Microsoft)
重要なのは、Mac 向け対策を「Windows セキュリティの付け足し」にしないことです。macOS には TCC、Gatekeeper、LaunchDaemon、Keychain、AppleScript、ユーザー配下 Library という固有の調査ポイントがあります。Sapphire Sleet の事例は、それらを攻撃者がどうつなげるかを具体的に示しています。
最後に整理すると、防御側が得るべき教訓は3つです。第一に、初期侵入は脆弱性ではなくユーザー誘導から始まることがあります。第二に、Mac の正規ツールは攻撃チェーンの一部として悪用されます。第三に、検知は IOC だけでなく、Script Editor 起点の多段実行、TCC.db 操作、LaunchDaemon 永続化、資格情報とウォレット情報の持ち出しを一連の流れとして見る必要があります。
まずは自社の Microsoft Defender XDR や EDR ログで、Script Editor から curl や osascript が起動したイベントを確認してください。そこから TCC.db、LaunchDaemon、Keychain、ブラウザプロファイル、外部アップロードへ調査を広げることで、Mac-focused intrusion の早期発見につながります。
コメント