欺骗邮件，绕过 SPF |敌对分子如何执行欺骗电子邮件攻击并绕过现有的 SPF 实施？ |简介 | 1#2 |.com

在当前的文章系列中，我们将了解 SPF 邮件标准的结构化漏洞，该漏洞很容易被敌对分子利用。知道此 SPF 漏洞的敌对分子可以绕过现有的“SPF 墙”，该墙是为保护我们的组织收件人免受欺骗或网络钓鱼攻击而构建的。

除了我们指出 SPF 邮件标准的结构化漏洞的部分之外，我还想进入“下一个级别”，并演示如何执行绕过现有 SPF 实施的欺骗电子邮件攻击。

当前系列文章包括两篇文章。
下一篇文章是 - 如何模拟欺骗电子邮件攻击并绕过 SPF 发件人验证？ | 2#2

众所周知的困境——我应该公开披露 SPF 漏洞吗？ |黑帽与白帽

在我们继续之前，我想谈谈读者心中可能出现的最基本的阻力：你怎么敢发布这样的信息，可以被敌对实体用来伤害和破坏我的组织？

简单的事实是，大多数时候，这个“敌对实体”是专业人士，拥有广泛的知识和明确的路径，了解为什么他应该用来执行欺骗或网络钓鱼攻击，以及如何处理现有的发件人身份验证标准如SPF。

换句话说，“敌对实体”不需要我的帮助和支持来揭露 SPF 邮件标准的结构化漏洞。我可以向你保证，他已经知道这个“SPF盲点”，而且如果他决定攻击你的组织，他很可能会使用它！

作为被任命服务和保护我们组织的资产和用户的人，我们应该有正直和勇气承认存在许多可能伤害我们的威胁和风险。

在我看来，最好的心态应该是——继续讨论更具建设性和成熟的问题，例如——鉴于我意识到这种存在的威胁，而不是“闭上眼睛”并忽视我们邮件基础设施的脆弱性对于我的邮件基础设施，我可以采取哪些措施来为我的组织和用户提供更好的保护？

SMTP作为无辜的协议|欺骗电子邮件和 SPF 作为部分解决方案

我将 SMTP 协议描述为“无辜的协议”，因为 SMTP 协议的主要目的是以最快、最有效的方式将电子邮件从主机 A 传输到主机 B。

当源主机 (A) 寻址目标主机 (B) 并请求启动 SMTP 会话时，目标主机 (B) 的基本假设是主机 A 确实是他所声称的那个人。

这种默认假设被敌对分子利用，他们通过呈现看似合法的主机\接收者的身份来掩饰自己的真实身份。

随着时间的推移，这种“身份问题”引起了组织的注意，他们正在寻找一种解决方案，使他们能够验证发件人的身份，并确保发件人确实是他所声称的人。

为满足验证发件人身份的需要而发明的最流行和众所周知的邮件安全标准之一是 SPF（发件人策略框架）。

SPF标准基于非常简单的验证测试；其中我们验证特定邮件服务器是否有权发送或代表特定域名。

“特定域名”是指指向我们邮件服务器的发件人的电子邮件地址中显示的域名。

问题是 SPF 机制有一个固有的弱点，因为发件人验证过程是通过验证
邮件信封上出现的发件人身份来实现的。 但是，不是可以出现在 强>邮件标题。

这种固有的弱点被敌对分子利用，可以轻松绕过我们现有的 SPF 墙，并执行欺骗电子邮件攻击。

附上来自 SPF 组织网站的报价：

发件人策略框架 (SPF) 是一个开放标准，指定了防止发件人地址伪造的技术方法。更准确地说，当前版本的 SPF（称为 SPF v1 或 SPF Classic）保护用于传递邮件的信封发件人地址。请参阅右侧的框，了解电子邮件中不同类型发件人地址的快速说明。
（还有其他解决方案可以保护标头发件人地址，或者根本不关心谁发送了邮件，仅最初是谁写的。）

我认为我们大多数人都不知道或只了解一些术语，例如
邮件信封、邮件标头 以及发件人使用“多个发件人身份”的 SMTP 方法。

如果您有足够的耐心，我向您保证，在阅读本文后，您将更好地理解这些概念。

为了充分披露 - 我的观点是 SPF 立场是势在必行，并被认为是必要的邮件安全标准，每个使用邮件基础设施的组织必须采用 。

我的主要目的是提请您注意 SPF 标准的“盲点”，并让您了解您可能需要使用额外的邮件安全标准和机制，与 SPF 标准一起或同时使用。

那么如何解决这个SPF“盲点”呢？

我想将这个问题扩展到更广泛的问题：

问：是否有或者什么是“完美的解决方案”，可以为我的组织提供全面的保护，使其免受欺骗或网络钓鱼攻击？
答：好消息是，有一个“完美的解决方案”，当应用该解决方案时，我们可以确保您的组织对欺骗攻击有很好的保护。

不太好的消息是，没有神奇的公式或简单的“红色按钮”可以用来创建“透明的能量圆顶”，以保护我们的组织免受任何“坏人”的侵害，同时使我们能够用户定期、透明地“做自己的事情”，不受任何干扰。

我们困扰的解决方案是 - 不同邮件安全标准的组合或“鸡尾酒”，使我们能够验证发件人身份，例如 DKIM、DMARC、Exchange Online 欺骗电子邮件规则、用户意识计划等。

这种组合的实施将使我们能够建立起坚固而厚实的“防护墙”，这将保护我们的邮件基础设施和我们的用户免受大部分风险以及墙外正在寻找进入方式的敌对因素的影响。

我们的主要任务是：

• 承认欺骗或网络钓鱼攻击的风险，以及我们经历过上述危险的事实。
• 熟悉每种可能的解决方案以及每种可能解决方案的特点（优点、缺点等）。
• 确定最能满足我们组织 DNA 和组织特定业务需求的最佳解决方案组合。
• 实施现有的保护机制，并对采用和吸收该解决方案所需的必要时间（学习模式阶段、测试阶段、处理误报场景等）有必要的耐心。

在下图中，我们可以看到我将其描述为“安全鸡尾酒”的概念的示例。
这个术语的含义是一个场景，在该场景中我们使用两个或多个邮件标准或其他机制的组合例如交换规则，这将是相辅相成的。

例如，如果您的邮件基础设施基于 Exchange 架构，我们可以使用 Exchange 规则来识别
使用带有我们域名的电子邮件地址的未经身份验证的收件人 + 实施 SPF 发件人验证标准，这将确定使用带有我们域名的电子邮件地址的收件人通过未经授权的邮件服务器发送电子邮件的情况。

另一种选择是使用依赖于 DKIM + SPF 标准的 DMARC 邮件标准，并为大多数可能的欺骗攻击场景提供出色的保护。

回顾一下——不要寻找任何简单直接的解决方案来神奇地解决你所有的问题。熟悉现有风险以及该风险的当前解决方案。

如果您想了解有关如何实施可识别并响应的 Exchange 规则的更多信息，我撰写了 12 篇文章的系列文章，回顾了您可以使用的可能选项 - 处理 Office 365 中的电子邮件欺骗攻击基础环境|简介 |第 1 部分#12

如果您想了解有关如何在 Office 365（基于 Exchange Online 的环境）中实施 DKIM 的更多信息，我撰写了 5 篇文章的系列文章，回顾主题 - DKIM - 域密钥识别邮件 | 基本介绍 | 第 1#5 部分

当前系列文章的结构

系列文章“敌对分子如何执行欺骗电子邮件攻击并绕过现有的 SPF 实施”包括两篇文章。

当前文章我们的主要关注点是：

1. SMTP 会话和电子邮件消息的数据结构。
2. SPF 验证过程的实施方式。
3. 敌对分子可以用来绕过现有 SPF 实施的理论方法。

在下一篇文章中，我们将回顾“如何分离”，其中我们模拟敌对分子的场景，执行欺骗电子邮件攻击并设法绕过我们现有的 SPF 基础设施。

SMTP会话和电子邮件消息的数据结构

元数据和电子邮件消息

大多数时候，当我们使用术语“电子邮件”时，我们涉及电子邮件消息内容，例如电子邮件中包含的文本或电子邮件中的附件。

实际上，每个电子邮件消息都包含附加的信息层，可以将其描述为元数据或“关于数据的数据”。

被视为电子邮件消息一部分的元数据包括有关特定电子邮件消息的许多详细信息和信息，以及电子邮件消息向源邮件服务器请求的过程的文档，并以托管目标收件人的目标邮件服务器。

邮件信封和邮件标头作为电子邮件元数据的逻辑容器

SMTP 协议定义了两种类型的“逻辑容器”，它们将保存与特定电子邮件消息相关的元数据：

邮件信封 和 邮件标题。

• 邮件信封 由代表发件人和收件人的邮件服务器使用。
• 邮件标头 由邮件客户端（由用户）使用。

保存在邮件信封中的信息

邮件信封包含以下类型的信息：

1. 保留有关代表发件人的“源邮件服务器”的信息，例如，初始化 SMTP 会话的邮件服务器的 IP 地址或有关源邮件服务器支持的特定安全标准（例如 DKIM）的信息。
2. 保存有关邮件流中涉及的所有邮件服务器的信息。
3. 保留有关发件人 + 收件人身份的信息 - 发件人的电子邮件地址和目标收件人的电子邮件地址。

邮件结构 - 邮件标头和邮件正文

电子邮件的“邮件组件”包括两部分：

1. 邮件标头 - 这是保存元数据信息的“附加容器”。如果您想知道，除了邮件信封 组件，简单的答案是与现实生活场景非常相似，
邮件信封 被视为“临时车辆”，用于将电子邮件从A点“运输”到B点。

电子邮件发送后，消息被代表收件人的目标邮件服务器接受，邮件服务器读取出现在邮件信封中的信息 复制邮件标题部分的大部分信息，然后“撕除了“邮件信封。

2. 邮件正文 - 邮件正文是包括电子邮件撰写者添加到电子邮件消息中的文本和附件的部分。

邮件标头包含以下类型的信息：

1. 保存有关特定电子邮件消息的字符的信息 - 例如，特定电子邮件消息的字符集、MIME 类型等。

2. 保留从邮件信封复制的信息。如前所述，邮件信封 在发送电子邮件之前被邮件服务器删除至目的地收件人。

3. 保存有关“目标邮件服务器”执行的不同安全检查的信息，即代表目标收件人的邮件服务器。
大多数时候，代表目标收件人的邮件服务器执行设计的安全检查识别“有问题的邮件”，例如欺骗电子邮件、包含恶意软件的电子邮件、垃圾邮件等。

有关“安全检查结果”的信息，例如 SCL（垃圾邮件可信度）值，将保存到邮件标头。
另一个示例是邮件服务器配置为使用 SPF、DKIM、DMARC 等标准执行发件人身份验证的场景。此发件人身份测试的结果也将写入邮件标头。

4. 保存有关发件人+收件人身份的信息 - 有关发件人
电子邮件地址和目标收件人电子邮件地址的信息。

注意：在常见情况下，邮件标头的发件人或收件人身份（电子邮件地址）将从邮件信封中复制。

另一种可选方案是邮件信封将包含发件人\收件人身份邮件标头中指定的发件人\收件人身份。

基于邮件的基础设施中的主要身份类型

在本文中，我们多次提到“身份”一词。
在不深入技术讨论的情况下，在与邮件基础设施相关时定义该术语的含义非常重要。

当涉及邮件基础设施时，“身份”一词的简单定义可以翻译为：

1. 电子邮件地址
2. IP地址
3. 用户凭证
4. 证书

关于邮件基础设施和 SPF 标准的主题，我们涉及的主要身份主要是电子邮件地址身份和 IP 地址身份。

当我们说发件人想要向目标收件人发送电子邮件时，我们涉及到发件人的电子邮件地址和目标收件人的电子邮件地址。

另一种类型的“身份”是代表特定收件人发送电子邮件的邮件服务器的身份。在这种情况下，我们通过邮件服务器使用的 IP 地址来关联邮件服务器的身份。

注意：如果我们想更准确的话，还有一种附加类型的身份是电子邮件地址身份的派生，即域名身份。域名标识是从电子邮件地址的“右侧部分”“获取”的。

注意：与邮件基础设施相关，还有其他类型的“身份”，例如用户凭据和证书。在本文中，我们不会提及这种“身份”，因为这个主题超出了我们文章的范围。

需要验证发件人身份

邮件基础设施中最基本的安全需求之一是需要毫无疑问或确定地验证邮件流会话中涉及方的身份。

注意：需要强调的是，许多邮件基础设施不支持用于验证发送给其组织的“外部主机”（发件人或邮件服务器）身份的安全邮件标准。

如果我们想更准确的话，当我们说我们需要验证特定身份时，大多数时候，有兴趣执行此程序的一方是——“接收方”，即目的地的邮件基础设施接受者。

当“外部实体”寻址代表特定域（特定收件人）的邮件服务器，并使用独特的“身份”（特定电子邮件地址或特定 IP 地址）介绍自己时，代表目标收件人的邮件基础设施需要知道发件人确实是他所声称的人。

例如，欺骗电子邮件或欺骗和网络钓鱼攻击的基本原理是基于以下概念：敌对分子对特定组织的邮件服务器进行寻址，并“声称”他是合法组织的收件人。

为了能够知道这个“实体”是真实的、合法的收件人还是通过使用授权用户的身份来伪装自己的敌对分子，邮件服务器将需要实施某种“身份检查”来验证该“实体”发件人的身份。

验证发件人身份的最流行的方法之一是 SPF 标准。当使用SPF标准时，代表目的地收件人的邮件服务器将验证“源邮件服务器”的身份，意思是，代表发件人的邮件服务器通过检查源邮件服务器的IP地址是否出现在“授权”中。列表。 ”

注意：“授权列表”是通过 SPF 记录（TXT 记录）实现的，该记录发布在公共 DNS 基础设施上，并包含有权发送邮件的邮件服务器的 IP 地址列表电子邮件代表特定的域名。

简单邮件流中的不同身份

为了说明这个“身份”概念，让我们使用下图。

在我们的场景中，A 方想要向 B 方发送一封电子邮件。

1. 第一个身份（数字 1）是电子邮件地址，代表想要发送电子邮件的用户\收件人。在我们的场景中，该用户的身份是 - [email protected]

2. 第二种类型的身份（编号 2）是在“原始发件人”想要代表其他发件人发送电子邮件消息的情况下实现的。

一个典型的场景是助理和经理的场景，其中秘书想要代表她的经理向外部收件人发送电子邮件。

在我们的具体示例中，经理身份是 - [email protected]

3. 第三个身份（数字3）是代表发件人的邮件服务器的身份。

我们通过指定邮件服务器 IP 地址来关联源邮件服务器身份。

4. 第四个身份（数字4）是代表目标收件人的邮件服务器的身份。

我们通过指定邮件服务器 IP 地址来关联目标邮件服务器身份。

如果目标邮件服务器支持 SPF，则发件人身份的验证过程是通过验证源邮件服务器 IP 地址是否已注册为特定域名（出现在 E-mail 中的域名）的授权 IP 来实现的。发件人的邮件地址）。

在我们的具体场景中，SPF 验证过程将检查特定邮件服务器是否有权为该域名发送电子邮件 - thankyouforsharing.org

5. 第五个身份（数字 5）是代表目标收件人的电子邮件地址。在我们的示例中，目标收件人由电子邮件地址表示 - [email protected]。

注意：在现实生活中，邮件流可能会更加复杂，并且包括额外的邮件服务器。

包含发件人和收件人身份值的邮件字段

在本节中，我想回顾一下 SMTP 协议用于表示发件人和收件人电子邮件地址“身份”的特定“邮件字段”。

如前所述，标准电子邮件包含两部分 - 邮件信封 和
邮件标头。

每个组件都使用不同的“邮件字段”来表示发件人和收件人的身份。

从

邮件来自

邮件信封 - 保存发件人和收件人信息的“邮件字段”

1. 发件人身份 - 邮件信封 使用名为 - MAIL FROM 用于“保存”有关发件人身份的信息（发件人电子邮件地址）。
2. 收件人身份 - 邮件信封 使用名为 - RCPT TO 用于“持有”有关收件人身份的信息（目标收件人电子邮件地址）。

邮件标头 ——保存发件人和收件人值的“邮件字段”

对于“邮件组件”，保存发件人和收件人身份信息的部分是邮件标头 。

1. 发件人身份 - 邮件标头 使用名为 - 的“邮件字段” FROM 用于“保存”有关发件人身份的信息（发件人电子邮件地址）。
2. 收件人身份 - 邮件标头使用名为 - 的“邮件字段” TO 用于“保留”有关收件人身份的信息（目标收件人电子邮件地址）。

邮件信封基础结构和邮件标头基础结构之间的关系

我们使用两组不同身份的方法（邮件信封身份和邮件标头身份）可以被视为令人困惑。

现在我们就基本回答一下，SMTP协议为满足各种业务场景的需求而创建的这种“分离”。

在某些情况下，邮件信封 中有关发件人和收件人身份的信息将与邮件标头 在某些情况下，不是。

常见场景 - 邮件信封中的身份与邮件信封中的身份相同#000000;">邮件标头。

最常见的情况是我们仅使用一组发件人和目标收件人身份。

例如，当用户写入新的电子邮件地址时，他的电子邮件地址会自动配置在 MAIL FROM 邮件字段中，并且目标收件人的电子邮件地址在 RCPT TO 邮件字段中配置。

鉴于目标邮件服务器完成了所有安全检查并且愿意接受电子邮件，有关发件人和收件人身份的信息将从 邮件信封到邮件标头。

• MAIL FROM 字段中的信息将复制到 邮件标头字段名为 - FROM。
• RCPT TO 字段中的信息将复制到 邮件标题字段名为 - TO。

另一种情况 - 邮件信封 中的身份与邮件信封中的身份不同#000000;">邮件标头。

在这种情况下，存在代表源、发送者的不同“身份集”和代表目的地接收者的不同“身份”。

为了能够演示这种情况，让我们使用以下场景：

• 苏珊是约翰的私人助理。
• 约翰要求苏赞向他的一位客户发送一封电子邮件。

当Suzan创建新电子邮件时，有关Suzan身份的信息将保存在邮件中MAIL FROM 字段中的信封。

有关John身份的信息将在FROM 字段中定义。

在这种情况下，存储在MAIL FROM字段中的信息邮件信封，不会被复制到邮件标头 因为 FROM 字段已“填充”了 John 的电子邮件地址。

SMTP 邮件流中涉及的“附加”身份

在本节中，我想简要回顾一下 SMTP 邮件流中涉及的三个附加“身份”。

源邮件服务器的身份| HELO \EHLO 命令

如前所述，“源邮件服务器”的“主要身份”是服务器IP地址。

邮件源服务器在与另一个邮件服务器初始化 SMTP 会话时可以提供的其他身份类型是 - 邮件服务器代表的主机名 + 域名。

源邮件服务器可以提供的信息不是强制性要求，而是可选的。

如果源邮件服务器想要提供这种类型的身份（他的主机名、他代表的域名或主机名+域名的组合，描述为 FQDN），则邮件服务器可以在 SMTP 之后提供此信息命令 HELO （或 EHLO）。

回复身份

电子邮件中可以包含的第二种类型的“身份”是邮件字段
，名为 - REPLY-TO。

顾名思义，此邮件字段的目的是包含有关特定
我们希望目标收件人“点击”回复按钮时将使用的电子邮件地址的信息。

默认情况下，此邮件字段为空，并且在目标收件人使用回复选项的情况下将使用的默认值（电子邮件地址）是 - 收件人 邮件字段。

返回路径 身份

电子邮件中可以包含的第三种“身份”是邮件字段
，名为 - RETURN-PATH。

该邮件字段的目的是包含电子邮件地址，目标邮件服务器将使用该地址来通知“发件人”有关问题，例如收件人不存在等。
默认情况下，该值邮件字段RETURN-PATH的（电子邮件地址）不是由源发件人或源邮件服务器确定的而是通过目标邮件服务器。

当目标邮件服务器收到电子邮件时，他会从MAIL FROM字段中“提取”电子邮件地址，然后将此电子邮件地址复制到 RETURN-PATH 邮件字段，该字段将作为 邮件标头。

大多数情况下，即使源发件人明确指定了 RETURN-PATH 邮件字段的电子邮件地址值，目标邮件服务器将忽略此信息，并使用邮件信封TO，目标邮件服务器将执行以下过程：

• 将 MAIL FROM 字段中的电子邮件地址复制到 邮件标题 发件人
• 将RCPT TO字段中的电子邮件地址复制到邮件标题 收件人
• 将 MAIL FROM 字段中的电子邮件地址复制到 邮件标头 RETURN-PATH

案例2

如果从源邮件服务器发送的信息包含以下一个或所有邮件字段的值 - FROM 或TO，目标邮件服务器将执行以下过程：

如果邮件字段之一“属于”邮件标头 (FROM 或 TO）包含特定值（电子邮件地址） ，信息不会被复制，或者换句话说，不会被邮件信封。

读取“属于”邮件标题的邮件字段（FROM 或TO）并且不包含特定值（电子邮件地址），信息将从邮件信封邮件字段分别复制。

该过程的最后将包括由目标邮件服务器执行的以下任务：

• 目标邮件服务器将删除邮件信封（邮件信封不是发送给收件人的电子邮件的一部分）。
• 目标邮件服务器将电子邮件传递给目标收件人

SPF 验证流程 - 常见场景

在下面的部分中，我想简要回顾一下目标邮件服务器实现的 SPF 验证过程。

为了演示 SPF 验证过程，我们使用以下场景：

• Suzan 是使用电子邮件地址的源发件人 - [email protected]
• Bob 使用电子邮件地址的目标收件人 - [email protected]

代表 Suzan 的源邮件服务器对代表目标收件人 - Bob 的邮件服务器进行寻址。

在我们的场景中，邮件信封包含有关发件人的信息 (MAIL FROM），以及有关目标收件人的信息（RCPT TO），但 邮件标头字段（FROM 和 TO) 为空。

鉴于目标邮件配置为使用 SPF 来验证发件人身份，邮件服务器将执行以下任务：

1. 从发件人地址（MAIL FROM）中“获取”代表发件人域名的部分。在我们的场景中，域名 - thankyouforsharing.org
2. “记下”源邮件服务器的 IP 地址。
3. 地址 DNS 服务器并检查域 thankyouforsharing.org 是否有 SPF 记录（TXT 记录）。如果存在此类记录，则“读取”SPF 记录的内容。
4. 验证源邮件服务器的 IP 地址是否显示为 SPF 记录中的 IP 地址之一。
5. 如果源邮件服务器的IP地址出现在列表中，则SPF验证测试认为“成功”。其含义是源邮件服务器被授权向 thankyouforsharing.org 收件人发送电子邮件。

更复杂的场景，以及SPF验证方法的漏洞

在下面的部分中，我想回顾一下敌对分子可以用来实施欺骗或网络钓鱼攻击来攻击我们的组织并绕过我们的邮件服务器实施的 SPF 验证检查的方式。

该攻击基于以下构建块：

1. SMTP标准 |使用多个发件人身份

SMTP 协议包括一个选项，其中“源”表示将电子邮件消息发送到目标收件人的元素，可以提供两种不同的身份：

• 发件人 A 的身份将显示在 MAIL FROM 邮件字段中（该邮件字段出现在 邮件信封）。
• 发件人 B 的身份将显示在 FROM 邮件字段中（该邮件字段出现在 FROM 中） #003366;">邮件标头）。

2. SPF发件人验证流程| MAIL FROM 邮件字段和 FROM 邮件字段

• SPF 发件人验证过程仅针对 MAIL FROM 上显示的发件人身份（电子邮件地址）实施。
• SPF 发件人验证过程未实施，仅针对出现在 来自

意思是SPF标准存在“盲点”，因为“FROM”身份没有经过检查或验证通过SPF验证测试。

最大的问题是，知道这种“致命鸡尾酒”的敌对分子可以很容易地利用SPF标准的这个“盲点”。

利用 SPF“盲点”的欺骗电子邮件攻击的 DNA

敌对分子利用SPF“盲点”的实施方式如下：

在执行欺骗或网络钓鱼攻击时，敌对分子的主要目的是导致对方为他执行某些操作（将钱转入银行帐户、单击网页链接等）。

为了说服他想要攻击的目标接收者“采取”具体行动，敌对分子需要隐藏其真实身份并将自己表现为合法用户/接收者。换句话说，提供目标收件人可以信任的电子邮件地址。

为了成功执行欺骗或网络钓鱼攻击，即使代表目标收件人的邮件基础设施使用由 SPF 标准实施的发件人验证过程也是如此。

为了实现这种“SPF绕过机制”，敌对分子执行以下步骤：

1. 购买虚拟域名 - 我使用“虚拟域名”一词，因为域名没有真正的含义。虚拟域名的目的是充当 SPF 发件人验证过程的诱饵，该过程将由代表目标收件人的邮件服务器实施。
2. 在托管虚拟域名的 DNS 服务器中配置所需的 SPF 记录。
3. 添加所需的信息，即他用于执行欺骗或网络钓鱼攻击的邮件服务器的 IP 地址。

欺骗电子邮件攻击的实施方式如下：

敌对分子创建一封包含两个发件人电子邮件地址的电子邮件。

• 第一个电子邮件地址（MAIL FROM）使用“合法域名”（虚拟域名）。在我们的具体示例中，MAIL FROM 电子邮件地址是“红色域”电子邮件地址。
• 第二个电子邮件地址（FROM）使用他想要攻击的收件人的域名。在我们的具体示例中，FROM 电子邮件地址是“绿色域”
  电子邮件地址。

鉴于代表目的地收件人的邮件服务器支持SPF，发件人验证过程将通过验证“红色电子邮件地址”（使用虚拟域名的电子邮件地址）来实现。

鉴于敌对分子

• 创建所需的 SPF 记录
• 使用 SPF 记录中显示的 IP 地址的邮件服务器（使用虚拟域名发送电子邮件的邮件服务器）

SPF 发件人详细验证将成功完成。

目标邮件服务器删除 邮件信封 ，包括 MAIL FORM 地址并留下“绿色电子邮件地址”（FROM 电子邮件地址)。
从收件人目的地的角度来看，该电子邮件是由发件人使用“绿色电子邮件地址”发送的。目标收件人不知道邮件信封中出现的“第一个电子邮件地址”已被删除。

恶意分子如何绕过SPF验证检查的演示

为了能够演示敌对分子如何绕过 SPF 发件人验证检查，让我们使用以下场景：

敌对分子计划攻击（执行欺骗\鱼叉式网络钓鱼攻击）名为 - o365pilot.com 的公司

敌对分子做了功课，找到了有关组织中发挥重要作用的人员的所需信息：

• 公司 CIO 是 Bob，使用电子邮件地址 [email protected]
• 公司 CFO 是 Suzan，使用电子邮件地址 [email protected]

敌对分子正计划向 Bob 发送显然是由 Suzan 发送的欺骗电子邮件。

敌对分子知道 o365pilot.com 的邮件基础设施对每封传入邮件实施 SPF 发件人验证检查。

为了能够绕过 SPF 发件人验证检查，恶意元素使用名为 - thankyouforsharing.org
恶意元素创建所需的 SPF 记录，该记录将使用用于发布有关该域名的授权邮件服务器的信息 - thankyouforsharing.org

敌对元素会创建一封新电子邮件，其中包含两个发件人的电子邮件地址：

• [email protected]
• [email protected]

敌对分子想要攻击的目标接收者是公司首席执行官鲍勃。

敌对分子邮件服务器将通过启动 SMTP 会话来寻址代表目标收件人的邮件服务器，并要求他将电子邮件传递给目标收件人。

目标邮件服务器将对 MAIL FROM 中显示的电子邮件地址执行 SPF 发件人验证测试。

在我们的场景中，邮件服务器将尝试验证域的 SPF 记录 - thankyouforsharing.org

如果 SPF 记录配置正确，则 SPF 发件人验证测试成功完成，代表目标收件人的邮件服务器“声明”该发件人是可信的（发件人是合法发件人）。

目标邮件服务器将复制 MAIL FROM
中显示的电子邮件地址（[email protected]) 到邮件字段 - 返回路径。

目标邮件服务器将删除包含电子邮件地址信息的邮件信封 -