目 录CONTENT

文章目录

钓鱼邮件专题

Administrator
2025-03-11 / 0 评论 / 0 点赞 / 12 阅读 / 0 字

今日直播精要

一、本周进度

  1. 进一步的攻击面分析

  2. 钓鱼相关枚举

二、钓鱼专题

邮件基础精要

DNS基础

链接资源:渗透测试之DNS

2. 网络钓鱼基础

概念和分类

网络钓鱼是一种社会工程技术,其中攻击者通过伪装成可信赖的实体来诱导目标个人或组织透露敏感信息,如登录凭据、财务数据或个人身份信息。这种攻击可以采取多种形式,包括但不限于:

  1. 基于渠道的分类:

    • 电子邮件钓鱼:这是最常见的钓鱼类型。攻击者发送看似来自合法机构(如银行、社交媒体平台、支付服务等)的电子邮件,以骗取个人信息。这些邮件通常包含紧急或诱惑性的内容,诱使受害者点击链接或下载附件,这些链接或附件可能含有恶意软件,或者会将用户重定向到假冒的网站以收集他们的信息。

    • 语音钓鱼(Vishing):在这种攻击中,骗子通过电话联系目标,通常伪装成银行、警察或其他官方机构的代表,以获取个人信息或财务信息。他们可能会要求受害者提供银行账户信息、密码、信用卡号等。

    • 短信钓鱼(Smishing):类似于电子邮件钓鱼,但攻击者使用短信作为交流方式。这些短信通常包含一个链接,引导收件人到一个恶意网站或要求他们直接回复敏感信息。

    • 社交媒体钓鱼:在社交网络平台上进行的攻击,可能包括冒充朋友的账户,发布含有恶意链接的状态更新,或通过私信发送钓鱼链接。攻击者利用社交媒体的信任和社交网络来诱骗用户提供个人信息或点击恶意链接。

  2. 基于目标的分类:

    • 普通钓鱼:随机目标广泛的用户群体。

    • 鱼叉式钓鱼:这是一种更加定向的攻击,攻击者通过收集目标的个人信息(如从社交媒体上),然后发送定制化的欺骗性信息,以提高成功率。

    • 网络钓鱼(Whaling):这种攻击专门针对公司的高级管理人员,如CEO或财务主管。攻击者通常会通过研究目标的个人和职业细节来定制欺骗性信息,以窃取大额资金或重要的公司信息。

  3. 基于技术的分类:

    • 克隆钓鱼:攻击者复制一个合法的电子邮件消息,并将其中的链接或附件更换为恶意的版本,然后再次发送给不知情的受害者。由于邮件看起来与先前收到的合法邮件非常相似,因此更容易被受害者信任。

    • 商业电子邮件入侵(BEC):这种攻击针对企业,攻击者通常通过冒充高层管理人员或合作伙伴的电子邮件账户,诱导员工转账或提供敏感信息。

    • 钓鱼网站:攻击者创建一个看起来与真实网站非常相似的假冒网站,目的是欺骗用户在该网站上输入个人信息。这些网站的设计和网址往往与真实网站极为相似,很容易使人上当。

  4. 基于攻击手段的分类:

    • SEO钓鱼:(Search Engine Optimization Phishing):这种方法涉及优化恶意网站,使其在搜索引擎结果中排名较高,以吸引无意中搜索相关关键词的用户。当用户访问这些网站时,他们可能会被诱导输入个人信息,或者下载恶意软件。

电子邮件基本原理

邮件系统主要由三个部分组成,即邮件客户端、邮件服务器和邮件传输协议。邮件客户端,如Outlook, Gmail,是用户与邮件系统交互的界面。而邮件服务器负责存储、转发和处理邮件。邮件传输协议则规定了邮件的发送和接收方式。邮件系统中使用的主要协议有三个,分别是简单邮件传输协议(SMTP),用于发送邮件,它规定了邮件从发送方到达邮件服务器的路径,以及邮件服务器之间的邮件传递方式。邮局协议版本3,即POP3,用于接收邮件,允许邮件客户端从服务器下载邮件并在本地存储。再有是互联网消息访问协议IMAP,也是用于接收邮件的,但与POP3不同,IMAP允许客户端在服务器上管理邮件,不必将所有邮件下载到本地。

邮件发送和接收过程是用户在邮件客户端撰写邮件后,邮件客户端通过SMTP协议将邮件发送到服务提供商的SMTP服务器,该服务器再将邮件转发到接收方的邮件服务器。接收方的邮件服务器存储邮件,等待接收方通过客户端检索。接收方使用POP3或IMAP协议通过客户端从服务器上下载或读取邮件。

但从一封邮件看,一般包含头部(Header)、正文(Body)和附件(Attachments)三部分,其中头部较为复杂,由一系列字段组成,包含了控制邮件传输和呈现的所有元数据,具体是:

字段

描述

发件人(From)

显示邮件的发送者的电子邮件地址。

收件人(To)

显示邮件的主要接收者的电子邮件地址。

抄送(Cc)

将邮件发送给额外的接收者,这些接收者的地址对所有收件人都是可见的。

密送(Bcc)

与抄送类似,但收件人的地址对其他收件人不可见。

主题(Subject)

邮件的主题或标题。

日期(Date)

邮件发送的日期和时间。

消息ID(Message-ID)

邮件的唯一标识符。

引用(References)/回复ID(In-Reply-To)

用于将邮件关联到一系列回复中。

内容类型(Content-Type)

指定邮件正文的MIME类型,如纯文本(text/plain)或HTML(text/html)。

用户代理(User-Agent)

标识发送邮件的应用程序或邮件客户端。

头部的细节、正文和附件这些字段我们在处理邮件时都需要与其打交道。

电子邮件相关协议

再具体说说电子邮件相关的协议,尤其和邮件钓鱼相关的smtp等协议。

一是电子邮件传输类协议:

  1. SMTP(Simple Mail Transfer Protocol):是用于发送电子邮件的标准协议。它定义了邮件客户端如何向邮件服务器发送邮件,以及邮件服务器之间如何交换邮件。SMTP使用"STORE AND FORWARD"模式,确保邮件能够从发送者传输到接收者。

  2. POP3(Post Office Protocol version 3):是一种用于从邮件服务器接收电子邮件的协议。它允许电子邮件客户端从服务器下载邮件,并通常会在下载后删除服务器上的邮件副本。POP3是一种基于拉取的协议,适合在单一设备上管理邮件。

  3. IMAP(Internet Message Access Protocol):是另一种用于从邮件服务器检索邮件的协议。与POP3不同,IMAP允许用户在多个设备上查看和管理服务器上的邮件,邮件保留在服务器上。这使得IMAP更适合多设备环境和频繁的邮件访问。

二是电子邮件安全类协议:

  1. SPF(Sender Policy Framework):SPF是一种用于防止电子邮件地址伪造的电子邮件验证方法。它允许邮件域的所有者在DNS中指定哪些邮件服务器被授权发送其域的邮件,从而使接收邮件的服务器可以验证发件服务器是否在这些授权服务器中。这种方法主要用于减少垃圾邮件和钓鱼攻击,提高邮件的可信度。

  2. DKIM(DomainKeys Identified Mail):DKIM是一种电子邮件安全技术,允许发件人在邮件头部中添加数字签名,以此来验证邮件是否确实来自声明的发件人域,并且在传输过程中未被篡改。这种技术的目的在于确保邮件的真实性和完整性,防止邮件内容在传递过程中被篡改。

  3. DMARC(Domain-based Message Authentication, Reporting & Conformance):DMARC基于DKIM和SPF技术,允许电子邮件域的所有者发布策略来定义如何处理不符合DKIM或SPF验证的邮件。它通过增加对齐机制,并为邮件域提供邮件处理报告,从而增强电子邮件的安全性和信任度。

  4. STARTTLS:STARTTLS是一个协议命令,用于在已有的不安全邮件传输协议(如SMTP、IMAP和POP3)上启动TLS加密。这一命令的目的是在标准的邮件传输过程中加入加密层,提高数据传输过程中的安全性,确保邮件内容在传输中不易被窃听或篡改。

  5. S/MIME(Secure/Multipurpose Internet Mail Extensions):S/MIME是一种用于加密和数字签名的安全邮件协议,基于公钥加密技术。它使邮件内容在传输过程中保持加密,并可验证发件人身份,目的是确保邮件内容的机密性和完整性,以及身份验证。

  6. TLS(Transport Layer Security):TLS是一种加密协议,用于在客户端和服务器之间提供安全的通信通道,虽然STARTTLS是启动TLS的命令,但TLS本身确保数据在传输过程中的安全性,防止数据被拦截和窃听。

  7. PGP(Pretty Good Privacy):PGP是一种用于邮件加密的技术,提供数据加密和数字签名,经常用于个人邮件通信中。这种技术使用户能够安全地发送电子邮件,确保只有预期的接收者能够阅读邮件内容。

  8. Email Authentication Records in DNS:这是一种在DNS记录中添加额外邮件验证信息的技术方法,而不是一个单独的协议。它包括添加SPF, DKIM记录和DMARC策略,目的是提供一种机制来验证发件人身份,并确定他们是否有权发送邮件,以防止邮件欺诈和垃圾邮件。

  9. MTLS(Mutual TLS):MTLS是TLS的一个扩展,要求两个通信方(例如,两个邮件服务器)都必须进行身份验证。这种方法的目的是提高安全级别,确保双方通信更为安全和可靠。

三是电子邮件组件类协议:

  1. MIME(Multipurpose Internet Mail Extensions):MIME是一种扩展标准,允许邮件包含多种格式的数据(如文本、HTML、图像和声音)。MIME扩展了电子邮件的功能,使其不仅能传输ASCII文本,还能处理多媒体内容。

  2. MTA(Mail Transfer Agent):MTA是负责在互联网上转发电子邮件的软件。它是电子邮件传输过程中的关键组成部分,确保邮件可以从发送者顺利传送到接收者。

  3. MDA(Mail Delivery Agent):MDA是用于在邮件系统内部将邮件从服务器传递到最终收件人邮箱的组件。它处理邮件的最后一步投递。

  4. MUA(Mail User Agent):MUA,通常称为电子邮件客户端,是用户用来与邮件系统交互的界面。用户通过MUA撰写、发送、接收和阅读电子邮件。

安全性较高的电子邮件服务

当讨论电子邮件服务提供商的安全性时,有几家公司因其卓越的安全措施和对隐私的承诺而脱颖而出。截至2023年,ProtonMail是其中的佼佼者,这家位于瑞士的公司提供端到端加密的邮件服务,确保只有发送和接收方能够阅读邮件内容。其服务器位于瑞士,因此受到该国严格的隐私法律保护。ProtonMail不记录用户的IP地址,并支持双因素认证,允许用户在不提供任何个人信息的情况下创建账户。

另一家知名的安全邮件服务提供商是德国的Tutanota。Tutanota同样提供端到端加密,保证所有邮件(包括发往非Tutanota用户的邮件)在服务器上加密。它的客户端是开源的,还提供加密的日历和联系人功能以及双因素认证。

CounterMail是另一个安全性极高的邮件服务,使用OpenPGP加密技术。其独特之处在于,其服务器不使用任何硬盘存储,所有数据都存储在RAM中,这增加了物理安全性和匿名性。CounterMail支持匿名支付和邮箱创建,并提供USB密钥作为双因素认证的一个选项。

Mailfence,位于比利时,提供端到端加密和数字签名功能的邮件服务。Mailfence致力于保护用户的隐私,不会跟踪或扫描用户的邮件,遵守欧洲的隐私法律,并支持双因素认证和PGP密钥的导入。

Posteo,是一家德国邮件服务提供商,以其对隐私的保护和环保政策而著称。Posteo提供匿名注册和支付方式,不会跟踪用户数据,并提供全站加密和双因素认证。

FastMail,尽管是澳大利亚的公司,不提供端到端加密,但在保护用户隐私和数据安全方面享有良好声誉。它使用安全的数据中心和加密的数据连接,并支持双因素认证。

常用SMTP命令和交互

常用SMTP命令一览

命令

用途

例子

HELO

用于客户端向服务器标识自己。

HELO redteamnotes

EHLO

类似于HELO,但用于标识支持扩展的SMTP协议。

EHLO redteamnotes

MAIL FROM

定义发件人的邮件地址。

MAIL FROM:sender@redteamnotes.com

RCPT TO

定义收件人的邮件地址。

RCPT TO:recipient@redteamnotes.com

DATA

标志着邮件主体内容的开始,后跟邮件的头部和正文。

DATA

QUIT

结束SMTP会话。

QUIT

RSET

重置当前会话,清除所有已设置的参数。

RSET

VRFY

用于验证指定的用户或邮件地址是否存在。

VRFY user@redteamnotes.com

STARTTLS

将连接从非加密切换到TLS加密模式。

STARTTLS

举例及详解一

┌──(kali㉿loaclhost)-[~/RedteamNotes/RedteamingLive/]
└─$ telnet 10.10.110.74 25
Trying 10.10.110.74...
Connected to 10.10.110.74.
Escape character is '^]'.
220 redteamnotes ESMTP Postfix (Ubuntu)
ehlo RedteamNotes.com
250-redteamnotes
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8
redteamnotes
502 5.5.2 Error: command not recognized
VRFY admin
550 5.1.1 <admin>: Recipient address rejected: User unknown in local recipient table
VRFY admin@redteamnotes.com
550 5.1.1 <admin@redteamnotes.com>: Recipient address rejected: User unknown in local recipient table

对上面的命令注意解释下

关于Escape character is '^]':

在 telnet 会话中,"Escape character is '^]'" 这个提示是非常重要的,因为它提供了一种方式来访问 telnet 客户端的控制功能,而不是将输入发送到远程会话。这个特殊的转义字符(通常是 Ctrl + ] 组合键)允许用户从远程会话中"逃脱"回到 telnet 命令提示符,而不中断或关闭当前的连接。

这里有几个使用转义字符的场景:

  1. 暂停或管理会话:如果你正在与一个远程服务器进行交互,可能需要暂时返回到本地 telnet 客户端来执行某些命令,比如检查状态或修改设置,然后再返回到远程会话。

  2. 安全退出:使用转义字符可以安全地退出 telnet 会话。直接关闭 telnet 窗口或终端可能会导致会话不正常结束,这在某些情况下可能会导致问题。

  3. 故障排查:在遇到远程服务器无响应或类似问题时,转义字符允许你回到 telnet 客户端来执行诊断命令或安全地关闭会话。

使用转义字符通常是这样的:

  • 按下 Ctrl + ](这是 ^] 的意思),这会将你带到 telnet 的命令提示符。

  • 在 telnet 命令提示符下,你可以输入命令,比如 quit 来退出 telnet 会话,或 status 来查看连接状态。

这个特性是 telnet 的一个标准组成部分,对于确保能够控制和适当管理 telnet 会话非常重要。

关于EHLO

HELO 和 EHLO 命令的起源与 SMTP(Simple Mail Transfer Protocol)的发展历程紧密相关。SMTP 是互联网的早期协议之一,用于发送电子邮件。为了理解这些命令的起源,我们需要回顾SMTP 的历史。

  1. SMTP 的早期历史:SMTP 最初在 1982 年的 RFC 821 中定义。在这个版本的 SMTP 中,HELO 是开始 SMTP 会话的标准命令。 HELO 后面跟着的是发送方的主机名,这样接收方就知道是谁在尝试与其通信。

  2. SMTP 的扩展:随着时间的推移,人们意识到原始的 SMTP 协议需要更多的功能,比如身份验证、消息传输加密等。为了支持这些新功能,SMTP 需要进行扩展。这些扩展在 1995 年的RFC 1869 中定义,这也是 EHLO 命令首次出现的地方。 EHLO (代表 "Extended HELO")是一个新的命令,用于表示客户端希望使用 SMTP 的扩展功能。当服务器接收到 EHLO 命令时,它会回复并列出其支持的所有扩展。

  3. 为什么需要新命令:引入 EHLO 而不是仅修改 HELO 的原因是为了向后兼容。这样,旧的SMTP 服务器和客户端仍然可以按照原始的方式工作,而新的客户端和服务器可以利用扩展功能。

总之,HELO 和 EHLO 的起源与 SMTP 协议的发展历程密切相关。随着 SMTP 功能的增加,为了保持向后兼容性,EHLO 被引入为一个新命令,用于支持这些扩展功能。

这个命令用于启动会话并向服务器标识客户端的主机名。但是,如果没有提供主机名,服务器会返回错误。

SMTP(Simple Mail Transfer Protocol)命令本身是不区分大小写的。

ESMTP (Extended Simple Mail Transfer Protocol)

ESMTP 是 Simple Mail Transfer Protocol (SMTP) 的扩展版本。SMTP 是一个用于发送和接收电子邮件的互联网协议。
ESMTP 引入了一些额外的命令和功能,允许更灵活和可靠的电子邮件传输。
例如,它支持邮件大小协商、身份验证和加密等功能。
当一个邮件服务器使用 EHLO 命令而不是原始的 HELO 命令回应时,它表明该服务器支持 ESMTP。

Postfix

Postfix 是一种流行的开源邮件传输代理(MTA),用于路由和传递电子邮件。它被设计为快速、易于管理且安全。Postfix 通常用于替代更老的 Sendmail MTA,因为它更易于配置和管理。Postfix 可以配置为使用 SMTP 或其扩展版本 ESMTP 来发送电子邮件。

250消息序列

在 SMTP 通信中,当你看到一系列以数字开头,如 "250-",这通常意味着服务器正在列出多行响应。这些响应行都是对同一个命令的回应,但由于信息内容较多,因此分成了几行。在这种情况下,每行都以 "250-" 开头,表示它们是同一响应的一部分。

命令解析

  1. PIPELINING: 这项功能允许客户端在等待前一个命令的响应之前发送多个命令。这可以提高通过网络发送命令的效率,特别是在高延迟的网络连接中。

  2. SIZE 10240000: 这表明服务器允许的最大邮件大小是 10,240,000 字节(约 10 MB)。客户端在发送邮件之前应该检查邮件大小,以确保它不会超过这个限制。

  3. VRFY: 这个命令允许客户端验证一个邮箱地址是否存在于服务器上。服务器在响应时会告诉客户端该邮箱是否有效。

  4. ETRN: "ETRN" 是 "Extended Turn" 的缩写。这个命令被用于请求一个 SMTP 服务器启动一个过程来发送其队列中的邮件到请求方。这主要用于那些只能间歇性连接到互联网的系统。通过使用 ETRN 命令,这样的系统可以告知它们现在已连接并准备好接收队列中的邮件。

  5. ENHANCEDSTATUSCODES: 这意味着服务器在其响应中提供更详细的状态代码。这些增强的状态代码提供比传统的三位 SMTP 状态代码更具体的错误和状态信息。

  6. 8BITMIME: 这个扩展允许 SMTP 传输 8 位数据,而不是传统的 7 位。这对于发送非 ASCII 字符(例如,带有特殊字符或国际字符的邮件)很有用。

  7. DSN: 交付状态通知(DSN),Delivery Status Notification。这是一种机制,允许邮件发送者请求关于他们发送的邮件的交付状态报告。这些报告可以提供信息,比如邮件是否成功到达接收者的邮箱,或者如果邮件无法投递,失败的原因。

  8. SMTPUTF8: 这表明服务器支持使用 UTF-8 编码的邮件地址和消息内容。这是一个相对较新的扩展,允许更广泛的字符集用于国际化支持。

这些命令能干嘛?

了解这些 SMTP 命令后,你可以执行以下操作:

  1. 使用 PIPELINING 提高效率: 你可以一次发送多个命令而无需等待每个命令的响应。这对于提高发送大量邮件的效率特别有用,尤其在网络延迟较高的情况下。

  2. 通过 SIZE 控制邮件大小: 在发送大型邮件之前,你可以确保邮件大小不超过服务器的接收限制。这可以避免因邮件过大而被拒绝的问题。

  3. 利用 VRFY 验证邮件地址: 在发送邮件之前,你可以检查邮箱地址的有效性。这有助于减少发送到无效地址的邮件数量。

  4. 使用 ETRN 在需要时请求邮件传输: 对于拥有间歇性连接的服务器(如备份邮件服务器),你可以请求主服务器在连接恢复时发送积压的邮件。

  5. 通过 ENHANCEDSTATUSCODES 获取详细错误信息: 如果邮件发送失败,你可以获得更详细的错误代码,帮助诊断问题。

  6. 使用 8BITMIME 发送多语言邮件: 你可以发送包含非标准ASCII字符的邮件,如使用特殊字符或不同语言的邮件。

  7. 利用 DSN 跟踪邮件状态: 你可以请求关于邮件是否已送达、被拒绝或延迟的通知,以了解邮件的交付状态。

  8. 使用 SMTPUTF8 发送国际化邮件: 你可以发送包含 UTF-8 字符的邮件,这对于国际通信特别重要,因为它支持多种语言和字符集。

举例及详解二

=== Trying 10.10.110.74:25...
=== Connected to 10.10.110.74.
<- 220 redteamnotes ESMTP Postfix (Ubuntu)
-> EHLO redteamnotes.0.100.168.192.in-addr.arpa
<- 250-redteamnotes
<- 250-PIPELINING
<- 250-SIZE 10240000
<- 250-VRFY
<- 250-ETRN
<- 250-ENHANCEDSTATUSCODES
<- 250-8BITMIME
<- 250-DSN
<- 250 SMTPUTF8
-> MAIL FROM:<redpen@redteamnotes.com>
<- 250 2.1.0 Ok
-> RCPT TO:<admin@redteamnotes.com>
<- 250 2.1.5 Ok
-> DATA
<- 354 End data with <CR><LF>.<CR><LF>
-> Date: Mon, 11 Dec 2023 02:48:18 -0500
-> To: admin@redteamnotes.com
-> From: redpen@redteamnotes.com
-> Subject: Cred Update, Pay Attention More
-> Message-Id: <20231211024818.1951097@redteamnotes.0.100.168.192.in-addr.arpa>
-> X-Mailer: swaks v20201014.0 jetmore.org/john/code/swaks/
->
-> goto http://redpen.redteamnotes.com
->
->
-> .
<- 250 2.0.0 Ok: queued as ECBCE2413D8
-> QUIT 
<- 221 2.0.0 Bye 
=== Connection closed with remote host.

逐行解释一下,-> 和 <- 符号表示通信的方向:-> 表示客户端(发送电子邮件的一方)发送的命令或信息。<- 表示服务器(负责传递电子邮件的一方)的响应或信息。

方向

内容

说明

详细解释

客户端尝试连接

Trying 10.10.110.74:25...

尝试连接到服务器的25 端口

SMTP标准端口

连接成功

Connected to 10.10.110.74.

成功建立连接

-

220 redteamnotes ESMTP Postfix (Ubuntu)

服务器准备就绪

220 表示服务就绪

EHLO redteamnotes.0.100.168.192.in-addr.arpa

客户端发送EHLO 命令

EHLO 命令用于向服务器识别自身,并请求服务器列出它支持的命令和功能

250-redteamnotes...

服务器支持的功能列表

250 表示操作成功,后续信息列出服务器支持的扩展功能

MAIL FROM:redpen@redteamnotes.com

指定发件人地址

MAIL FROM 命令用来开始一个邮件事务,并设置发件人的邮箱地址

250 2.1.0 Ok

服务器确认发件人地址

250 表示命令成功执行。2.1.0 表示与发件人地址相关的成功响应

RCPT TO:admin@redteamnotes.com

指定收件人地址

RCPT TO 命令用来指定每个邮件的接收者

250 2.1.5 Ok

服务器确认收件人地址

250 表示成功, 2.1.5 是特定于收件人地址的成功响应

DATA

开始传输邮件内容

DATA 命令表示开始传输邮件主体内容

354 End data with .

服务器准备接收数据

354 表示服务器已准备好接收邮件内容,以特定格式结束

邮件内容(包括日期、收件人等)

发送具体的邮件内容

邮件内容,包括日期、收件人、发件人、主题等

250 2.0.0 Ok: queued as B5F752415A8

邮件被接收并排队等待发送

250 2.0.0 表示邮件内容接收成功, queued as 后面的是邮件在服务器队列中的ID

QUIT

请求结束会话

QUIT 命令用于结束SMTP会话

221 2.0.0 Bye

确认会话结束

221 表示服务器响应结束会话的请求

连接关闭

Connection closed with remote host.

会话结束,连接关闭

-

SMTP协议中定义了一系列的状态代码,用于在电子邮件传输过程中指示不同的状态和错误。这些代码是由国际互联网标准化组织定义的,特别是在RFC 5321标准中有详细描述。RFC(Request for Comments)文档是由互联网工程任务组(IETF)发布的,用于记录和规范互联网相关的各种协议和标准。

以下是SMTP协议中一些常见的状态代码及其含义:

成功响应

  • 211 - 系统状态,或系统帮助回复

  • 214 - 帮助消息

  • 220 - 服务就绪

  • 221 - 服务关闭传输信道

  • 250 - 请求的邮件操作完成

  • 251 - 用户不在本地,但会尝试转发到收件人

请求进一步操作的响应

  • 354 - 开始邮件输入,以 . 结束

暂时性失败

  • 421 - 服务不可用,关闭传输信道

  • 450 - 请求的邮件操作未完成,邮箱不可用(例如,邮箱忙)

  • 451 - 放弃请求的操作;处理过程中出错

  • 452 - 系统存储不足,请求的操作未执行

永久性失败

  • 500 - 语法错误,服务器无法理解命令

  • 501 - 参数语法错误

  • 502 - 命令未实现

  • 503 - 错误的命令序列

  • 504 - 命令参数未实现

  • 550 - 请求的操作未执行,邮箱不可用(例如,邮箱未找到,不可访问)

  • 551 - 用户非本地,请尝试

  • 552 - 过程中存储分配超出限制

  • 553 - 邮箱名不合法

  • 554 - 事务失败

类别

  • 2 表示成功

  • 4 表示暂时错误

  • 5 表示永久错误

主题

  • 0 通常用于语法或系统状态问题

  • 1 指与地址相关的问题

  • 2 与邮箱操作相关

  • 3 与消息相关

  • 4 与网络和路由相关

  • 5 与协议状态相关

  • 6 消息内容或媒体状态

  • 7 与安全相关或策略问题

常见的扩展状态码

  • 2.1.0 - 发件人地址成功接受

  • 2.1.5 - 收件人地址成功接受

  • 4.4.1 - 无法连接到收件人邮件服务器

  • 5.1.1 - 收件人邮箱地址无效

  • 5.7.1 - 发送者未被授权,消息拒绝

每个代码都具体描述了邮件传输过程中遇到的不同情况,使得邮件服务器能够更准确地诊断和响应各种情况。

在与SMTP服务器交互时,有一系列标准命令用于执行不同的操作。每个命令都有其特定的语法和用途。以下是一些常用的SMTP命令及其语法:

命令

语法

用途

HELO

HELO <域名>

开始与SMTP服务器的对话(旧版协议)。

EHLO

EHLO <域名>

开始与SMTP服务器的对话,请求服务器声明支持的功能。

MAIL FROM

MAIL FROM:<发件人地址>

开始一个邮件事务,指定发件人地址。

RCPT TO

RCPT TO:<收件人地址>

指定邮件的接收者,可多次使用指定多个收件人。

DATA

DATA

开始传输邮件内容,以单独一行的 . 结束。

QUIT

QUIT

结束SMTP会话。

RSET

RSET

重置当前的邮件事务。

VRFY

VRFY <邮箱地址>

验证指定的邮箱地址是否存在。

EXPN

EXPN <邮件列表名称>

展开邮件列表,显示所有成员的邮箱地址。

NOOP

NOOP

无操作,通常用于保持或测试连接的状态。

STARTTLS

STARTTLS

启动加密通信。

SPF及绕过

SPF机制

SPF(Sender Policy Framework,发件人策略框架)是一种用于验证电子邮件的发件人身份的电子邮件认证方法。它的主要目的是帮助防止电子邮件地址伪造,这是垃圾邮件、钓鱼攻击和其他形式的网络诈骗常用的手段。SPF允许域名的所有者定义哪些邮件服务器被授权发送代表他们的域名的电子邮件。SPF的机制和原理是:

  1. DNS记录:域名所有者在他们的DNS(域名系统)记录中创建一个SPF记录。这个SPF记录包含了一系列的IP地址,这些IP地址代表了被授权发送该域名电子邮件的邮件服务器。

  2. 电子邮件发送:当一封电子邮件从某个邮件服务器发送时,接收服务器(收件人使用的邮件服务器)会检查这封邮件的发件人域名。

  3. 查找和验证SPF记录:接收服务器查询发件人域名在DNS中的SPF记录。然后,它比较发件邮件服务器的IP地址与SPF记录中列出的IP地址。

  4. 验证结果:如果邮件服务器的IP地址在SPF记录中,这意味着它被授权为该域名发送邮件。这种情况下,邮件被认为是合法的,并且可能会被正常投递。如果IP地址不在SPF记录中,邮件可能会被标记为可疑或被直接拒绝,因为它似乎是未经授权的或伪造的。

为什么仅SPF是不够安全的?

尽管SPF是自20世纪90年代末以来一直存在的经过验证的电子邮件验证层,但它确实存在挑战。简单来说,电子邮件的转发在互联网上是常见的,而SPF机制无法在转发过程中存活。转发通常发生在你发送电子邮件给 redpen@redteam.cn,而邮件地址所有者已将他的电子邮件设置为转发到另一个地址,比如 redpen@redteamnotes.com。SPF通常与DKIM(DomainKeys Identified Mail)和DMARC(Domain-based Message Authentication, Reporting and Conformance)等技术结合使用,以提供更全面的电子邮件安全性解决方案。

DKIM和DMARC是如何规避掉SPF的不足的,提高了哪些方面的安全性?

DKIM(DomainKeys Identified Mail)和DMARC(Domain-based Message Authentication, Reporting, and Conformance)是两种电子邮件认证技术,它们与SPF(Sender Policy Framework)一起,以提供更全面的电子邮件安全和防伪造解决方案。每种技术都解决了电子邮件认证的特定方面,并且在某些方面弥补了SPF的不足。

DKIM

DKIM允许发送方通过数字签名证明邮件内容和附件的完整性,这些签名与发送方的域名关联。它的工作原理是:

  1. 签名:发送服务器对邮件(包括头部和正文)进行数字签名。这个签名是基于一个私钥生成的,而这个私钥只有发送域知道。

  2. DNS记录:与私钥相对应的公钥被发布在发送域的DNS记录中。

  3. 验证:接收服务器使用DNS中的公钥来验证邮件上的签名。如果签名有效,这表明邮件自离开发送服务器以来未被篡改。

DKIM的优势在于它确保了电子邮件内容的完整性和真实性,这是SPF所无法做到的。它对电子邮件转发过程也具有更好的容忍性,因为即便邮件路径改变,签名仍然有效。

DMARC

DMARC是一种基于策略的邮件验证方法,它利用SPF和DKIM作为其验证机制的基础。DMARC的主要功能是:

  1. 策略发布:域名所有者在其DNS记录中发布DMARC记录,其中定义了他们希望接收服务器如何处理不符合SPF或DKIM的邮件。

  2. 验证和执行:接收服务器进行SPF和DKIM验证,然后根据DMARC记录中定义的策略(如拒绝、隔离或允许邮件)来处理邮件。

  3. 报告:DMARC还提供了反馈机制,允许接收服务器向发送域的管理员发送关于他们邮件的验证结果和处理方式的报告。

DMARC的优势在于它提供了一种方法,使域名所有者可以指定如何处理不符合SPF和DKIM的邮件,从而减少了滥用他们的域名发送垃圾或垃圾邮件的情况。此外,它的反馈机制对于域名所有者监控和改进他们的电子邮件安全策略非常有用。

整体来说,即SPF验证发件人服务器的身份,但不涉及邮件内容。DKIM确保邮件在传输过程中未被篡改,验证了内容的完整性。DMARC结合了SPF和DKIM的检查结果,提供了一种处理未通过验证邮件的机制,同时确保了邮件"From"地址的真实性。通过这种方式,三者共同构建了一个更加全面和有效的电子邮件身份验证系统,减少了垃圾邮件和钓鱼攻击的可能性。

通过如上三种机制,我们知道了邮件安全的边界。也知道SPF的腾挪空间。下面进一步看怎么操作。

如何探测SPF

用nslookup的实际例子


┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt qq.com 1.1.1.1 
Server: 1.1.1.1
Address: 1.1.1.1#53 
Non-authoritative answer: 
qq.com text = "v=spf1 include:spf.mail.qq.com -all" 
Authoritative answers can be found from:

上面是指定用1.1.1.1,这一cloudflare的dns服务器查询qq.com域的txt类型记录。结果解读:

  1. v=spf1 :是一个 SPF 记录,并且是 SPF 协议的第一版。

  2. include:spf.mail.qq.com :表示 qq.com 域接受从 spf.mail.qq.com 域指定的邮件服务器发送的邮件。实际上,这是一个引用其他域的 SPF 记录的方法,这意味着 qq.com 将其邮件发送策略部分外包给了 spf.mail.qq.com 。

  3. -all :是一个策略声明,意味着只有在 SPF 记录中明确列出的邮件服务器(或在 include 指令中引用的那些)被允许发送代表 qq.com 的邮件。任何其他服务器都不被认为是合法的发送源。 -all 指的是一个硬性拒绝,表示如果邮件不是来自列出的服务器,它应该被拒收。

进一步追踪到spf.mail.qq.com ,如下:

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt spf.mail.qq.com 1.1.1.1 
Server: 1.1.1.1 
Address: 1.1.1.1#53 

Non-authoritative answer: 
spf.mail.qq.com text = "v=spf1 include:qq-a.mail.qq.com include:qq-b.mail.qq.com include:qq-c.mail.qq.com include:biz-a.mail.qq.com include:biz-b.mail.qq.com include:biz-c.mail.qq.com include:biz-d.mail.qq.com -all" 

Authoritative answers can be found from:
  1. include 条目指定了其他域的 SPF 记录应被包括在 spf.mail.qq.com 的 SPF 检查中。在这里,有几个域被包括进来:

    • qq-a.mail.qq.com

    • qq-b.mail.qq.com

    • qq-c.mail.qq.com

    • biz-a.mail.qq.com

    • biz-b.mail.qq.com

    • biz-c.mail.qq.com

    • biz-d.mail.qq.com

这意味着 spf.mail.qq.com 将这些域指定的邮件服务器视为合法的发送源。
2. -all 依然是一个硬性拒绝策略,表示除了在 SPF 记录中明确列出的服务器外,其他任何服务器发送的邮件都应被视为非授权的。这有助于防止垃圾邮件和邮件伪造。

继续追踪,就是明确具体ip段了。

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt qq-a.mail.qq.com 1.1.1.1 
Server: 1.1.1.1 
Address: 1.1.1.1#53 

Non-authoritative answer: 
qq-a.mail.qq.com text = "v=spf1 ip4:101.226.139.0/25 ip4:101.91.43.0/25 ip4:101.91.44.128/25 ip4:112.64.237.128/25 ip4:116.128.173.0/25 ip4:121.51.40.128/25 ip4:121.51.6.0/25 ip4:162.62.52.214 ip4:162.62.55.67 ip4:162.62.57.0/24 ip4:162.62.58.211 ip4:162.62.58.216 -all" Authoritative answers can be found from:

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt qq-b.mail.qq.com 1.1.1.1      
Server: 1.1.1.1
Address: 1.1.1.1#53 
 
Non-authoritative answer: 
qq-b.mail.qq.com text = "v=spf1 ip4:162.62.58.69 ip4:162.62.63.194 ip4:180.163.24.128/25 ip4:183.2.187.0/25 ip4:203.205.221.128/25 ip4:203.205.251.0/25 ip4:210.51.43.0/25 ip4:58.246.222.128/25 ip4:58.250.143.128/25 ip4:61.241.55.128/25 -all"

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt qq-c.mail.qq.com 1.1.1.1 
Server: 1.1.1.1 
Address: 1.1.1.1#53 

Non-authoritative answer: 
qq-c.mail.qq.com text = "v=spf1 ip4:113.108.92.0/25 ip4:121.14.77.0/25 ip4:81.69.217.16/28 ip4:54.164.151.162 -all" 

Authoritative answers can be found from:

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt biz-a.mail.qq.com 1.1.1.1 
Server: 1.1.1.1 
Address: 1.1.1.1#53 

Non-authoritative answer: biz-a.mail.qq.com text = "v=spf1 ip4:114.132.122.39 ip4:114.132.123.192 ip4:114.132.124.171 ip4:114.132.125.233 ip4:114.132.197.227 ip4:114.132.224.180 ip4:114.132.233.22 ip4:114.132.58.0/24 ip4:43.155.65.254 ip4:114.132.62.0/24 ip4:106.55.200.77 -all" 

Authoritative answers can be found from:

再看一个163的:

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt 163.com 1.1.1.1 
Server: 1.1.1.1 
Address: 1.1.1.1#53 

Non-authoritative answer: 
163.com text = "google-site-verification=hRXfNWRtd9HKlhZBOuUgGrxBJh526R8Uygp0jEZ9wY" 
163.com text = "0hz8zn8jpkr3vffgll8hnd6j873bzvsg" 
163.com text = "57c23e6c1ed24f219803362dadf8dea3" 
163.com text = "v=spf1 include:spf.mail.163.com -all" 
163.com text = "facebook-domain-verification=kqgnezlldheaauy9huiesb3j2emhh3 " 
163.com text = "qdx50vkxg6qpn3n1k6n1tg2syg5wp96y" 

Authoritative answers can be found from:

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt spf.mail.163.com 1.1.1.1 
Server: 1.1.1.1 
Address: 1.1.1.1#53 

Non-authoritative answer: 
spf.mail.163.com   text = "v=spf1 include:spf-a.mail.163.com include:spf-b.mail.163.com include:spf-c.mail.163.com include:spf-d.mail.163.com include:spf-e.mail.163.com -all"

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt spf-a.mail.163.com 1.1.1.1 
Server: 1.1.1.1 
Address: 1.1.1.1#53 

Non-authoritative answer: 
spf-a.mail.163.com     text = "v=spf1 ip4:220.181.12.0/22 ip4:220.181.31.0/24 ip4:123.125.50.0/24 
ip4:220.181.72.0/24 ip4:123.58.177.0/24 ip4:123.58.178.0/24 ip4:123.126.96.0/24 
ip4:123.126.97.0/24 ip4:103.129.252.0/25 ip4:60.191.83.0/24 ip4:103.136.33.32/28 -all" 

Authoritative answers can be found from:

再看gmail的:

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt gmail.com 1.1.1.1 
Server: 1.1.1.1 
Address: 1.1.1.1#53 

Non-authoritative answer: 
gmail.com text = "v=spf1 redirect=_spf.google.com" 
gmail.com text = "globalsign-smimedv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8=" 

Authoritative answers can be found from:

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt google.com 1.1.1.1 
;; Truncated, retrying in TCP mode. 
Server: 1.1.1.1 
Address: 1.1.1.1#53 

Non-authoritative answer: 
google.com text = "MS=E4A68B9AB2BB9670BCE15412F62916164C0B20BB" 
google.com text = "onetrust-domain-verification=de01ed21f2fa4d8781cbc3ffb89cf4ef" 
google.com text = "google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ" 
google.com text = "globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8=" google.com text = "v=spf1 include:_spf.google.com ~all" 
google.com text = "webexdomainverification.8YX6G=6e6922db-e3e6-4a36-904e-a805c28087fa" 
google.com text = "apple-domain-verification=30afIBcvSuDV2PLX" google.com text = "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95" google.com text = "atlassian-domain-verification=5YjTmWmjI92ewqkx2oXmBaD60Td9zWon9r6eakvHX6B77zzkFQto8PQ9QsKnbf4I" 
google.com text = "google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o" 
google.com text = "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e" 
google.com text = "docusign=1b0a6754-49b1-4db5-8540-d2c12664b289" 

Authoritative answers can be found from:

不同的是 ~all 这个策略声明。与 -all 的硬性拒绝不同,~all 表示一个"软性拒绝"。这意味着如果邮件不是来自列出的服务器,它不应该被默认认为合法,但这种情况下的拒绝不像 -all 那样严格。实际上,这通常意味着不符合条件的邮件可能被标记为可疑或进行额外检查,而不是直接被拒收。

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs] 
└─$ nslookup -type=txt aliyun.com 1.1.1.1 
Server: 1.1.1.1 
Address: 1.1.1.1#53 

Non-authoritative answer: 
aliyun.com text = "_globalsign-domain-verification=4iyx4b5rRwLg7FV5zcOHBVsJ81M9U37IAtXJMHRqu4" 
aliyun.com text = "v=spf1 ip4:115.124.30.0/24 ip4:121.0.18.0/23 ip4:121.0.30.0/24 ip4:42.120.70.0/23 ip4:47.88.44.32/27 ip4:59.82.0.0/23 ip4:47.90.199.0/24 -all" 
aliyun.com text = "google-site-verification=zEkDfQfI5fc3VhAFyUCbLxv2vCyoo4wJjiLgfV-UG8k" 
aliyun.com text = "kqpmfrf0schjrfhv52j66tgl1dn2pb01" 

Authoritative answers can be found from:

aliyun直接给出ip段。

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt lenovo.com 1.1.1.1
;; Truncated, retrying in TCP mode.
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
lenovo.com text = "_globalsign-domain-verification=4qaYYFkDr3zY8xFnX817RHQdbwKtr7S6GWVF9HLJ3P"
lenovo.com text = "google-site-verification=nGgukcp60rCgFxMOJw1NHH0B4VnSchRrlfWV-He_tE"
lenovo.com text = "qctqpsq058s3t12m0rjf2jxw8jnvn0zr"
lenovo.com text = "google-site-verification=sHIlSlj0U6UnCDkfHp1AolWgVEvDjWvc0TR4KaysD2c"
lenovo.com text = "_dnsauth=4hlzyrmrk0hdkk4c96qw745ll5h58x35"
lenovo.com text = "Dynatrace-site-verification=9bffa29b-0dbd-4e8f-8c8c-b28fca3b1bdf__49s5b44hnes32j605089h3f60a"
lenovo.com text = "duo_sso_verification=2eFmztpfk73LXpFC92aOkVdh4qWYBJ169vmf2WqC2omGJBXPVugwvp3gTFjX8cr2"
lenovo.com text = "v=spf1 include:spf-00823401.pphosted.com include:spf-00823402.pphosted.com include:_netblocks.eloqua.com include:spf.protection.outlook.com include:spf.pfpool.lenovo.com ip4:72.32.45.225 ip4:40.65.201.146 " "ip4:138.108.60.125 ip4:138.108.24.107 ip4:52.247.21.11 ~all"
lenovo.com text = "63posrsg6o3q95dtuc80da228n"
lenovo.com text = "qh7hdmqm4lzs85p704d6wsybgrpsly0j"
lenovo.com text = "google-site-verification=hxNSoF46anzjUtyFgpRVpzshTkYClFBJ7OAT3Dz6440"
lenovo.com text = "facebook-domain-verification=1r2am7c2bhzrxpqyt0mda0djoquqsi"
lenovo.com text = "duo_sso_verification=sKtyF9pQMvjVPX6vq4nzV00r7qKNkEVAkkb0Tlx1om1ZqroOG1eZEexVxJr0kfAY"
lenovo.com text = "x1n4n7dfpt5hlqlv6vpbtg2czj5bk2y8"
lenovo.com text = "+mW6gkHobmAcjibjfpJSLGKu+Cgfmz8XWkYduBur1wMdL8m2qRi2aBmAnCrHIkdhi08V8zZiyeUATg7W1SVWEQ=="
lenovo.com text = "Visit www.lenovo.com/think for information about Lenovo products and services"
lenovo.com text = "google-site-verification=HESboqU3DntBTT9PbwXRvCBnD3atK7HWgIcv3TJcllw"
lenovo.com text = "MS=ms38130575"
lenovo.com text = "google-site-verification=VxW_e6r_Ka7A518qfX2MmIMHGnkpGbnACsjSxKFCBw0"
lenovo.com text = "a82c74b37aa84e7c8580f0e32f4d795d"
lenovo.com text = "fastly-domain-delegation-Gg2T0SlTwT-2021-03-09"
lenovo.com text = "google-site-verification=247PPmmalrNARHoE2rmOJ3YQygtMquQwLpM_LzVXsFg"
lenovo.com text = "google-site-verification=vyPsFusgDLeWzvnapRyBbiva5dXJ1JIJjcNbGuO52-k"
lenovo.com text = "google-site-verification=KT4YATm6NeQqaD0WLCJtFOjb0gYXhbzUekUM9Rm-fb8"
lenovo.com text = "ece42d7743c84d6889abda7011fe6f53"
lenovo.com text = "4b60110d90a0ba16827618f3165cf720c5458664c9392ea157363087784e0292"
lenovo.com text = "adobe-idp-site-verification=5540c96206f5fe2df921a6c596ea9fb3d7e418d3eddb598c29935cc03163805b"

Authoritative answers can be found from:

联想的配置不是很统一。

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt mi.com 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
mi.com canonical name = sgp.ali.cdn.b2cop.lb.mi.com.
sgp.ali.cdn.b2cop.lb.mi.com text = "7v7jdvg8ndcjmeh3ojk8a8p1qj"

Authoritative answers can be found from:

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt xiaomi.com 1.1.1.1
;; Truncated, retrying in TCP mode.
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
xiaomi.com text = "v=spf1 include:spf_bj.mxmail.xiaomi.com include:spf_hk.mxmail.xiaomi.com -all"
xiaomi.com text = "24hjr0j58f4i57k9j8djph40ep"
xiaomi.com text = "9j4r4oi1c19pncsj42ior6hpdo"
xiaomi.com text = "e0pkdtpmonfeg28uutnd5om6e0"
xiaomi.com text = "jev3402pa7d4ki1f5ouskgdqfq"
xiaomi.com text = "s7ek888cj4hvn9rasglf4je4n2"
xiaomi.com text = "2x7zvq0v08z5ztlrwhttmblx51zfsmb9"
xiaomi.com text = "r1vwn769ljsjlzyc69mjs88dnmmcpt8w"
xiaomi.com text = "skr990tfv7bx6yk6cbhch7nxb5vf5fbx"
xiaomi.com text = "smnljjtzt4scqj8c6s8z5hg700fll4jd"
xiaomi.com text = "google-gws-recovery-domain-verification=42647253"
xiaomi.com text = "google-site-verification=7NF45UOiPcz3QIVa7lwMIln_h3lQzT6E1NPDCUAkB4"
xiaomi.com text = "google-site-verification=j9Z3D0O0oY_wBVt6izA-yUgnNm9e4PUC4GA40iGEINM"

Authoritative answers can be found from:

再看几个其他的例子:

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt proton.me 1.1.1.1
;; Truncated, retrying in TCP mode.
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
proton.me text = "yandex-verification: 95a7888a0f987e6a"
proton.me text = "v=spf1 include:_spf.protonmail.ch ~all"
proton.me text = "protonmail-verification=5262a92f988e64f1be1362138befdf1e19d6a4c1"
proton.me text = "google-site-verification=2FGIDo-GflWE6t_gWd9gpPTehHD85hbNiEujPVgysc"
proton.me text = "google-site-verification=MUjtKY-4uQAjE92Z2-s1nm9m4mvdqY2z6HCvi_Bj4so"
proton.me text = "google-site-verification=QviHfE1VQ57-tDmDLxM6BQH1mdgvdQ_0QsIvCht2IaU"
proton.me text = "google-site-verification=_ayl1WqWIag2WkIbK4sNg_x3NCT5nYOl_DgtFPTYKeg"

Authoritative answers can be found from:
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt redteam.cn 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
*** Can't find redteam.cn: No answer

Authoritative answers can be found from:
redteam.cn
   origin = dns19.hichina.com
   mail addr = hostmaster.hichina.com
   serial = 2023122517
   refresh = 3600
   retry = 1200
   expire = 86400
   minimum = 600
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt huawei.com 1.1.1.1
;; Truncated, retrying in TCP mode.
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
huawei.com text = "N3U/UqKcdI+8rthQEYTbph+m6MCg7+IW43PP5SuPxww="
huawei.com text = "MS=C4F6A693225CC6E058F6C9C39FD728C06C43E597"
huawei.com text = "v=spf1 ip4:45.249.212.32 ip4:45.249.212.35 ip4:45.249.212.255 ip4:45.249.212.187/29 ip4:45.249.212.191 ip4:168.195.93.47 ip4:185.176.79.56 ip4:119.8.179.247 ip4:119.8.89.136/31 ip4:119.8.89.135 ip4:119.8.177.36/31 ip4:119.8.177.38 -all"
huawei.com text = "fz9vxRtJpRFrw8&VLnW9Z4gUPdofN1DwkF516%&L9YXHev2&VuoPYaiKqkD@tf7&eI^Aryg5I8SWU R&MxzvhgCfK3*OjUnT%6&ghuawei20190518"
huawei.com text = "v=DMARC1;p=none;rua=mailto:dmarc@edm.huawei.com"
huawei.com text = "google-site-verification=wqACMoaMtJAtTNspMBb0JCRVzOL4wcawL0B9QAcJPw"

Authoritative answers can be found from:
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt xdf.cn 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
xdf.cn text = "MS=ms83596776"
xdf.cn text = "v=spf1 ip4:82.156.131.39 ip4:112.125.89.35 ip4:211.155.83.128 ip4:211.155.83.129 ip4:211.155.83.130 ip4:211.155.83.131 ip4:106.39.103.128/25 ip4:39.106.37.244 ip4:152.136.120.80 ip4:211.155.83.62 -all"

Authoritative answers can be found from:
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt douyin.com 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
douyin.com text = "_globalsign-domain-verification=fCy8iAkoDxut36WyQPSgBF0R9b_ygKh7t6b-HxD2C2"
douyin.com text = "google-site-verification=1yY-7k04Dn_GCZZ_xw4WIi07ndHiLvkD6KIyyaI6OE"
douyin.com text = "v=spf1 include:_spf.google.com include:mail.zendesk.com include:spf2.bytedance.com include:_netblocks.m.feishu.cn+include:_netblocks.mxem.feishu.cn~all"
douyin.com text = "_globalsign-domain-verification=_kSZf7OMkS5ZPBq5tPyB8ZZk1TB2YnuiksH8BZdpN"
douyin.com text = "verification-code-site-edm-cn=3W5yDeZliWIS2C3sjmew"

Authoritative answers can be found from:
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt cloudflare.com 1.1.1.1
;; Truncated, retrying in TCP mode.
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
cloudflare.com text = "MS=ms70274184"
cloudflare.com text = "ZOOM_verify_7LFBvOO9SIigypFG2xRlMA"
cloudflare.com text = "apple-domain-verification=DNnWJoArJobFJKhJ"
cloudflare.com text = "status-page-domain-verification=r14frwljwbxs"
cloudflare.com text = "docker-verification=c578e21c-34fb-4474-9b90-d55ee4cba10c"
cloudflare.com text = "miro-verification=bdd7dfa0a49adfb43ad6ddfaf797633246c07356"
cloudflare.com text = "facebook-domain-verification=h9mm6zopj6p2po54woa16m5bskm6oo"
cloudflare.com text = "onetrust-domain-verification=bd5cd08a1e9644799fdb98ed7d60c9cb"
cloudflare.com text = "logmein-verification-code=b3433c86-3823-4808-8a7e-58042469f654"
cloudflare.com text = "google-site-verification=C7thfNeXVahkVhniiqTI1iSVnElKR_kBBtnEHkeGDlo"
cloudflare.com text = "google-site-verification=ZdlQZLBBAPkxeFTCM1rpiB_ibtGff_JF5KllNKwDR9I"
cloudflare.com text = "liveramp-site-verification=EhH1MqgwbndTWl1AN64hOTKz7hc1s80yUpchLbgpfY0"
cloudflare.com text = "stripe-verification=5096d01ff2cf194285dd51cae18f24fa9c26dc928cebac3636d462b4c6925623"
cloudflare.com text = "stripe-verification=bf1a94e6b16ace2502a4a7fff574a25c8a45291054960c883c59be39d1788db9"
cloudflare.com text = "drift-domain-verification=f037808a26ae8b25bc13b1f1f2b4c3e0f78c03e67f24cefdd4ec520efa8e719f"
cloudflare.com text = "cisco-ci-domain-verification=27e926884619804ef987ae4aa1c4168f6b152ada84f4c8bfc74eb2bd2912ad72"
cloudflare.com text = "atlassian-domain-verification=WxxKyN9aLnjEsoOjUYI6T0bb5vcqmKzaIkC9Rx2QkNb751G3LL/cus8/ZDOgh8xB"
cloudflare.com text = "v=spf1 ip4:199.15.212.0/22 ip4:173.245.48.0/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all"

Authoritative answers can be found from:
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt markmonitor.com 1.1.1.1
;; Truncated, retrying in TCP mode.
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
markmonitor.com text = "MS=ms64044723"
markmonitor.com text = "onetrust-domain-verification=8fa95c5bed48415db6eff59daea56015"
markmonitor.com text = "v=spf1 include:spf1.markmonitor.com include:spf2.markmonitor.com -all"
markmonitor.com text = "webexdomainverification.5523f43614297acbe053ab06fc0a5471=b0c2366e-7287-438d-af3f-0c171d193a5e"
markmonitor.com text = "0DuNVXCw+Ru0wk/l1QQLpIrBqVp0lV/Sq6AYcat5UGoDXbEm3DJi3zGniT7Yc70rlPXm/L96RJ7ZUSH9MTf/tw=="
markmonitor.com text = "google-site-verification=E2u1YzHLf2tBYBPtKA53nJJU8CxqvETi9tCgrStrHSE"
markmonitor.com text = "MS=ms42144968"

Authoritative answers can be found from:

拓展一点nslookup命令的实务:

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=any cloudflare.com 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53

** server can \'t find cloudflare.com: NOTIMP

对于 type=any 的请求,DNS 服务器(1.1.1.1)返回了 "NOTIMP"(Not Implemented)错误。

这意味着该服务器不支持或不愿处理 type=any 查询。

这种情况在现代的 DNS 服务器中越来越常见,

因为 type=any 查询被认为可能用于 DNS 放大攻击,

并且通常不是正常的 DNS 查询行为。

但是可以写个脚本依次查询

#!/bin/bash
DOMAIN=$1
DNS=$2
for type in A AAAA MX NS TXT SOA CNAME; do
  echo "查询 $type 记录:"
  dig $DOMAIN $type @$DNS +short
  echo ""
done

bash dns.sh markmonitor.com 1.1.1.1

┌──(root㉿kali)-[~/Desktop/APTLabs]
└─# bash dns.sh markmonitor.com 1.1.1.1
查询 A 记录:
104.18.39.152
172.64.148.104

查询 AAAA 记录:

查询 MX 记录:
0 markmonitor-com.mail.eo.outlook.com.

查询 NS 记录:
ns2.markmonitor.com.
ha2.markmonitor.zone.
ns5.markmonitor.com.
ha4.markmonitor.zone.
ns1.markmonitor.com.
ns6.markmonitor.com.
ns3.markmonitor.com.
ns4.markmonitor.com.
ns7.markmonitor.com.

查询 TXT 记录:
"MS=ms42144968"
"MS=ms64044723"
"logmein-verification-code=ANmgyb4yoduCdzD71JRmCSyp2"
"knowbe4-site-verification=2196cd8a72de50eedd7703120b752b77"
"onetrust-domain-verification=8fa95c5bed48415db6eff59daea56015"
"google-site-verification=E2u1YzHLf2tBYBPtKA53nJJU8CxqvETi9tCgrStrHSE"
"google-site-verification=GZUp3F-aoKxu2bX09NyuMPTi-LXAC-qID0GhrRmddog"
"v=spf1 include:spf1.markmonitor.com include:spf2.markmonitor.com -all"
"0DuNVXCw+Ru0wk/l1QQLpIrBqVp0lV/Sq6AYcat5UGoDXbEm3DJi3zGniT7Yc70rlPXm/L96RJ7ZUSH9MTf/tw=="
"webexdomainverification.5523f43614297acbe053ab06fc0a5471=b0c2366e-7287-438d-af3f-0c171d193a5e"

查询 SOA 记录:
ns1.markmonitor.com. hostmaster.markmonitor.com. 2025022802 10800 3600 604800 10800

查询 CNAME 记录:

在线查询SPF工具

https://dmarcian.com/spf-survey/

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=soa redteam.cn 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
redteam.cn
    origin = dns19.hichina.com
    mail addr = hostmaster.hichina.com
    serial = 2024010913
    refresh = 3600
    retry = 1200
    expire = 86400
    minimum = 600

Authoritative answers can be found from:

SOA

SOA(Start of Authority,起始授权)记录是一个关键的 DNS(域名系统)记录,它包含了关于特定 DNS 区域的重要信息。DNS 区域指的是由特定 DNS 服务器管理的一个域名或一组域名。以 nslookup -type=soa redteam.cn 查询结果为例,SOA 记录提供了如下信息:

  • 主 DNS 服务器:例子中是 dns19.hichina.com 。这是管理 redteam.cn DNS 区域的主要服务器,被视为该区域信息的权威源。

  • 责任人的联系方式:格式为 hostmaster.hichina.com 。这是一个电子邮件地址,用于联系管理该 DNS 区域的个人或团队。在 DNS 记录中,传统的邮件地址中的 @ 符号通常会被点( . )替换,这是由于 DNS 记录的语法限制,避免与域名混淆。

  • 序列号:例如 2024010913 ,是一个版本号,用来标识区域文件的更新。每次区域文件更新时,此数字递增,以帮助在多个 DNS 服务器间同步数据。

  • 刷新时间:例如 3600 秒,指辅助 DNS 服务器在尝试从主 DNS 服务器获取区域信息更新前等待的时间间隔。

  • 重试时间:例如 1200 秒,是辅助 DNS 服务器在初始同步尝试失败后,再次尝试之前的等待时间。

  • 过期时间:例如 86400 秒,如果在这个时间内辅助 DNS 服务器仍无法从主服务器获取更新,它将停止响应该区域的查询,以防止提供过时或不准确的信息。

  • 最小 TTL(生存时间):例如 600 秒,定义了其他 DNS 服务器或系统缓存区域中记录的最短时间。

SOA 记录对于 DNS 的管理和运作至关重要,它们确保 DNS 信息的准确性和一致性,并协调 DNS 服务器间信息的同步和更新。通过设置这些参数,DNS 管理员可以有效控制信息的流通和更新频率,确保域名解析的稳定性和可靠性。

在 DNS 记录中使用点( . )替换电子邮件地址中的 @ 符号看似可能导致混淆,因为点是用来分隔域名的部分。实际上,这种替换是出于 DNS 记录的语法和历史原因。

  1. DNS 记录的语法限制:DNS 记录中通常只允许使用一定范围内的字符,主要是字母、数字和某些符号(如点)。DNS 记录的格式和解析规则设计得比较简单和严格,主要是为了确保在解析过程中的一致性和准确性。在这种格式中,@ 符号具有特殊的含义,它通常用于表示 DNS 记录中的当前域名。例如,在 BIND(广泛使用的 DNS 服务器软件)的区域文件中,@ 用于表示区域的根域名。

  2. 避免解析冲突:由于 @ 在 DNS 记录中的特殊用途,如果在记录中使用 @ 来表示电子邮件地址,可能会造成解析上的混淆或冲突。例如,DNS 解析器可能无法正确区分电子邮件地址和域名中的 @ 符号。

  3. 历史惯例:将 @ 替换为点( . )是一个历史上形成的惯例。这种替换在技术上是可行的,因为点在电子邮件地址中通常不会出现(除了在域名部分),而且 DNS 系统中已经广泛用点来分隔域名的不同部分。

因此,虽然看起来这种替换可能导致混淆,但在实践中,由于 DNS 系统的工作方式和历史发展,这种方法已被广泛接受和使用。

如下有邮件相关解析,却没有spf记录的情况。

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=mx linshi-email.com 114.114.114.114
Server: 114.114.114.114
Address: 114.114.114.114#53

Non-authoritative answer:
linshi-email.com mail exchanger = 10 _dc-mx.b7406c49095a.linshi-email.com.

Authoritative answers can be found from:
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ nslookup -type=txt linshi-email.com 114.114.114.114
Server: 114.114.114.114
Address: 114.114.114.114#53

Non-authoritative answer:
*** Can't find linshi-email.com: No answer

Authoritative answers can be found from:
linshi-email.com
    origin = jose.ns.cloudflare.com
     mail addr = dns.cloudflare.com
     serial = 2328868472
     refresh = 10000
     retry = 2400
     expire = 604800
     minimum = 1800

用dig查询spf的例子

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ dig -t txt qq.com @1.1.1.1

; <<>> DiG 9.19.19-1-Debian <<>> -t txt qq.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47040
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;qq.com.                        IN      TXT

;; ANSWER SECTION:
qq.com.                 7200    IN      TXT     "v=spf1 include:spf.mail.qq.com -all"

;; Query time: 464 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon Jan 22 07:56:08 EST 2024
;; MSG SIZE  rcvd: 83

@1.1.1.1 明确指定了查询应该通过地址为 1.1.1.1 的 DNS 服务器进行。

用host查询spf等信息的例子

┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ host -t txt 163.com
163.com descriptive text "v=spf1 include:spf.mail.163.com -all"
163.com descriptive text "qdx50vkxg6qpn3n1k6n1tg2syg5wp96y"
163.com descriptive text "57c23e6c1ed24f219803362dadf8dea3"
163.com descriptive text "google-site-verification=hRXfNWRtd9HKlhZBOuUgGrxBJh526R8Uygp0jEZ9wY"
163.com descriptive text "facebook-domain-verification=kqgnezlldheaauy9huiesb3j2emhh3 "
163.com descriptive text "0hz8zn8jpkr3vffgll8hnd6j873bzvsg"
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ host -t soa 163.com
163.com has SOA record ns4.nease.net. admin.nease.net. 20249501 7200 1800 1209600 60
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ host -t a 163.com
163.com has address 198.18.5.20
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ host -t mx 163.com
163.com mail is handled by 10 163mx01.mxmail.netease.com.
163.com mail is handled by 50 163mx00.mxmail.netease.com.
163.com mail is handled by 10 163mx03.mxmail.netease.com.
163.com mail is handled by 10 163mx02.mxmail.netease.com.
┌──(kali㉿RedteamNotes)-[~/Musics/APTLabs]
└─$ host -t txt gmail.com 114.114.114.114
Using domain server:
Name: 114.114.114.114
Address: 114.114.114.114#53
Aliases: 

gmail.com descriptive text "v=spf1 redirect=_spf.google.com"
gmail.com descriptive text "globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="

其他spf探测工具

还有很多工具能够加速spf的查询。比如:https://dmarcian.com/spf-survey/?domain=gmail.com

再比如:https://easydmarc.com/tools/spf-lookup?domain=qq.com

spf授权总结

"v=spf1 +all"  接受所有邮件(几乎不使用,因为这会使SPF失去意义)
"v=spf1 -all"  失败,拒绝不匹配的邮件(最严格)
"v=spf1 ~all"  软失败,标记不匹配的邮件但可能接受(较常用)
"v=spf1 ?all"  中立,不做任何建议

"v=spf1 ip4:192.168.10.14/16 -all"(只允许 192.168.0.1/16 范围内的IP发送邮件) 
"v=spf1 mx -all"(允许当前域名的 mx 记录对应的IP地址发送邮件) 
"v=spf1 mx mx:test.redteamnotes.com -all"(允许当前域名和 test.redteamnotes.com 的 mx 记录对应的IP地址发送邮件) 
"v=spf1 a mx ip4:174.214.78.188 -all"(允许当前域名的 a 记录和 mx 记录和一个给定的IP地址发送邮件) 
"v=spf1 include:spf.redteamnotes.com -all"(采用和 spf.redteamnotes.com 一样的SPF记录)

周六实际操作内容

周六结合靶机环境进一步讲解spf绕过和利用smtp邮件服务器发送邮件,设计swaks等的使用。

0

评论区