Objective-See的研究、工具和写作得到了“Objective-See之友”的支持，例如：
📝 👾 想一起玩吗？
As “Sharing is Caring” I’ve uploaded the malicious binaries Turtle.zip to our public macOS malware collection. The password is: infect3d
由于“共享就是关怀”，我已将恶意二进制文件Turtle.zip上传到我们的公共macOS恶意软件集合中。密码为：infect3d
…不过，请不要感染自己！
Background 背景
A few years ago, @jacse mused that maybe turtles are the secret to avoiding ransomware. And while that may have been true in the past, today it appears that turtles instead may in fact be ransomware harbingers 😂
几年前，@jacse沉思着，也许海龟是避免勒索软件的秘诀。虽然这在过去可能是正确的，但今天看来，海龟实际上可能是勒索软件的预兆 😂
Yesterday (Nov 29th), Austin pinged me about a possible new ransomware specimen that was targeting macOS.
昨天（11 月 29 日 th ），Austin 向我通报了针对 macOS 的可能的新勒索软件样本。
Found sample on VT 91a5faa41d19090e1c5c1016254fd22a – [possible] Mac ransomware. …Couldn’t find much on it so wondering your thoughts if you have time! -Austin
在 VT 91a5faa41d19090e1c5c1016254fd22a 上找到样本 – [可能] Mac 勒索软件。…找不到太多东西，所以如果你有时间，想知道你的想法！-奥斯汀
…thanks Austin! 🙏🏽 …谢谢奥斯汀！🙏🏽
If we pop over to VirusTotal and search for a file with the hash 91a5faa41d19090e1c5c1016254fd22a, we find the sample:
如果我们跳转到 VirusTotal 并搜索带有哈希的文件 91a5faa41d19090e1c5c1016254fd22a ，我们会找到示例：
VirusTotal 上可能的勒索软件
Though uploaded just two days ago, 24 of the anti-virus engine are already flagging it as malicious. This is unusual, as generally new malware takes a while to get picked up by such engines. However, as we can see in the above screenshot, crowdsource YARA rules flag is on Windows APIs. Also the names the AV engines have assigned the malicious binary are rather vague such as “Other:Malware-gen”, “Trojan.Generic”, or “Possible Threat”. Others flag it as Windows malware (“Win32.Troj.Undef”). At first blush, yes kind of strange, but if you keep reading, you’ll see this actually all makes sense!
虽然两天前才上传，但防病毒引擎的 24 个已经将其标记为恶意。这是不寻常的，因为通常新的恶意软件需要一段时间才能被此类引擎捕获。但是，正如我们在上面的屏幕截图中看到的那样，众包 YARA 规则标志位于 Windows API 上。此外，AV 引擎为恶意二进制文件分配的名称也相当模糊，例如“Other：Malware-gen”、“Trojan.Generic”或“可能的威胁”。其他人将其标记为 Windows 恶意软件 （“Win32.Troj.Undef”）。乍一看，是的，有点奇怪，但如果你继续阅读，你会发现这实际上是有道理的！
一个 AV 引擎 Rising 将其检测为“Ransom.Turtle”
…we’ll see shortly this is the internal name of the ransomware.
…我们很快就会看到这是勒索软件的内部名称。
One of the neat features of VirusTotal is the ability to map out relationships. Using this, we find the sample came from a zip file, named “TR.zip”. This was also uploaded to VirusTotal (5 days ago):
VirusTotal 的一个巧妙功能是能够映射关系。使用它，我们发现示例来自一个名为“TR.zip”的 zip 文件。这也已上传到 VirusTotal（5 天前）：
…a lot of times, we see malware first developed for more popular platforms such as Windows, then ported to macOS. Perhaps (also recalling the YARA hit on Windows APIs), this is why there are already so many AV detections even for the macOS variant).
…很多时候，我们看到恶意软件首先为更流行的平台（如 Windows）开发，然后移植到 macOS。也许（也回想一下 YARA 对 Windows API 的打击），这就是为什么即使对于 macOS 变体，也已经有如此多的 AV 检测）。
If we download the archive and unzip it, we find it contains files (prefixed with “TurtleRansom”) that appear to be compiled for common platforms, including, Windows, Linux, and yes, macOS:
如果我们下载存档并解压缩它，我们会发现它包含的文件（以“TurtleRansom”为前缀），这些文件似乎是为常见平台编译的，包括 Windows、Linux 和 macOS：
特定于平台的二进制文件
Using macOS’s file utility, can confirm this:
使用 file macOS的实用程序，可以确认这一点：
% file TR/TurtleRansom-v0-windows-arm64.exe TR/TurtleRansom-v0-windows-arm64.exe: PE32+ executable Aarch64, for MS Windows % file TR/TurtleRansom-v0-macos-arm64.pkg TR/TurtleRansom-v0-macos-arm64.pkg: Mach-O 64-bit executable arm64 % file TR/TurtleRansom-v0-macos-amd64-softfloat.pkg TR/TurtleRansom-v0-macos-amd64-softfloat.pkg: Mach-O 64-bit executable x86_64
Noting that the macOS .pkg files are not packages, but simple Mach-O executables, one compiled for Intel and one for Arm (aka Apple Silicon).
请注意，macOS .pkg 文件不是软件包，而是简单的 Mach-O 可执行文件，一个为 Intel 编译，一个为 Arm（又名 Apple Silicon）编译。
For the remainder of this analysis, we’ll focus on the Arm build (“TurtleRansom-v0-macos-arm64.pkg“).
在本分析的其余部分，我们将重点介绍 Arm 构建 （“ TurtleRansom-v0-macos-arm64.pkg ”）。
Triage 分流
First, let’s see if its signed (and notarized?) using macOS’ codesign utility:
首先，让我们看看它是否使用 macOS codesign 的实用程序进行了签名（并经过公证？
% codesign -dvv TR/TurtleRansom-v0-macos-arm64.pkg TR/TurtleRansom-v0-macos-arm64.pkg Identifier=a.out Format=Mach-O thin (arm64) CodeDirectory v=20400 size=16446 flags=0x20002(adhoc,linker-signed) hashes=511+0 location=embedded Signature=adhoc Info.plist=not bound TeamIdentifier=not set Sealed Resources=none Internal requirements=none
Though it is signed so it can run on macOS, its only signed adhoc (and not notarized). This means Gatekeeper should block it (unless the user explicitly allows it to run, or it is deployed via some exploit).
虽然它已签名，因此可以在 macOS 上运行，但它唯一的签名是临时的（并且未经公证）。这意味着 Gatekeeper 应该阻止它（除非用户明确允许它运行，或者它是通过某些漏洞部署的）。
Next let’s extract any embedded strings (via the aptly named strings utility), as such strings can often give us a sense of capabilities and guide continued analysis efforts.
接下来，让我们提取任何嵌入的字符串（通过恰如其分的 strings 实用程序），因为这些字符串通常可以让我们了解功能并指导持续的分析工作。
% strings - TR/TurtleRansom-v0-macos-arm64.pkg ? Go build ID: "JZS5wyJGq5YWpqV3jo6B/mrrrnHE8O7C4AIP5rWHa/Jwu16Tp63gAWq6z_ByO1/eBbE7TLPTZlqPRrSlUyz" TURTLERANSv0 D:/VirTest/TurmiRansom/main.go ... _main..inittask _main.en0cr0yp0tFile _main.main _main.main.func1 ... .doc .docx .txt ... _crypto.init _crypto/aes.(*KeySizeError).Error _crypto/aes.(*aesCipher).BlockSize _crypto/aes.(*aesCipher).Encrypt _crypto/aes.(*aesCipherAsm).BlockSize _crypto/aes.(*aesCipherAsm).Encrypt _crypto/aes.(*aesCipherGCM).BlockSize _crypto/aes.(*aesCipherGCM).Encrypt _crypto/aes..inittask _crypto/aes.KeySizeError.Error _crypto/aes.NewCipher ... syscall.init syscall.Getwd syscall.Open syscall.read syscall.readdir_r syscall.Rename syscall.Seek syscall.write syscall.execve ...
The binary doesn’t appear to obfuscate any of its strings, hence there are strings a plenty. Some of the ones I’ve included confirm the malware was written in Go, and internally referred to as “TURTLERANS” (aka “Turtle Ransomware”) or “TurmiRansom”. We also see a function named en0cr0yp0tFile and references to target file extensions (e.g. .docx), cryptographic routines and file I/O.
二进制文件似乎不会混淆它的任何字符串，因此有很多字符串。我包含的一些恶意软件证实该恶意软件是用 Go 编写的，内部称为“TURTLERANS”（又名“Turtle Ransomware”）或“TurmiRansom”。我们还看到一个函数的命名 en0cr0yp0tFile 和对目标文件扩展名（例如 .docx ）、加密例程和文件 I/O 的引用。
Though the strings command doesn’t support UTF-8 string, we find (for example in a disassembler that does support such strings), various strings in Chinese also related to ransomware operations, such as “加密文件” which translate to “Encrypt files”.
虽然该 strings 命令不支持 UTF-8 字符串，但我们发现（例如在支持此类字符串的反汇编程序中），各种中文字符串也与勒索软件操作有关，例如“加密文件”，翻译为“加密文件”。
At this point, all signs point to well, yes, ransomware. Let’s now dive in deeper to see how the ransomware goes about encrypting files.
在这一点上，所有迹象都指向，是的，勒索软件。现在让我们更深入地了解勒索软件如何加密文件。
Analysis 分析
In the strings output we saw a method named: main.en0cr0yp0tFile.
在字符串输出中，我们看到了一个名为 main.en0cr0yp0tFile .
When analyzing binaries written in Go, you usually find the interesting logic (written by the malware author, vs just some linked in 3rd-party library) in the main.* routines.
在分析用 Go 编写的二进制文件时，您通常会在 main.* 例程中找到有趣的逻辑（由恶意软件作者编写，而不仅仅是第三方库中链接的一些逻辑）。
Let’s take a look at the disassembly of the en0cr0yp0tFile function …focusing on the library/API calls it makes:
下面我们来看看 en0cr0yp0tFile 功能的拆解…重点关注它进行的库/API 调用：
main.en0cr0yp0tFile:
...
0x0000000100095e04 bl _os.ReadFile
...
0x0000000100095e24 bl _crypto/aes.NewCipher
...
0x0000000100095e5c bl _crypto/cipher.NewCTR
...
0x0000000100095ec4 bl _runtime.concatstring2
...
0x0000000100095ee4 bl _os.rename
...
0x0000000100095f08 bl _os.WriteFile
...
0x0000000100095f18 ret
Pretty easy to see given a file, it reads it into memory, encrypts it with AES (in CTR mode), renames the file, then overwrites the file’s original contents with the encrypted data. Pretty standard ransomware logic.
很容易看到一个文件，它将其读入内存，使用 AES（在 CTR 模式下）对其进行加密，重命名文件，然后用加密数据覆盖文件的原始内容。非常标准的勒索软件逻辑。
The en0cr0yp0tFile function is invoked by the main.func1. This function is called for each file in the malware’s working directory. (File enumerating is done via a call to the path_filepath_Walk function). However, it does not encrypt all files …only those matching the extensions .doc, .docx, or .txt (recall, we saw these as embedded strings):
该 en0cr0yp0tFile 函数由 main.func1 调用。为恶意软件工作目录中的每个文件调用此函数。（文件枚举是通过调用函数 path_filepath_Walk 完成的）。但是，它不会加密所有文件……只有那些与扩展名 、 .docx 或 .txt 匹配 .doc 的字符串（回想一下，我们将这些视为嵌入字符串）：
0x0000000100096761 db 0x2e ; '.'
0x0000000100096762 db 0x74 ; 't'
0x0000000100096763 db 0x78 ; 'x'
0x0000000100096764 db 0x74 ; 't'
...
0x0000000100096128 add x1, x1, #0x761 ; 0x100096761 (".txt")
0x000000010009612c orr x2, xzr, #0x4
0x0000000100096130 bl runtime.memequal
Let’s now hop into a virtual machine and execute the ransomware in a directory containing documents and text files. If we run file monitor at the same time, we can observe the ransomware in action:
现在，让我们跳入虚拟机，在包含文档和文本文件的目录中执行勒索软件。如果我们同时运行文件监视器，我们可以观察到勒索软件的实际情况：
# FileMonitor.app/Contents/MacOS/FileMonitor -pretty -filter TurtleRansom-v0-macos-arm64.pkg
{
"event" : "ES_EVENT_TYPE_NOTIFY_OPEN",
"file" : {
"destination" : "/Users/user/Desktop/TR/file.docx",
"process" : {
"path" : "/Users/user/Desktop/TR/TurtleRansom-v0-macos-arm64.pkg",
"name" : "TurtleRansom-v0-macos-arm64.pkg",
"pid" : 938
}
}
}
{
"event" : "ES_EVENT_TYPE_NOTIFY_RENAME",
"file" : {
"source" : "/Users/user/Desktop/TR/file.docx",
"destination" : "/Users/user/Desktop/TR/file.docx.TURTLERANSv0",
"process" : {
"path" : "/Users/user/Desktop/TR/TurtleRansom-v0-macos-arm64.pkg",
"name" : "TurtleRansom-v0-macos-arm64.pkg",
"pid" : 938
}
}
}
{
"event" : "ES_EVENT_TYPE_NOTIFY_WRITE",
"file" : {
"destination" : "/Users/user/Desktop/TR/file.docx.TURTLERANSv0",
"process" : {
"path" : "/Users/user/Desktop/TR/TurtleRansom-v0-macos-arm64.pkg",
"name" : "TurtleRansom-v0-macos-arm64.pkg",
"pid" : 938
}
}
}
Note that the encrypted files are suffixed with the hardcoded extension “TURTLERANSv0”.
请注意，加密文件后缀为硬编码扩展名“ TURTLERANSv0 ”。
Decryption 解密
Can we decrypt files encrypted by the ransomware? 🤔 Good question!
我们可以解密被勒索软件加密的文件吗？🤔 问得好！
Recall the encryption is done via Go’s crypto/AES library. If we set a breakpoint on the call to the aes.NewCipher function, which takes as its only argument a key, we should be able to recover the symmetrical encryption/decryption key:
回想一下，加密是通过 Go 的加密/AES 库完成的。如果我们在调用函数时设置一个断点，该函数 aes.NewCipher 将密钥作为其唯一参数，我们应该能够恢复对称加密/解密密钥：
% lldb TurtleRansom-v0-macos-arm64.pkg
...
(lldb) b 0x100095e24
Breakpoint 11: where = TurtleRansom-v0-macos-arm64.pkg`main.en0cr0yp0tFile + 84, address = 0x0000000100095e24
(lldb) c
Process 1002 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 11.1
frame #0: 0x0000000100095e24 TurtleRansom-v0-macos-arm64.pkg`main.en0cr0yp0tFile + 84
TurtleRansom-v0-macos-arm64.pkg`main.en0cr0yp0tFile:
-> 0x100095e24 <+84>: bl 0x100074c70 ; crypto/aes.NewCipher
(lldb) x/s $x0
0x14000106cb0: "wugui123wugui123"
Once the breakpoint is hit, we print out the first argument (found in the x0 register). It contains the value, “wugui123wugui123”, which is ransomware’s key.
一旦命中断点，我们打印出第一个参数（在 x0 寄存器中找到）。它包含值“ wugui123wugui123 ”，这是勒索软件的密钥。
ChatGPT says, “‘Wugui’ (乌龟) in Chinese translates to “turtle” or “tortoise” in English.
ChatGPT说：“”在中文中翻译为”或”。
Back in the disassembly, we can see that address 0x100098545 is passed to the en0cr0yp0tFile function:
回到反汇编中，我们可以看到地址 0x100098545 被传递给 en0cr0yp0tFile 了函数：
0x00000001000961c0 adrp x5, #0x100098000 ; 0x100098545@PAGE
0x00000001000961c4 add x5, x5, #0x545 ; 0x100098545@PAGEOFF, 0x100098545
0x00000001000961c8 ldp x5, x6, [x5]
0x00000001000961cc stp x5, x6, [sp, #0x50]
...
0x00000001000961e4 bl main.en0cr0yp0tFile
And if we go to the address 0x100098545 we found that this holds the (hard-coded) key “wugui123wugui123”:
如果我们去地址 0x100098545 ，我们发现它包含（硬编码的）键“ wugui123wugui123 ”：
0x0000000100098545 db 0x77 ; 'w' ; DATA XREF=_main.main.func1+292
0x0000000100098546 db 0x75 ; 'u'
0x0000000100098547 db 0x67 ; 'g'
0x0000000100098548 db 0x75 ; 'u'
0x0000000100098549 db 0x69 ; 'i'
0x000000010009854a db 0x31 ; '1'
0x000000010009854b db 0x32 ; '2'
0x000000010009854c db 0x33 ; '3'
0x000000010009854d db 0x77 ; 'w'
0x000000010009854e db 0x75 ; 'u'
0x000000010009854f db 0x67 ; 'g'
0x0000000100098550 db 0x75 ; 'u'
0x0000000100098551 db 0x69 ; 'i'
0x0000000100098552 db 0x31 ; '1'
0x0000000100098553 db 0x32 ; '2'
0x0000000100098554 db 0x33 ; '3'
As AES is symmetrical and here the key is hard-coded, its trivial for us to write a decryptor:
由于 AES 是对称的，并且这里的密钥是硬编码的，因此我们编写解密器非常简单：
import sys
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
def decryptTurtle(key, iv):
with open(sys.argv[1], 'rb') as file:
ciphertext = file.read()
cipher = Cipher(algorithms.AES(key.encode('utf-8')), modes.CTR(iv), backend=default_backend())
decryptor = cipher.decryptor()
plainText = decryptor.update(ciphertext) + decryptor.finalize()
print(plainText)
iv = b'\x00' * 16
key = "wugui123wugui123"
decryptTurtle(key, iv)
感谢 Ema 🇱🇹 帮助编写解密器
Now, if we create a file with any content, run the ransomware so that it encrypts the file, then pass the now encrypted file to our decryptor it is able to fully decrypt and recover the orginal contents:
现在，如果我们创建一个包含任何内容的文件，请运行勒索软件以加密文件，然后将现在加密的文件传递给我们的解密器，它能够完全解密和恢复原始内容：
% echo "The quick brown fox jumps over the lazy dog" > test.txt % ./TurtleRansom-v0-macos-arm64.pkg 加密文件 /Users/user/Desktop/TR/test.txt 成功 % python3 turtle.py test.txt.TURTLERANSv0 b'The quick brown fox jumps over the lazy dog\n'
Hooray! 🥳 万岁！🥳
Detection 检波
Of course it goes without saying, having your files ransomed sucks! But good news, in this case the average macOS user is unlikely to be impacted by this macOS sample. Still the fact that ransomware authors have set their sights on macOS, should give us pause for concern and also catalyze conversions about detecting and preventing this (and future) samples in the first place!
当然，不言而喻，让您的文件被赎回很糟糕！但好消息是，在这种情况下，普通 macOS 用户不太可能受到此 macOS 示例的影响。尽管如此，勒索软件作者将目光投向了 macOS，这一事实应该让我们停下来关注，并首先促进有关检测和预防此（以及未来）样本的转换！
First, Apple has been fairly proactive about mitigating ransomware attacks on macOS (and maybe this is why we’ve yet seen a major ransomware outbreak on macOS). So, kudos to Cupertino. Specifically Apple has implemented SIP (and now read-only system volumes) to protect OS-level files. This means even if ransomware finds its way onto a macOS system it won’t (easily) be able to mess with core OS files. Apple has also added (TCC) protections to user files founds in (now) protected directories such as ~/Desktop, ~/Documents, etc. etc. This means, that without an exploit or explicit user-approval users files will remain protected. (Though TCC is pretty easy to bypass …or worse case you just ask the user, and they’ll likely acquiesce).
首先，苹果在缓解macOS上的勒索软件攻击方面一直相当积极主动（也许这就是为什么我们还没有看到macOS上出现重大勒索软件爆发的原因）。所以，向库比蒂诺致敬。具体来说，Apple 已经实施了 SIP（现在是只读系统卷）来保护操作系统级别的文件。这意味着即使勒索软件进入 macOS 系统，它也无法（轻松）弄乱核心操作系统文件。Apple 还为在（现在）受保护的目录中找到的用户文件添加了 （TCC） 保护，例如 ~/Desktop 、 ~/Documents 等。这意味着，如果没有漏洞利用或明确的用户批准，用户文件将保持受保护状态。（虽然TCC很容易绕过……或者更糟糕的是，你只是问用户，他们可能会默许）。
Still an additional layer or detection/protection may be warranted, especially as we’ve all probably inadvertently clicked “Allow” on access prompts, while even Apple has been known to notarize malware.
仍然可能需要额外的层或检测/保护，特别是因为我们都可能无意中在访问提示上单击了“允许”，而即使是 Apple 也已知对恶意软件进行公证。
If we stop to think specifically about ransomware, in theory, it should be trivial to detect (at least in most cases). Why? Simply put, ransomware’s actions provide us with a powerful detection heuristic.
如果我们停下来专门考虑勒索软件，从理论上讲，检测它应该是微不足道的（至少在大多数情况下）。为什么？简而言之，勒索软件的行为为我们提供了强大的检测启发式方法。
In April 2016 (yes, wayyyy back then!) I posted a blog titled, “Towards Generic Ransomware Detection”. In this post, I mused,
2016 年 4 月（是的，当时是 wayyyy！我发布了一篇题为“迈向通用勒索软件检测”的博客。在这篇文章中，我沉思道，
“If we can monitor file I/O events and detect the rapid creation of encrypted files by untrusted processes, then ransomware may be generically detected” -(a younger) Patrick Wardle
“如果我们能够监控文件 I/O 事件并检测不受信任的进程快速创建加密文件，那么勒索软件可能会被普遍检测到”——（年轻）帕特里克·沃德尔
To back this up, I released a free (and now open-source) tool called “RansomWhere?” that implemented this heuristic-based approach. Specifically it monitors file I/O events and for newly created files asks:
为了支持这一点，我发布了一个名为“RansomWhere？”的免费（现在是开源的）工具，它实现了这种基于启发式的方法。具体来说，它监视文件 I/O 事件，对于新创建的文件，它会询问：
- Is the process creating file untrusted (e.g. not an Apple platform binary)?
创建文件的过程是否不受信任（例如，不是 Apple 平台二进制文件）？ - Is created file encrypted?
创建的文件是加密的吗？ - Is the (untrusted) process rapidly creating several encrypted files?
（不受信任的）进程是否正在快速创建多个加密文件？
If these are all true, “RansomWhere?” will suspend the process as its likely ransomware and alert the user and handle the response (resume/terminate).
如果这些都是真的，“RansomWhere？”将暂停该进程，因为它可能是勒索软件，并提醒用户并处理响应（恢复/终止）。
与任何检测方法和安全工具一样，也存在局限性。我的目标是在“RansomWhere”中清楚地阐明这些内容。S 工具页面：
赎金在哪里？s 限制
Most notably, “RansomWhere?” is slightly reactive, meaning several files maybe be encrypted (and thus ransomed) before the tool detects and blocks the ransomware.
最值得注意的是，“RansomWhere？”具有轻微的反应性，这意味着在工具检测到并阻止勒索软件之前，可能会对多个文件进行加密（从而被勒索）。
And though “RansomWhere?” is a bit dated, it appears to be able to generically detect the actions of Turtle Ransomware and thus thwart it …even though it had no a priori knowledge of this malware:
虽然“RansomWhere？”有点过时了，但它似乎能够普遍检测 Turtle Ransomware 的行为，从而阻止它……即使它没有先验的了解这个恶意软件：
赎金在哪里？…做它的事情！
Hooray! Free, open-source tools FTW! 🥳
万岁！免费的开源工具 FTW！🥳
Does your EDR product provide generic ransomware detection!? 🤔
您的 EDR 产品是否提供通用勒索软件检测！？🤔
Conclusion 结论
Today we dove into a new ransomware sample, internally dubbed “Turtle”. And while in its current state it does not post much of a threat to macOS users, it yet again, shows that ransomware authors continue to set their sites on macOS.
今天，我们深入研究了一个新的勒索软件样本，内部称为“Turtle”。虽然在目前的状态下，它并没有对 macOS 用户造成太大威胁，但它再次表明勒索软件作者继续在 macOS 上设置他们的网站。
原文始发于Patrick Wardle：It’s Turtles All The Way Down 🐢
相关文章
