Attaques sans malware : détecter le vol d'identifiants en PME

CrowdStrike constate que la majorité des intrusions ne reposent plus sur du code malveillant mais sur des identifiants valides. Pour les PME et leurs prestataires IT, cela déplace le champ de bataille de l'antivirus vers l'identité.

En bref

• CrowdStrike alerte sur la montée des attaques sans malware ("malware-free"), où l'attaquant se connecte avec des identifiants légitimes plutôt que d'exécuter un binaire détectable.
• L'IA générative accélère la phase de reconnaissance et d'ingénierie sociale : phishing crédible, deepfakes vocaux, scripts d'intrusion générés à la demande.
• Les temps de propagation latérale se comptent désormais en minutes, ce qui rend le triage manuel du lundi matin structurellement inefficace.
• Pour une PME sans SOC, la détection passe par l'exploitation systématique des journaux d'authentification (Entra ID, Active Directory, VPN, SaaS) plutôt que par l'achat d'un nouvel agent.
• Trois réflexes prioritaires : MFA résistant au phishing, revue des accès à privilèges, alerting sur les anomalies de connexion.

Contexte

L'analyse rapportée par Le Monde Informatique part d'un constat de CrowdStrike : l'attaque détectable par sa charge utile appartient au passé. L'éditeur, qui publie chaque année un rapport de threat intelligence basé sur la télémétrie de sa plateforme Falcon, observe depuis plusieurs exercices une bascule vers des intrusions dites malware-free — l'adversaire n'installe rien, ou presque rien. Il se contente d'utiliser ce qui existe déjà : un compte utilisateur valide, un accès VPN, une session SaaS, les outils d'administration natifs du système (« living off the land »).

La mécanique est connue des équipes sécurité des grands comptes depuis le milieu des années 2010, mais deux éléments changent la donne en 2024-2025.

Premier élément : l'industrialisation du marché des identifiants. Les initial access brokers revendent des accès valides à des groupes de rançongiciel. Le vol se fait par infostealer (une infection courte, souvent hors du périmètre géré — machine personnelle, poste d'un sous-traitant), par phishing de session, ou par simple réutilisation de mots de passe issus de fuites publiques. L'identifiant devient une marchandise, avec un prix et une chaîne logistique.

Second élément : l'IA générative. Selon l'alerte relayée, l'IA accélère les attaques sur plusieurs plans. Côté ingénierie sociale, elle produit des courriels en français impeccable, contextualisés sur l'organigramme public de la cible, et des voix synthétiques suffisamment crédibles pour un appel au support informatique. Côté exploitation, elle réduit le temps nécessaire pour écrire un script d'énumération ou adapter un outil offensif. Le détail exact des chiffres avancés par CrowdStrike sur la progression annuelle des attaques sans malware n'est pas disponible dans l'extrait fourni : non documenté ici, à vérifier dans le rapport source.

Pour les PME, le problème est structurel. Leur stack de sécurité a été bâtie autour du poste de travail : antivirus, puis EDR quand le budget le permettait. Or si l'attaquant n'exécute rien de malveillant, ces couches ne déclenchent rien. Une connexion réussie avec le bon mot de passe et le bon code MFA (intercepté par proxy inverse) est, du point de vue du système, un événement normal.

Détails techniques

Anatomie d'une intrusion sans malware

Le déroulé typique, tel qu'on le retrouve dans les rapports d'incident sur des cibles de moins de 500 postes :

1. Collecte — Un infostealer (Lumma, Vidar, RedLine et successeurs) infecte un poste non géré. Il exfiltre les cookies de session, les mots de passe enregistrés dans le navigateur, les tokens OAuth. Durée : quelques secondes. L'infection peut être nettoyée ensuite, les identifiants restent valides.
2. Contournement du MFA — Deux voies dominantes : le phishing en temps réel via un proxy inverse (Evilginx, Tycoon 2FA, EvilProxy) qui relaie la page de connexion légitime et capture le cookie de session post-authentification ; ou le MFA fatigue / social engineering du helpdesk pour faire réenrôler un facteur.
3. Connexion légitime — L'attaquant rejoue le cookie ou s'authentifie directement. Aucun binaire, aucune signature.
4. Reconnaissance — Énumération de l'annuaire avec les outils du système : Get-ADUser, net group, requêtes Graph API sur Entra ID, exploration de SharePoint/OneDrive. Rien de tout cela n'est intrinsèquement malveillant.
5. Escalade et persistance — Ajout d'une méthode MFA sur un compte compromis, création d'une règle de transfert de boîte, inscription d'une application OAuth avec consentement, ajout d'un membre à un groupe d'administration.
6. Impact — Exfiltration, fraude au virement (BEC), ou déploiement d'un rançongiciel en toute fin de chaîne, quand la détection ne sert plus à rien.

La fenêtre utile de détection se situe entre les étapes 3 et 5. Elle se mesure en dizaines de minutes.

Ce qu'il faut instrumenter côté Microsoft 365 / Entra ID

La plupart des PME françaises tournent sur Microsoft 365. Les journaux existent, encore faut-il les interroger. Quelques requêtes KQL exploitables dans Microsoft Sentinel ou via Advanced Hunting (Defender XDR) :

// Connexions réussies depuis un pays inhabituel, hors périmètre attendu
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where Location !in ("FR", "BE", "CH", "LU")
| summarize Tentatives = count(), Ips = make_set(IPAddress, 10)
    by UserPrincipalName, Location, AppDisplayName
| order by Tentatives desc

// Ajout ou modification d'une méthode d'authentification (persistance MFA)
AuditLogs
| where OperationName has_any (
    "User registered security info",
    "User changed default security info",
    "Admin registered security info")
| project TimeGenerated, OperationName,
    Initiator = tostring(InitiatedBy.user.userPrincipalName),
    Cible = tostring(TargetResources[0].userPrincipalName),
    Result

// Création de règles de boîte de transfert externe — signal BEC classique
OfficeActivity
| where Operation in ("New-InboxRule", "Set-InboxRule")
| where Parameters has_any ("ForwardTo", "RedirectTo", "ForwardAsAttachmentTo")
| project TimeGenerated, UserId, Operation, ClientIP, Parameters

Sans licence Sentinel, l'onglet Connexions du portail Entra ID permet déjà de filtrer manuellement sur les connexions à risque, et le rapport « Utilisateurs à risque » d'Identity Protection (P2) automatise une partie du travail. À défaut, l'export des SigninLogs vers un stockage et un script hebdomadaire valent mieux que rien.

Côté Active Directory on-premise

Les événements de sécurité à surveiller en priorité sur les contrôleurs de domaine :

| Event ID | Signification | Signal recherché |

|---|---|---|

| 4624 (type 3, 10) | Connexion réseau / RDP réussie | compte de service utilisé depuis un poste utilisateur |

| 4625 | Échec de connexion | rafales sur un même compte (password spraying) |

| 4648 | Connexion avec identifiants explicites | usage de runas, pivot |

| 4728 / 4732 / 4756 | Ajout à un groupe privilégié | escalade |

| 4738 | Modification de compte utilisateur | changement de UAC, désactivation de la préauth Kerberos |

| 4769 | Ticket de service Kerberos | tickets RC4 pour des SPN → kerberoasting |

Une commande utile pour un audit ponctuel des comptes dormants — vecteur idéal pour un attaquant, car personne ne remarque leur usage :

# Comptes actifs sans connexion depuis 90 jours
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly |
  Where-Object { $_.Enabled -eq $true } |
  Select-Object Name, SamAccountName, LastLogonDate |
  Sort-Object LastLogonDate |
  Export-Csv .\comptes_dormants.csv -NoTypeInformation

Et pour identifier les comptes avec mot de passe qui n'expire jamais, souvent des comptes de service historiques :

Get-ADUser -Filter 'PasswordNeverExpires -eq $true -and Enabled -eq $true' `
  -Properties PasswordLastSet, ServicePrincipalName |
  Select-Object SamAccountName, PasswordLastSet, ServicePrincipalName

Le durcissement qui casse réellement la chaîne

Toutes les formes de MFA ne se valent pas face à un proxy inverse. Le classement pratique :

• Résistant au phishing : clés FIDO2/WebAuthn, Windows Hello for Business, passkeys, certificats. Le défi cryptographique est lié à l'origine du domaine : un proxy sur login-microsoft.tld-douteux.com ne peut pas le relayer.
• Partiellement résistant : notification push avec number matching + contexte géographique (Microsoft Authenticator configuré correctement).
• Contournable : OTP par application (TOTP), et surtout SMS, vulnérable au SIM swapping comme au relais.

Complément indispensable côté Entra ID : les stratégies d'accès conditionnel qui exigent un appareil conforme ou joint au domaine. Le cookie volé ne suffit alors plus, car l'attaquant ne possède pas le certificat d'appareil. Ajouter Continuous Access Evaluation pour réduire la durée de validité des tokens, et une politique de révocation de session sur détection de risque.

Implications pour les consultants IT

Le premier changement porte sur le discours commercial. Vendre un EDR à une PME reste pertinent, mais présenter l'EDR comme la réponse au risque cyber devient un contresens technique. L'argumentaire doit se déplacer : l'identité est le nouveau périmètre, et la question à poser au dirigeant n'est plus « avez-vous un antivirus ? » mais « combien de comptes à privilèges avez-vous, qui les utilise, et que se passe-t-il si l'un d'eux est utilisé depuis Bucarest à 3 h du matin ? ». Concrètement, cela signifie intégrer un volet gouvernance des identités dans les prestations d'infogérance : revue trimestrielle des accès, inventaire des comptes de service, suppression des comptes de partants sous 24 heures.

Le deuxième changement concerne l'architecture de la détection. Une PME de 80 personnes ne financera pas un SOC 24/7. Mais elle peut financer une collecte centralisée de journaux d'authentification avec une dizaine de règles d'alerte pertinentes, routées vers une boîte surveillée ou un canal Teams. Le coût marginal est faible quand l'organisation est déjà sur Microsoft 365 : Entra ID P1 pour l'accès conditionnel, un connecteur Sentinel avec un volume de données maîtrisé (ne pas tout ingérer : SigninLogs, AuditLogs, OfficeActivity, journaux DC). L'enjeu pour le consultant est de dimensionner ce socle sans dériver vers une facture d'ingestion incontrôlée — un piège classique de Sentinel.

Le troisième changement est opérationnel : le playbook de réponse. Face à une compromission d'identifiants, changer le mot de passe ne suffit pas. Il faut révoquer les sessions (Revoke-MgUserSignInSession ou l'action « Révoquer les sessions » dans le portail), auditer les méthodes MFA enregistrées, vérifier les règles de boîte, inspecter les consentements OAuth, et regarder les inscriptions d'appareils. Un runbook de quinze lignes, testé une fois par an, fait la différence entre un incident de deux heures et une fraude au virement à six chiffres. Ce runbook doit être écrit avant l'incident, avec les comptes de secours (break-glass) documentés et exclus des politiques d'accès conditionnel — faute de quoi une politique trop restrictive verrouille l'administrateur au pire moment.

Enfin, le volet conformité. NIS2 étend le périmètre des entités régulées à de nombreuses ETI et à leurs fournisseurs, avec des obligations sur la gestion des accès et la notification d'incident. Le RGPD impose déjà de démontrer les mesures techniques appropriées : une politique de MFA documentée et une traçabilité des connexions constituent des éléments de preuve directs. Pour les prestataires, la contractualisation du périmètre de surveillance devient un sujet juridique autant que technique : préciser ce qui est journalisé, pendant combien de temps, et qui regarde.

Sur la dimension IA, un point d'attention supplémentaire : la sensibilisation classique au phishing (« attention aux fautes d'orthographe ») est périmée. Les messages générés par LLM sont grammaticalement corrects et contextuellement pertinents. Le nouveau critère de vigilance à enseigner est procédural — toute demande de changement de coordonnées bancaires, de virement urgent ou de réinitialisation d'accès passe par un canal de vérification hors bande, quel que soit le degré de crédibilité du message ou de la voix au téléphone.

Pour aller plus loin

• Lien source originale : CrowdStrike alerte sur des cyberattaques plus furtives, accélérées par l'IA

Trois actions concrètes cette semaine :

1. Auditer la répartition des méthodes MFA sur le tenant Entra ID (rapport Authentication methods activity). Identifier tous les comptes encore en SMS ou sans second facteur, en priorisant les administrateurs, la direction et la comptabilité. Objectif : passer les comptes à privilèges sur FIDO2 ou Windows Hello for Business.
2. Vérifier l'inventaire des comptes dormants et des comptes de service sur l'AD et le tenant cloud, avec les scripts PowerShell ci-dessus. Désactiver tout ce qui n'a pas servi depuis 90 jours, documenter le reste avec un propriétaire nommé.
3. Surveiller trois signaux faibles en mettant en place des alertes : ajout d'une méthode d'authentification hors procédure, création d'une règle de transfert externe de boîte, connexion réussie depuis un pays hors périmètre métier. Ces trois règles couvrent une part disproportionnée des scénarios de compromission d'identité en PME.