Onderzoekers waarschuwen voor een nieuwe variant van PamStealer op macOS. In deze versie wordt de kernpayload niet langer “lokaal” op de machine terug te halen zodra je sampleanalyse doet. In plaats daarvan is serverhulp nodig: pas na een live decryptieketen en een server-side key exchange kan de payload worden ontpakt.
Dat verandert de manier waarop securityteams malware kunnen onderzoeken en offline kunnen ontleden. Tegelijk zien we dat de misleiding is aangepast: slachtoffers worden nu gelokt via een nepwebsite voor een zogenoemde cryptocurrencywallet, waarna een disk image en AppleScript het startpunt vormen.
Server-side decryptie maakt analyse lastiger
Waar eerdere PamStealer-varianten payloadinformatie in de JXA-dropper (JavaScript for Automation) leken te verwerken, verschuift de nieuwe aanpak naar een model waarin de server de sleutelrol speelt. In de recent onderzochte variant wordt een decryption utility opgehaald die de payload pas kan ontpakken nadat de malware een key exchange met de server afrondt.
Het belangrijkste gevolg: zonder de samenwerking van het command-and-control (C2)-systeem kan de payload niet “statisch” worden teruggewonnen. Bovendien wordt tijdens elke uitvoering een nieuw (ephemeral) keypair gegenereerd, waardoor het vastleggen van een data-encryption key (DEK) niet zomaar opnieuw te gebruiken is om de inhoud later alsnog te ontleden.
Voor incident response betekent dit dat het verzamelen en nabootsen van de juiste sessiestromen (in een gecontroleerde omgeving) belangrijker wordt. Los “payloadextractie” uit een sample is in deze variant minder vaak voldoende.
Nieuwe lokkende pagina en aangepaste delivery
De onderzoekers beschrijven dat de lokpagina is gewijzigd. Eerdere observaties zagen slachtoffers gelokt worden met fake websites die zich voordeden als tools zoals Maccy, Scoppr en Nancy Clipboard. In de nieuwe variant draait het om een ander webadres: wavel[.]app, dat een niet-bestaande cryptocurrencywalletdienst met de naam Wavel promoot.
Wanneer gebruikers op de knop “Download for macOS” klikken, krijgt de gebruiker een disk image met de bestandsnaam Wavel.dmg voorgezet. Het openen daarvan start een proces dat in Script Editor (de ingebouwde Apple-tool) uitkomt en vervolgens instructies geeft om een JXA-dropper uit te voeren.
Daarmee blijft de keten in grote lijnen dezelfde familie: JXA initieert, maar de inhoud en flow zijn aangepast om de server-side decryptie mogelijk te maken.
JXA als drager: van embedded key naar keten
Een opvallend detail is hoe de JXA-laag in deze variant wordt gebruikt. In eerdere versies deed de JXA-bron onder andere decryptiehandelingen via een ingebedde aanpak. In deze Wavel-route bevat de JXA-bron juist geen componenten die nodig zijn om de payload lokaal te ontcijferen.
De onderzoekers beschrijven dat de JXA-laag een base64-string decodeert en vervolgens de decoded output doorgeeft aan /bin/zsh via zsh -s. De JXA-processen stoppen daarna al snel, terwijl de volgende fase op de achtergrond doorloopt.
De zsh-dropper zet vervolgens de “opbouwfase” in gang, waaronder het downloaden en aanroepen van de pkgunpack-utility, het uitvoeren van een X25519 key exchange, en het decrypten en klaarzetten van een payloadbundle.
Persistentiemechanismen: stil blijven draaien
Naast de decryptieketen werkt de malware hard aan persistentie. De keten bevat maatregelen om meldingen op macOS te onderdrukken zodra er een nieuw background login item wordt toegevoegd. Vervolgens worden vier herhaalde/“redundant” persistentiemechanismen geïnstalleerd via LaunchAgent en aanvullende scripts.
Een kernonderdeel is een repair-script dat gecontroleerd opnieuw wordt uitgevoerd en ontbrekende onderdelen terugzet. Daar bovenop wordt er een shell hook toegevoegd aan ~/.zshrc: op elke nieuwe interactieve zsh-sessie wordt de repair-logica getriggerd.
De herstelroutine krijgt extra stealth doordat deze kopieën worden geplaatst in Git hooks-mappen onder ~/Library/Application Support/System/.githooks/. Concreet gaat het om locaties als post-checkout en pre-commit. Wanneer de malware bovendien de Git-configuratie wijzigt met git config –global core.hooksPath, wordt de repair-scriptfunctie bij elke relevante git-actie in omgevingen op de besmette machine stil geactiveerd.
Dat betekent: zelfs als een gebruiker zich niet bewust is van extra LaunchAgents of achtergronditems, kan het systeem zichzelf blijven herstellen via routinegebruik (zoals checkout/commit) binnen ontwikkelprojecten.
Van Rust naar Swift: de diefstalfase
In de laatste stap komt de stealer-component naar voren. Deze is in de nieuwe variant geschreven in Swift, waar eerder genoemde versies nog leunden op een voorganger in Rust. Hoewel de implementatietaal verschuift, blijft het einddoel gelijk: het verzamelen van gevoelige gegevens.
De onderzoekers noemen onder meer:
- Het proberen te bemachtigen van een systeemeigen wachtwoord via een nep crashdialoog en validatie-aanpak op basis van PAM-achtige controle.
- Het enumereren en ophalen van keychain-items.
- Het stelen van inloggegevens uit Chromium- en Firefox-achtige browsers, waaronder onder meer Google Chrome, Microsoft Edge, Mozilla Firefox, Brave, Vivaldi, Opera en verschillende varianten/regionale browsers.
- Het fingerprinten van het systeem en het verzamelen van uitgebreide metadata, plus het ophalen van een gebruikersprofielfoto.
- Het verzamelen van user-specifieke bestanden zoals .zsh_history, .zshrc, .bash_history en .gitconfig.
- Het inventariseren van actieve processen en geïnstalleerde applicaties.
Het opnemen van relatief minder “standaard” browsers vergroot volgens de onderzoekers het bereik ten opzichte van wat je vaak ziet bij meer commodity macOS stealers.
Wat betekent dit voor verdediging?
Omdat PamStealer op macOS de payload decryptie afhankelijk maakt van live C2-samenwerking, verschuift de verdedigingsfocus deels. Je kunt nog steeds incidenten herkennen op gedrag (processen, netwerkactiviteit en persistentiemechanismen), maar “offline reverse engineering” van de payload kan lastiger worden.
Praktisch helpt het om te letten op signalen rondom:
- Script Editor en JXA-gedreven execution-ketens die kort daarna zsh vervolgstappen starten.
- Downloadgedrag richting decryption utility domeinen en verdere staging.
- LaunchAgent- of background login item wijzigingen en het onderdrukken van macOS-notificaties.
- Wijzigingen in Git hooks-paths (zoals core.hooksPath) en het verschijnen van scripts in githooks-mappen.
- Gebruik van stage directories in ZIP-vormen en het uploaden van die staging content richting een server.
Wil je daarnaast context rond aanvallen waarbij malware zich door runtime of ketens blijft aanpassen, dan is dit mogelijk ook relevant: agentic remediation en de CTEM-cyclus met AI. Dat artikel gaat weliswaar breder over detectie en respons, maar sluit aan op het idee dat je sneller wilt schakelen zodra je te maken hebt met dynamische aanvalsketens.
En als je vooral kijkt naar hoe aanvallers met tooling en infrastructuur hun werk “operationeel” maken, dan biedt een overzicht van cyberdreigingen nuttige achtergrond over de voortdurende verschuiving naar effectiviteit in echte aanvallen.
Conclusie
De nieuwste variant maakt duidelijk dat PamStealer op macOS verder evolueert richting een ontwerp waarbij payloaddecryption afhankelijk is van serverhulp. Door een server-side decryptieketen, een key exchange met ephemeral sleutels en meerdere persistentiemechanismen wordt het voor verdedigers lastiger om de kerninhoud los van een live sessie te analyseren.
Tegelijk biedt de gewijzigde delivery—met wavel[.]app, Wavel.dmg en Script Editor—gerichte aanknopingspunten om vroeg te detecteren en de schade te beperken. Wie macOS-systemen beheert, doet er daarom goed aan om zowel technische sporen (processen, scripts, keychain) als persistentiemechanismen (LaunchAgent en Git hooks) structureel te monitoren.
Bron: https://thehackernews.com/2026/09/pamstealer-macos-malware-adds-live-c2.html
