SCPJack transforme le cloud public en un réseau de relais SMTP pour le spam de masse

L'opération attribuée à l'acteur connu comme PCPJack révèle une tendance inquiétante: l'abus systématique des infrastructures publiques de cloud - Amazon Web Services, Google Cloud et Microsoft Azure - pour transformer les machines légitimes en un réseau caché de relais SMTP. Des chercheurs en sécurité qui ont analysé des répertoires ouverts sur un serveur de commande et de contrôle ont découvert des outils de déploiement, des binaires de tunnel et une intégration offensive de cadres qui vous permettent de convertir des serveurs compromis en proxies de courrier utilisables à l'échelle.

Le modus operandi comprend la chute d'un binaire persistant chez les victimes, les techniques de balayage et de vérification automatiques SMTP (test smtp.gmail [.] com: 587) et un mécanisme de synchronisation fréquente des listes de proxy vérifiées vers les serveurs en aval. Parmi les outils identifiés sont Sliver, un cadre post-exploitation avec dépôt public https: / / github.com / BishopFox / slide, et Chisel, une utilité de tunnels qui facilite la création de canaux inversés entre hôtes https: / / github.com / jpillora / sisel. En plus de révéler des artefacts techniques, le constat confirme comment les attaquants peuvent orchestrer une plate-forme de distribution de masse ou d'évasion, sans dépendre de leur propre infrastructure visible.

Les implications sont multiples. Tout d'abord, la conversion de serveurs cloud en relais SMTP permet d'éviter les listes noires et les contrôles de réputation, permettant des campagnes de spam, phishing ou la distribution de charges malveillantes avec une plus grande chance de livraison. Deuxièmement, l'abus des fournisseurs de cloud présente un risque pour des tiers: les clients légitimes peuvent subir des dommages de réputation si leurs ressources sont utilisées pour des activités illicites. Enfin, la preuve indique une campagne opportuniste qui exploite des qualifications et des configurations faibles, ce qui souligne l'importance de la gouvernance dans les identités et le contrôle d'évacuation dans les environnements nuageux.

Du point de vue de la détection, les artefacts observés offrent des pistes activables : processus tunnel et binaires (Chisel) écoute dans des ports dérivés d'identificateurs d'implantation, services persistants installés sur des itinéraires temporaires tels que / var / tmp avec des noms cachés, et scripts qui listent les sockets avec ss-tlnp pour vérifier les proxies. Les équipes de sécurité devraient hiérarchiser la recherche de ces indicateurs dans leur inventaire des cas et des dossiers de réseau, et suivre les synchronisations inhabituelles de SCP vers des adresses externes.

Pour réduire la surface d'attaque, les organisations de cloud doivent appliquer des contrôles d'accès stricts : forcer l'authentification multifactorielle, faire pivoter et vérifier les clés et les références de service, appliquer le principe de moins de privilège dans les rôles et les identités, et limiter l'évacuation par des groupes de sécurité, des pare-feu VPC ou des politiques de sortie qui limitent le trafic SMTP uniquement aux fournisseurs autorisés. Les guides officiels des bonnes pratiques en matière de cloud fournissent des cadres utiles pour ces mesures. https: / / docs.aws.amazon.com / livres blancs / derniers / aws-security-best-pratiques /.

Dans les incidents actifs, la réponse devrait combiner confinement et criminalistique : isoler les cas commis sans les éliminer immédiatement pour préserver les preuves, capturer des images et des spins de mémoire, recueillir des artefacts dans des répertoires temporaires et des entrées cron / systemd, et analyser les dossiers d'accès et les journaux d'audit CloudTrail / AzureActivity / Cloud pour les chaînes d'engagement. Informer le fournisseur de cloud et l'équipement d'abus et, si nécessaire, le CERT et les forces de sécurité permettront la coordination des remèdes et le retrait éventuel de l'infrastructure malveillante.

L'équipement de protection du courrier électronique a également un rôle clé à jouer. La mise en œuvre et le renforcement du SPF, du DKIM et du DMARC contribuent à atténuer l'impact des campagnes utilisant des relais externes; en même temps, les passerelles de courrier et les filtres antiphishing doivent être configurés pour détecter des augmentations de volume inhabituelles et des modes d'expédition atypiques. Pour les services internes nécessitant du courrier, il convient de centraliser le trafic SMTP par l'intermédiaire de fournisseurs gérés et de bloquer les ports de sortie 25 / 587 / 465 avec des exceptions justifiées.

Cette opération rappelle que la sécurité du cloud n'est pas seulement la responsabilité du fournisseur : l'interaction entre les configurations faibles, la gestion des références et le contrôle inadéquat crée des opportunités pour des acteurs tels que PCPJack pour mettre en place des infrastructures abusives. La détection précoce dépend à la fois de la surveillance de l'intégrité des paramètres et de l'analyse du comportement du réseau et du trafic de sortie.

Enfin, la communauté doit maintenir une approche collaborative : partager des indicateurs avec les réseaux d'échange de renseignements, signaler les serveurs engagés aux canaux d'abus des fournisseurs de cloud et tenir les règles de détection à jour dans les outils EDR/IDS. Une approche proactive et coordonnée réduit le champ des abus et rend difficile l'échelle des campagnes opportunistes sans être détectée.