HazyBeacon キャンペーンを分析：AWS Lambda 悪用のクラウドネイティブ攻撃

HazyBeacon Abuses AWS Lambda Function URLs for Stealthy Command-and-Control Operations

2026/06/19 gbhackers — HazyBeacon は、CL-STA-1020 として特定された、ステルス型のクラウド・ネイティブ・マルウェア・キャンペーンのことである。このマルウェアは、Amazon Web Services (AWS) Lambda Function URL を悪用することで、隠蔽された Command-and-Control (C2) チャネルを構築しており、攻撃者の戦術における大きな進化を示している。Qualys の最近の調査によると、このキャンペーンはミスコンフィグされたサーバレス・インフラを悪用して、主に東南アジア全域の政府機関を標的としている。その結果として、正規のクラウド活動の中に悪意のトラフィックを紛れ込ませることが可能となる。

HazyBeacon による AWS Lambda Function URL の悪用

攻撃者が所有する VPS サーバや侵害済みのドメインといった、従来のインフラに依存する C2 アーキテクチャとは異なり、HazyBeacon は正規の AWS 環境内へ悪意のコンポーネントをデプロイする。それにより、借用インフラを手にする攻撃者は、盗み出した Identity and Access Management (IAM) 認証情報を介して初期アクセスを獲得する。

多くのケースにおいて、これらの認証情報は、公開された GitHub リポジトリ／フィッシング・キャンペーン／侵害された開発者環境から収集されたものである。これらの認証情報により、攻撃者は Lambda 関数を作成し、AuthType を NONE に設定した公開関数 URL を介して公開することで、認証制御を効果的に回避できる。

デプロイされた Lambda 関数はプロキシとして機能し、感染したエンドポイントと攻撃者のバックエンド・インフラ間のトラフィックを中継する。被害者のシステム上で実行されているマルウェアは、暗号化された HTTP リクエストを介して Lambda URL と通信し、そのリクエストは攻撃者が制御するサーバへと転送される。

その一方で、レスポンスも同じ経路を逆方向にたどるため、堅牢でステルス性の高い通信ループが形成される。また、すべてのトラフィックは “on.aws” で終わる信頼された AWS ドメインから発信されるように見えるため、従来のネットワーク防御やドメイン・レピュテーション・システムでは、この活動を検出またはブロックすることが困難である。

このマルウェアは、柔軟性と永続性を重視して設計された軽量なモジュール型フレームワークとして動作し、システム偵察／リモート・コマンド実行／ペイロード配信／データ流出などを主要な機能として備えている。

その他にも、感染システム上でのフットプリントを最小限に抑えながら通信ロジックを AWS インフラへオフロードすることで、検出の可能性を低減しながら運用効率を維持している。

このキャンペーンを可能にする重要な要素は、2022 年に導入された AWS Lambda Function URL のシンプルさと可視性の低さである。この機能により、開発者は API Gateway やロードバランサーを必要とせずに、HTTPS エンドポイント経由でサーバレス関数を公開できるようになった。

これにより、運用上のオーバーヘッドが軽減されるが、ミスコンフィグが存在する場合にはセキュリティ・リスクが生じる。つまり、AWS の信頼性を悪用するスケーラブルな C2 メカニズムが、認証なしで一般公開されるエンドポイントを介して、攻撃者に提供されてしまう。

この攻撃のライフサイクルは、予測可能なクラウド中心のキル・チェーンに従っている。認証情報を侵害した攻撃者は、get-caller-identity やポリシー列挙といったノイズの少ない API コールを実行して権限を確認する。その後に、無害に見える命名規則を用いた Lambda 関数を、監視が手薄なリージョンへ向けてデプロイする。

さらに、公開 Function URL の付加により永続性が確保され、侵害された AWS アカウントがグローバル C2 ネットワークの一部となり、1 時間当たり数千件もの悪意のリクエストを処理してしまう可能性が生じる。

この活動を MITRE ATT&CK フレームワークへマッピングすると、有効なアカウントの悪用 (T1078.004)／サーバレス実行 (T1648)／Web サービス・ベースの C2 (T1102) への依存が浮き彫りとなる。

特に注目すべき点は、このキャンペーンが AWS の脆弱性を悪用するのではなく、脆弱な ID ガバナンスと不十分な監視体制を悪用していることである。それが示唆するのは、クラウド・セキュリティ管理における重要性の高まりである。

このような脅威を軽減するには、アイデンティティ中心のセキュリティ制御を優先する必要がある。具体的には、多要素認証の徹底／アクセスキーの定期的なローテーション／未使用認証情報の削除などにより、不正アクセスのリスクを大幅に低減できる。

さらに、すべてのリージョンにおいて、包括的な AWS CloudTrail ロギングを有効化することで、不正な Lambda デプロイなどの不審な API アクティビティへの可視性を確保すべきである。

それに加えて、VPC Flow Logs や異常検出を活用することで、プロキシとして使用される Lambda 関数のトラフィック・パターンを特定し、明示的な承認がない限り公開 Function URL の作成を制限する、Service Control Policies (SCPs) を導入する必要がある。それにより、サーバレス環境に対するゼロトラスト・モデルを効果的に適用できる。

HazyBeacon キャンペーンが浮き彫りにするのは、攻撃対象領域をクラウド・ネイティブへと大きく移行させる攻撃者たちの動きである。正規サービスの武器化により検出を回避し、攻撃元の特定を困難にしている。

クラウド導入が加速する中、ユーザー組織が留意すべきことは、インフラのミスコンフィグや ID 管理の弱点により、信頼されるプラットフォームがサイバー・スパイ活動の能動的な構成要素へと変貌していく可能性である。

自身のクラウド環境を、攻撃者のコマンド・インフラにしないためには、継続的な監視／厳格なアクセス制御／プロアクティブな検出戦略が不可欠となる。

訳者後書：HazyBeacon キャンペーンが標的にするのは、AWS の脆弱性ではなく、開発段階や運用におけるミスコンフィグと不十分な ID 管理にあります。具体的には、GitHub などから流出した IAM 認証情報が悪用されて初期アクセスを許したこと、そして Lambda 関数の公開 URL の認証設定が NONE (なし) という無防備な状態のまま作成されたことです。その結果、正規のインフラが、攻撃者の C2 サーバへの通信経路として悪用されてしまいました。ご利用のチームは、ご注意ください。よろしければ、AWS での検索結果も、ご参照ください。