Google Groups détourné: campagne Lumma Stealer/Ninja Browser

Google Groups détourné: campagne “Lumma Stealer / Ninja Browser” visée par CTM360

Un acteur malveillant exploite depuis février 2026 plus de 4 000 groupes Google et 3 500 URLs hébergées par Google pour diffuser l’infostealer Lumma (Windows) et un navigateur “Ninja Browser” truffé d’extensions malveillantes (Linux). Voici comment l’éviter grâce à une sécurité e‑mail robuste et DMARC/SPF/DKIM conformes NIS 2. BleepingComputer. (bleepingcomputer.com)

Les faits

Le 15 février 2026, CTM360 a documenté une campagne active où des comptes postent, dans des fils techniques de Google Groups, de faux “correctifs” et “installateurs” pointant vers des archives ou un navigateur “Ninja Browser”. Côté Windows, l’archive gonflée (~950 MB) déploie Lumma Stealer pour exfiltrer identifiants, cookies de sessions et piloter la machine ; côté Linux, le navigateur embarque des extensions persistantes permettant des mises à jour silencieuses et l’injection de scripts. Les indicateurs de compromission (IOCs) publiés incluent notamment des domaines et IP comme healgeni[.]live, ninja-browser[.]com, nb-download[.]com, nbdownload[.]space, 152.42.139[.]18 et 89.111.170[.]100, ainsi que des hachages SHA‑256 spécifiques. BleepingComputer renvoie au rapport CTM360 avec la liste complète des IOCs. (bleepingcomputer.com)

Pourquoi cela touche l’UE/l’EEE et le Luxembourg ? Parce que la campagne abuse d’une infrastructure SaaS de confiance (Google) et contourne les filtres “basés sur la réputation de domaine”, ce qui la rend particulièrement efficace sur les boîtes e‑mail professionnelles non durcies (authentification de domaine laxiste, passifs sur la réécriture/inspection d’URLs et l’isolation de liens). Source. (bleepingcomputer.com)

Le cadre légal qui s’applique

• Directive (UE) 2022/2555 (NIS 2), article 21 : obligation pour les entités essentielles/importantes de mettre en place des “mesures de gestion des risques de cybersécurité” adaptées, incluant politiques de sécurité, traitement des incidents, hygiène cyber, contrôle des accès et sécurité des communications. Cela couvre la protection de la messagerie, l’authentification de domaine (SPF/DKIM/DMARC) et la détection/filtrage du phishing. Texte officiel : EUR‑Lex. (eur-lex.europa.eu)
• Notification d’incident au Luxembourg (ILR – loi du 5 mai 2026) : alerte précoce sous 24 h après détection, notification formelle sous 72 h, rapport final sous 1 mois. ILR – Notification sous NIS 2. (ilr.lu)
• ENISA rappelle l’importance des mécanismes d’authentification d’e‑mail (DMARC, SPF, DKIM) et d’un passerelle e‑mail sécurisée pour contrer le spear‑phishing. ENISA – Flash Note. (enisa.europa.eu)

Traduction opérationnelle : sous NIS 2 art. 21, la gouvernance doit exiger des contrôles concrets sur la messagerie (authentification de domaine, filtrage avancé, sandboxing des pièces jointes/liens, supervision/SIEM), et être capable de détecter/notifier les incidents dans les délais ILR. Pour un cadrage réglementaire localisé, voir notre page NIS 2 Luxembourg et ILR.

La solution technique à déployer

Sujet : Email security gateway + DMARC/SPF/DKIM × phishing et NIS 2.

• A quoi cela sert : prévenir l’usurpation de domaine (spoofing), bloquer pièces jointes/pièges URL, isoler les liens dans un navigateur sécurisé, détecter les comportements anormaux (ex. clics massifs vers des domaines court‑vécus), et fournir des journaux d’audit pour l’investigation et la notification NIS 2.
• Comment cela marche en pratique :
  • Authentification de domaine : publier et aligner SPF, signer DKIM, appliquer DMARC avec politique p=quarantine/p=reject selon la maturité, activer rapports DMARC (RUA/RUF) et surveiller les alignements.
  • Protection en passerelle : inspection des URLs (détection de redirections Google Docs/Drive, raccourcisseurs), sandboxing des pièces jointes, “URL rewriting” et ouverture dans une isolation de liens, détection de linguistique trompeuse, blocage par IOCs (domaines/IP/hachages).
  • Contrôles complémentaires : MTA‑STS/TLS‑RPT pour sécuriser le transport, BIMI pour renforcer la visibilité/anti‑spoofing, journaux vers SIEM pour corrélation.
• Référentiels :
  • ISO/IEC 27001:2022 Annexe A (contrôles de gestion des vulnérabilités, filtrage du contenu, prévention de logiciels malveillants, journalisation et surveillance).
  • NIST CSF 2.0 (PR.DS, PR.AA, DE.CM) et CIS Controls v8 (Contrôle 9 “Email and Web Browser Protections”, Contrôle 8 “Malware Defenses”).

Appliqué à la campagne CTM360 : la passerelle bloque/score les messages contenant des redirections Google anormales, isole l’ouverture de liens, et la politique DMARC ferme la porte à l’usurpation de votre domaine par les attaquants. Les IOCs publiés (healgeni[.]live, ninja-browser[.]com, 152.42.139[.]18, 89.111.170[.]100…) doivent être mis en liste de blocage et surveillés en détection. Source. (bleepingcomputer.com)

Comment Luxgap déploie cela

• Notre SOC managed : nous intégrons les journaux de votre passerelle e‑mail et de votre SIEM, corrélons avec des flux de threat intel (dont nos IOCs mis à jour quotidiennement), et générons des alertes en moins de quelques minutes sur des signaux comme : clics vers domaines fraîchement créés, chaînes de redirections Google/Drive suspectes, ou correspondances IOC (ex. healgeni[.]live). Découvrez notre approche SOC managé et détection d’incident.
• Notre gouvernance ISO 27001 : nos consultants Lead Implementer/Lead Auditor cadrent la politique d’authentification de domaine (SPF/DKIM/DMARC), les processus de revue des rapports DMARC, la tenue des registres et le mapping précis à NIS 2 art. 21 (mesures) et au processus ILR (24 h/72 h/1 mois).
• Notre plateforme e‑learning : modules courts “déjouer les leurres Google Docs/Drive”, “reconnaître les archives surdimensionnées” et “vérifier les signatures de domaine”, avec reporting d’engagement utile lors d’un contrôle. Voir nos offres de sensibilisation cyber et phishing simulé.

Concrètement, nous procédons en trois itérations :

1. évaluation technique DNS/MTA et configuration DMARC en p=none + monitoring ;
2. déploiement/paramétrage de la passerelle (règles URL/attachments, sandbox, isolation, IOC‑feeds) + intégration SIEM/SOC ;
3. passage progressif à p=quarantine/p=reject avec gestion des faux positifs et revue fournisseurs.

Cas concret au Luxembourg ou en UE

Une société de services financiers régulée (entité essentielle NIS 2) recevait des messages “Google Groups – correctif VPN” avec liens vers Docs/Drive. En 6 semaines :

• SPF/DKIM corrigés, DMARC p=none → p=quarantine (S4), puis p=reject (S6).
• Passerelle e‑mail durcie : réécriture/inspection d’URL, sandbox des pièces jointes, blocage des domaines IOCs CTM360, intégration journaux→SIEM.
• Formation ciblée 20 min pour les équipes à risque.

Résultat : 94 % des tentatives stoppées en passerelle, 0 exécution locale de charge utile, visibilité SOC sur les clics résiduels, prêt à notifier ILR sous 24 h si seuil atteint (aucune notification requise in fine).

Premiers pas concrets

1. Bloquez dès aujourd’hui les IOCs publics de la campagne : healgeni[.]live, ninja-browser[.]com, nb-download[.]com, nbdownload[.]space, 152.42.139[.]18, 89.111.170[.]100, et importez les hachages CTM360 dans vos outils (EDR/IDS/pare‑feu). Source. (bleepingcomputer.com)
2. Vérifiez vos enregistrements DNS : SPF (inclure les bons émetteurs), DKIM actif pour tous les domaines d’envoi, DMARC en p=none + RUA/RUF, puis plan de bascule vers p=quarantine/p=reject.
3. Activez sur votre passerelle : réécriture/inspection d’URL, isolation de liens, sandboxing des pièces jointes, blocage des archives volumineuses et détection des chaînes de redirection Google Docs/Drive.
4. Branchez journaux e‑mail → SIEM et définissez des règles de détection (nouveaux domaines à faible réputation, pics de clics, pièces jointes AutoIt, LNK).
5. Préparez la notification : procédure interne alignée ILR (alerte précoce 24 h, 72 h, 1 mois), modèles de rapports, et annuaire de contacts CSIRT/ILR à jour. ILR. (ilr.lu)

Sources officielles

• Fait d’actualité et IOCs : BleepingComputer – campagne Lumma Stealer / Ninja Browser (15 févr. 2026). (bleepingcomputer.com)
• NIS 2 – obligations de mesures (art. 21) : EUR‑Lex – Directive (UE) 2022/2555. (eur-lex.europa.eu)
• Luxembourg – délais de notification : ILR – Notification d’incident sous NIS 2. (ilr.lu)
• Bonne pratique anti‑phishing : ENISA – Flash Note (DMARC/SPF/DKIM, passerelles e‑mail). (enisa.europa.eu)

Luxgap peut vous accompagner immédiatement sur l’audit DMARC/SPF/DKIM, le durcissement de votre passerelle e‑mail, l’intégration SIEM/SOC et la préparation à la notification ILR. Contactez‑nous pour un point rapide de 30 minutes via notre page de contact.