黑客滥用 GitHub 与 Jira 通知功能，通过受信任 SaaS 渠道实施网络钓鱼

网络犯罪分子如今正将开发者与 IT 团队最信赖的工具变为攻击武器。通过滥用 GitHub 与 Jira 内置的自动化通知功能，威胁行为者得以发送极具欺骗性的钓鱼邮件，而这些邮件恰恰发自平台自身的官方服务器。

此次攻击行动的危险之处在于其手法极其简单。传统的网络钓鱼依赖于伪造发件人地址或仿冒相似域名，安全工具通常能够识别这些特征。

但在此次攻击中，钓鱼邮件来自经过验证的基础设施——即隶属于 GitHub 和 Jira 开发公司 Atlassian 的真实服务器。

由于这些邮件满足所有标准身份验证要求（包括 SPF、DKIM 及 DMARC），绝大多数安全网关在技术上缺乏拦截它们的依据。

思科 Talos 团队对这一日益猖獗的趋势进行了追踪分析，并于 2026 年 4 月 7 日发布了研究报告。数据显示，在 2026 年 2 月 17 日攻击活动的峰值当天，来自 GitHub 基础设施的邮件中约有 2.89% 与此类滥用行为相关。

在为期五天的时间窗口内，发自 "noreply@github.com" 的邮件流量中约有 1.20% 在主题行中包含了以"发票"为诱饵的内容。

Talos 研究人员将这种手法称为平台即代理（PaaS - Platform-as-a-Proxy）模型。攻击者无需入侵任何系统或攻破平台本身。

他们仅需利用平台现有的功能（如仓库提交、项目邀请）作为推送恶意内容的渠道。邮件的投递工作则由平台代为完成，附带经过验证的签名和可信的品牌标识。

在几乎所有的观察案例中，最终目的均为凭证窃取。受害者会被诱骗点击虚假的账单提醒、欺诈性的支持热线号码或具有欺骗性的账户警告信息。

一旦用户交出了登录凭证，攻击者便获得了初始访问入口，这可能导致未经授权的访问、账户接管乃至更深的网络渗透。

攻击手法详解：GitHub 与 Jira 通知管道

在 GitHub 上，攻击始于创建一个代码仓库。随后，攻击者会推送一次提交，并在提交信息的字段中填充社会工程学内容。GitHub 的提交界面包含两个文本区域：一个是简短的必填摘要行，另一个是较长的可选描述区域。

攻击者将听起来十分紧急的诱饵（例如伪造的发票或账单提醒）放置在摘要行中，并在扩展描述中填入完整的诈骗信息，包括虚假的电话号码或欺诈性链接。

提交代码后，GitHub 会自动通过邮件通知所有协作者，且完整的恶意信息会嵌入在通知邮件正文中。

生成的邮件看起来像一封标准的 GitHub 通知。原始邮件头部信息显示发送服务器为 "out-28.smtp.github.com"——一个合法的 GitHub 邮件服务器，IP 地址为 "192.30.252.211"。

DKIM 签名字段显示为 "d=github.com"，并通过了所有验证检查，未触发任何安全警报。

Jira 的利用方式则采用了不同的机制。攻击者会创建一个 Jira Service Management 项目，设置一个虚假的项目名称（例如"Argenta"），并将钓鱼信息嵌入到"欢迎信息"或"项目描述"字段中。

然后，他们利用"邀请客户"功能，输入目标受害者的电子邮箱地址。Atlassian 的后端随后会生成一封自动邀请邮件，将攻击者预设的内容封装在其自有签名和品牌模板内。


收到的邮件看起来与官方的 Jira 系统通知毫无二致，甚至包含了 Atlassian 的页脚品牌标识。

安全建议

Cisco Talos建议各企业应转变对 SaaS 平台邮件的盲目信任态度。

安全团队应将 GitHub 与 Atlassian 的 API 审计日志集成至 SIEM 或 SOAR 系统中，以便在钓鱼邮件发出前标记出异常活动——例如来自不常用地点的批量用户邀请或项目创建行为。

任何来自 GitHub 或 Jira 等平台、带有财务相关或紧急催促内容性质的通知邮件都应被标记并进行复核，因为这些内容与这些工具本身的预期用途明显不符。

在处理敏感交互时，用户应直接通过浏览器访问官方平台门户，而非点击通知邮件中的链接。

此外，也鼓励企业将撤销举报自动化并提交至平台的信任与安全团队，以此增加攻击者的操作成本。