クラウド関連のインシデントケースを収集して見えてきたもの

個人的に収集したクラウド関連インシデントへの洞察の共有です。
紹介する事例は全て公開情報を元にしています。
クラウドを取り巻く脅威の実態を知ることでクラウド環境のセキュア化に繋がれば幸いです。

Transcript

1. 1 伊藤忠サイバー＆インテリジェンス株式会社 クラウド関連のインシデントケースを収集して見えてきたもの 2025/2/28
2. 2 構成 2 インシデントケースの収集を行う理由 総括 主な初期侵入ベクトル 攻撃者のモチベーション 01 04 02 03
3. 3 3 謝辞 • 紹介する事例は全て公開情報を元にしています。 • 事例や分析の公開があるからこそ、先んじて対策が可能であり、 また、教訓を得られます。 • 全ての事例共有に心から感謝を。
4. 4 4 このスライドについて • 個人的に収集したクラウド関連インシデントへの洞察の共有です • 原因やTTPsを知ることでクラウド環境のセキュア化に繋がれば幸いです • ※ 後で読んでいただくように、全体的に文字多めです
5. 5 5 01 インシデントケースの収集を行う理由
6. 6 6 なぜ、事例の収集をおこなうのか？ 1. クラウドは日が浅い分野 ◦ 攻撃も防御も、ケースと知見が不足している ◦ インパクトを知りたい、危ない機能は実運用を見つつ塞ぐ ◦ 彼を知り己を知れば百戦殆からず 2. Huntingのチップス、IoCの収集、強化策の元ネタ ◦ 個別のテクニックや事例に対応していてもきりがない ◦ まずは入口塞ぎたい ◦ たくさん見ているとパターンが見えてくる 3. 攻撃者は研究熱心 ◦ マイナーな機能でも悪用してくる ◦ 何なら、ドキュメントされてない機能すら悪用してくる
7. 7 7 02 主な初期侵入ベクトル
8. 8 8 認証の突破 – 総当たり攻撃 • まだまだ、現役の手法 ◦ 古典的な手法だが、今でも頻繁に使用されてる ◦ 2022/7 発行のGoogle社の脅威レポート (Threat Horizo​​ns) では、初期ア クセスの51%が総当たりによるものと報告されている。 ◦ 既知のWeakなPWや、過去に漏洩したPWを使用したリスト型など様々 • 主なTTPsとして採用しているAPTも存在する 02. 主な初期侵入ベクトル (1/12) https://attack.mitre.org/techniques/T1110/ https://www.microsoft.com/en-us/security/blog/2023/09/14/peach-sandstorm-password-spray-campaigns-enable-intelligence-collection-at-high-value-targets/ https://services.google.com/fh/files/blogs/gcat_threathorizons_full_july2022.pdf
9. 9 9 認証の突破 – Phishing • 主要かつ、進化し続けている手法 ◦ QRコード型 ◦ AiTM ◦ MFA疲労攻撃 ◦ やり取り型 ◦ Google Ad ◦ Device Code Phishing / Consent Phishing • 様々な脅威主体が活用 ◦ APT／BEC／ランサムアクター、Initial Access Broker、等々、 • 調査した範囲ではM365のフィッシングが多いが、AWSのフィッシングも 02. 主な初期侵入ベクトル (2/12) https://www.cadosecurity.com/blog/an-ongoing-aws-phishing-campaign https://msrc.microsoft.com/blog/2023/02/threat-actor-consent-phishing-campaign-abusing-the-verified-publisher-process-ja/
10. 10 10 脆弱性の悪用 • 0-day、N-day、etc ◦ 収集した範囲では既知の脆弱性の悪用が多い ◦ 稀に、0-day が悪用された事例も • IMDS、TMDS、クレデンシャル収集 ◦ 当然、メタデータサービスへのアクセスや、クレデンシャルファイルの探索が行われる ◦ IMDSv2は銀の弾丸ではない、RCEされれば無力 • 到達できれば、何の脆弱性でもよい ◦ 構成次第ではSQLi、LFIやメモリリークの脆弱性でもクレデンシャルを抜ける 02. 主な初期侵入ベクトル (3/12) https://unit42.paloaltonetworks.com/sugarcrm-cloud-incident-black-hat/ https://www.cisa.gov/sites/default/files/2024-01/aa24-016a-known-indicators-of-compromise-associated-with-adroxgh0st-malware_0.pdf https://hackerone.com/reports/2107680
11. 11 11 脆弱性の悪用 – 不要なサービスの公開 • 不用意なサービスの公開 ◦ 特にDocker、Jupyter、Kubernetesなどが狙われる ◦ 感染後に他のコンテナやk8sへ感染を広げるワームや、AWS/Azure/Git/SSH/DBな どの数十種類のクレデンシャルファイルの探索と持ち出しを行うケースも ◦ IMDSやTMDSも当然狙われる ◦ 攻撃者が管理するDocker Swarmに追加して、マイニングリソースとしての貸し出し ◦ Create APIを公開している場合、/ のマウントによりエスケープされる 02. 主な初期侵入ベクトル (4/12) https://www.cadosecurity.com/blog/team-tnt-the-first-crypto-mining-worm-to-steal-aws-credentials https://www.cadosecurity.com/blog/qubitstrike-an-emerging-malware-campaign-targeting-jupyter-notebooks https://intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/ https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/ https://unit42.paloaltonetworks.com/teamtnt-operations-cloud-environments/ https://www.aquasec.com/blog/threat-alert-teamtnts-docker-gatling-gun-campaign/
12. 12 12 脆弱性の悪用 – 設定ミス • ストレージの設定ミス ◦ Amazon S3 や Google Drive の共有設定ミスなど ◦ データ漏洩はもちろん、ソースコードやクラウドのアクセスキー漏洩に繋がった事例も • ローコード系 ◦ Firebase や Power Pagesでデータへのアクセス不備がよく見つかっている ◦ 過去の調査によれば4000のAndroidアプリで適切にアクセス制御されていないfirestoreが 使用されており、他の調査では2万近くのオープンなfirestoreが発見されている。 • リソース固有の設定 ◦ Cognitoの自己サインアップや、CloudFrontのキャッシュ設定ミス(Request Collapsing) など 02. 主な初期侵入ベクトル (5/12) https://decoded.avast.io/vladimirmartyanov/research-shows-over-10-of-sampled-firebase-instances-open/ https://www.bleepingcomputer.com/news/security/misconfigured-firebase-instances-leaked-19-million-plaintext-passwords/ https://thehackernews.com/2020/05/android-firebase-database-security.html https://appomni.com/ao-labs/microsoft-power-pages-data-exposure-reviewed/ https://www.nccgroup.com/us/research-blog/10-real-world-stories-of-how-we-ve-compromised-cicd-pipelines/
13. 13 13 ソーシャルエンジニアリング • APTアクターに多い手法 ◦ SNS、LinkedIn、インターネット上の情報、等々から執念深くプロファイリングを行う ◦ ITサポートデスクや管理者を標的としているパターンも • 知人を騙る ◦ 事前に得た情報を元に、業界人やターゲットの知人を装ってたやり取りで信頼を築く • PWリセット、ソフト・アプリのインストール ◦ 基本的には何かしらのソフトをインストールさせたり、PhishingでIDを侵害する 02. 主な初期侵入ベクトル (6/12) https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection/ https://unit42.paloaltonetworks.jp/muddled-libra-evolution-to-cloud/ https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/
14. 14 14 Supply Chain - 偽Package/Software/Extension • 著名なソフトウェアやライブラリに偽装 ◦ typosquattingや、著名なライブラリ、ツールに似た名前の採用 ◦ Starjacking ◦ Google Adsの悪用 ◦ イマドキのソフトウェア開発は依存関係が巨大になりがち • クラウドを標的にしていなくとも ◦ 大抵の開発者や運用者の端末にはクラウドのクレデンシャルが存在（しかも、強い） ◦ action:vm* & resource: web-* のように細かく制限しても、リソース単位で操作権限 を持っている事に変わりはない。ベンダーがよく謳う最小権限は必要だが、銀の弾丸ではない。 • Packageだけじゃない ◦ 偽物VSCodeや、拡張機能、Browser Extensionの配布が行われている 02. 主な初期侵入ベクトル (7/12) https://www.bleepingcomputer.com/news/security/pypi-python-packages-caught-sending-stolen-aws-keys-to-unsecured-sites/ https://socket.dev/blog/malicious-python-package-typosquats-fabric-ssh-library https://checkmarx.com/blog/malicious-python-package-targets-macos-developers-to-access-their-gcp-accounts/ https://www.bleepingcomputer.com/news/security/docker-hub-repositories-hide-over-1-650-malicious-containers/ https://www.sonatype.com/blog/this-week-in-malware-400-npm-packages-target-azure-uber-airbnb-developers https://checkmarx.com/blog/starjacking-making-your-new-open-source-package-popular-in-a-snap/
15. 15 15 Supply Chain – 悪意あるコードの注入 • 正規ライブラリの改竄 ◦ fake packageに比べると少ない ◦ 正規のライブラリにAWSのクレデンシャルを窃取するコードが挿入さえた事例あり ◦ ライブラリに以外にもWikiのDLリンクが改竄された事例も • Supply Chainへの介入 ◦ こちらも、事例としては少ない ◦ 製品のアップデート配信基盤へリーチして、マルウェアが配信された事例あり 02. 主な初期侵入ベクトル (8/12) https://www.bleepingcomputer.com/news/security/popular-python-and-php-libraries-hijacked-to-steal-aws-keys/ https://x.com/malwrhunterteam/status/1619296415313952769 https://threats.wiz.io/all-incidents/solarwinds-supply-chain-attack
16. 16 16 Supply Chain – 連携システム側のインシデント • クラウド権限を預ける ◦ システム監視やセキュリティ監査、CI/CDなどで外部ソリューションと連携する際、大 抵は、必要なクラウド権限を製品側に付与する • 預けたクレデンシャルが漏洩したら？ ◦ SaaSソリューションの侵害により、連携していたAPIキーなどが漏洩した事例あり • ベンダーも同様のリスクを抱えている ◦ ベンダーにも自社インフラ、サービスインフラ、開発環境、従業員、etcを抱えている 為、前述のリスクや脅威の影響を受ける可能性がある ◦ APTアクターがCSPを標的としていた事例も。 02. 主な初期侵入ベクトル (9/12) https://circleci.com/blog/january-4-2023-security-alert/ https://www.bleepingcomputer.com/news/security/thousands-of-github-aws-docker-tokens-exposed-in-travis-ci-logs/
17. 17 17 その他 – 認証情報の公開 • コードや配布物に混入 ◦ 配布しているコンテナからアクセスキーが漏洩 -> システムの改竄 ◦ 過去の調査によると1900の iOS アプリでハードコードされたAWSシークレットを発 見 ◦ フロントエンドのJSにハードコードしているケースも ◦ とある実験によれば、シークレットの公開から５分でによる悪用を確認 • 取引先やベンダーが公開 ◦ 取引先やベンダーのインフラ・サービスが侵害されたり、従業員が誤って公開したパ ターン • アクセスキーの共有 ◦ 共有ドライブやチャットで生のシークレットを共有しており、内部侵入からクラウド侵 害へ繋がった事例あり 02. 主な初期侵入ベクトル (10/12) https://about.codecov.io/apr-2021-post-mortem/ https://www.bleepingcomputer.com/news/security/over-1-000-ios-apps-found-exposing-hardcoded-aws-credentials/ https://medium.com/@danielsilva691/discovering-account-takeover-vulnerability-through-source-map-analysis-0cd4038cbc04 https://unit42.paloaltonetworks.com/malicious-operations-of-exposed-iam-keys-cryptojacking/ https://www.theregister.com/2017/11/14/dxc_github_aws_keys_leaked/
18. 18 18 その他 – リソースの放置 • 一意なFQDNを持つクラウドリソース ◦ <バケット名>.s3.amazonaws.com など ◦ もちろん総当たりできるし、Google Dorkやクローリングなどでも • 乗っ取り ◦ CNAMEやリンクに使用していて、その後使用をやめた場合、攻撃者が同じ名前で リソースを作成することで、偽サイトの立ち上げや、悪意あるコードが行える ◦ 国内では、収集した範囲では、Azure系リソースの乗っ取りが多い • Supply Chainの汚染につながる可能性 ◦ もちろん、サプライチェーンリスク ◦ 悪意あるアップデートファイルやスキミングスクリプトの混入などのリスク 02. 主な初期侵入ベクトル (11/12) https://learn.microsoft.com/ja-jp/azure/security/fundamentals/subdomain-takeover#prevent-dangling-dns-entries https://www.paloaltonetworks.com/blog/cloud-security/subdomain-takeover/ https://labs.watchtowr.com/8-million-requests-later-we-made-the-solarwinds-supply-chain-attack-look-amateur/
19. 19 19 その他 – クラウド自体の脆弱性 • クラウドは無敵ではない ◦ クラウドサービス自体の脆弱性も定期的に見つかっている ◦ 悪用の有無は定かではないが、コンテナイメージの書き換えや、他のクラウドアカウン ト上でコード実行が出来たものも ◦ 数は少ないが、中には既に悪用が確認されていたものも • 常に研究されている ◦ Hot な分野なので、発表される脆弱性の一部は、”若干”アピール合戦感は否 めない ◦ とはいえ、ロギングのバイパスや永続化の手法など、実際に攻撃者が戦術に採用し ているケースも存在する ◦ IRから新たな手法が見つかることもあり、攻撃者も同様に研究している 02. 主な初期侵入ベクトルベクトル (12/12) https://www.panoptica.app/research/aws-sagemaker-jupyter-notebook-instance-takeover https://thehackernews.com/2022/12/serious-attacks-could-have-been-staged.html https://socradar.io/microsoft-patches-power-pages-zero-day-cve-2025-24989-recent-pan-os-flaw-cve-2025-0111-joins-cisa-kev/ https://aadinternals.com/post/aad-deepdive/ https://www.crowdstrike.com/en-us/blog/how-adversaries-persist-with-aws-user-federation/
20. 20 20 03 モチベーション
21. 21 21 BEC • M365環境の悪用に慣れている ◦ M365の機能の悪用を戦術に組み込んだ事例が増えている ◦ レガシー認証の突破も多い ◦ 受信ルール追加に加えて、既存ルールの変更 ◦ アプリ登録＋Microsoft Graph APIも悪用されるようになってきた • 正規のサービスを悪用 ◦ 攻撃者のアプリ登録やアプリ作成以外にも、正規のSaaSアプリを登録してくるケースも ◦ ファイルをDLさせるために、Dropboxなどの正規のファイルストレージを使用 ▪ 業務利用している場合、初手で止めにくい 03. モチベーション (1/6) https://www.huntress.com/blog/legitimate-apps-as-traitorware-for-persistent-microsoft-365-compromise https://www.microsoft.com/en-us/security/blog/2024/10/08/file-hosting-services-misused-for-identity-phishing/ https://www.microsoft.com/en-us/security/blog/2023/12/12/threat-actors-misuse-oauth-applications-to-automate-financially-driven-attacks/
22. 22 22 ランサム • クラウドだからといって、ランサムに強いわけではない ◦ クラウド環境でのランサム事例も少なくない ◦ バックアップや回復速度は利点だが、暴露型もあることを忘れてはいけない • クラウドを意識したTTPs ◦ Amazon S3のバージョニングを無効化した事例 ◦ Azure Run Commandを使用したランサムウェアのデプロイ ◦ 複数のクラウドプラットフォームに順応したアクターも 03. モチベーション (2/6) https://www.microsoft.com/en-us/security/blog/2024/09/26/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/ https://cloud.google.com/blog/topics/threat-intelligence/unc3944-sms-phishing-sim-swapping-ransomware/?hl=en https://www.invictus-ir.com/news/ransomware-in-the-cloud
23. 23 23 マイニング • クラウドの機能を活用したマイニングも ◦ デカいEC2を立てるだけじゃない ◦ Azure Batchのような大規模計算用のサービスを悪用するケース ◦ CPUマイニングに有利な高額なインスタンスの使用 ◦ 通常使われていないリージョンでのマイニング • クラウドのIPレンジをターゲットにしているケース ◦ クラウドのIPレンジに絞って脆弱なホストの探索を行い、マイナーを設置するケース （キャンペーン）も数件 03. モチベーション (3/6) https://dfir.ch/posts/azure_batch/ https://intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/
24. 24 24 スパム • 踏み台になることも ◦ Amazon SESの悪用の試みが散見された ◦ 攻撃者による上限緩和の試みも ◦ M365アカウント侵害からの、内部フィッシング、外部へのスパムなども 03. モチベーション (4/6) https://securitylabs.datadoghq.com/articles/tales-from-the-cloud-trenches-unwanted-visitor/ https://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/#post-125981-_kdq0vw6banab
25. 25 25 LLMJacking / LLMHijacking ※ベンダーによって呼称が異なる • AIリソースを標的としたケースの増加 ◦ ここ１年以内で、AI系リソースの悪用事例が出てきている ◦ 複数のAIサービスのAPIをProxy可能なツールの悪用 ◦ モデルコストを被害者に転嫁する ◦ モデルのフィルター回避 03. モチベーション (5/6) https://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/ https://permiso.io/blog/exploiting-hosted-models https://securitylabs.datadoghq.com/articles/2024-q4-threat-roundup/#threat-actors-target-cloud-ai-environments
26. 26 26 標的型攻撃 • 研究熱心 ◦ あまり一般的でない機能も戦術へ組み込んでくる ◦ もちろん、シンプルな戦術も併せて使用する ◦ フェデレーションドメインの追加やテナント同期など ◦ 特に、Entra ID / M365 の侵害に関してはかなり研究＆武器化が進んでいる様子 ◦ オンプレからクラウドへのLateral Movementも珍しくない 03. モチベーション (6/6) https://cloud.google.com/blog/topics/threat-intelligence/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452?hl=en https://www.microsoft.com/en-us/security/blog/2023/09/14/peach-sandstorm-password-spray-campaigns-enable-intelligence-collection-at-high-value-targets/
27. 27 27 04 総括
28. 28 28 全てはAPI • クラウドAPI ◦ クラウドの機能はAPIとして提供されている ◦ APIはインターネット上に公開されていて、権限を持つユーザであれば即座に実行 できる。 ◦ つまり、Attack Surfaceであり、守る対象。 • クレデンシャル漏洩から始まる ◦ 上記の特性により、APIを実行可能なクレデンシャルが漏洩すれば、攻撃者は即 座にデータにアクセスでき、機能を悪用することが出来る。 ◦ クレデンシャルはあらゆる場所に存在する。 04. 総括
29. 29 29 どこから守っていくか？ 無数にあるが、頑張って３つに絞るなら以下 • IDとクラウドAPIの保護 ◦ ログイン時の要件を定める（IPや認証強度、検疫） ◦ クラウドAPIのアクセス元制限と、許可外IPからのアクセスを検知 • サービス・リージョン制限 ◦ 使ってないサービスやリージョンを閉じる＆使用の試みを検知 • 特権の管理 ◦ 権限とアカウントの棚卸 ▪ 特にEntra IDでは一般ユーザーがアプリ登録とゲスト招待を行える ◦ 高い権限の使用にはJust-in-Timeな付与や、使用時のメール通知なども検討 04. 総括
30. 30 30 どうやって集めるか？ • セキュリティーベンダーのブログ ◦ TTPsなど勉強になる ◦ 公開後に似たような攻撃が来ることも • HackerOne ◦ “AWS” や “Azure” で検索する ◦ 現実のサービス上で見つかった脆弱性なので、リアリティーがある ◦ 自分も作ってしまいそうな脆弱性もあったり • TweetDeck ◦ AWS AND “Data*Breach” とかクエリを書く ※ 中には、分析や結論の根拠の不足を感じる記事もあるため、注意が必要。 通常、マルウェアや侵害時のアクティビティーについて、特定のアクターやモチベーションに紐づける事は困難であり、 明確な根拠が示されていない場合は要注意。 04. 総括
31. 31 31 リンク集 後日公開予定です 04. 総括