Le logiciel 3CX a subi une attaque par supplychain. Ce logiciel est utilisé par de nombreuses entreprises pour leur téléphonie. Il s’installe sur les postes de travail Windows, MacOs et Android.
Le but de cet article n’est pas tant d’analyser l’attaque par elle-même et le malware déployé puisque cela a été très bien fait par Volexity https://www.volexity.com/blog/2023/03/30/3cx-supply-chain-compromise-leads-to-iconic-incident/
et une bonne infographie de Thomas Roccia https://twitter.com/fr0gger_/status/1641668394155151366?s=20 est également disponible, mais d’expliquer les impacts d’une telle attaque.
Petits rappel des faits.
Le processus de mise à jour a été compromis par un groupe d’attaquant. Le but est lorsque le logiciel 3CX va faire sa mise à jour, il va installer en plus une dll malveillante qu’il va charger. L’impact est direct puisque l’attaquant à la main sur l’ensemble des machines dont la mise à jour a été faite.
Dans notre cas, c’est la dll ffmpeg.dll qui va être installée.
Ensuite comme l’explique Volexity, la dll télécharge après son chargement un fichier hosté sur github qui est encodé en base64 et chiffré en AES. Ce fichier a des urls ou le malware va être téléchargé.
Le stealer lui-même
On a d’abord parlé de stealer mais le malware est plus un outil de reconnaissance. En effet, au vu du nombre d’utilisateurs de 3CX (12 millions), l’attaquant a cette technique de pêche au chalut, va devoir trier. Pour cela, il se base sur les informations remontées sur le C2 dans un fichier json ainsi que la GUID de la machine qui passe dans les headers HTTPs. Si la machine l’intéresse, il va maintenir le C2.
Autre impact fort, mis en avant par Volexity, est un chargeur de shellcode. Ce qui veut dire qu’une fois, le malware exécuté, il peut charger ce qu’il veut comme code. Et surtout faire cela uniquement en mémoire. Cela sera donc plus difficile aux équipes de réponses sur incident et aux analystes de savoir ce que souhaite réellement l’attaquant.
L’attribution à la nord Corée
L’attaque a été attribuée par Lazarus. Cette attribution se base sur le shellcode et la clé AES utilisée. Cela peut faire un peu court pour plusieurs raisons :
- Le kit peut avoir été acheté.
- Les attaquants ont pu délibérément utiliser des clés et des shellcode connus pour faire un false flag.
Les prochains jours/mois permettront peut-être d’avoir plus de détails sur cette attaque
Une chose est certaine, si l’on regarde la timeline complète de l’attaque, notamment chez Sentinel One https://www.sentinelone.com/blog/smoothoperator-ongoing-campaign-trojanizes-3cx-software-in-software-supply-chain-attack/
L’infrastructure est là depuis février 2022.
Les premiers déploiements de la version backdoorés est 22 mars 2023.
Et certains artefacts comme des dates de compilation remontent à janvier 2023. https://twitter.com/Hexacorn/status/1641465612386856970?s=20
L’attaque est donc préparée de longue date par un acteur sachant exactement ce qu’il fait.
Update par Seongsu Park
