SToFU Systems · 事件研究 · 2026 年 10 月 20 日
内容
- 它始于开发调查
- 下载并检查文件
- Git 结帐后挂钩如何运行
- Git 挂钩下载器的作用
- 档案中是否隐藏了应用程序？
- 下载服务器返回的内容
- 这可能是一个合法的帮手吗？
- 检查不熟悉的 Git 存储库
- 档案审查后
- 信件和证据文件
它始于开发调查
第一条消息于 2026 年 10 月 15 日通过我们的网站到达。发件人希望帮助建立一个检测金融欺诈的平台。拟议的系统将对交易风险进行评分并使用行为分析，以及区块链验证和报告等其他要求。
10 月 19 日，我们收到了下载链接。随附的电子邮件将我们引导至 conf 架构和分支 NDA 协议的分支。它再次要求审查并签署保密协议。
请您在NDA分支机构审核项目材料并审核并签署NDA。
遵循这些说明将使审阅者从提取存档到切换 Git 中的分支。该电子邮件将这两个操作作为阅读文档的一部分进行了介绍。它没有提到执行下载的程序。
包含项目存档和打开 NDA 分支的说明的电子邮件。识别细节被灰色矩形覆盖。
下载并检查文件
该链接指向标准 Dropbox 文件共享页面。我们下载了 AI-Fraud-Detection_Blockchain.tar.gz 进入隔离的审查环境并保留原始档案以供参考。具体分享网址在此保留。
我们列出了存档内容并直接读取提供的 Git 对象。这使我们可以从所有三个分支恢复文档，而无需签出分支或运行提供的代码。在分支树中，我们发现了 15 个 Markdown 文件和 1 个 Word 文档。
| 分公司 | 文件 | 我们发现了什么 |
|---|---|---|
master |
8 个 Markdown 文件 | 自述文件、项目概述、产品要求和业务用例。其他文件涵盖性能、安全、测试和操作。 |
conf |
7 个 Markdown 文件 | 开发提案、区块链架构和集成、智能合约要求、数据和 API 设计、人工智能风险引擎和交付里程碑的指南。 |
NDA |
1 个 DOCX 文件 | 带有签名块和模板占位符的保密协议。 |
拟议的产品将交易分析、欺诈规则和机器学习分数与区块链验证相结合。它建议的堆栈使用 Node.js 和 TypeScript 以及 Express、PostgreSQL、Python 机器学习库和以太坊。交付文件列出了 24 周内的六个里程碑。我们在提供的树中找到了规划文档，没有应用程序实施、经过训练的模型或智能合约源可供审查。
有些细节值得再看一遍。 API 示例包含文字字符串 <built-in function id> and <built-in function hash> 在端点路径中。 NDA 仍然包含模板占位符。这些不一致之处引发了人们对材料准备得有多仔细的质疑。
可执行文件 .git/hooks/post-checkout 文件是一个更严重的发现。它的评论描述了一个浏览器或扩展更新帮助程序，与审查该项目没有明显的联系。阅读脚本会发现下载外部程序并在后台启动它的说明。电子邮件请求切换分支可能会将审阅者带到该执行路径，同时尝试阅读 NDA。
我们保持存储库处于非活动状态，并以文本形式检查钩子。相关的存档元数据和脚本的行为如下。
Git 结帐后挂钩如何运行
该文件 AI-Fraud-Detection_Blockchain.tar.gz 长度为 779,429 字节。它的 100 个 TAR 条目包括 60 个常规文件。一个完整的 .git 目录随文档一起到达。
hooks 目录包含通常的 .sample 文件和名为的可执行文件 post-checkout.
AI-Fraud-Detection_Blockchain/.git/hooks/post-checkout没有 .sample 后缀。它的TAR模式是 0777，其中包括执行权限，长度为2,774字节。
Git 调用 post-checkout 通过以下操作更新工作树后 checkout or switch，前提是环境允许钩子执行。的 Git 文档 描述了触发器。
为什么存档的 .git 目录很重要
一个正常的 git clone 不复制源存储库的本地客户端挂钩，因为 Pro Git 解释。此次交付包括现有的 .git 存档内的目录，因此本地挂钩随之而来。
挂钩的路径、模式和大小直接从原始 TAR 中读取。我们没有将接收到的目录作为 Git 存储库进行操作。
我们直接检查了容器和 Git 对象，没有运行 checkout or switch 在收到的存储库上。
Git 挂钩下载器的作用
shell 脚本中的注释描述了浏览器或扩展更新帮助程序。我们在项目文档中没有发现对这样一个助手的要求。该脚本是未混淆的纯文本。
未使用的大小阈值
脚本集 THRESHOLD 到 100 并向 Git 请求已更改文件名的列表。它初始化 TRIGGER 为零。
THRESHOLD=100
FILES=$(git diff --name-only "$OLD_HEAD" "$NEW_HEAD")
TRIGGER=0在循环内部，它计算 SIZE。没有可比性 THRESHOLD 并且没有改变的分配 TRIGGER。下载块运行时 TRIGGER 为零。
if [ "$TRIGGER" -eq 0 ]; then沿着该脚本的正常路径，即使更改的文件列表为空，条件也为真。阈值不限制下载。
保留原始行号。 TRIGGER 保持为零。 THRESHOLD 已声明但从未在比较中使用。
单独下载 Linux、macOS 和 Windows
返回的值 uname -s 确定下载路径和本地文件名。
| 检测到的系统 | 服务器路径 | 本地文件名 |
|---|---|---|
| Linux | /api/l |
run-command.sh |
| 达尔文 / macOS | /api/m |
run-command.sh |
| MINGW、MSYS、CYGWIN、Windows_NT | /api/w |
run-command.cmd |
| 系统无法识别 | /api/l |
run-command.sh |
这些 URL 共享一台主机，此处替换为 <DOWNLOAD_DOMAIN>。我们私下保留了未编辑的钩子。这些分支涵盖 Linux、macOS 和 Windows，并针对无法识别的系统提供 Linux 后备。我们没有测试这些系统上的执行情况。
下载文件并尝试运行它
该钩子将文件保存在 ${TMPDIR:-/tmp} using curl, 或 wget if curl 不可用。在以下执行指令之前没有签名或预期哈希检查。
chmod +x "$CMD_FILE"
"$CMD_FILE" > /dev/null 2>&1 &最后的 & 符号在后台启动该命令。标准输出和标准错误都转到 /dev/null.
尝试执行后，钩子会写入 azuku into .git-checker 在临时目录中。它在再次下载之前从不检查该标记。它也不等待后台进程成功后再写入文件。因此，在执行尝试失败后，该标记可能仍然存在。
原始下载、chmod、后台执行和标记写入指令。此摘录中没有第二阶段的计划。
接近末尾的评论说要删除临时下载目录。下面没有删除命令。
档案中是否隐藏了应用程序？
网络下载又提出了另一个问题。档案中是否已经有一个应用程序，也许在 Git 历史记录或 NDA 中？我们检查了容器边界，然后解码了每个提供的 Git 对象并检查了 DOCX 内容。
档案边界
在检查其内容之前，我们记录了原始存档的 SHA-256。
6f44ff4e461828dd1fe6ede75ca8d9d4b579c2ac223463629e9a7537b9df5040将 gzip 解压缩为数据会生成 890,880 字节的 TAR 流。 gzip 流干净地结束，后面没有未使用的字节。最后一个 TAR 条目之后的最后 5,120 字节是零填充。
然后我们检查了这些容器条目所占的文件和对象。
已保存 gzip 流结束和 TAR 填充检查。未执行示例中的任何代码。
找到 TAR 头中的钩子
的 post-checkout 条目的标题开始于 0xCF600, 或 849,408，在解压的 TAR 中。其文件数据开始于 849,920。这些偏移量指的是 TAR 流，而不是压缩的 .gz 文件。
在该偏移处，标头以路径开始 post-checkout.
TAR / 十六进制转储
000cf600 41 49 2d 46 72 61 75 64 2d 44 65 74 65 63 74 69 |AI-Fraud-Detecti|
000cf610 6f 6e 5f 42 6c 6f 63 6b 63 68 61 69 6e 2f 2e 67 |on_Blockchain/.g|
000cf620 69 74 2f 68 6f 6f 6b 73 2f 70 6f 73 74 2d 63 68 |it/hooks/post-ch|
000cf630 65 63 6b 6f 75 74 00 00 00 00 00 00 00 00 00 00 |eckout..........|
000cf640 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000cf650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000cf660 00 00 00 00 30 30 30 30 37 37 37 00 30 30 30 31 |....0000777.0001|
000cf670 37 35 30 00 30 30 30 31 37 35 30 00 30 30 30 30 |750.0001750.0000|
000cf680 30 30 30 35 33 32 36 00 31 35 32 35 32 30 30 34 |0005326.15252004|
000cf690 33 30 37 00 30 32 34 30 37 35 00 20 30 00 00 00 |307.024075. 0...|
000cf6a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|在 TAR 标头中， mode 占用字节数 [100:108] and size occupies [124:136]。该条目的解码字段位于转储之后。
| TAR字段 | 原始字节/值 |
|---|---|
| mode | b'0000777\x00' |
| size | b'00000005326\x00' |
| 八进制模式 | 0777 |
| 小数位数 | 2774 字节 |
| 存储/计算校验和 | 10301 / 10301 |
八进制大小解码为 2,774 字节。存储的标头校验和是 10,301。使用填充空格的校验和字段重新计算它会得到相同的结果。
挂钩的原始 TAR 标头和解码字段。它的名称、权限和大小在容器字节中可见。
我们还对从此条目中提取的钩子进行了哈希处理。
854b3b88b06fad9d9ffec36b35be0133b1d502084d4d7cce232eda2b2dd03092的 TAR 条目转储 and 匿名挂钩 包含在文章中。上面的散列标识了私人持有的未编辑的原件，而不是经过编辑的出版物副本。
无需读取 Git 对象 checkout
有 24 个松散物体 in .git/objects，每个都存储在 zlib 流中。解压后的数据包含一个 Git 标头，后跟对象主体。
<type> <size>\0<body>我们检查了声明的主体长度并在整个解码序列（包括标头和 NUL 字节）上计算了 SHA-1。结果必须与文件名中的对象 ID 匹配。这会检查对象的完整性。它没有说明谁创建了它。
对于每个对象，我们将声明的长度与主体长度进行比较，并验证完整解码数据的哈希值。
expanded = zlib.decompress(compressed_object)
header, body = expanded.split(b"\0", 1)
kind, declared_size = header.decode("ascii").split()
assert len(body) == int(declared_size)
assert hashlib.sha1(expanded).hexdigest() == object_id我们也检查了 zlib 流结尾。对象解析为 16 个 blob、5 个树和 3 个提交。在三个分支头之后，它们的父提交和子树占所有 24 个对象。提供的对象中不存在无法访问的 blob。
Git/提交关系
master 4bc26f6c18910ca777c8238d2f88f6e725fcdc3f
tree feb0feaf7b8e826b085e90dea5399772d7b91f02
parent (none)
conf 239b9aa2edc8c5e21fddeea5ed0e937496ae013f
tree 048b51f9673f94354251ce16a78e663c71667a4c
parent 4bc26f6c18910ca777c8238d2f88f6e725fcdc3f
NDA a1311875d86bf6f1a6b9f2fee6527abbd1ce647d
tree cc020d922090835ea4ac3a3e418d0213d7a2ad94
parent 239b9aa2edc8c5e21fddeea5ed0e937496ae013f的 完整的对象清单 包括当前工作树之外的对象。
所有 24 个 Git 对象的清单
| 对象ID | 类型 | 正文，字节 |
|---|---|---|
| 08e2cda2f440c1792c7c35a3499bfd1ade3e9bad | blob | 6497 |
| 22bb86aacf377c17c7ad0d52c5cefeeb93dfa13e | blob | 5123 |
| 2a7091bdd006a2f98a8c795fd7d2a04c8ee53056 | blob | 2610 |
| 39e13459086f36bc7c933d4e7b5d249a22db24bd | blob | 3061 |
| 3f50e45c67dee5aac77147a5418afe551e8871be | blob | 2433 |
| 476dc872c6def747dcdac549b67a8dc80948b7e1 | blob | 3191 |
| 5a51550933b593eb65da458bbdd579f85c082dab | blob | 752100 |
| 5e53fd0880963e1767ad23fb8612b76e31f04003 | blob | 2807 |
| 60a7cbff83445488fd34b12de1814dc56c956963 | blob | 2054 |
| 74d479352822f5cc1d03552f517cfb5b2d7aa6d3 | blob | 2281 |
| 84e694473554c8a7c01f038a1b6ef8d9355405f7 | blob | 2033 |
| bb7b5d8bc28c4a6257f7d87a685c61ba16a3789c | blob | 2425 |
| d83c8e0c416766be34276013944f5b94726e8c8f | blob | 2776 |
| dfd0f171bca257780eb0d9e22ba2eda1db9d4b68 | blob | 8402 |
| e3b57e48010fc25fd12e7f5f25e952aca843e537 | blob | 6316 |
| ed325750862eb6cdc92b216258a00a784312d793 | blob | 3062 |
| 239b9aa2edc8c5e21fddeea5ed0e937496ae013f | commit | 213 |
| 4bc26f6c18910ca777c8238d2f88f6e725fcdc3f | commit | 165 |
| a1311875d86bf6f1a6b9f2fee6527abbd1ce647d | commit | 212 |
| 048b51f9673f94354251ce16a78e663c71667a4c | tree | 438 |
| 2cb70db8d9317603cb5f0fee0029b66581a7162e | tree | 104 |
| 61874365e5498a30c8b61ef63bbb1d28b4cf4e22 | tree | 320 |
| cc020d922090835ea4ac3a3e418d0213d7a2ad94 | tree | 57 |
| feb0feaf7b8e826b085e90dea5399772d7b91f02 | tree | 104 |
通过每个对象的原始 Git 编码验证长度和 SHA-1。 24 项检查全部通过。
遵循从树到字节的保密协议
的 NDA 分支指向包含一个文件的树， Non-Disclosure-Agreement.docx。 Git 树条目将模式和文件名存储为文本，后跟 NUL 和 Blob ID 的 20 个原始字节。我们直接从树体解析条目。
Git 树/十六进制转储
00000000 31 30 30 36 34 34 20 4e 6f 6e 2d 44 69 73 63 6c |100644 Non-Discl|
00000010 6f 73 75 72 65 2d 41 67 72 65 65 6d 65 6e 74 2e |osure-Agreement.|
00000020 64 6f 63 78 00 5a 51 55 09 33 b5 93 eb 65 da 45 |docx.ZQU.3...e.E|
00000030 8b bd d5 79 f8 5c 08 2d ab |...y.\.-.|
原始 NDA 树字节和对其 DOCX blob 的解码引用。
该条目引用以下 blob。
5a51550933b593eb65da458bbdd579f85c082dabzlib解压后，对象以 blob 752100\0。紧接着标题之后的是字节 50 4b 03 04, 的 PK ZIP 容器的签名。
Git blob / zlib 之后
00000000 62 6c 6f 62 20 37 35 32 31 30 30 00 50 4b 03 04 |blob 752100.PK..|
00000010 0a 00 00 00 00 00 87 4e e2 40 00 00 00 00 00 00 |.......N.@......|
00000020 00 00 00 00 00 00 09 00 00 00 64 6f 63 50 72 6f |..........docPro|
00000030 70 73 2f 50 4b 03 04 14 00 00 00 08 00 87 4e e2 |ps/PK.........N.|
00000040 40 a5 76 12 16 69 01 00 00 7b 02 00 00 10 00 00 |@.v..i...{......|
00000050 00 64 6f 63 50 72 6f 70 73 2f 61 70 70 2e 78 6d |.docProps/app.xm|
00000060 6c 9d 92 c1 4e c3 30 10 44 ef 48 fc 43 94 7b 62 |l...N.0.D.H.C.{b|
压缩的对象字节、解码的 Git 标头和 DOCX 的开头。根据完整对象检查长度和对象 ID。
身体是 752,100 字节 长的。它的 SHA-256 与我们单独保存用于分析的 DOCX 相匹配。
9d85170d2c0aa7a9b90dfc3855715a31d971bba7abb563e9efa1153fdc15634f这些对象说明了从 NDA 分支到文档的字节。
计算所有 16 个 blob
Fifteen blobs decode as UTF-8 Markdown project documents. The remaining blob is the DOCX above. None starts with a PE, ELF or Mach-O header.
| 树上的小路 | 大小，字节 | 类型/第一个字节 |
|---|---|---|
| 04-解决方案提案-指导.md | 2054 | UTF-8 text · 23 20 44 65 76 65 6c 6f 70 6d 65 6e 74 20 43 6f |
| 06-区块链架构.md | 6497 | UTF-8 text · 23 20 42 6c 6f 63 6b 63 68 61 69 6e 20 41 72 63 |
| 07-区块链集成规范.md | 2807 | UTF-8 text · 23 20 42 6c 6f 63 6b 63 68 61 69 6e 20 49 6e 74 |
| 08-智能合约规范.md | 2610 | UTF-8 text · 23 20 53 6d 61 72 74 20 43 6f 6e 74 72 61 63 74 |
| 09-数据-和-api-architecture.md | 2776 | UTF-8 text · 23 20 44 61 74 61 20 26 20 41 50 49 20 41 72 63 |
| 11-AI-fraud-and-risk-engine.md | 3062 | UTF-8 text · 23 20 41 49 20 46 72 61 75 64 20 44 65 74 65 63 |
| 14-可交付成果-接受-和-里程碑.md | 6316 | UTF-8 text · 23 20 44 65 6c 69 76 65 72 61 62 6c 65 73 2c 20 |
| 详细/03-business-and-use-cases.md | 3061 | UTF-8 text · 23 20 42 75 73 69 6e 65 73 73 20 52 65 71 75 69 |
| 详细/05-非功能性需求.md | 2033 | UTF-8 text · 23 20 4e 6f 6e 2d 46 75 6e 63 74 69 6f 6e 61 6c |
| 详细/10-安全和隐私-requirements.md | 2433 | UTF-8 text · 23 20 53 65 63 75 72 69 74 79 20 26 20 50 72 69 |
| 详细/12-测试和质量-requirements.md | 2425 | UTF-8 text · 23 20 54 65 73 74 69 6e 67 20 26 20 51 75 61 6c |
| 详细/13-deployment-monitoring-and-operations.md | 2281 | UTF-8 text · 23 20 44 65 70 6c 6f 79 6d 65 6e 74 2c 20 4d 6f |
| 简介/01-project-overview.md | 8402 | UTF-8 text · 23 20 50 72 6f 6a 65 63 74 20 4f 76 65 72 76 69 |
| 简介/02-产品要求.md | 3191 | UTF-8 text · 23 20 50 72 6f 64 75 63 74 20 52 65 71 75 69 72 |
| 保密协议.docx | 752100 | DOCX/ZIP·50 4b 03 04 0a 00 00 00 00 00 87 4e e2 40 00 00 |
| 自述文件.md | 5123 | UTF-8 text · 23 20 41 49 20 46 72 61 75 64 20 44 65 74 65 63 |
所有 16 个提供的 blob 均已分类。这些树包含项目文档，但未找到产品实施。
我们阅读正文并检查他们的签名。 DOCX 是唯一的非文本 blob，需要单独的容器检查。
将 DOCX 打开为 ZIP
该文件包含 25 个 ZIP 条目，由17个文件部分和8个目录组成。我们读取每个文件部分并检查其 CRC。
| DOCX部分 | 大小，字节 | CRC32 |
|---|---|---|
| [内容类型].xml | 1482 | ec936159 |
| _rels/.rels | 737 | 1f222201 |
| customXml/_rels/item1.xml.rels | 296 | 7a393f74 |
| 自定义Xml/item1.xml | 400 | 4ed0e3fe |
| customXml/itemProps1.xml | 327 | 457b4363 |
| docProps/app.xml | 635 | 161276a5 |
| docProps/core.xml | 595 | d5626da7 |
| docProps/custom.xml | 722 | 8d44908d |
| 字/_rels/document.xml.rels | 1086 | 22475620 |
| 字/_rels/settings.xml.rels | 398 | e5802c0c |
| 字/文档.xml | 91835 | 4df71596 |
| 字/fontTable.xml | 4234 | 2796cccd |
| word/media/image1.png | 712863 | 09063019 |
| word/media/image2.png | 10193 | 3aea21cf |
| 字/设置.xml | 4116 | 34faa9ef |
| 字/样式.xml | 30020 | b4e9edbd |
| 字/主题/theme1.xml | 6329 | ed5975e1 |
DOCX 部分名称、长度和 CRC32 值。我们检查了 ZIP 和 XML 数据，而无需在 Office 中打开文档。
没有 vbaProject.bin 或零件列表中的 OLE 附件。两个 PNG 文件包含一个徽标和一个签名图像。我们还检查了 XML 关系，并在文档作者的计算机上找到了对本地办公室模板路径的引用。我们没有解析或加载它。
签名图像和 Git 作者字段没有给我们提供可靠的方法来识别发件人。两者都可以复制或替换。
我们在提供的内容中没有发现单独的应用程序或产品实现。钩子通过网络获取下一个程序。我们的集装箱检查并不排除所有可能的利用或隐写技术。
下载服务器返回的内容
我们获取了三个确切的 URL 作为数据，而不执行响应或遵循重定向。 10 月 19 日，在 世界标准时间 17:29:27 至 17:29:28，每个返回的HTTP 200。三具尸体都是一样的 21-byte 消息。
Permanently suspended
三个保存的端点观察结果。在准备本文时，我们没有向下载器 URL 发出进一步的请求。
我们没有第二阶段字节可以进行逆向工程。我们也不知道这些端点之前向其他访问者或在不同的请求条件下返回了什么。暂停消息没有为我们提供有关服务暂停原因的经过验证的解释。
该挂钩尝试下载并执行外部文件。关于被盗密码、代币、源代码或钱包的索赔需要我们没有的证据。
这可能是一个合法的帮手吗？
内部更新程序可能会错误地进入存档。 Git 挂钩、后台进程和 curl 都有合法用途。
在这次提交中，电子邮件明确要求我们访问另一家分行。这样做可能会调用提供的下载程序，尽管分支更改的指定原因是阅读协议。该电子邮件没有提及执行。我们还发现浏览器更新程序和建议的系统之间没有任何联系，并且脚本的大小检查不完整。
我们将提交视为尝试的代码交付攻击，并阻止钩子运行。重新考虑该评估将需要下载文件的来源以及承包商为何需要执行这些文件来审查 NDA 的可验证解释。
我们尚未确定运营商的身份。文档内的发件人地址、提交元数据和名称不足以确定归属。
所提供的钩子描述的执行步骤的分析图。
检查不熟悉的 Git 存储库
关注电子邮件的开发人员可以在阅读有关项目的同时到达执行触发器。无需构建或启动提议的应用程序。
如果您使用生产 SSH 密钥或云令牌在计算机上查看客户端提交，则意外脚本可能会访问这些资源。一次性环境需要使这些凭证遥不可及。审查机器上的浏览器会话值得同样的考虑。
审查应包括提供的 .git 工程师开始使用常用命令之前的目录和任何 IDE 自动化。安装脚本也需要仔细检查。在主机日志中，我们会查找 Git 或 shell 将文件下载到临时目录中然后执行它。一个 curl 过程本身告诉我们的信息要少得多。
保留原始电子邮件和存档可以让以后的审阅者检查发送的内容。哈希值和主机事件有助于确定机器上发生的情况。缺失的标记无法确定程序从未运行过。
下载或解压存档可以运行这个钩子吗？
下载和普通提取不会调用Git post-checkout 钩住自己。在此示例中，记录的触发器是 Git 通过以下方式更新工作树 checkout or switch，当允许钩子执行时。我们直接检查提供的对象，而不调用这些操作。
档案审查后
我们预计下一次交流将是关于架构和交付日期的。我们发送了有关该钩子的回复，并保留了材料以供进一步审查。我们仍然无法说出远程程序做了什么或者是谁操作了它。该钩子给了我们足够的理由来停止所请求的 Git 工作流程。
五年多来，SToFU Systems 和我们的解决方案帮助公司保护其系统，包括抵御通过业务信函和开发材料发起的攻击。我们的 安全审计 检查代码和访问权限如何被滥用。我们还提供 逆向工程 当团队需要了解不熟悉的软件时。
如果存储库或二进制文件提出问题， 与我们的团队交谈 在将其放入正常的开发环境之前进行技术审查。
信件和证据文件
下面的四条消息使用占位符来表示个人姓名、地址、第三方身份和识别链接。保留其他新消息措辞。由于每封电子邮件单独出现，因此省略了重复的引用。 Web 表单的服务 IP 和不相关的收件人地址也被保留。
1.通过我们的网站第一次查询
电子邮件/识别详细信息已替换
Date: Thu, 15 Oct 2026 12:55:21 +0000
From: SToFU Site Form <TEAM_EMAIL>
To: <TEAM_EMAIL>
Subject: SToFU Systems - Contact by <SENDER_NAME> <SENDER_EMAIL>
Reply-To: <SENDER_NAME> <SENDER_EMAIL>
Time: 2026-10-15T12:55:21+00:00
IP: [redacted]
Page: /contact
Name: <SENDER_NAME>
Email: <SENDER_EMAIL>
Attachments: none
Message:
We are currently developing an AI-powered FinTech fraud detection platform designed to help financial organizations identify suspicious transactions, assess potential risks in real time, and strengthen their fraud prevention and investigation processes.
The planned platform will incorporate AI/ML-based fraud detection, transaction risk scoring, behavioral analysis, configurable fraud-detection rules, blockchain-based verification, automated alerts, investigation support, and reporting and analytics.
We are looking to connect with an experienced technology partner with expertise in blockchain, financial technology, AI/ML, and scalable web platform development to help us bring this product to life.
We would welcome the opportunity to discuss your team’s capabilities, experience, and potential role in the project. The specific scope of your team’s involvement, technical responsibilities, and collaboration model can be determined through our discussion, based on your expertise and recommendations.
If this opportunity aligns with your team’s capabilities and interests, I’d be happy to share the project overview and technical roadmap for an initial review.
---
通过我们的网站进行第一次查询。保留电子邮件的匿名发布视图。
私有未编辑的 EML SHA-256： bf7d0f3a59b84f509ca436e0750640e844e9731ce363a42a99d5be60cdf8597e
2.我们索取材料的回复
电子邮件/识别详细信息已替换
Date: Sat, 17 Oct 2026 19:46:28 -0000
From: <TEAM_MEMBER_NAME> <TEAM_EMAIL>
To: <SENDER_NAME> <SENDER_EMAIL>
Subject: Re: Your AI fraud detection platform
Cc: [redacted: third-party addresses]
Hi <SENDER_NAME>,
Thank you for getting in touch through our website. I'm <TEAM_MEMBER_NAME>, <TEAM_MEMBER_ROLE> of SToFU Systems (<COMPANY_WEBSITE>). You can find me on <PROFESSIONAL_NETWORK> here:
<PROFILE_URL>
Your fraud detection platform sounds like a great project. Helping financial teams spot suspicious transactions and investigate them more effectively is a worthwhile problem to solve, and we'd be very happy to help you bring it to life.
We'd be glad to help with the architecture, development, security, and ongoing maintenance. We'll do everything we can to get the platform launched and keep it running reliably as it grows.
If you plan to seek investment, we can also help prepare the technical side for those conversations, including a working product or demo, clear architecture and documentation, and a practical development roadmap.
Please send over the project overview and technical roadmap you mentioned. It would be helpful to understand what you've already built and what you'd like to tackle first.
I'd be happy to arrange a call to discuss the project and how we could work together. What day and time would suit you? Please include your time zone so we can find a slot that works for both teams.
Thank you again for reaching out, and have a great day!
Best regards,
<TEAM_MEMBER_NAME>
<TEAM_MEMBER_ROLE>
SToFU Systems
<COMPANY_WEBSITE>
我们的回复要求提供材料。保留电子邮件的匿名发布视图。
私有未编辑的 EML SHA-256： 1e5330dd82e02911254722744a3202e9b761c8c1d2950be937cd5d539c1bcad9
3. 命名 NDA/conf 分支的存档电子邮件
电子邮件/识别详细信息已替换
Date: Mon, 19 Oct 2026 09:03:41 +0000
From: <SENDER_EMAIL>
To: <TEAM_EMAIL>
Subject: Re: Your AI fraud detection platform
Hi <TEAM_MEMBER_NAME>,
Thank you for your interest in our AI-powered FinTech fraud detection platform.
I’ve also reviewed your <PROFESSIONAL_NETWORK> profile, and I’m confident that you and your team can make a valuable contribution to our project.
I’m happy to share the project materials for your review.
We’ve prepared the project overview, technical roadmap, and NDA, which provide the key information needed to understand the project, its objectives, and the proposed technical direction.
The platform focuses on AI-driven fraud detection, transaction risk assessment, behavioral analysis, fraud prevention, blockchain-based verification, automated alerts, investigation support, and financial risk analytics.
This is the Link:
<FILE_SHARE_URL>
Please review the project materials and review and sign the NDA in the NDA branch.
The NDA is required because the project materials contain confidential business, technical, architectural, and product information.
So, please send me the signed NDA as soon as possible.
In particular, we would appreciate your initial technical assessment of the proposed system architecture and timeline. The detailed documentation and specifications related to these areas are available in the conf branch.
After your review, we would like to arrange a meeting to discuss your technical observations, recommendations, questions, development approach, and potential partnership opportunities in more detail.
Once you have completed your review, please let me know your preferred meeting date and time and provide the signed NDA.
Please feel free to take the time you need to review the materials thoroughly. I look forward to receiving your feedback and speaking with you about the project.
Kind regards,
<SENDER_NAME>
命名 NDA / conf 分支的存档电子邮件。保留电子邮件的匿名发布视图。
私有未编辑的 EML SHA-256： f7007ed3053d3ba2ef71ea01c74ec0c4aebfd48417f757ecec8d9d7d5884bf33
4.我们发现hook后的回复
电子邮件/识别详细信息已替换
Date: Mon, 19 Oct 2026 19:37:58 +0200
From: SToFU Systems <TEAM_EMAIL>
To: <SENDER_NAME> <SENDER_EMAIL>
Subject: Re: Your AI fraud detection platform
Hi <SENDER_NAME>,
We reviewed the materials you sent. Unfortunately, we found no application source code or working implementation, only planning documents and an NDA.
Execution of the supplied Git post-checkout hook was disabled during our review. The hook downloads and runs platform-specific files from <DOWNLOAD_DOMAIN>, hides their output, and writes a local marker. Our security policies do not allow the execution of untrusted third-party hooks.
Thank you for your time and for the elaborate attempt to deliver malicious code.
We have traced the technical delivery chain and preserved the archive, hook, download responses, correspondence, and author names and email addresses recorded in the repository. The relevant evidence will be passed to the competent law enforcement authorities in the applicable jurisdictions.
SToFU Systems
我们发现钩子后的回复。保留电子邮件的匿名发布视图。
私有未编辑的 EML SHA-256： 31df91adb2eb52be2171836d3e26610328a0a1a1273dbf7d56efe4354bb62e19
- 匿名挂钩，全部 101 行
- TAR 标头和文件数据的开头
- 所有 24 个 Git 对象
- zlib 之前和之后的 DOCX blob
- NDA 树转储
- 所有 16 个 blob 及其第一个字节
- 所有 DOCX 零件
- Gzip 和 TAR 边界
- 机器可读的字节级检查
- 保存三个端点的观察结果
- 图来源和哈希值
- 通讯出处
完整钩子的匿名视图
保留所有 101 个源行号。识别灰色矩形覆盖的细节。
未经编辑的原件由私人持有。公共证据文件使用占位符，屏幕截图使用不透明的灰色矩形。标记为原始的哈希值标识私人来源，而不是编辑的出版物副本。附图是本地证据视图的屏幕截图，在渲染之前删除了识别文本。没有执行收到的代码。
