GitHub／Jira の偽公式通知に御用心：シンプルな手口でセキュリティ・ゲートウェイを回避

Hackers Abuse GitHub and Jira Notifications to Deliver Phishing Through Trusted SaaS Channels

2026/04/13 CyberSecurityNews — いまのサイバー犯罪者たちは、開発者や IT チームが最も信頼しているツール自体を武器化している。GitHub と Jira に組み込まれた自動通知機能を悪用する攻撃者たちは、それらプラットフォーム自身のサーバから発信されるメッセージとして、説得力の高いフィッシングメールを配信している。その単純さに、このキャンペーンの危険性が潜んでいる。従来のフィッシングは、送信元アドレスを操作するために偽装などを行うが、セキュリティ・ツールによる検知が可能な場合が多い。

しかし、このケースでは、GitHub や Jira の正規サーバといった検証済みインフラから悪意のメールが送信される。これらのメールは、SPF／DKIM／DMARC などの認証要件を満たすため、多くのセキュリティ・ゲートウェイは技術的にブロックできない。

この手法の増加傾向を追跡する Cisco Talos のアナリストたちが、2026年4月7日に調査結果を公開した。そのデータによると、2026年2月17日のピーク時には、GitHub インフラから送信されたメールの約 2.89% が、この悪用に関連していた。

5 日間に限定すると、”noreply@github.com”からのトラフィックの約 1.20% に、”invoice” をルアーとする件名が含まれていた。Talos 研究者たちは、この手法を Platform-as-a-Proxy (PaaP) モデルと呼ぶ。攻撃者にとって、システム侵害やプラットフォーム侵入は不要である。

これらのプラットフォームは検証済み署名と信頼されたブランドを持ち、リポジトリコミットやプロジェクト招待といった既存の機能を介して、悪意のコンテンツを配信する。

大半のケースにおいて、最終的な目的は認証情報の窃取である。騙された被害者たちは、偽の請求通知／サポート番号／アカウント警告へと誘導される。そこでユーザーが認証情報を入力すると、攻撃者は不正アクセスやアカウント乗っ取りを可能にし、さらなるネットワーク侵害の足掛かりを得る。

GitHub／Jira 通知パイプラインにおける攻撃手法

GitHub における攻撃は、リポジトリ作成から開始される。攻撃者はソーシャル・エンジニアリング内容を含むコミット・メッセージを push する。

GitHub のコミット・インターフェイスには、必須とされる短いサマリ・フィールドと、任意の長文説明のフィールドが存在する。攻撃者は、サマリ部分に偽請求や警告といった緊急性の高いフックを配置し、詳細説明部分に詐欺メッセージ全文／偽電話番号／悪意のリンクを記述する。

このコミットが送信されると、メール本文にコミット内容の全文を取り込んだメッセージが、すべてのコラボレーターへ向けて、GitHub から自動通知される。

生成されるメールは、通常の GitHub 通知として表示される。メールヘッダの送信サーバは “out-28.smtp.github.com” であり、IP は “192.30.252.211” という、正規の GitHub メール・サーバである。DKIM 署名は “d=github.com” となるため、すべての検証を問題なく通過する。

その一方で、Jira では異なる手法が用いられる。攻撃者は Jira Service Management プロジェクトを作成し、Argenta などの偽名称を設定する。フィッシング・コンテンツは、”Welcome Message” や “Project Description” などに埋め込まれる。

Invite Customers 機能を利用して対象メール・アドレスを登録すると、Atlassian のバックエンドが自動招待メールを生成し、攻撃者のコンテンツを署名付きテンプレート内に組み込む。このメールは、Atlassian ブランド付きフッタを含む公式通知として表示される。

Cisco Talos がユーザー組織に対して推奨するのは、SaaS プラットフォームからのメールを、盲目的に信頼しないことである。セキュリティ・チームは、GitHub および Atlassian API 監査ログを SIEM／SOAR に統合し、未知の場所からのプロジェクト作成などの異常を検知すべきである。

GitHub や Jira から送信される通知に、財務関連や緊急性の高い内容が含まれる場合にはレビュー対象とすべきである。機密性の高い操作については、通知リンクをクリックせずに、公式ポータルへ直接アクセスする必要がある。

さらに組織は、プラットフォームの Trust and Safety チームへのテイクダウン報告を自動化し、攻撃者の運用コストを引き上げるべきである。

訳者後書：今回の深刻な問題の原因は、GitHub や Jira といった信頼性の高いプラットフォームに備わっている自動通知機能が、攻撃者によりメール送信の踏み台 (プロキシ) として悪用されたことにあります。通常のフィッシング・メールは、送信元の偽装を見破ることで検知できますが、この手法で届くメールは、プラットフォーム側の正規サーバから本物の署名 (SPF／DKIM など)を伴っています。攻撃者が、リポジトリのコメント欄やプロジェクトの招待機能に悪意のメッセージを書き込むだけで、公式な通知としてシステムが自動的に被害者へ届けてしまうため、セキュリティ・ソフトによるブロックが極めて困難になります。このような、システムの正規な仕様を逆手に取る手法を、Cisco Talos は Platform-as-a-Proxy (PaaP) と呼んでいます。