Macだから安全、ではない

MacSync Stealerが突きつけるクラウド資格情報流出リスクと企業対応

確認基準日：2026年8月20日

企業のサイバーセキュリティ対策では、今もなお「MacはWindowsより攻撃されにくいから、監視も少し軽くてよい」という考え方が残っていることがあります。

しかし、クラウドを利用する現在の企業環境では、この考え方は危険です。

2026年8月18日、Microsoft Defender ExpertsとMicrosoft Security Researchは、macOSを狙う情報窃取型マルウェア「MacSync Stealer」に関する調査結果を公表しました。

Microsoftが確認した活動では、利用者をだましてTerminalでコマンドを実行させるClickFix型のソーシャルエンジニアリングと整合するところから攻撃が始まり、Keychain、ブラウザ認証情報、Cookie、セッション情報、SSH鍵、クラウド資格情報、AWS credentials、Kubernetes configuration、機密ファイルなどを収集し、圧縮、分割した上でHTTP PUTによって外部へ送信するところまで確認されています。

さらにMicrosoftは、単一のC2ドメインを追跡するのではなく、実行プロセス、コマンドライン、URI、HTTP header、アップロード方法などの「行動」を相関させることで、30を超える関連ドメインを結び付けています。

結論から言えば、今回の事案を「Mac向けマルウェアが増えている」という話だけで終わらせるべきではありません。

企業が考えるべきなのは、

Endpoint → Identity → Cloud → Data → Contract → Report

という一連の流れです。

MacがAzure、Microsoft Entra、Microsoft 365、AWS、GitHub、SSH、Kubernetesなどへ接続する業務端末であるなら、Macの侵害は「端末1台の問題」から「企業IDとクラウド資格情報の問題」へ変わります。

1．MacSync Stealerとは何か

Microsoft Security BlogはMacSync Stealerを、macOSを対象とする情報窃取型マルウェアとして説明しています。

特徴的なのは、攻撃インフラを頻繁に切り替える点です。

従来型の防御では、

「悪性ドメインAを発見した」「ファイアウォールへ登録した」「EDRのIOCへ追加した」

という対応がよく行われます。

しかし、攻撃者がドメインを短期間で切り替える場合、静的IOCだけを追跡していると、防御側は常に後追いになります。

Microsoft Defender Expertsはそこで、ドメイン名そのものではなく、複数のエンドポイント・ネットワーク挙動を相関させました。その結果、30を超えるドメインを関連インフラとして結び付け、これらが単なるC2通信だけでなく、データの収集、ステージング、外部送信にも使われていることを確認しました。

今回の調査が示している重要な教訓は、

「IOCを追うセキュリティ」から「攻撃者の行動を追うセキュリティ」へ移行する必要がある

ということです。

2．攻撃は「マルウェアをクリック」ではなくTerminalから始まる

Microsoftが確認した実行は、対話型のzsh Terminal sessionから始まっています。

これはClickFix型ソーシャルエンジニアリングと整合する動作です。

ClickFixでは、利用者に、

「この問題を解決するにはTerminalへこのコマンドを貼り付けてください」

といった操作をさせ、ユーザー自身の手で悪意あるコマンドを実行させることがあります。

MacSync StealerでMicrosoftが確認した流れは、対話型shellからcurlで攻撃者側のペイロードを取得し、base64やgunzipなどmacOSに存在するツールでデコード・展開した後、osascriptを利用したAppleScript支援型処理へ進むものです。

技術的に重要なのは、多くの工程でmacOS標準の機能やコマンドが利用されていることです。

zsh、curl、base64、gunzip、osascript、cp、rm、mkdirなどは、それ自体がマルウェアではありません。

そのため、

「このプロセスが動いたら即マルウェア」

という単純な検知ではなく、

誰が → 何を起点に → どのプロセスを起動し → その直後に何へ通信し → 何を読み → 何を圧縮し → どこへ送信したか

という前後関係を見る必要があります。

Microsoft自身も、不審なTerminalやshell利用、AppleScript支援型実行、curlによる取得、credential storeへのアクセス、一時領域へのステージング、アーカイブ作成などを相関して確認することを推奨しています。

3．攻撃者が狙うのは「Macのパスワード」だけではない

今回、企業にとって特に重要なのは収集対象です。

Microsoftは、MacSync StealerがmacOS Keychain関連情報だけでなく、ブラウザのSafe Storage key、ブラウザ認証情報、Cookie、login database、session data、IndexedDB、LevelDB、extension storage、Safari data、Apple Notes、SSH key、AWS credentials、Kubernetes configurationなどを対象としていたことを確認しています。

さらに、Downloads、Documents、Desktop等から、PDF、DOCX、TXT、KEY、PEM、KDBX、OVPN、WALLET、SEEDなどのファイルも収集対象として確認されています。

ここに、現代の情報窃取型マルウェアの怖さがあります。

企業が対策すべき「資格情報」は、

種類	想定されるリスク
ID・パスワード	アカウントへの不正ログイン
Browser Cookie / Session	セッション再利用
Keychain	保存済み資格情報へのアクセス
SSH Key	サーバー・Git環境等へのアクセス
PEM	証明書・秘密鍵の悪用
AWS credentials	クラウド環境へのアクセス
Kubernetes config	Cluster/APIへのアクセス
OVPN	VPN接続への悪用
KDBX	Password Manager情報の窃取
業務文書	個人情報・機密情報の漏えい

となります。

つまり、「パスワードを変更したから対応終了」とは限りません。

SSH鍵や証明書、API Key、クラウドcredential、既存sessionまで窃取されていれば、別のcredential rotationが必要になります。

4．収集したデータは実際に外部送信されていた

今回の調査で非常に重要なのは、Microsoftが単なるC2へのbeaconingだけではなく、active data exfiltrationを確認していることです。

収集されたデータは/tmp/sync*配下などの一時領域へステージングされ、/tmp/osalogging.zipへ圧縮された後、複数のchunkへ分割されていました。

そしてcurlとHTTP PUT、--data-binaryを利用して攻撃者側へ送信されていました。

Microsoftが確認したupload parameterには、

upload_id

chunk_index

total_chunks

などがあります。

さらに外部送信後、malwareはtemporary archive、staging folder、lock file等を削除していました。

つまり、

収集 → 圧縮 → 分割 → 転送 → 証拠削除

までが一連の処理として確認されています。

インシデント対応で「感染したMacをすぐ初期化する」という判断をした場合、さらに証拠を失う可能性があります。

5．なぜドメインブロックだけでは不十分なのか

MicrosoftがMacSync Stealerの追跡に利用したのは、単一のFQDNではありません。

複数のドメインを横断して繰り返される、

観点	確認された例
Payload取得	/curl/
C2通信	/dynamic?txd=
Exfiltration	/gate?buildtxd=
Header	api-key
Upload method	HTTP PUT
Curl option	--data-binary
Upload ID	upload_id=
分割番号	chunk_index=
総分割数	total_chunks=

などです。

ドメインは攻撃者が交換できます。

しかし攻撃ツールの実装やC2 APIの設計、データ転送方式をすべて短期間で変更するにはコストがかかります。

そのため、Infrastructure IOCよりもBehavioural Pivotの方が長く使える場合があります。

これが今回のMicrosoft調査の中心です。

6．Defender XDRで何をハンティングするか

MicrosoftはDefender XDR向けAdvanced Hunting Queryも公開しています。

防御側では例えば、curlによる通信でMacSync Stealerに特徴的なURI parameterが現れていないかを確認できます。Microsoftの公開Queryを基礎に、自社環境向けに期間、端末、allowlistを調整することが前提です。

DeviceNetworkEvents
| where InitiatingProcessFileName =~ "curl"
| where RemoteUrl has_any (
    "/curl/",
    "/dynamic?txd=",
    "/gate?buildtxd=",
    "upload_id=",
    "chunk_index=",
    "total_chunks="
)
| project
    Timestamp,
    DeviceName,
    InitiatingProcessAccountName,
    InitiatingProcessCommandLine,
    RemoteUrl,
    RemoteIP
| order by Timestamp desc

また、curlによるHTTP PUT型の送信を確認する場合は、通信先だけでなくCommand Lineも併せて確認します。

DeviceNetworkEvents
| where InitiatingProcessFileName =~ "curl"
| where InitiatingProcessCommandLine has_all ("-X PUT", "--data-binary")
| where RemoteUrl has_any (
    "upload_id=",
    "chunk_index=",
    "total_chunks=",
    "/gate?buildtxd="
)
| project
    Timestamp,
    DeviceName,
    InitiatingProcessCommandLine,
    RemoteUrl

さらにosascriptからshellやcurl等が呼ばれる流れもハンティング対象になります。MicrosoftはMacSync Stealerに関連して、osascript、shell command、credential-store access、archive creation、file deletionなどをDefender for Endpointで検知・調査できる活動として整理しています。

ただし、ここで注意が必要です。

これらのコマンドやURIの一部に一致しただけで、

「MacSync Stealer感染確定」

と判断することはできません。

正規管理スクリプト等との誤検知を避けるため、

Process ancestry + Command line + Network + File operation + User context

を相関させる必要があります。

7．macOS 26.4以降ではApple側にもClickFix対策が入った

AppleもTerminalを利用するソーシャルエンジニアリングへの対策を強化しています。

AppleのPlatform Security資料では、macOS 26.4以降にTerminal paste protection、AppleScript scanning等のセキュリティ強化が導入されていることが確認できます。Webブラウザやメッセージングアプリ等からTerminalへコマンドを貼り付ける場合の警告や、既知の悪意あるスクリプトをXProtectが検査・遮断する仕組みが説明されています。

これは非常に有効な防御です。

しかし、

OSの保護機能がある＝企業側のEDRやログ監視が不要

ではありません。

利用者によるoverride、別経路での実行、未知のマルウェア、既に侵害済みの端末なども考慮する必要があります。

OS、EDR、MDM、Identity、Conditional Accessを重ねることがZero Trustの基本になります。

8．MacもDefender XDRの監視対象にする

Microsoft Defender for Endpoint on macOSは、Mac端末について「prevent、detect、investigate、respond」の機能を提供し、Microsoft Defender portalからEDR、Advanced Hunting、Response Action等を利用できるとMicrosoftは説明しています。公式資料の最終更新日は2026年6月17日です。

特に企業環境では、

「MacだからEDRを入れない」

「開発者PCなので例外」

「クリエイター端末なので管理外」

という運用は再検討すべきです。

クラウド資格情報を保有する端末ほど、監視対象に含める必要があります。

9．IntuneでDefender for EndpointをmacOSへ展開する

MicrosoftはIntuneを使用したDefender for Endpoint on macOSの展開手順も公開しています。

公式手順では、System Extension、Network Extension、Full Disk Access、Defender設定、Background Services、Notification、Microsoft AutoUpdate、Device Control、DLP、Onboarding packageなど、多数の構成要素があります。

特にNetwork Extensionは重要です。

Microsoftによると、Defender for Endpoint on macOSはEDR機能の一部としてsocket trafficを検査し、その情報をDefender portalへ送信します。そのためNetwork Extension policyの適切な展開が必要です。

Full Disk Accessも同様です。

macOSのTCCによるプライバシー制御下でDefenderが必要なアクセスを維持するため、MicrosoftはMDMを使ったFull Disk Access profileの展開を説明しています。

したがって、

「DefenderアプリがMacにインストールされている」

だけでは導入確認として不十分です。

実際には、

System Extension承認→ Network Extension→ Full Disk Access→ Background Service→ Defender設定→ Onboarding→ Defender portalへの登録→ EDR Telemetry確認

まで確認する必要があります。

10．Intune 2607でmacOS Custom Complianceが追加

Microsoft Intuneでは、2026年7月27日の週に展開されたService release 2607で、macOS向けCustom Compliance Settingsが追加されました。

Microsoftは、scriptとJSON ruleを利用して、標準設定だけではカバーできないdevice configuration、security posture、custom attributes等を評価できると説明しています。結果は標準Compliance reportingと並んでIntune admin centerへ表示されます。

これはMac管理にとって大きな意味があります。

これまでもIntuneではmacOSについて、System Integrity Protection、Minimum / Maximum OS Version、Minimum / Maximum OS Build Version、Password、Storage Encryption、Firewall、GatekeeperなどをComplianceとして評価できます。

2607以降は、それに企業独自のチェックを追加できます。

例えば、

「社内で必須としている設定が存在するか」

「企業指定のsecurity configurationが維持されているか」

といった組織固有の状態判定へ広げられます。

つまり、

Intune登録済み ≠ Secure

であり、

Intune登録済み + Complianceを満たしている

という評価へ進めることが重要です。

11．重要な補足――macOSでDefender Device RiskをそのままConditional Accessへ渡せるのか

ここは正確に整理する必要があります。

2026年5月26日更新のMicrosoft公式「Configure Microsoft Defender for Endpoint with Intune and onboard devices」は、Defender for EndpointとIntuneの接続、およびDevice RiskをComplianceへ利用する方法を説明しています。

しかし、「Require the device to be at or under the machine risk score」を使用するCompliance Policyの対応プラットフォームとして現在明記されているのはAndroid、iOS/iPadOS、Windowsです。macOSはそこに含まれていません。

したがって、

MacでDefenderがRiskを検知→ IntuneへRiskを直接渡す→ macOSを自動Non-Compliant→ Conditional Accessで遮断

という構成を、現時点のMicrosoft公式資料だけから一般的なmacOS対応機能として断定することはできません。

確認できません。

macOSについて確実に確認できる設計は、

Intune標準Compliance / Custom Compliance→ DeviceをCompliant / Non-Compliantとして判定→ Microsoft Entra Conditional Accessで「Require device to be marked as compliant」を要求

という構成です。Microsoft Entraでは、IntuneのComplianceをConditional Access条件として利用できます。

この違いは設計時に重要です。

12．Mac侵害を確認したら、クラウド側も同じ時系列で見る

ここからは実務上の示唆です。

Microsoftの2026年8月18日の調査は、

「MacSync Stealerによって特定企業のAzureやMicrosoft 365が侵害された」

と報告しているわけではありません。

その事実は確認できません。

一方、MicrosoftはMacSync Stealerがcloud credentials、SSH keys、browser session dataなどを収集していることを確認しています。

したがって、対象Macがクラウド管理端末だった場合は、端末調査だけでは不十分です。

例えば午前10時15分にMac上で不審なcurlが動き、10時17分にarchiveが作成され、10時18分にHTTP PUTが発生したのであれば、その後のMicrosoft Entra Sign-in、Azure操作、Microsoft 365アクセスを同じUTC基準の時系列で確認します。

見るべき対象は、Microsoft EntraのSign-in Logs、Audit Logs、認証方式の追加変更、Role assignment、Application / Service Principal、OAuth Consent、Azure Activity Log、必要なResource Logs、Microsoft 365 Audit、Defender XDR Incident等です。

ここで行うのは、

「クラウドも侵害された」と決めつけることではありません。

逆です。

「クラウドへ波及していないと判断した根拠」を作るための調査です。

13．資格情報窃取を疑ったらパスワード変更だけで終わらない

MacSync Stealerでは複数種類のcredentialが対象です。

そのため侵害調査では、窃取可能性のあるcredentialを種類別に特定しなければなりません。

パスワードだけならpassword resetで対処できる場合があります。

しかしSSH keyならkey pairの廃止・再発行、certificateならcertificate revocationと再発行、cloud credentialならkey rotation、sessionやtokenならsession revocation等が必要になる場合があります。

対象端末が開発端末なら、Git repository、CI/CD、Kubernetes cluster、cloud subscription、secret storeなどへ影響が広がる可能性も評価する必要があります。

これはMacSync Stealerの特定被害事例としてMicrosoftが確認したという意味ではなく、確認された窃取対象から合理的に導かれるインシデント対応上の評価項目です。

14．証拠を消す前に保全する

今回のMacSync Stealerでは、exfiltration後にtemporary archive、staging folder、lock file等が削除されることが確認されています。

そのため、感染が疑われた際に、

「とにかく初期化」「とにかく再インストール」

を先に行うと、侵害範囲を判断するための証拠を失うおそれがあります。

もちろん、被害拡大防止のため端末隔離を優先すべき状況もあります。

重要なのは、

封じ込めと証拠保全をセットで設計しておくこと

です。

日本でも個人情報保護委員会は2026年1月28日に「不正アクセス発生時のフォレンジック調査の有効活用に向けた着眼点」を公表しています。資料自体の日付は2026年1月16日です。

同資料では、フォレンジック調査によって、不正アクセスの原因・被害範囲の把握、経営層・取引先・顧客・監督官庁等とのコミュニケーション、ログ等の証拠収集・保全に役立つことが示されています。

つまりログは、

セキュリティ部門のためだけの情報ではありません。

法務判断、顧客説明、行政報告、場合によっては訴訟対応の基礎資料にもなります。

15．MacSync Stealer感染＝直ちに個人情報保護委員会への報告、ではない

クラウド法務上はここを分ける必要があります。

MacSync Stealerが端末に存在したという事実だけで、直ちに個人情報保護委員会への漏えい等報告義務が確定するわけではありません。

確認すべきなのは、

端末内または端末経由で個人データへアクセス可能だったか。

実際にアクセス・収集されたか。

外部送信されたか。

漏えい、滅失、毀損が発生した、または発生したおそれがあるか。

そして、法令上の報告対象事態に該当するかです。

個人情報保護委員会が定める主な報告対象事態には、要配慮個人情報を含む事態、財産的被害が生じるおそれがある事態、不正目的の行為による漏えい等、1,000人を超える漏えい等があります。

重要なのは「確定した漏えい」だけが問題ではないことです。

現行ガイドラインは、

「漏えい等が発生したおそれ」

も一定の場合に報告対象としています。

したがって、

「外部送信したファイル名を100％特定できないから報告対象ではない」

という単純な判断はできません。

ログ、フォレンジック結果、アクセス可能範囲等を総合して評価する必要があります。

16．速報は調査完了を待てない

報告対象事態に該当する場合、個人情報保護委員会への速報は「速やかに」行う必要があります。

2026年6月14日版の通則編では、その目安を、事態を知った時点から概ね3～5日以内としています。

確報は原則として30日以内です。

規則第7条第3号に該当する不正目的の行為による漏えい等の場合は60日以内です。

また法人の場合、起算点となる「知った」時点は、原則としていずれかの部署が当該事態を知った時点です。

情報システム部門が月曜日に把握して、経営会議が金曜日だったから金曜日を起算日にする、といった扱いはできません。

17．委託先・顧客への通知は別の時計で動く

委託関係にも注意が必要です。

個人情報保護委員会の2026年6月14日版ガイドラインでは、報告義務を負う委託先が委託元へ通知する例外制度について、通知は「速やかに」、目安として概ね3～5日以内とされています。

さらに実務では契約書があります。

業務委託契約、情報セキュリティ覚書、クラウド契約、秘密保持契約等に、

「24時間以内」「48時間以内」「発覚後直ちに」

などの通知期限が定められている場合があります。

この期限が存在するかは、個別の契約書を確認しなければ分かりません。

したがって、

個人情報保護法上の行政報告期限

と、

委託元・顧客に対する契約上の通知期限

は別々に管理する必要があります。

18．企業が整備すべきインシデントタイムライン

MacSync Stealerのような案件では、技術対応と法務対応を別々の管理表にしない方が合理的です。

一つのタイムラインに、

時点	確認・実施事項
T0	不審なTerminal / EDR Alertを検知
T1	端末隔離・証拠保全
T2	Process / Network / File event調査
T3	収集対象・外部送信の確認
T4	Credential窃取範囲を特定
T5	Password / Token / Key等を失効
T6	Entra / Azure / M365等のクラウドログ調査
T7	個人データ・機密データへの影響評価
T8	契約上の通知期限確認
T9	個人情報保護法上の報告対象性判断
T10	顧客・委託元・行政機関への必要な通知
T11	恒久対策・再発防止策
T12	Incident Close判定

を並べます。

これにより、

「いつ知ったか」「いつ封じ込めたか」「何を根拠に漏えいなしと判断したか」「誰へいつ通知したか」

を後から説明できます。

19．今回のMicrosoft調査から企業が今確認すべき10項目

•  業務利用しているMacを資産台帳からすべて抽出できるか

•  Intune、Jamf等のMDM管理外Macが残っていないか

•  Defender for Endpoint等のEDRへ全業務Macがオンボードされているか

•  System Extension、Network Extension、Full Disk Access等が正しく適用されているか

•  IntuneのmacOS Compliance PolicyでOS Build、暗号化、Firewall、Gatekeeper等を確認しているか

•  Service release 2607のCustom Complianceを利用できるか検討したか

•  Terminal、zsh、curl、osascript等の不審な連続実行をハンティングできるか

•  Keychain、browser session、SSH key、cloud credential等の窃取を前提とした失効手順があるか

•  Mac侵害時にEntra・Azure・Microsoft 365まで同じタイムラインで調査できるか

•  個人データ影響、契約通知、行政報告を技術調査と並行して判断できる体制があるか

20．まとめ――「Macを守る」のではなく「Macからクラウドまで守る」

MacSync Stealerについて、2026年8月18日にMicrosoftが確認した事実は明確です。

対話型shellから始まり、curlによるpayload retrieval、AppleScript支援型実行、Keychain・browser・cloud・SSH credentialや機密ファイルの収集、一時領域へのステージング、ZIP圧縮、chunk分割、HTTP PUTによる外部送信、そして一時ファイル削除まで確認されています。

そして30を超える関連ドメインが、単なる静的IOCではなくbehavioural correlationによって結び付けられました。

企業がここから学ぶべきなのは、

「Macにもウイルス対策ソフトを入れよう」

というだけの話ではありません。

業務端末に存在する、

IdentityCredentialSessionSSH keyCertificateCloud configurationBusiness data

までを攻撃面として考える必要があります。

感染した端末を駆除する。

それは必要です。

しかしインシデント対応はそこで終了しません。

何が実行されたか。

何が収集されたか。

何が外部へ送信されたか。

どの資格情報が侵害された可能性があるか。

その資格情報がクラウドで悪用されていないか。

個人データへ影響したか。

誰へ、いつ報告する必要があるか。

そこまで確認して初めて、企業として説明可能なインシデント対応になります。

山崎行政書士事務所では、Azure、Microsoft Entra、Microsoft 365、Microsoft Intune等の技術構成確認、Macを含むクラウド接続端末の管理設計、Defender XDRを利用したログ・証拠・影響範囲の整理、クラウド契約・委託契約における責任分界の確認、顧客・委託元への通知文書、個人情報保護委員会への報告資料、原因・経緯・再発防止策の文書化を、Azure技術支援とクラウド法務の両面から横断して支援します。

EndpointとCloud。

技術と法務。

検知と報告。

これらはインシデントが終了してから接続するものではありません。

最初の検知時点から、同じ時系列で動かすことが重要です。

主な確認資料

Microsoft Security Blog「Hunting MacSync Stealer infrastructure through behavioral pivots」公開日：2026年8月18日Microsoft Defender Experts / Microsoft Security Research。

Microsoft Learn「Microsoft Defender for Endpoint on macOS」最終更新日：2026年6月17日。

Microsoft Learn「What's new in Microsoft Intune」Week of July 27, 2026 / Service release 2607。macOS Custom Compliance Settingsを追加。

Microsoft Learn「Device compliance settings for macOS in Intune」更新日：2026年7月22日。

Microsoft Learn「Configure Microsoft Defender for Endpoint with Intune and onboard devices」最終更新日：2026年5月26日。Device Risk連携の対応プラットフォームも確認。

Apple Platform Security / Apple Support「Terminal and script protections」「If your Mac blocks a Terminal command paste or script」macOS 26.4以降のTerminal paste protection等を確認。

個人情報保護委員会「不正アクセス発生時のフォレンジック調査の有効活用に向けた着眼点」資料日：2026年1月16日、個人情報保護委員会での公表：2026年1月28日。

個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」2026年6月14日版。速報概ね3～5日、確報30日／60日等を確認。

#サイバーセキュリティ #MacSecurity #macOS #MacSyncStealer #ClickFix #MicrosoftDefender #MicrosoftIntune #MicrosoftEntra #Microsoft365 #Azure技術支援 #クラウド法務 #個人情報保護 #インシデント対応 #ZeroTrust #山崎行政書士事務所