Microsoft 365 MSA を利用したトークン奪取攻撃の詳細が明らかになりました

昨日お伝えした MSA への攻撃ですがなんとすぐにアップデートが行われて詳細が追加されていました。

推測では MS の脆弱性とユーザーの管理問題があったのではないかというところでしたが、答え合わせをしていきましょう。

まずはアップデートの内容です。

https://msrc.microsoft.com/blog/2023/07/microsoft-mitigates-china-based-threat-actor-storm-0558-targeting-of-customer-email/?WT.mc_id=M365-MVP-5002496

ここにあるリンクを開くと、詳細なレポートに遷移することができます。

このレポートを読み解いてみましょう。

https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/?WT.mc_id=M365-MVP-5002496

スタートはフィッシングからですね。その後クレデンシャルを盗み取ったという流れのようです。クレデンシャルの取得は、過去よりこの組織がよく使う方法があるようで、 DLL をハイジャックするという手法だったようです。下手なアプリはインストールしないようにしないとですね。

そして、ログとトークンを合わせて確認してみると通常の方法ではないということが分かったとのこと。ブラウザーからアクセスした場合にあるログがなかったとかそういうことですかね。

そこから認証機能にエクスプロイトがあったことが判明。すでにその問題はパッチがあてられたとのこと。なので Microsoft 365 にまだ問題があるのでは?という目線は不要のようです。安心できますね。

MSA のキーを署名する際に誤ったキーを利用しても認証が通るようになっていた。というような状態だったようです。

MSA と Azure Entra ID が連携しているときに、 Azure Entra ID サインイン時に MSA の証明書で署名してもサインインできてしまったとか、そういった感じだったのかもしれません。残念ながらどういったパターンの時に MSA と Entra ID が紐づくのか。という点は読み解けませんでした。

ただ、この辺りがその動きの部分ですね。

Outlook on the Web の GetAccessTokenForResource API を利用すると、一度認証されたトークンを用いれば MSA と Entra ID のキーを取り違えていても認証できてしまう状態だった。といった内容のようです。やっぱり MSA と Entra ID が紐づけられたアカウントであるというのが条件のようです。

この攻撃を行ったものは、犯行が分かりにくくなるように VPN Proxy を利用してアクセスログがからの断定を難しくする措置を講じていたようです。

この問題を発見したセキュリティチームの能力の高さがうかがえますね。

ログ出力パターンを抑えておくというのは今後のセキュリティチームには必須の能力になるのかもしれません。組織サイズによっては外部委託という選択した現実味を帯びますね。

その中の一つの選択肢が E5 ということなのかもしれません。

音楽:So much more to say