对2019全年的Mac恶意程序的全面分析（Lazarus Loader ）

gejigeji 资讯 2020-01-13 10:32:47

457566

导语：Lazarus黑客组织创建的Lazarus Loader (又名macloader)，作为第一阶段的植入程序加载程序，可以直接从内存中下载并执行模块！

Lazarus Loader (又名macloader)

Lazarus黑客组织创建的Lazarus Loader (又名macloader)，作为第一阶段的植入程序加载程序，可以直接从内存中下载并执行模块！

感染媒介：被植入恶意载荷的应用

2019年12月，安全研究人员Dinesh_Devadoss发现了来自朝鲜的黑客可能在新发现的传播恶意软件的加密货币交易网站的背后，如果他们下载了一个所谓的套利平台，将会感染macOS用户。

该恶意软件最初是由安全研究员Dinesh Devadoss发现的，他在推特上发布了该发现。 Bleeping Computer对其进行了检测，发现在大多数病毒检测引擎中几乎未检测到该恶意软件，只有五个经过测试的恶意软件发现了该恶意软件。

#Lazarus #macOS＃木马 
 md5：6588d262529dc372c400bef8478c2eec
 hxxps：//unioncrypto.vip/

包含代码：从内存中加载Mach-O并执行/写入文件并执行@patrickwardle

我们已经注意到，Lazarus APT组织喜欢以加密货币的用户或管理员为目标。他们实际上是通过伪造的加密货币公司和交易应用程序感染此类目标的方法。在该恶意程序中，我们再次看到他们利用这种方法感染目标。

具体来说，他们首先创建了一个经过伪造的加密货币交易平台“ Union Trader Crypto” ，它托管在一个名为“ unioncrypto.vip”的网站上，该网站宣传“智能加密货币套利交易平台”。

使用此IP地址查询VirusTotal，我们找到一个触发了恶意应用程序下载的URL请求（https://www.unioncrypto.vip/download/W6c2dq8By7luMhCmya2v97YeN）：

该应用程序通过名为UnionCryptoTrader.dmg的磁盘映像交付，我们可以通过hdiutil attach命令安装该磁盘映像：

$ hdiutil attach ~/Downloads/UnionCryptoTrader.dmg 
expected   CRC32 $7720DF1C
/dev/disk4            GUID_partition_scheme           
/dev/disk4s1          Apple_APFS                      
/dev/disk5            EF57347C-0000-11AA-AA11-0030654 
/dev/disk5s1          41504653-0000-11AA-AA11-0030654 /Volumes/UnionCryptoTrader

它包含一个包：UnionCryptoTrader.pkg：

$ ls -lart /Volumes/UnionCryptoTrader
total 40120
-rwxrwxrwx  1 patrick  staff  20538265 Sep  4 06:25 UnionCryptoTrader.pkg

通过我们的“WhatsYourSign”应用程序，可以很容易地看到UnionCryptoTrader.pkg包未签名：

这意味着如果macOS试图打开它，用户将受到警告：

显然，Lazarus组织还是使用了其赖以成功的攻击手段，即针对具有木马交易应用程序的加密货币交换的员工。

持久性攻击的来源：Launch Agent

调查UnionCryptoTrader.pkg程序包，发现将在安装过程结束时执行的安装后脚本：

所以，该脚本的目的是永久安装启动守护程序。

具体而言，脚本将执行以下操作：

1.将隐藏的plist（.vip.unioncrypto.plist）从应用程序的Resources目录移至/ Library / LaunchDaemons；

2.将其设置为root权限；

3.创建一个/ Library / UnionCrypto目录；

4.将隐藏的二进制文件（.unioncryptoupdater）从应用程序的Resources目录移至/ Library / UnionCrypto /；

5.将其设置为可执行；

6.执行此二进制文件（/ Library / UnionCrypto / unioncryptoupdater）；

我们可以通过文件或进程监控器来被动地观察安装的这一部分：

# ProcessMonitor.app/Contents/MacOS/ProcessMonitor -pretty

{
  "event" : "ES_EVENT_TYPE_NOTIFY_EXEC",
  "process" : {
    "uid" : 0,
    "arguments" : [
      "mv",
      "/Applications/UnionCryptoTrader.app/Contents/Resources/.vip.unioncrypto.plist",
      "/Library/LaunchDaemons/vip.unioncrypto.plist"
    ],
    "ppid" : 3457,
    "ancestors" : [
      3457,
      951,
      1
    ],
    "signing info" : {
      "csFlags" : 603996161,
      "signatureIdentifier" : "com.apple.mv",
      "cdHash" : "7F1F3DE78B1E86A622F0B07F766ACF2387EFDCD",
      "isPlatformBinary" : 1
    },
    "path" : "/bin/mv",
    "pid" : 3458
  },
  "timestamp" : "2019-12-05 20:14:28 +0000"
}

...

{
  "event" : "ES_EVENT_TYPE_NOTIFY_EXEC",
  "process" : {
    "uid" : 0,
    "arguments" : [
      "mv",
      "/Applications/UnionCryptoTrader.app/Contents/Resources/.unioncryptoupdater",
      "/Library/UnionCrypto/unioncryptoupdater"
    ],
    "ppid" : 3457,
    "ancestors" : [
      3457,
      951,
      1
    ],
    "signing info" : {
      "csFlags" : 603996161,
      "signatureIdentifier" : "com.apple.mv",
      "cdHash" : "7F1F3DE78B1E86A622F0B07F766ACF2387EFDCD",
      "isPlatformBinary" : 1
    },
    "path" : "/bin/mv",
    "pid" : 3461
  },
  "timestamp" : "2019-12-05 20:14:28 +0000"
}

...

{
  "event" : "ES_EVENT_TYPE_NOTIFY_EXEC",
  "process" : {
    "uid" : 0,
    "arguments" : [
      "/Library/UnionCrypto/unioncryptoupdater"
    ],
    "ppid" : 1,
    "ancestors" : [
      1
    ],
    "signing info" : {
      "csFlags" : 536870919,
      "signatureIdentifier" : "macloader-55554944ee2cb96a1f5132ce8788c3fe0dfe7392",
      "cdHash" : "8D204E5B7AE08E80B728DE675AEB8CC735CCF6E7",
      "isPlatformBinary" : 0
    },
    "path" : "/Library/UnionCrypto/unioncryptoupdater",
    "pid" : 3463
  },
  "timestamp" : "2019-12-05 20:14:28 +0000"
}

尽管安装启动守护程序需要root权限，但安装程序将提示用户输入其凭据：

安装程序完成后，二进制的unioncryptoupdater将执行并永久安装：

$ ps aux | grep  [u]nioncryptoupdater
root  1254  /Library/UnionCrypto/unioncryptoupdater

当然，BlockBlock会检测启动守护进程的持久性尝试：

如前所述，持久性是通过vip.unioncrypto.plist启动守护程序实现的：

由于RunAtLoad项被设置为true时，将指示macOS每次重新启动受感染的系统时自动启动ProgramArguments数组中指定的二进制文件。因此，/Library/UnionCrypto/unioncryptoupdater将自动重新执行。

重新安装启动守护程序（其plist和二进制文件都隐藏在应用程序的资源目录中），再次与Lazarus组的操作方式匹配。具体请见卡巴斯基的报告：“ AppleJeus：Lazarus使用伪造的安装程序和macOS恶意程序盗窃加密货币。”

功能：第一阶段植入（内存模块加载器）

好了，现在来分析持久化的unioncryptoupdater二进制文件。

通过file命令，我们可以确定它是一个标准的macOS(64位)二进制：

$ file /Library/UnionCrypto/unioncryptoupdater 
/Library/UnionCrypto/unioncryptoupdater: Mach-O 64-bit executable x86_64

codesign实用程序向我们显示了它的标识符（macloader-55554944ee2cb96a1f5132ce8788c3fe0dfe7392）以及未使用有效的代码签名ID进行签名的事实，而是使用了adhoc (Signature=adhoc)：

$ codesign -dvv /Library/UnionCrypto/unioncryptoupdater 
Executable=/Library/UnionCrypto/unioncryptoupdater
Identifier=macloader-55554944ee2cb96a1f5132ce8788c3fe0dfe7392
Format=Mach-O thin (x86_64)
CodeDirectory v=20100 size=739 flags=0x2(adhoc) hashes=15+5 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=0 size=12

运行字符串实用程序（带有-a标志）将显示一些有趣的字符串：

$ strings -a /Library/UnionCrypto/unioncryptoupdater 

curl_easy_perform() failed: %s
AES_CYPHER_128 encrypt test case:
AES_CYPHER_128 decrypt test case:
AES_CYPHER_192 encrypt test case:
AES_CYPHER_192 decrypt test case:
AES_CYPHER_256 encrypt test case:
AES_CYPHER_256 decrypt test case:
Input:
IOPlatformExpertDevice
IOPlatformSerialNumber
/System/Library/CoreServices/SystemVersion.plist
ProductVersion
ProductBuildVersion
Mac OS X %s (%s)
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
/tmp/updater
%s %s
NO_ID
%s%s
12GWAPCT1F0I1S14
auth_timestamp
auth_signature
check
https://unioncrypto.vip/update
done
/bin/rcp
Could not create image.
Could not link image.
Could not find ec.
Could not resolve symbol: _sym[25] == 0x4d6d6f72.
Could not resolve symbol: _sym[4] == 0x4d6b6e69.

诸如IOPlatformSerialNumber之类的字符串以及对SystemVersion.plist的引用可能暗示了基本的调查功能，比如收集有关受感染系统的信息，对libcurl API（curl_easy_perform）和嵌入式URL的引用表明可能含有网络或命令和控制功能。

在反汇编器中打开一个二进制文件（unioncryptoupdater），显示主函数简单地调用一个名为onRun的函数：

1int _main() {
2    rbx = objc_autoreleasePoolPush();
3    
4    onRun();
5    
6    objc_autoreleasePoolPop(rbx);
7    return 0x0;
8}

虽然很长、很复杂，但我们可以分析它的逻辑，过程分6步：

1.实例化一个名为Barbeque: Barbeque::Barbeque()的c++类，通过将nm实用程序的输出传递到c ++ filt中，我们可以从Barbeque类中转储其他方法：

$ nm unioncryptoupdater | c++filt

unsigned short Barbeque::Barbeque()
unsigned short Barbeque::get( ... )
unsigned short Barbeque::post( ... )
unsigned short Barbeque::~Barbeque()

根据方法名称，也许Barbeque类包含与网络相关的逻辑。

2.调用一个名为getDeviceSerial的函数，通过IOKit (IOPlatformSerialNumber)检索系统序列号：

调试恶意软件(在VM中)，显示此方法正确返回虚拟机的序列号(VM+nL/ueNmNG)：

(lldb) x/s $rax
0x7ffeefbff810: "VM+nL/ueNmNG"

3.通过读取系统文件/System/Library/CoreServices/SystemVersion.plist（包含各种与版本有关的信息），调用名为getOSVersion的函数以检索系统版本：

$ defaults read /System/Library/CoreServices/SystemVersion.plist
{
    ProductBuildVersion = 18F132;
    ProductCopyright = "1983-2019 Apple Inc.";
    ProductName = "Mac OS X";
    ProductUserVisibleVersion = "10.14.5";
    ProductVersion = "10.14.5";
    iOSSupportVersion = "12.3";
}

同样，在调试器中，我们可以观察到恶意软件正在检索这些信息，特别是ProductName、ProductUserVisibleVersion和ProductBuildVersion：

(lldb) x/s 0x7ffeefbff790
0x7ffeefbff790: "Mac OS X 10.14.5 (18F132)"

4.构建一个由时间和硬编码值组成的字符串：12GWAPCT1F0I1S14；

5.调用Barbeque :: post（）方法以联系远程命令和控制服务器（https://unioncrypto.vip/update）：网络逻辑通过libcurl来执行实际的通信：

防火墙LuLu可以轻松检测到此连接尝试：

6.如果服务器使用字符串“ 0”响应，则恶意程序将休眠10分钟，然后再次通过服务器重启：

否则，它将调用base64解码服务器的响应的函数，然后调用名一个为processUpdate的函数来执行从服务器下载的有效载荷。

好的，我们已经有了一个相当标准的持久性第一阶段植入载荷，它将信标发送到远程服务器，以便（可能）实现第二阶段全功能植入载荷。

这时，远程命令和控制服务器仍处于联机状态，它只响应一个“0”，这意味着没有提供有效载荷。

因此，在其余的分析中，我们必须依靠静态分析方法。

但是，第一阶段的植入的特别之处在于：含有直接从内存执行接收到的有效载荷的能力！

那该恶意程序如何实现这种隐身功能？

回想一下，如果服务器以有效载荷（而不是字符串“0”）响应，则恶意程序将调用processUpdate函数。首先，processUpdate通过aes_decrypt_cbc解密所述有效载荷，然后调用一个名为load_from_memory的函数。

首先，load_from_memory函数映射一些内存（带有保护：PROT_READ | PROT_WRITE | PROT_EXEC）。然后，在调用名为memory_exec2的函数之前，将解密后的有效载荷复制到此内存区域中：

memory_exec2函数调用Apple API NSCreateObjectFileImageFromMemory，来从mach-O文件的内存缓冲区创建“目标文件映像”。之后，将调用NSLinkModule方法来链接“目标文件映像”。

由于内存中的进程映像的布局与磁盘中的映像不同，所以不能简单地将文件复制到内存中并直接执行它。相反，必须调用NSCreateObjectFileImageFromMemory和NSLinkModule等API（它们负责准备内存中的映射和链接）。

一旦恶意程序映射并链接了下载的有效载荷，它就会调用一个名为find_macho的函数，该函数似乎在内存映射中搜索MH_MAGIC_64，mach_header_64结构（0xfeedfacf）中的64位“mach magic number”：

一旦find_macho方法返回，恶意程序便开始解析内存中的mach-O文件，它似乎正在寻找LC_MAIN加载命令（0x80000028）的地址：

有关解析mach-O文件的深入技术讨论，请参阅：“解析Mach-O文件”。

LC_MAIN加载命令包含诸如mach-O二进制文件的入口点之类的信息，例如，unioncryptoupdater二进制文件的偏移量18177：

然后，恶意程序检索入口点的偏移量（在LC_MAIN load命令中的偏移量0x8处找到），设置一些参数，然后跳转到该地址：

此时，内存中已经开始执行远程下载的有效载荷！

在2015年的BlackHat大会上，我讨论了这种内存中文件执行方法，该方法可增加隐身性并使取证复杂化。

不出所料，它终于出现在macOS恶意程序中了。

有关在macOS中执行内存中代码的更多详细信息，请参阅：

1.从内存运行macOS上的可执行文件；

2.苹果的“ MemoryBasedBundle ”示例代码；

如果你想基于此方法处理Mach-O的内存中加载，我可以编写一个简单的PoC：https：//t.co/IP3JhRyf7h，只需运行make即可。

前#OBTS发言人Felix Seele（@ c1truz_ ）指出，著名的InstallCore恶意程序还使用了NSCreateObjectFileImageFromFromMemory和NSLinkModule API来实现内存中执行。

有趣的是，如果内存中的代码执行失败，则该恶意程序具有一个“备份”计划。具体来说，如果load_from_memory不返回0，则代表成功，它将把接收到的有效载荷写到/ tmp / updater，然后通过调用系统来执行：

这几篇文章对2019年新出现的Mac恶意程序进行了全面技术分析，但是，如前所述，我们没有涵盖前几年出现的恶意程序。

本文翻译自：https://objective-see.com/blog/blog_0x53.html如若转载，请注明原文地址

分享至

感谢您的支持，我会继续努力的!

打开微信扫一扫后点击右上角即可分享哟

对2019全年的Mac恶意程序的全面分析（Lazarus Loader ）

发表评论

你可能感兴趣的