クラウド信用基盤の転用問題｜SES悪用解析

クラウド信用基盤の転用問題 大解析

本質は「認証済み正規インフラの悪用」にあり、従来の偽ドメイン検知中心の思想が崩壊しています。
☁️ これは単なるメール詐欺ではなく、クラウド時代の構造的脅威です。

本質的脅威
IAM管理破綻
AWS侵害ではない
運用崩壊
攻撃者はAWSをハックするのではなく、漏洩済みIAMを使って正規利用者として送信します。
共有インフラ
巻き添え被害
ブラックリスト無力化
CDNと同構造
巨大プールで共有されるIPを止めると数千社の正常メールが死ぬため、防御製品は安易に遮断できません。
攻撃速度
高密度運用
人間系フロー凌駕
短期決戦
キー取得→上限確認→即時送信→停止前に撤収。構築コストの低さが攻撃を加速させています。
ファイルレス化
マルウェア不在
AV検知対象消失
正規遷移
正規OAuthやGraph APIを通じた攻撃により、ローカル端末に悪性コードが存在しません。
防御の移行
ID行動検知
文脈異常へのシフト
主戦場変化
「誰が送ったか」から「何を要求しているか(OAuth等)」。Zero TrustとCASBが鍵となります。

従来型検知モデルの崩壊と構造差

gavel「技術的正当性」が攻撃側に乗っている状態📨


現在の多くのメールセキュリティ製品が「認証通過＝比較的安全」という重み付けを内部で持っている点を利用し、SES悪用型はセキュリティの網をすり抜けます。

図：従来型フィッシングとSES悪用型の技術的指標の乖離

従来型とSES悪用の明確な違い

技術指標従来型フィッシングSES悪用型従来型検知の成否
送信ドメインタイポスクワッティング等偽ドメイン正規AWSインフラ✖ 無力化
SPF/DKIM失敗・不一致正常通過✖ スルー
IPレピュテーション海外踏み台IP・低評価高レピュテーション✖ 信頼付与

従来型AV/EDR防御限界率

0%

IAMキー漏洩経路と運用崩壊

IAMキー漏洩経路について、実際は「高度な侵入」よりも「開発・運用の崩壊」が主因です。秘密情報が開発工程全域に拡散していることが致命的な弱点となっています。🔑

S3 Public ACL 漏洩

35%

GitHub誤公開 / CI/CD露出

45%

自動化された即時悪用

近年はSecret scanning botnet等により自動化され、「公開後数分以内に悪用」が普通に起きます。攻撃者はSESを長期運用せず、「取得→即時大量送信→撤収」という人間系対応を凌駕する速度で動きます。

防御製品の限界と「業務優先」の制約

さらに深刻なのは「共有インフラ問題」です。SES送信IPは巨大プールで共有されるため、1つのIPをブラックリスト化すると、数千社の正常メールが巻き添えになります。

図：誤検知率低下への圧力と解約リスクのトレードオフ

「止めたら顧客に怒られる」現実📉

AWS SES全面警戒やMicrosoft 365リンク全面隔離をやると企業業務が崩壊します。ユーザーは「危険なら止めろ」と言いますが、企業側は「誤検知で業務停止すると契約解約」となります。そのため防御製品は、多少すり抜けても業務優先になりやすい設計となっています。

文脈異常検知への移行と現実的対策

攻撃が「偽サイト」から「正規クラウド内悪性コンテンツ」へ移行し、ファイルレス化（マルウェアが存在しない）する中、AV/EDRの伝統的検知対象は消えています。現在の主戦場は「ファイル」から「ID行動」へ変わっています。🌐

レイヤー具体的な対策・技術目的・効果
技術面 (予防)IAM Access Analyzer / Git pre-commit secret scan認証情報のソースコード混入や意図しない公開を未然に防ぐ。
技術面 (制限)SCPでSES制限 / IAMキー長期禁止 / STS短命化漏洩時の被害を局所化・短時間化する。
技術面 (検知)Behavioral analysis / Outbound mail anomaly detection正規APIを利用した「ふるまいの異常（一斉送信等）」を捉える。
運用面 (教育)「amazonaws.comだから安全」の認識破壊正規SaaSインフラへの盲目的な信頼を排除する。
運用面 (確認)OAuth承認・電子署名の別経路確認同意画面を通じた権限委譲やMFA回避を防ぐ。
結論：被害局所化への思想転換
現在は「侵入されない」ではなく「侵入後に横展開させない」という思想で運用されています。Identity Protection, Zero Trust, UEBA, CASB を軸に、「認証突破」ではなく「認証済み状態の乗っ取り」をいかに早く検知・隔離するかが問われています。

よくある質問 (FAQ)

help_outlineSES悪用はAWS側の脆弱性によるものですか？expand_more
infoいいえ、AWS侵害ではありません。実態は「顧客側IAM管理破綻」です。漏洩したIAMキーを使い、正規利用者としてAPI経由で送信されます。AWS側から見ると正常なAPI利用に見えるのが厄介な点です。
help_outlineなぜ従来型のスパムフィルターをすり抜けるのですか？expand_more
infoSPF/DKIM正常、高レピュテーションIP、正規TLS、正規クラウドASNなど、「メールの技術的正当性」が攻撃側にあるためです。多くの製品が持つ「認証通過＝比較的安全」という重み付けを突いています。
help_outlineDocusign偽装などの電子署名メールが多いのはなぜですか？expand_more
info電子署名メールは元々「外部リンクへ飛ばす」「緊急性がある」「知らない会社から来る」という性質があり、フィッシングの文脈と極めて親和性が高いためです。ユーザーの不審感が弱まりやすい心理を突いています。✍️
help_outline企業向けセキュリティ製品がSES悪用を防ぎきれない理由は？expand_more
info共有インフラ（正規クラウド）を止めることによる「正常業務の巻き添え」を嫌うためです。AWS全体やGoogle Driveを遮断すると業務が止まりクレームに繋がるため、多少のすり抜けを許容する「業務優先」の設計になりがちです。
help_outline今後の防御の主戦場はどこになりますか？expand_more
info防御対象が「ファイル」から「ID行動」へ変わります。マルウェアが存在しないファイルレス攻撃に対しては、Identity Protection、Zero Trust、UEBA、CASBなどを活用し、不審なOAuth承認やセッション異常といった「文脈」を検知することが重要です。