dtsakmakis/dtsakmakis-greek-smishing-phishing-case-study

# 希腊 Smishing / 钓鱼攻击活动分析     ## 目录 - [TL;DR](#tldr) - [免责声明](#disclaimer) - [范围与意图](#scope-and-intent) - [执行摘要](#executive-summary) - [活动概览](#campaign-overview) - [基础设施观察](#infrastructure-observations) - [初始诱饵](#initial-lure) - [示例 Smishing 消息（已脱敏）](#example-smishing-message-redacted) - [钓鱼工作流](#phishing-workflow) - [攻击流程概览](#attack-flow-overview) - [视觉证据（已脱敏）](#visual-evidence-redacted) - [技术分析](#technical-analysis) - [关键发现及其重要性](#key-findings-and-why-they-matter) - [观察到的 TTPs](#observed-ttps) - [ATT&CK 映射](#attck-mapping) - [风险评估](#risk-assessment) - [检测机会](#detection-opportunities) - [狩猎思路](#hunting-ideas) - [防御经验总结](#defensive-lessons-learned) - [局限性](#limitations) - [关键要点](#key-takeaways) - [结论](#conclusion) ## TL;DR - 冒充希腊公共当局的 Smishing 攻击活动（交通罚款场景） - 多阶段钓鱼流程：车辆查询 → 违规 → PII 收集 → 支付 - 使用低额支付以降低怀疑并增加转化率 - 受害者数据（PII + 卡片详情）似乎通过基于 WebSocket 的机制传输 - 观察到的卡片拒绝行为暗示可能存在针对发卡行的过滤 - 即使取消卡片，收集的个人数据仍可能导致后续诈骗 ## 免责声明 本仓库包含一份针对冒充希腊公共当局的钓鱼攻击活动的**已脱敏防御性分析**。其目的是记录面向受害者的攻击流程，强调技术观察，并提取与意识教育、检测和事件响应相关的防御经验。 文中不包含任何有助于复用、复制或滥用底层钓鱼基础设施的操作细节。实时基础设施细节、敏感端点和特定受害者的数据已被有意省略、泛化或脱敏。 ## 范围与意图 本报告侧重于**面向受害者的钓鱼工作流**和攻击活动的**可观察客户端行为**。它**不是**一份完整的事件响应报告、恶意软件逆向工程报告或服务器端取证调查。 该分析基于： - 与钓鱼工作流的直接交互 - 钓鱼页面的浏览器端检查 - 受害者旅程的手动重构 - 通过拦截代理进行的流量检查 - 对观察到的行为的防御性解读 由于调查是从受害者端进行的，某些结论必然是**分析性评估**，而非服务器端确认的事实。 ## 执行摘要 本案例研究记录了对通过冒充公共当局针对希腊用户的 Smishing 传播钓鱼攻击活动的分析。该诱饵使用了虚假交通罚款支付场景，旨在制造紧迫感，同时将请求金额保持在足够低的水平以减少怀疑。 钓鱼流程按顺序收集了多类受害者数据，包括车辆相关信息、联系方式、个人身份信息 (PII) 和支付卡数据。分析期间一个值得注意的技术观察是，受害者提交的数据似乎通过**基于 WebSocket 的机制**传输，而不是通过传统的表单提交流程。 本报告的目的不是复现钓鱼工具包，而是记录社会工程学流程、可观察的技术行为、对受害者的相关风险，以及与分析师和防御者相关的防御性结论。 ## 活动概览 从宏观层面看，该攻击活动遵循了一种熟悉且有效的模式： 1. 通过 SMS 投递简短诱饵 2. 冒充受信任的公共部门实体 3. 引入一个可信的行政问题 4. 请求低额支付以减少犹豫 5. 分阶段收集个人信息 6. 索取支付卡数据 7. 似乎验证或选择性拒绝提交的卡片信息 这种结构表明该钓鱼工作流针对**转化效率**、**数据质量**和**快速变现**进行了优化。 ## 基础设施观察 对钓鱼域名的基本检查揭示了通常与机会主义钓鱼基础设施相关的特征： - 使用非政府 TLD (.vip) - 域名命名模式模仿公共当局（AADE + 年份） - 注册特征与机会主义钓鱼基础设施一致 - 托管特征与官方公共服务不一致 这些特征在启用 Smishing 的钓鱼攻击活动中很常见，即使没有更深入的基础设施分析，也可以作为有用的**检测和意识信号**。 ## 初始诱饵 该攻击活动通过包含冒充希腊公共当局网站链接的 Smishing 风格消息进行投递。此案例中使用的前置借口是交通违规和相关的低额支付请求。 此诱饵之所以有效，是因为它同时结合了几个强有力的社会工程学要素： - 冒充受信任的机构 - 合理的行政背景 - 隐含的紧迫感 - 由于支付金额小而产生的低阻力决策 较低的要求金额特别有效，因为它减少了怀疑，并鼓励受害者将交互视为例行行政任务，而不是潜在的欺诈交易。 从防御者的角度来看，此诱饵符合现代移动优先钓鱼攻击活动中常见的模式：简短的消息、受信任的公共部门主题，以及旨在让受害者从好奇迅速转向服从的落地页。 ## 示例 Smishing 消息（已脱敏） 该攻击活动通过 SMS 投递，使用了以下消息格式： 发件人（已脱敏）：+212******** ### 观察结果 - 当局冒充（交通罚款背景） - 时间压力（“逾期超过 10 天未付”） - 暗示法律后果 - 直接支付链接 - 备用交互方式（“回复 YES”） - 国际发件人号码与官方通信不符 ### 为什么这很重要 这是一种**高转化率 Smishing 模式**，结合了紧迫感、权威性和低阻力。 ### 额外见解 国际发件人号码与本地化诱饵的结合，可能表明投递方法已针对本地化 Smishing 攻击活动进行了调整。 ## 诱饵为何有效 此攻击活动结合了少数几种众所周知的社会工程技术，以减少阻力并增加服从性： - **权威冒充**：主题模仿受信任的公共机构 - **行政合理性**：罚款和运输相关费用是熟悉且可信的 - **低额支付**：金额感觉是例行公事而非令人担忧 - **隐性紧迫感**：背景鼓励快速行动，没有明显的压力 - **逐步披露**：引导受害者逐步输入更敏感的信息 单独来看，这些要素很常见。结合起来，它们创造了一个低阻力流程，在保持感知合法性的同时鼓励完成操作。 ## 分析方法论 该分析是作为**防御性案例研究**进行的，重点是可观察的受害者端行为，而不是攻击性基础设施探索。 ### 1. 视觉与流程检查 手动审查了钓鱼页面以了解： - 冒充主题 - 表单序列 - 从诱饵到支付请求的进展 - 每个阶段收集的信息类别 这使得工作流可以被映射为一个结构化的、多步骤的数据收集序列。 ### 2. 流量检查 使用拦截代理检查流量，以比较： - 可见的页面转换 - 表单提交行为 - 用户交互触发的网络请求 - 任何非传统的浏览器到服务器通信模式 这是导致观察到站点行为不像简单的传统 HTTP 表单提交序列的关键步骤。 ### 3. 行为关联 将用户操作与网络活动相关联，以确定： - 数据输入事件何时伴随可观察到的流量 - 页面是否触发了可见的基于 POST 的提交 - 提交的数据是否似乎通过另一个渠道移动 这有助于确立数据流可能涉及基于 WebSocket 的机制。 ### 4. 防御性解读 然后从防御者的角度解释观察到的工件： - 正在收集什么数据 - 操作者的可能目标是什么 - 这对受害者风险意味着什么 - 哪种检测或意识措施可能有用 ## 使用的工具 以下工具和方法与分析相关： - 基于浏览器的手动检查 - 逐页受害者流程审查 - 用于拦截代理和流量检查的 Burp Suite - 通过代理工具观察 WebSocket 流量 - 基本域名和基础设施健全性检查 - 用于防御性报告的手动脱敏和文档记录 ## 示例安全调查工作流 以下步骤说明了一种**防御性、受害者端方法**，用于分析类似的钓鱼页面，而无需与后端基础设施交互： ### 1. 视觉流程映射 - 按顺序审查每个页面 - 识别步骤之间的转换（查询 → 违规 → PII → 支付） - 记录每个阶段请求的数据 ### 2. 浏览器端检查 - 使用开发者工具观察页面结构和脚本 - 识别动态元素和客户端验证行为 ### 3. 流量检查 - 使用拦截代理监控： - 初始页面加载请求 - 用户触发的操作 - 任何 WebSocket 连接 - 将可见的 UI 步骤与底层网络活动进行比较 ### 4. 基本域名背景检查 ``` whois redacted-domain.example dig redacted-domain.example ``` 这些步骤旨在支持**分析和理解**，而不是与恶意基础设施交互或复制它。 ## 钓鱼工作流 ### 步骤 1 - 初始数据收集 受害者流程的第一阶段请求与所谓违规相关的基本信息，包括车辆相关标识符和电话号码。这似乎旨在增加场景的可信度，同时也允许操作者在流程早期收集受害者元数据。 从社会工程学的角度来看，这是有效的，因为它营造了一种印象，即站点正在检索或验证合法的案件记录。 ### 步骤 2 - 虚假违规 / 支付背景 在初始表单提交后，受害者会看到一个虚假的违规摘要和支付请求。请求的金额很低，这与旨在减少犹豫并鼓励立即采取行动的常见钓鱼和 Smishing 策略一致。 此步骤充当初始参与和主动服从之间的心理桥梁。当受害者看到支付请求时，交互感觉已经是程序性的了。 ### 步骤 3 - 个人信息收集 在支付阶段之前，钓鱼流程请求了额外的个人身份信息，包括受害者的姓名、地址、城市、电子邮件地址和电话号码。在这个阶段，攻击活动已经超越了简单的诱饵验证，进入了结构化的个人数据收集。 这表明该攻击活动旨在保留价值，即使受害者在提交卡片之前放弃了流程。 ### 步骤 4 - 支付卡收集 最后阶段请求支付卡信息，包括持卡人姓名、卡号、有效期和 CVV。这证实了钓鱼工作流不仅旨在收集个人数据，还旨在获取可变现的支付卡信息，用于尝试欺诈或转售。 ### 步骤 5 - 卡片响应行为 卡片提交后，工作流并没有简单终止。相反，观察到的行为包括一条拒绝式消息，指出提交的卡片应替换为不同发卡行的卡片。 这是一个重要的行为细节，因为它表明该工具包可能不是被动地收集任何提交的卡片。相反，它可能结合了基于发卡行特征、BIN 相关行为或操作者偏好的过滤逻辑。 ## 攻击流程概览 下图从受害者角度总结了观察到的钓鱼工作流和数据收集阶段： ``` [Smishing Message] ↓ [Phishing Domain: 2026aade[.]vip] ↓ [Initial Input] (vehicle ID + phone) ↓ [Fake Violation] (low-value payment) ↓ [PII Collection] (name, address, email, phone) ↓ [Payment Collection] (card details) ↓ [Card Filtering Logic] (issuer-aware behavior observed) ↓ [Data Transmission] (WebSocket-based data transmission) ``` ## 视觉证据（已脱敏） 以下屏幕截图从受害者角度说明了观察到的钓鱼工作流。图像已脱敏，以删除任何敏感或个人身份信息。 ### 步骤 1 - 初始输入页面  落地页请求车辆标识符和电话号码，营造出与官方记录相关的合法查询流程的印象。 ### 步骤 2 - 虚假违规摘要  向受害者展示伪造的违规摘要和低额支付请求。 此步骤在通过小额支付将阻力降至最低的同时，强化了合法性。 ### 步骤 3 - 个人信息收集  在支付之前，工作流收集额外的个人身份信息 (PII)，包括姓名、地址和联系方式。 这表明该攻击活动旨在保留价值，即使受害者未进入支付阶段。 ### 步骤 4 - 支付页面和卡片处理行为  最后阶段收集完整的支付卡详情。 观察到的行为包括拒绝 Revolut 卡，并消息指示受害者改用不同的银行卡，表明潜在的发卡行感知过滤逻辑。 ## 整个流程中收集的数据 钓鱼工作流似乎收集了以下类别的信息： - 车辆相关标识符 - 电话号码 - 全名 - 地址和城市相关详情 - 电子邮件地址 - 支付持卡人姓名 - 支付卡号 - 有效期 - CVV 这种多阶段设计增加了攻击者的灵活性。即使提交的卡后来被取消，剩余的个人数据仍可能支持后续诈骗、针对性钓鱼或打包转售。 ## 技术分析 对钓鱼站点的初步检查表明这是一个相对简单的 Web 流程，但更深入的分析揭示了与传统基于表单提交模式不同的行为。 在分析期间，受害者提交的数据在初始页面加载后似乎没有通过可见的 HTTP 表单提交的标准序列传输。相反，观察到的行为表明提交的数据正通过**基于 WebSocket 的通道**传输。这是一个值得注意的实现细节，因为它不同于通常与低投入钓鱼页面相关的更简单的基于 POST 的提交流程。 基于 WebSocket 的数据传输机制可以支持将受害者提交的数据近实时地交付到后端基础设施或操作者界面。从防御角度来看，这是相关的，因为它可能会降低仅在浏览器开发者工具或基本代理跟踪中寻找明显表单提交请求的分析师的可见性。 另一个值得注意的观察是明显拒绝提交的 Revolut 卡，随后的消息指示应使用不同的银行卡。虽然没有直接的服务器端可见性无法确定后端逻辑，但此行为与选择性卡片处理一致，可能基于发卡行或 BIN 相关特征。这种行为可能表明操作者或钓鱼工具包已调整优先级，以接收来自特定发卡行的卡片。 总体而言，站点行为与旨在最大化受害者转化和收集数据下游价值的钓鱼工作流一致，同时保持相对简单的受害者端体验。 ## 关键发现及其重要性 ### 发现 1 - 多阶段数据收集 钓鱼工作流没有立即请求支付数据。相反，它首先在较早的步骤中收集了背景和个人信息。 **重要性：** 这增加了受害者服从的机会，并确保即使受害者在支付前放弃流程，操作者仍能获得有用的个人信息。 ### 发现 2 - 低额支付借口 请求的支付金额足够小，感觉在行政上是合理的，而不是在财务上令人担忧。 **重要性：** 这是一种经典的转化策略。小额收费通常引发较少的谨慎，更有可能被视为例行公事。 ### 发现 3 - 基于 WebSocket 的数据传输 观察到的流量在初始页面加载后不像是一系列简单的表单 POST 提交。用户提交的数据似乎与 WebSocket 活动相关联。 **重要性：** 这在分析上很重要，因为它可能会降低仅检查传统请求流的防御者的可见性。它也暗示了更具交互性的后端或操作者工作流。 ### 发现 4 - 明显的卡片过滤行为 提交的 Revolut 卡未被接受，页面指示应使用不同发卡行的卡片。 **重要性：** 这表明攻击活动可能是选择性的，而非无差别的。发卡行感知行为可能表明工具包自定义或下游欺诈偏好。 ### 发现 5 - 结合 PII 和支付数据收集 该攻击活动收集了身份相关信息和卡片数据。 **重要性：** 这拓宽了操作者的变现选项。即使支付卡欺诈失败，剩余的个人数据对于后续钓鱼、诈骗电话或转售仍保留价值。 ## 观察到的 TTPs 在分析期间观察到以下技术和行为模式： - 通过 SMS 投递钓鱼诱饵，将受害者引导至主题落地页 - 冒充受信任的希腊公共当局 - 使用低额支付借口以减少犹豫 - 顺序、多阶段收集受害者数据，而不是单一的综合表单 - 收集个人身份信息和支付卡数据 - 明显通过基于 WebSocket 传输受害者提交的数据 - 基于提交的卡片类型怀疑存在发卡行或 BIN 感知的卡片过滤行为 综合来看，这些特征与现代针对转化、数据质量和操作者快速访问受害者提交信息进行优化的 Smishing 钓鱼工具包一致。 ## ATT&CK 映射 本案例中观察到的活动可以在高层大致映射到以下 MITRE ATT&CK 概念： - **Phishing (钓鱼)** - 通过旨在将受害者引导至攻击者控制的基础设施的欺骗性消息投递诱饵 - **Masquerading / impersonation themes (伪装/冒充主题)** - 将攻击者控制的内容展示为属于合法的公共当局 - **Information collection (信息收集)** - 从受害者处收集联系方式、身份和支付相关信息 - **Data transmission over web-based channels (通过 Web 通道传输数据)** - 明显通过浏览器发起的 WebSocket 机制传输受害者提交的数据 此映射故意保持高层级，因为分析基于受害者端观察和浏览器流量行为，而不是服务器端或端点取证可见性。 ## 风险评估 钓鱼流程收集了多类敏感信息，包括联系方式、位置相关信息和支付卡数据。即使受损的卡后来被取消，剩余的个人数据仍可能在后续钓鱼、诈骗电话、身份主题社会工程学中被滥用，或作为更广泛受害者数据集的一部分打包转售。 本案中主要的短期风险是支付卡滥用。次要风险包括额外的 Smishing 尝试、针对性钓鱼消息、诈骗电话，以及重复使用收集的个人信息以增加未来欺诈尝试的可信度。 还值得注意的是，一旦受害者与钓鱼工作流交互，他们可能会被威胁行为者归类为响应者或高价值目标，从而增加通过其他渠道进行后续联系的可能性。 ## 可能的后续滥用场景 卡片取消后，剩余的可能滥用场景包括： - 额外的钓鱼 SMS 消息 - 虚假快递或海关支付诱饵 - 虚假银行或安全验证电话 - 使用收集的个人背景进行针对性电子邮件攻击 - 将受害者归类为“响应者”以用于未来诈骗 - 将个人数据打包到更广泛的犯罪数据集中 这就是为什么及时取消卡片很重要，但并不能完全消除下游风险。 ## 响应行动 在识别出钓鱼活动后，立即取消了受损的支付卡。这显著降低了与事件相关的主要财务风险。 针对类似案例，建议的额外响应行动包括： - 监控未经授权或失败的支付尝试 - 审查近期交易是否有可疑活动 - 对后续钓鱼消息或诈骗电话保持警惕 - 通过相关滥用渠道报告钓鱼域名和相关基础设施 - 保留脱敏证据用于意识教育、培训或内部分析目的 ## 实用受害者指南 对于类似攻击活动的受害者，通常建议采取以下行动： 1. 立即取消或替换任何已提交的支付卡 2. 审查近期交易和失败尝试 3. 在可用的情况下启用交易通知 4. 对后续电话、SMS 消息或电子邮件保持怀疑 5. 避免点击通过未经请求的消息收到的未来支付链接 6. 通过适当的提供商或滥用渠道报告钓鱼页面 7. 保留一份关于提交内容及其时间的脱敏记录 ## 分析师评估 从分析师的角度来看，此攻击活动似乎更关注**转化效率**，而非先进的技术复杂性。社会工程学流程简单、熟悉且有效：公共部门主题、可信的行政借口，以及鼓励快速服从的低额支付金额。 最值得注意的技术要素是明显使用基于 WebSocket 的数据传输。虽然本质上并不先进，但这是一个有意义的实现细节，因为它可能会降低那些预期更明显的 HTTP 表单提交序列的防御者的分析可见性。 观察到的卡片拒绝行为也值得注意。虽然在没有后端访问权限的情况下无法确凿归因，但它可能暗示发卡行感知的处理逻辑、工具包自定义，或操作者对更可能在下游欺诈尝试中成功的卡片的偏好。 总体而言，钓鱼流程似乎是结构化的、可重复使用的，并且专为快速收集个人数据和可变现支付信息而构建的。 ## 检测机会 此案例突显了防御者的几个有用的检测和意识机会： - 识别围绕公共服务、罚款、费用或行政行动主题的 SMS 投递诱饵 - 监控新观察到或低声誉的冒充政府或公共服务域名 - 标记使用非政府拥有的命名模式但在视觉上模仿受信任机构的域名 - 检查在多个分阶段步骤中收集受害者信息的落地页 - 查找源自最近访问的低信任域名的可疑浏览器发起的 WebSocket 连接 - 监控同时收集个人身份信息和卡片数据的支付主题钓鱼页面 - 在钓鱼工具包分析期间，将发卡行特定的拒绝消息视为潜在的行为线索 在意识层面上，此案例也强调了需要培训用户仔细验证域名，对通过 SMS 投递的支付请求保持怀疑，并避免将通过未经请求的消息收到的支付数据输入链接。 ## 狩猎思路 防御者和分析师可以从本案例中得出以下狩猎思路： - 搜索使用公共部门命名主题的最近注册或低声誉域名 - 查找涉及通过 SMS 请求的小额行政支付的用户报告 - 审查浏览器或代理遥测数据，寻找与新发现域名相关的可疑 WebSocket 连接 - 识别结合机构品牌与消费者支付收集的页面 - 监控围绕罚款、通行费、交通处罚、海关或包裹费用的诱饵集群 - 在钓鱼页面分析期间将分阶段表单收集视为行为指标 ## 防御经验总结 此案例强化了几个实用教训： - 钓鱼工具包不需要技术先进即可有效 - 小额支付通常是一种深思熟虑的社会工程学决策 - 即使支付卡被取消，个人数据收集对攻击者仍可能具有价值 - 分析师不应假设可见的表单页面总是映射到标准的 HTTP 提交模式 - 浏览器端 WebSocket 活动在钓鱼分析期间值得关注 - 即使仅基于受害者端证据，防御性报告仍可能具有价值 ## 局限性 本分析有几个重要的局限性： - 它基于受害者端交互和客户端可见行为 - 它不包括服务器端日志或后端工件 - 它不包括端点受损遥测数据 - 它不声称确认访问了面向操作者的基础设施 - 一些发现是基于观察到的行为而不是经过验证的后端证据的分析性评估 这些局限性定义了本报告中提出的结论的置信度。 ## 关键要点 此钓鱼案例结合了可信的公共部门借口、低阻力支付场景和多阶段数据收集，以增加受害者服从的可能性。在技术上，观察到的基于 WebSocket 的数据传输提醒我们，钓鱼工具包并不总是依赖明显的表单 POST 请求。 对于防御者来说，主要教训很清楚：社会工程学的简单性通常比技术复杂性更有效，非传统的客户端数据流在分析期间值得关注，即使主要支付工具及时取消，个人数据的残留暴露仍可能促成未来的欺诈尝试。 ## 结论 此案例最好被理解为一份**已脱敏的防御性钓鱼分析**，而不是一份完整的入侵后 DFIR 报告。其价值在于记录现代启用 Smishing 的钓鱼工作流如何向受害者展示、它试图收集什么信息、其浏览器可见行为如何与预期不同，以及防御者可以从该行为中学到什么。 即使没有基础设施细节或服务器端遥测数据，该案例仍作为钓鱼分析、分析师推理和防御性文档记录的实用示例具有价值。 ## 许可证 本项目采用 MIT 许可证授权。

标签：DAST, ESC8, IP 地址批量处理, meg, Object Callbacks, PII窃取, Redacted, Smishing, TTP映射, WebSocket, 依赖分析, 信息安全, 信用卡诈骗, 信用卡验证, 公共服务伪装, 冒充公检法, 基础设施分析, 多步骤钓鱼, 威胁情报, 威胁搜寻, 安全报告, 安全教育, 希腊, 开发者工具, 恶意软件分析, 支付欺诈, 数据传输分析, 案例分析, 检测规则, 流量违规, 狩猎思路, 短信钓鱼, 社会工程学, 网络犯罪, 网络资产发现, 网络钓鱼, 金融欺诈, 钓鱼分析, 防御分析