在macOS 10.15 Catalina中，Apple进行了许多安全性能地改进，包括通过使所有可执行文件都受XProtect扫描来加固系统，而不管文件是否带有com.apple.quarantine位标记。对于安全研究人员而言，这意味着不再像以前的macOS一样，仅通过使用xattr实用程序删除隔离位就可以运行已知的XProtect恶意软件了。这对于用户来说是个好消息，但是对于那些想要探索XProtect样本的更详细的行为细节的研究人员来说，这可能是个问题。在本文中，研究人员将研究研究人员如何绕过这种各种安全功能，并在需要时仍在Catalina上运行已知的恶意软件。
为什么要在Catalina上运行已知的恶意软件
不久之前，研究人员可能不太关心XProtect已知的恶意软件，因为XProtect很少更新，并且没有涵盖macOS研究社区已知的许多攻击。最重要的是，在Catalina之前，XProtect总是很容易被绕过。
然而，时代已经变了，苹果公司终于意识到，Mac电脑在野外正受到各种不同攻击因素的攻击。最近几个月，苹果公司不仅更频繁地更新其内部安全工具，而且还发现了其他研究人员之前面临的一些攻击。但Apple很少共享攻击情报，而且如果攻击被Catalina上的XProtect阻止，则研究人员则无法更深入地研究攻击的工作原理。这种深度探索是必要的，至少有两个原因。首先，研究人员要开发比XProtect使用的遗留方法更有效的缓解措施和阻止措施；其次，研究人员希望能够分析恶意软件的行为并跟踪活动，以便在攻击开始之前采取行动。
如何在Catalina上运行已知的恶意软件样本
鉴于研究人员不能再删除com.apple.quarantine位以允许恶意软件在Catalina上运行了，研究人员必须采取其他策略。
首先，研究人员可以在macOS的早期版本(例如10.14)上运行示例，在这些早期的版本中，研究人员可以使用常规的XProtect绕过。这在某些情况下可能没问题，但这意味着研究人员无法测试特定于Catalina的恶意行为。此外，一旦研究人员升级到10.16及更高版本，测试计算机上的操作系统将越来越落后于实际使用的恶意软件作者所针对的操作系统。最终，研究人员最终会获得一个甚至根本不支持该恶意软件的操作系统，因此从长远来看，还需要另一种解决方案。
第二种可能性是禁用SIP并修改XProtect文件(例如删除所有签名)，尽管在实验室设备或专门用于测试恶意软件的VM上执行此操作没有问题，但这个解决方案会带来很多副作用。除非万不得已，不要使用该方案。它的问题是在SIP关闭的情况下，你可能会遇到更多的问题，因为恶意软件在这样一个不寻常的环境中会有不同的行为。恶意软件的开发者知道，真正的用户很少在禁用SIP的情况下运行，因此他们可以使用一种简单的反分析技术来运行csrutil状态，然后相应地退出或改变行为。
第三种可能性是确定样本触发的规则，然后修改样本以避免该规则。XProtect很久以前就不仅仅是一个简单的基于哈希的文件扫描程序了，现在它使用了Yara规则，因此仅仅在示例的末尾添加一两个字节来更改计算的文件散列是行不通的。然而，正如我们将看到的，仍然可以通过一些工作绕过XProtect，但是有几个“陷阱”需要注意，我将在下面解释。
如何在macOS 10.15及更高版本上攻击计算机
当然，研究人员指的是在运行恶意软件之前正确隔离的一次性VM实例的攻击!一旦你处在一个安全的、可任意使用的环境中，第一个任务就是确定恶意软件所针对的规则是什么。就本文而言，我将使用此示例，该示例在发布时未被VT上的任何静态引擎检测到：
174c5712759c4abd2bdfc1b93f4c990011c45aeed236e89c1c864b1e8379c54d
在Catalina上，研究人员仍然必须删除com.apple.quarantine位，才能同时满足Gatekeeper(山狮中引入的一项新安全技术，它可保证用户安装来自Mac App Store或者拥有开发者签名的应用)和Notarization 要求(2019年，苹果在10.14.5上新引入的App Notarization机制，要求开发人员上传应用程序之前，将它们提交给苹果，以扫描恶意内容，并查找可能存在的代码签名问题，没有经过苹果检测的应用程序以后可能将不被允许运行)。
$ xattr -rc ~/mdworker_share.app
但是，正如研究人员看到的那样，当尝试引爆样本时，尽管VT不了解这种恶意软件，但XProtect却知道。
这意味着研究人员首先必须检查研究人员的恶意软件，并将其与XProtect.yara中的规则进行比较以找到匹配项。之前我们已经写过有关如何逆转XProtect签名定义的文章，因此请参阅该文章中的内容。
如果你试图测试已经在VT或其他存储库中发现的恶意软件，那么你可以通过查看恶意软件的检测名称来获得线索，但苹果的新签名并不使用普通的恶意软件名称。如今，苹果公司更喜欢使用无意义的字母数字标识符，如下面所示，来混淆他们所检测的内容：
如果像研究人员在此使用的示例一样，你的恶意软件不为杀毒引擎所知，并且被XProtect阻止，那么请先查看更新的XProtect规则。至少在目前，较新的规则往往位于文件的顶部。但研究人员发现经常关注XProtect的更改是很有用的，这样可以查看每次更改的内容，从而使这个过程更快、更容易。
你可能必须根据规则对样本的二进制文件进行grep字符串查找，直到找到匹配项为止。
在此示例的情况下，事实证明这些字符串与Apple所谓的MACOS.b264ff6的规则匹配，目前，该规则已添加到XProtect v2112中。
研究人员可以将恶意软件样本加载到十六进制编辑器中，并以十六进制搜索规则，以确认样本是否符合要求：
当然，请确保你的样本符合指定的确切条件，而不仅仅是一个字符串。对于此规则，研究人员需要从$ a和$ b集合中的字符串中每个击中一个，以及从字符串$ c中获得一个命中。
Macho and filesize < 3000000 and (1 of ($a*)) and (1 of ($b*)) and $c
如何修补二进制文件以绕过XProtect Yara规则
假设该规则在条件中有一个文件大小，我们可以选择将垃圾数据附加到二进制文件的末尾，或者修改规则中指定的一个字符串。该规则表示可执行文件必须小于3MB，而实际上研究人员的样本只有86Kb，因此要添加很多垃圾。不过，将垃圾附加到二进制文件中很容易。这样做可能需要几分钟，但是很容易用条件将数字替换为下面括号中的第二个数字，并且代码会将文件膨胀到所需的大小：
for i in {1..3000000}; do echo '0' >> mdworker_share; done
尽管这种方法在这个特定的示例上工作得很好，又可能导致其他样本改变其行为，例如，如果它对自己的文件大小进行自我检查。同样，尽管当前几乎所有XProtect规则都在条件中指定了文件大小，但将来可能不成立。因此，研究人员还应该考虑修补二进制文件，而不仅仅是将垃圾数据附加到二进制文件中。
在修补二进制文件时，需要注意一些“陷阱”，我将在下一部分中列出，但是你要注意的第一个也是最直接的一个是确保你不要更改会破坏的东西，或更改恶意软件的行为。例如，假设研究人员的示例具有在MACOS.b264ff6规则中指定的$ b4字符串：
$b4 = { /usr/sbin/system_profiler }
研究人员不应该只是将其更改为某些垃圾字符串，因为这可能会阻止他们分析的恶意软件正常运行或完全无法执行。相反，研究人员可以将该路径更改为另一个长度相等的路径，然后将system_profiler二进制文件的副本放在研究人员的测试设备上。例如，研究人员可以创建/tmp/sbin/system_profiler
修补程序本身就是使用类似hex Fiend的十六进制编辑器，对规则中出现的每个惟一字符串或十六进制字节进行搜索和替换。如果可以选择，请选择理想情况下只出现在一个地方的代码，以减少破坏样本的风险。
研究人员使用的这个特定示例匹配字符串$ a1，$ b2和$ c，只需要更改其中之一即可发起攻击。字符串$b2看起来像一个方法名，只有当用户取消授权请求时才会调用这个方法名。
$b2 = { didCancelAuthenticationChallenge }
由于我不打算在测试中执行此操作，因此我将在Hex Fiend中更改此方法名称的前几个字符，然后保存二进制文件。
在最坏的情况下，恶意软件会对其自身的代码完整性进行内部检查，或者你在不影响恶意软件行为的情况下无法找到要更改的值，则可能必须制作此类补丁才能首先通过XProtect进行启动，然后再取消补丁。调试器中的二进制文件，以使其在执行内部检查或修补的代码之前返回其原始状态。这涉及在修补的代码上设置断点(请记住，你必须在出现的任何地方对其进行修补/取消修补)，然后在继续之前提供原始值。
修补二进制文件时的一些注意事项
研究人员的示例现在可以运行了，但是在启动它之前，先了解一些陷阱，以确保做的一切都是正确的。
首先，请确保仅替换二进制文件中的字节，而不添加字节。虽然在二进制文件的末尾添加垃圾文件是可以的，但是在二进制文件中创建的任何补丁都不应该添加额外的字节，否则你将移动所有偏移量，代码将无法运行。
其次，确保你的补丁工具能够在不破坏二进制文件的情况下保存它们。例如，Ghidra似乎无法在不破坏二进制文件的情况下进行修补和保存。Hex Fiend可能是你最好的选择，但是其他工具当然也应该起作用。
第三，打补丁时，你将破坏可能存在的所有代码签名。这通常不是问题，因为你将通过删除com.apple.quarantine位来禁用代码签名检查，但是如果你确实需要对二进制文件进行有效的代码签名(例如，如果它检查自己的代码签名)在修补后使用临时签名对它重新签名，或者修补或跳过在二进制文件中返回代码签名检查的方法。
第四，如果你在Catalina上运行了一个示例，但该示例被XProtect阻止，则请勿修补被阻止的同一实例。看起来，无论是通过XProtect还是LaunchServices，卡塔琳娜都记得已被阻止的文件，并且无论你对其进行多少修补，它都将无法运行。因此，在另一台计算机或VM上修补一个干净的恶意软件副本，然后将其转移过来。在尝试启动之前，请记住删除隔离位。
如果你避免了上述所有“陷阱”，那么你现在应该能够引爆恶意软件，，并愉快地继续你的macOS反向工程探索！
样本
mdworker_share.app.zip
791157ca6a1f10ee209ea71ffa0f8c9109028f4d1013d092276a6a7e50e1b2a4
174c5712759c4abd2bdfc1b93f4c990011c45aeed236e89c1c864b1e8379c54d
46724f195ea18e82d833ed92637a20ed95f9afe1ef749aa06c9156f2719ce389
helper.app.zip
0ac25a8dd9134284406248110ad66dbdb7f4ec557570be02fb9f92bee93727bf
fa88ca779f16e7adbe0702db8473883c20b0aaa69a2345d07c81d322ff2bc990
terninal.app.zip
cbc7751d5fcca12d9e7ea2fd90862d14af8d024710ff22f5457a2f8d427b7fee
参考及来源：https://www.sentinelone.com/blog/macos-malware-researchers-how-to-bypass-xprotect-on-catalina/
