警惕钓鱼邮件:自动转发与Exchange联系人如何成为安全漏洞

本文通过真实案例揭示了钓鱼邮件如何利用自动转发和Exchange联系人绕过O365安全策略,深入企业内部环境,并提出了针对性的防御建议和解决方案。

停止自我钓鱼:自动转发和Exchange联系人如何背后捅刀

钓鱼攻击是一种持续存在的威胁,但最近用户教育和垃圾邮件过滤器已经帮助减轻了部分威胁。但是,当钓鱼邮件进一步突破用户邮箱,深入企业内部环境时,会发生什么?用户还能保持同样的警惕性吗?

本文所讨论的事件是我在为SOC客户检查O365日志时发现的真实事件。为了在整篇博客中保持清晰,我将Microsoft 365称为O365,因为我们的日志字段目前是这样标记的。我还将隐去电子邮件域名,因此在必要时,我将客户域名称为“customer.com”。

当我第一次发现这个事件时,我正在寻找O365标记为钓鱼但仍被投递(而不是被阻止或隔离)的电子邮件。发生这种情况可能有几个原因,比如追溯性的钓鱼判定或对某些邮箱的例外处理。

o365.audit.Verdict: “Phish” and o365.audit.DeliveryAction: Delivered

我发现大量与营销相关的垃圾邮件。O365仅仅因为电子邮件营销服务伪造发件人地址,就将数万封电子邮件标记为钓鱼。这相当常见,因为你希望收件人看到你自己的电子邮件域名作为发件人,而不是你用来发送这些电子邮件的服务域名。

为了进一步缩小结果范围,我开始尝试排除各种字段值以缩小搜索结果。我省略了试错的细节,因为正是在那时我找到了激发这篇博客的事件。请看下面的日志截图:

从该图像中需要注意的几个重要事项:

  • P1Sender字段是一个营销电子邮件服务域名
  • P2Sender字段实际上是客户的地址accounting@customer.com
  • 电子邮件都被标记为钓鱼,并被阻止和隔离
  • O365策略指出这些电子邮件是“IntraOrgPhish”

快速解释P1Sender和P2Sender之间的区别:P1Sender是“MAIL FROM”地址,简单来说,通常可以理解为电子邮件的真实发件人。P2Sender是“From”地址,在电子邮件客户端中显示为电子邮件的发件人。在这个例子中,客户的会计电子邮件地址被伪造为From地址。这也可能是标记为“IntraOrgPhish”的原因。

现在,希望理解了这一点后,我们不应该太担心。所有这些电子邮件都被阻止和隔离了。查看发件人地址,看起来不像真正的组织内部钓鱼攻击,所以一切似乎都很好。稍后,如果我们想要一些工件,可以提取电子邮件,但除此之外,鉴于这种钓鱼电子邮件的普遍性,这里没有什么需要太多回应的。

然而,由于我的病态好奇心,我深入挖掘并发现了这一点:

其中一些电子邮件被发送到与Jira项目链接的Atlassian电子邮件,这些电子邮件即使被分类为钓鱼,也没有被阻止或隔离。相反,它们被标记为出站垃圾邮件。但这里的区别是什么?我给你一个提示——不是任何一个发件人地址。P1Sender保持相同的电子邮件营销域名,P2Sender仍然是accounting@company.com。那么为什么O365有不同的响应?

结果发现,这个会计电子邮件地址不出所料是相关公司的电子邮件分发列表,而这个电子邮件分发列表有一个成员是用于在Jira中转发和创建问题的“Exchange联系人”。这个Exchange联系人促进了这些钓鱼电子邮件转发到Jira,并且由于电子邮件现在是出站而不是入站,O365将这些分类为出站垃圾邮件并允许它们通过。

这就是事情变得令人担忧的地方。这些电子邮件被转发,包括恶意附件,到一个Jira项目,创建了包含这些附件的Jira问题,并在Jira中附加。如果你没有立即理解这个问题的严重性,请考虑这一点:用户可能对在随机电子邮件中打开附件犹豫不决,但他们会对在分配给他们的Jira工单中打开附件同样犹豫吗?

幸运的是,我们当天就迅速发现了这个问题。我们能够从项目中删除这些Jira工单,并创建了一个Elastic检测来警报我们钓鱼附件被转发到Atlassian。但最重要的是,我们没有找到任何日志事件表明有人打开了那个附件或访问了其中的任何链接。

总结这篇博客的信息,我建议你仔细审查和理解如何将电子邮件转发到你的工单系统——你很可能在钓鱼自己的用户。正如我之前提到的,即使是受过良好钓鱼威胁教育的人也可能不会预料到钓鱼邮件会出现在他们的工作项中。

你能对此做些什么(除了删除Jira并回归便签和信鸽进行项目管理)?

在我们这边,BHIS系统团队的一名成员为我们自己的一个电子邮件分发列表创建了一个服务账户,并将其连接到我们的工单系统。这允许从收件箱中提取电子邮件,而不是转发到联系人,这似乎是这个问题的根本原因。

如果你正在寻找如何在Jira中做到这一点,你可能会发现这个链接有帮助:https://support.atlassian.com/jira-service-management-cloud/docs/add-an-email-account/

作为奖励,如果你已经读到这里,这里是恶意.html文件中的部分内容:

正如你可能已经猜到的,该文件是一个伪造的登录页面,旨在窃取凭证。虽然凭证窃取器可能仍然无法在Jira中欺骗用户,但如果这是一个启用宏的Excel工作簿,我们还能这么说吗?我宁愿不去试探那种命运。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计