简述
在添加了TrustedSec AETR精英团队至今，我花了一些時间科学研究macOS自然环境下的Tradecraft。缺憾的是，针对进攻方而言，与Windows对比，对于macOS自然环境的进攻难度系数越来越大。伴随着个人隐私保护、沙盒和很多的权限管理，网络攻击无法在macOS机器设备上置放嵌入专用工具。
在破坏力链(Killchain)的后漏洞检测(post-exploitation)中，进程注入是一种主要的方式，Apple也耗费了很大的尽力去预防这类方式。从在历史上看来，大家之前可以在目标进程上启用task_for_pid，查找其Mach端口号，并实行mach_vm_以分派和载入/写入运行内存。而今日，这种API早已遭受严苛的限定，仅有root客户才可以启用这种函数公式。换句话说，只需二进制文件沒有应用Hardened Runtime，而且目标并不是Apple签字的二进制文件，那麼即使是root客户，也不可以查询其运行内存。
在这篇文章中，大家将讲解一些运用第三方技术完成编码注入的有意思方式。对咱们而言，这类方式可以转变为在目标应用软件的前后文中运行代码，而不用再专注于禁止使用系统软件一致性维护(SIP)。
一定要注意：文中中剖析的二种技术都并不是特殊于macOS的，他们还可以在Linux和Windows系统上完成，可是因为Apple对进程注入开展了限定，因此本篇文章关键放到了对macOS的危害上。
最先，使我们看一下所有人应当了解的技术——.NET Core。
NET Core
Microsoft的.NET Core架构是一种时兴的混合开发运作时和开发软件模块(SDK)，可以运用大家了解的.NET语言表达开发设计应用软件。由.NET Core运作时给予适用的最火爆的应用软件之一便是PowerShell的混合开发版本号，大家将以它做为最初的测试平台。
为了更好地展现我们在试着macOS注入全过程中所遭遇的多元性，大家最先演试根据task_for_pid API开展注入的传统式方式。一种简易的办法是应用：
当对于目标PowerShell进程运作时，大家取得了期望的报错。
没法查找PowerShell的每日任务端口号：
下面，大家试着以root真实身份运作。试着对沒有Hardened Runtime标示的程序开展检测，获得了常规的結果。
以root客户真实身份取得成功获得PowerShell的每日任务端口号：
可是，一旦大家进行应用Hardened Runtime标示签字的应用软件，便会碰到一样的不正确。
在结构加固后进程中不可以以root客户真实身份得到每日任务端口号：
如果我们应用lldb之类的物品，而它有着com.apple.security.cs.debugger的强悍作用，会产生哪些?当非root客户试着浏览未结构加固的进程时，大家获得了一些进度，可是这时也出現了一个提示框，警示大家存有的目标，这事实上就有一些危害隐秘性了。
要求调节管理权限时为客户表明的提示框：
再度，大家以root客户真实身份运作lldb，也不能应用Hardened Runtime调试进程。
程序调试没法以root客户真实身份额外到结构加固后的进程：
总而言之，这代表着，仅有在大家以root客户，且未应用Hardened Runtime标示对进程开展签字的情形下，才可以注入.NET Core进程。
既然这样，Apple的API如今对咱们而言就毫无价值，我们在没有一个理想化的系统漏洞的情形下，还能怎样去操纵目标.NET Core进程呢?为了更好地了解这一点，大家应当更详细分析一下运作时的源码，可以这里寻找：https://github.com/dotnet/runtime 。
NET Core调试
使我们重新开始，试着掌握例如Visual Studio Code那样的程序调试是怎样与.NET Core进程开展信息交互的。
查询dbgtransportsession.cpp中的.NET Core源码，可以发觉这一部分编码承担解决程序调试与调节內容的通讯，在函数公式DbgTransportSession::Init中构建了一系列命名管道。
针对macOS(和*nix)，这种管路是应用下面编码建立的FIFO命名管道：
为做好剖析，我们可以运行PowerShell，并见到在现阶段客户的$TMPDIR内建立了2个命名管道，其名字为PID，并含有in或out的后缀名。
.NET Core建立用以调节的命名管道：
在掌握命名管道的具体位置和目地后，大家怎样与目标进程开展通讯?回答坐落于方式DbgTransportSession::TransportWorker当中，该方式承担解决来源于程序调试的传到联接。
阅读文章编码，大家发觉程序调试要做的第一件事是建立一个新的调节会话。这是根据以MessageHeader结构开始的out管路推送信息来进行的，这一部分可以从.NET源代码中见到：
针对新的会话请求，该结构添充如下所示：
结构结束后，大家应用write syscall将其发送到总体目标：
在标头以后，大家必须推送一个sessionRequestData结构，该结构包括一个用以标志会话的GUID：
在推送进行会话请求后，大家从out管路中载入一个标头，该标头将指程序调试会话是不是取得成功：
在这里一环节，大家早已与总体目标创建了程序调试会话。下面，就可以与总体目标过程开展通讯了，那麼我们可以应用什么作用呢?根据查询运作时公布的信息种类，可以寻找2个非常值得留意的原语，分别是MT_ReadMemory和MT_WriteMemory。
这种信息符合实际大家的预估，可以使我们载入和写入总体目标过程的运行内存。这儿必须考虑到的是，我们可以在常见的macOS API启用以外载入和写入运行内存，进而为大家出示了.NET Core过程运行内存的侧门。
使我们逐渐试着从总体目标过程中载入一些运行内存。与会话建立一样，大家最先制做标头：
可是，这一次，大家还带来了一个期待从总体目标读取的详细地址：
我们可以借助下边的方式，分派一些非托管运行内存，来对于PowerShell开展尝试：
可以应用定义证实(POC)编码轻轻松松读取此运行内存。
从PowerShell中存贮运行内存：
自然，根据应用指令遮盖运行内存引入PowerShell，大家还可以完成反过来的实际操作。
将运行内存引入PowerShell：
用以实行此实际操作的POC编码请参照： https://gist.github.com/xpn/7c3040a7398808747e158a25745380a5 。
NET Core代码实行
以前大家对焦于如何把编码引入到PowerShell中，下面要化解的问题是，如何把读写能力原语变换为执行命令?这儿还要充分考虑，大家沒有变更内存保护的工作能力，因此假如要引进相近Shellcode的內容，只有载入标识为可写和可实行的运行内存网页页面。
在这样的情况下，大家有几种挑选，做为简易的定义证实而言，最先可以明确运行内存的RWX网页页面，并之中托管大家的Shellcode。Apple限定了大家解析xml远程控制过程详细地址室内空间的工作能力。可是，大家事实上还能够浏览vmmap，在其中包括了许多管理权限，也包含用以浏览总体目标Mach端口号的com.apple.system-task-ports。
在PowerShell中实行vmmap -p [PID]，能够看见许多合适托管编码的运行内存地区，下边以rwx/rwx管理权限突显。
应用vmmap鉴别运行内存的RWX网页页面：
即然大家知道将Shellcode引入的详细地址，大家就必须寻找一个可以载入的部位，来开启执行命令。函数指针是一个较为满意的部位，无需太长期就可以发觉很多梦想的总体目标。大家使用的一个办法是遮盖动态性函数表(DFT)中的表针，.NET Core运作时应用该表针为JIT编译程序给予协助函数公式。可以在jithelpers.h中寻找适用的函数指针的目录。
搜索偏向DFT的表针事实上非常简单，我们可以应用类似mimikatz的签字寻找技术性来检索libcorclr.dll，以搜索对符号_hlpDynamicFuncTable的引入，接着撤销引入。
转化成寻找_hlpDynamicFuncTable标记签字的命令：
下面要做的，便是寻找一个详细地址，从该地址逐渐开展签字检索。因此，大家运用了另一个公布的程序调试函数公式MT_GetDCB。这可能回到相关总体目标过程的很多有效信息内容，可是对咱们而言，大家关心的是回到的字段名，字段中包括协助函数公式的详细地址m_helperRemoteStartAddr。根据这一详细地址，就可以了解libcorclr.dll在总体目标过程运行内存中的部位，而且可以逐渐检索DFT。
如今，大家早已具有了引入和实行编码需要的任何內容，可以尝试将一些Shellcode载入运行内存的RWX网页页面，并根据DFT传送执行命令。大家采用的Shellcode比较简单，只要在PowerShell提示符中表明一条信息，随后再将实行回到给CLR(以避免奔溃)就可以：
撰写进行以上Shellcode以后，大家将全部这种搭配在一起，看一下实行全过程到底怎样。
演试短视频：https://youtu.be/KqTIrB_WUgA
用以注入Shellcode的详细POC编码请参照： https://gist.github.com/xpn/b427998c8b3924ab1d63c89d273734b6 。
Hardened Runtime是不是能预防进攻
如今，我们可以注入到.NET Core过程中，还剩余一个显著的问题，便是Hardened Runtime是不是可以阻拦这样的事情?依据人们的剖析，设定Hardened Runtime标志不容易对曝露给大家的调试管路造成危害，这代表着Hardened Runtime标志签字的应用程序依然会曝露以上IPC调试函数公式，该函数恰好是要完成注入所必需的。
举例来说，大家看一下另一个通过签字，并开启了Hardened Runtime标志的著名应用程序Fiddler。
与Fiddler应用程序密切相关的Hardened Runtime标志：
在这儿，大家找到Hardened Runtime标志集，可是，运行应用程序依然会造成建立调试管路。
在应用Hardened Runtime的情况下Fiddler建立的命名管道：
试着向Fiddler中注入一些Shellcode，以保证一切正常。此次，大家应用的是Cody Thomas的Mythic框架，将当中的Apfell嵌入专用工具注入到总体目标过程中。
有几种方式可以挑选，可是为了更好地简易考虑，大家应用wNSCreateObjectFileImageFromMemory方式从硬盘载入Bundle：
大家利用加载的Bundle来完成JXA执行：
如果我们如今依照对于Fiddler的.NET Core WebUI步骤执行与以前完全一致的流程，来完成编码引入，一切顺利得话，就可以将Apfell嵌入专用工具引入结构加固后的过程中，并派长出嵌入专用工具。
演试短视频：https://youtu.be/-e4OrX2nmeY
用以引入Apfell嵌入专用工具的POC编码： https://gist.github.com/xpn/ce5e085b0c69d27e6538179e46bcab3c。
好啦，如今大家看到了运作时这种掩藏函数公式的应用性，但这也是.NET Core的个案吗?事实上，并不是。大家下面看一下App Store里边的另一个架构——Electron。
挟持Electron
大家都知道，Electron是一个架构，可以用以将Web应用软件移殖到桌面上，与此同时可以可靠地储存RAM，供后面必须时应用。
那麼，大家怎样才能在通过签字和结构加固后的Electron应用软件中执行编码?这儿就需要引进系统变量——ELECTRON_RUN_AS_NODE。
这一系统变量是将Electron运用程序转换为基本的旧NodeJS REPL所需求的所有。例如，大家从App Store中获得一个受欢迎的应用软件(例如Slack)，并在设定了ELECTRON_RUN_AS_NODE系统变量的情形下运行该过程：
这也适用Visual Studio Code：
Discord...
乃至是BloodHound：
我原本认为这种是0-day，但其实早已在文本文档中公布过( https://www.electronjs.org/docs/api/environment-variables#electron_run_as_node )。
那麼，这对人们而言寓意哪些?一样，在macOS自然环境中，这代表着，如果我们对某一应用软件有兴趣，或是容许对于Electron应用软件应用个人隐私操纵，那麼就可以在含有ELECTRON_RUN_AS_NODE系统变量的情形下执行签字和固定的过程，随后将NodeJS编码传送并执行。
大家以Slack为例子，试着利用该应用软件通常容许的桌面上、文本文档等地区的浏览，来处理TCC问题。在macOS中，子过程将承继父过程的TCC管理权限，因而这代表我们可以应用NodeJS转化成子过程(例如Apfell的嵌入程序流程)，该子过程将承继客户授于的全部隐私设置容许的新项目。
因此，大家将应用launchd根据下列plist转化成Electron过程：
随后，我们可以运行每日任务，载入plist并应用ELECTRON_RUN_AS_NODE系统变量运行Slack，根据OSAScript实行Apfell：
假如一切顺利，大家将根据预估回到到Shell。
Apfell嵌入专用工具返还到Mythic架构：
通常，在这儿，在我们要求~/Downloads之类的信息时，大伙儿很有可能担忧会向客户表明个人隐私提醒，但事实上，因为现在是Slack的子过程，因而可以应用其承继的个人隐私管理权限。
演试短视频：https://youtu.be/1_3Q00-c_JA 。
自然，假如网络攻击在未得到批准的情形下要求浏览一切內容，我们可以让合理合法运用来背这一锅：
当载入Apfell嵌入专用工具要求浏览时，表明的TCC提示框：
如今，大家就早已熟练掌握了几类运用第三方架公布的作用来处理macOS过程引入限定的方式。这类引入技术性适用很多应用软件，充分考虑Apple在macOS系统软件中大力加强的限定，这类实际效果也让人诧异。大家期待，根据展现这类技术性，可以幫助一些蓝队组员能够更好地完成macOS后漏洞检测的引入阶段。
文中翻譯自：https://www.trustedsec.com/blog/macos-injection-via-third-party-frameworks/倘若转截，请标明全文详细地址。