Un vendredi matin du mois d’avril 2026, une alerte remonte sur la console de supervision d’un de nos clients. Un rançongiciel vient d’être identifié sur le poste d’une salariée. En remontant la piste, nous découvrons que l’infection ne date pas du matin : elle date de la veille, 16h02. Elle a été déclenchée par un clic sur une publicité Google parfaitement légitime en apparence, lors d’une recherche scolaire tapée par la salariée pour aider son enfant à préparer un exposé.

Nous allons voir ensemble comment, en 38 secondes, un binaire signé numériquement par une « vraie » entreprise — passant trois barrières de confiance successives — a réussi à s’installer, exfiltrer des cookies de session, et masquer sa présence sous un vernis de légitimité parfaite.

1. Le contexte : un cabinet ordinaire

Le client concerné est un cabinet de gestion immobilière d’une quinzaine de collaborateurs dans les Alpes-Maritimes. Stack informatique classique pour une TPE : postes Windows 11, Microsoft 365 pour la bureautique et la messagerie, un logiciel métier sectoriel (gestion de baux, comptabilité immobilière, signatures électroniques), un firewall périmétrique géré par un prestataire réseau tiers, et un service de supervision cyber que nous assurons via un EDR comportemental déployé sur l’ensemble du parc.

Le poste concerné est celui d’une assistante-comptable qui l’utilise pour sa comptabilité client : saisie de baux, encaissements, reversements propriétaires, signatures électroniques de quittances. Un profil de risque élevé : elle manipule chaque jour des RIB, des adresses, des données fiscales, des coordonnées bancaires.

2. La chaîne d’attaque en 8 étapes

3. Les trois barrières de confiance franchies

Ce qui rend cet incident pédagogique, c’est qu’il n’a rien d’exotique. Le binaire malveillant a franchi trois contrôles légitimes successifs qui auraient dû — en théorie — alerter n’importe quel utilisateur ou système prudent.

4. Le malware décortiqué

Une fois quarantainé par l’EDR, nous avons pu récupérer le binaire et l’analyser à froid dans un environnement isolé. La structure du fichier révèle plusieurs techniques d’évasion remarquables.

Technique d’évasion n°1 : le padding Authenticode

Sur les 106,47 Mo du fichier, 105 Mo sont du padding injecté dans la section SECURITY (signature Authenticode). Le loader réel ne fait que 6 Mo. Cette technique sert à deux choses :

1. Dépasser la taille maximale scannée par certains antivirus passerelles (souvent 50 à 100 Mo), qui renoncent et laissent passer
2. Masquer le faible poids réel du code malveillant sous un vernis de « logiciel légitime pesant » cohérent avec un vrai convertisseur PDF professionnel

Technique d’évasion n°2 : l’installeur NSIS avec DLLs légitimes

Le fichier est un installeur NSIS (format d’installation Windows très répandu et légitime, utilisé par des milliers de logiciels commerciaux). Il embarque 4 DLLs dont 3 sont des plugins NSIS parfaitement légitimes :

• nsc.dll (NScurl) — plugin open-source qui permet à l’installeur de télécharger des fichiers via HTTPS
• ns7.dll (nsis7z) — plugin open-source qui permet d’extraire des archives 7-Zip
• nsDialogs.dll + System.dll — plugins NSIS standards

En combinant ces briques légitimes, l’installeur peut : télécharger un payload chiffré depuis un serveur distant, le décompresser, l’exécuter. Comme chaque brique est signée et connue, un antivirus classique n’a rien à redire.

Technique d’évasion n°3 : le loader caché dans la bannière

La 4e DLL, banner.dll, est la pièce maîtresse malveillante. En apparence, elle expose les trois fonctions standard d’un plugin NSIS qui affiche une bannière d’installation (destroy, getWindow, show). Mais :

• Sa taille est de 2,1 Mo, alors qu’une vraie banner.dll NSIS pèse environ 50 Ko — soit 40 fois plus
• Ses chaînes de caractères sont chiffrées par XOR, rendues illisibles à l’analyse statique
• Elle importe les APIs Windows CryptAcquireContextW, CryptCreateHash, CryptEncrypt — pour déchiffrer son propre payload en mémoire au moment de l’exécution

Technique d’évasion n°4 : la rotation permanente des payloads

Dans le cadre de l’audit, nous avons retenté le téléchargement du binaire malveillant via un canal anonymisé (réseau Tor), quelques heures après l’incident, à la même URL exacte. Surprise : le fichier servi n’était plus le même. Empreinte cryptographique différente, taille différente, comportement différent.

Au moment de notre ré-analyse, l’URL malveillante servait en réalité un binaire WinRAR parfaitement légitime — une archive officielle signée par son éditeur légitime, sans aucun code malveillant. Une forme de « bait and switch » : les attaquants surveillent leurs propres serveurs, détectent les analystes et chercheurs en sécurité qui viennent inspecter leurs URLs depuis des IPs inhabituelles, et leur servent un leurre bénin pour noyer les tentatives d’analyse et éviter les demandes de retrait (« takedown requests ») auprès des hébergeurs.

D’autres scénarios sont probables en parallèle : rotation programmée du payload toutes les 6 à 24 heures, ciblage géographique (payload agressif uniquement sur les IPs françaises/européennes cibles, leurre WinRAR pour les IPs nord-américaines où sont beaucoup de chercheurs en sécurité), ou encore arrêt programmé d’une campagne publicitaire pour en relancer une nouvelle avec un binaire recompilé et une nouvelle signature numérique.

5. Ce qui a été volé : preuve par l’artefact

Sur le strict plan forensique, nous avons une preuve irréfutable d’exfiltration de données. Dans le dossier temporaire créé par le malware pendant son exécution, nous trouvons ce triptyque très parlant :

C:Users<utilisateur>AppDataLocalTempnspCD6D.tmp
├── cookies.txt       ← Cookies Chrome exportés (format Netscape/curl)
├── ns7.dll           ← Plugin 7-Zip pour compression archive
└── nsc.dll           ← Plugin libcurl pour POST HTTPS vers C2

La coexistence de ces trois fichiers dans le même dossier est la signature comportementale exacte d’une routine d’exfiltration : export des cookies Chrome dans un fichier texte au format standard, puis upload HTTPS vers un serveur distant via la librairie libcurl. Les 26 connexions sortantes observées vers un CDN pendant 38 secondes correspondent très exactement à ce transfert.

6. Deux composants installés : PDF + faux navigateur

L’analyse des actions de remédiation révèle que le malware installe en réalité deux composants distincts :

Les indicateurs techniques correspondent à une variante 2026 particulièrement offensive d’une famille d’adware documentée depuis 2019, qui a progressivement fusionné avec les techniques d’infostealers plus agressifs (padding Authenticode, process hollowing, rotation de certificats). C’est cette mutation — d’un simple détourneur publicitaire vers un voleur de sessions — qui fait basculer la menace d’ennuyeuse à critique.

7. Qui sont ces attaquants et pourquoi nous ciblent-ils ?

Une question qui revient souvent : « Nous sommes une PME tranquille, pourquoi quelqu’un voudrait nous attaquer ? » La réponse est structurelle et ne tient pas du hasard. Il faut comprendre qui sont ces attaquants et comment ils gagnent de l’argent pour saisir pourquoi aucune entreprise n’est « trop petite » pour être ciblée.

Des organisations criminelles, pas des adolescents dans leur chambre

L’image d’Épinal du hacker solitaire encapuchonné devant son écran est largement obsolète. Les campagnes comme celle que nous venons de décrire sont menées par des organisations criminelles structurées, qui fonctionnent comme de véritables entreprises : équipes de développeurs, service marketing, budgets publicitaires, sous-traitants, support client (pour aider leurs « affiliés »), et même juristes pour gérer les démêlés avec les hébergeurs.

Ces organisations sont souvent basées dans des pays où les poursuites judiciaires internationales sont difficiles (certains pays d’Europe de l’Est, l’ex-URSS, certains pays d’Asie du Sud-Est), mais elles recrutent, paient et opèrent à l’échelle mondiale. Leurs revenus sont estimés à plusieurs milliards de dollars par an globalement — davantage que le marché mondial du trafic de drogue pour certains analystes.

Comment gagnent-ils concrètement de l’argent ?

Le malware identifié dans cet incident rapporte aux attaquants selon quatre modèles économiques simultanés :

Les tendances 2026 à garder en tête

• Abandon progressif du ransomware « bruyant » (qui affole les médias) au profit du vol de données silencieux + extorsion ciblée (« si vous ne payez pas, on publie vos contrats clients »)
• Industrialisation du malvertising : les attaquants paient Google Ads comme des vraies entreprises. Budget publicitaire mensuel moyen d’une campagne : 5 000 à 50 000 USD, amorti en quelques jours par les infections rentabilisées.
• Ciblage professionnel via requêtes personnelles : les attaquants savent qu’un poste professionnel sert aussi à des usages privés (scolaire, recette, traduction, streaming). Ils achètent des mots-clés grand public pour toucher par rebond les salariés pendant leurs pauses.
• Signatures numériques légitimes abusées comme jamais, via des sociétés écrans qui passent les contrôles des autorités de certification (26 certificats documentés sur la famille identifiée dans cet incident).

8. Pourquoi le scoring comportemental a évolué sur 17 heures

Une question technique intéressante revient à la lecture de la timeline : pourquoi l’EDR a-t-il identifié la menace le lendemain matin et pas dès l’exécution initiale la veille après-midi ? La réponse tient au mécanisme même des EDR modernes.

Un scoring comportemental cumulatif, pas une signature binaire

Les EDR de nouvelle génération ne fonctionnent pas comme les antivirus traditionnels avec une base de signatures binaires. Ils utilisent un scoring comportemental cumulatif qui évalue chaque action d’un programme et attribue des points de suspicion. Certains facteurs augmentent le score (connexions réseau inhabituelles, injection de code, reconnaissance WMI), d’autres le diminuent (signature numérique valide, publisher reconnu, format d’installeur standard, taille non typique d’un malware).

Lors de la première exécution, le score est monté au-dessus du seuil « suspect » mais en-dessous du seuil « malveillant certain » grâce à la signature Authenticode valide du binaire. Le programme a été classé « ambigu » et observé silencieusement.

La réactivation le lendemain a franchi le seuil

Quand l’utilisatrice a déverrouillé son poste le lendemain matin, Chrome a restauré sa session, la barre de téléchargement est réapparue, et le binaire a été relancé. Cette seconde exécution a rejoué les mêmes comportements suspects : les deux exécutions cumulées ont dépassé le seuil d’alerte, déclenchant l’identification en 4 secondes après la relance. L’intervention Connect3S a enchaîné sans délai : kill des processus, mise en quarantaine, remédiation, puis ouverture immédiate de l’audit forensic.

9. Trois enseignements à retenir

10. Les signaux faibles à surveiller sur votre parc

Si vous êtes RSI / responsable informatique d’une PME, voici quelques indicateurs simples qui, sans remplacer une supervision EDR professionnelle, permettent de repérer ce type d’infection avant qu’elle ne devienne critique :

• Programmes installés inexpliqués dans Panneau de configuration → Programmes et fonctionnalités : OneLaunch, OneBrowser, PixelPerfectPDF, AppSuite-PDF, ManualFinder, PDFEditor, PDFSnap, ou tout « launcher/assistant » apparu sans demande utilisateur
• Nouveau navigateur par défaut ou moteur de recherche par défaut qui change tout seul dans Chrome
• Tâches planifiées inconnues dans taskschd.msc avec des noms comme ChromiumLaunchTask, OneLaunchUpdateTask, OneBUpdate
• Processus résidents dans le Gestionnaire des tâches nommés OneBUpdateService.exe, OneLaunchAssistant.exe, BrowC*.exe
• Extensions Chrome non demandées avec des permissions étendues (lire toutes les données des sites visités)

11. Indicateurs de compromission publiables

Pour les analystes SOC / RSI qui souhaitent chasser cette famille sur leur périmètre, voici les IOCs publiques de cet incident (partageables avec la communauté CTI) :

12. MITRE ATT&CK

Techniques observées sur cet échantillon, formalisées selon le framework MITRE ATT&CK :

T1583.008 Malvertising
T1566.002 Spearphishing Link
T1204.002 User Execution
T1036.003 Masquerading
T1588.003 Code Signing Cert
T1055.012 Process Hollowing
T1218 Binary Proxy Execution
T1564.004 NTFS File Attributes
T1480 Execution Guardrails
T1082 System Info Discovery
T1120 Peripheral Discovery
T1112 Modify Registry
T1071.001 Web Protocols
T1090 Proxy
T1547 Persistence Boot/Logon

Cet article est basé sur un incident réel audité par Connect 3S en avril 2026. Toutes les informations permettant d’identifier le client, ses salariés, ses outils métier ou sa configuration de supervision ont été caviardées. Les indicateurs techniques publiés (hashes, chemins, familles) sont ceux de la campagne publique identifiée, non spécifiques au client.