## L'opération cloud clandestine de PCPJack mise au jour L'acteur malveillant connu sous le nom de **PCPJack** a orchestré une campagne sophistiquée, détournant des serveurs cloud sur **Amazon Web Services (AWS)**, **Google Cloud** et **Microsoft Azure** pour forger un réseau de relais d'e-mails SMTP massif et clandestin. Cette infrastructure étendue a silencieusement converti des serveurs d'entreprise compromis aux États-Unis, en Europe et en Asie en proxys SMTP, qui ont ensuite été vérifiés pour leurs capacités de relais de messagerie et synchronisés avec un consommateur en aval toutes les cinq minutes. La société d'intelligence sur les menaces **Hunt.io** a découvert l'opération, notant que l'infrastructure était toujours pleinement active lors de la découverte. « Des serveurs d'entreprise compromis aux États-Unis, en Europe et en Asie ont été silencieusement convertis en proxys SMTP, vérifiés pour leur capacité de relais de messagerie et synchronisés avec un consommateur en aval toutes les cinq minutes », a déclaré **Hunt.io**. « L'infrastructure était toujours en cours d'exécution lorsque nous l'avons trouvée. »  ## Découverte fortuite : un serveur C2 ouvert révèle les tactiques Les détails complexes de la campagne de **PCPJack** ont été révélés en raison d'une faille critique en matière de sécurité opérationnelle. L'acteur malveillant a laissé deux répertoires ouverts sur un serveur de commande et de contrôle (C2) (213.136.80[.]73) sans aucune authentification. Cet oubli a permis à **Hunt.io** d'accéder au code source, aux binaires compilés, aux journaux d'état de déploiement, aux scanners Internet, aux outils d'exploitation et à une configuration **Sliver** active. **PCPJack** est apparu pour la première fois en avril 2026, identifié par **SentinelOne** comme un framework de vol d'informations d'identification ciblant spécifiquement les services cloud. Notamment, **PCPJack** prend également des mesures pour supprimer les artefacts associés à **TeamPCP**, un autre groupe de piratage proéminent connu pour ses attaques de chaîne d'approvisionnement logicielle, suggérant soit une rivalité, soit une tentative d'obscurcir son identité. ## Outils du métier : Sliver, Chisel et scripts personnalisés Parmi les fichiers découverts dans les répertoires ouverts se trouvait une trousse à outils de déploiement de proxy SMTP intégrée à **Sliver**. Cette trousse comprenait des binaires de tunneling et de proxy **Chisel**, compilés pour diverses architectures CPU Linux telles que AMD64, ARM64 et x86. Sur les machines victimes, le binaire est discrètement déposé sous forme de fichier caché préfixé par un point et persisté dans « /var/tmp/.xs ». Des scripts de déploiement ont également été trouvés, conçus pour charger la configuration du client C2 **Sliver** et filtrer les beacons Linux. Ces beacons sont des implants qui se connectent périodiquement au serveur C2 pour s'enregistrer et récupérer des commandes. ## Gestion sophistiquée des proxys L'opération démontre des capacités avancées de gestion de proxys. « Chaque beacon reçoit un port proxy SOCKS5 dérivé de manière déterministe d'un hachage MD5 de son UUID **Sliver**, mappé dans la plage 10000-14999 », a expliqué **Hunt.io**. « Le même beacon est toujours mappé au même port entre les exécutions, éliminant ainsi le besoin d'un registre de ports partagé. »  Un composant crucial du script de déploiement est une « porte de qualité » SMTP. Cette porte sonde l'accès sortant à `smtp.gmail[.]com:587`. Les hôtes qui échouent à cette vérification sont ignorés, car « les hôtes qui ne peuvent pas relayer d'e-mails n'ont aucune valeur pour ce pipeline », selon la société de cybersécurité. Les beacons sont traités par lots de 50, avec des délais chronométrés pour tenir compte des intervalles d'enregistrement lents. ## Évolution des tactiques et capacités de diagnostic Les itérations ultérieures des scripts de déploiement montrent une évolution, avec la suppression de la porte SMTP et de la logique de traitement par lots. De plus, un script de diagnostic était présent, conçu pour sélectionner cinq beacons actifs et leur assigner des commandes shell pour vérifier : * La présence des binaires **Chisel** aux chemins de dépôt connus * Qu'un processus **Chisel** est activement en cours d'exécution * L'espace disque disponible * L'accessibilité du port 9000 sur le C2 * La présence d'artefacts de persistance, tels que des entrées cron ou des services systemd  Le serveur C2 exécute également un script Python, `chisel_verifier.py`, en tant que démon d'arrière-plan persistant. Ce script énumère les ports de tunnel **Chisel** actifs via `ss -tlnp` toutes les 60 secondes, les teste pour leur capacité SMTP et supprime tout tunnel échoué ou abandonné du pool actif. ## Enrichissement des proxys et motif inconnu Les proxys vérifiés sont enrichis de données sur l'adresse IP de sortie, le pays et le numéro de système autonome (**ASN**) à l'aide de services tels que `api.ipify[.]org` et `ip-api[.]com`. Ces listes de proxys affinées sont ensuite synchronisées toutes les cinq minutes via **Secure Copy Protocol (SCP)** vers un serveur en aval distinct (38.242.204[.]245), bien que ce serveur soit actuellement inaccessible. Le but ultime de cette opération étendue reste flou. **Hunt.io** l'a décrite comme une campagne opportuniste, déclarant : « Le résultat de 230 nœuds est le résultat observable. Que cette progression reflète un seul opérateur en cours d'itération ou plusieurs acteurs partageant la même infrastructure ne peut être déterminé à partir des fichiers récupérés. » Quelle que soit l'intention spécifique, les implications sont importantes. « La liste des proxys vérifiés est synchronisée toutes les cinq minutes vers ce serveur, et quelqu'un la consomme. Que ce soit pour du spam, du phishing ou autre chose, l'infrastructure pour délivrer à grande échelle était clairement en cours d'exécution. »