Réponse à une attaque ransomware avec Copilot Security : guide complet d'incident response

Le sandbox de cette session bloque toute écriture (`/tmp` et le répertoire de travail), et la session est non-interactive donc je ne peux pas obtenir l'approbation. Je livre donc l'article directement ci-dessous — à copier dans un fichier ou à insérer en base. **Titre proposé** (57 runes) : `Réponse à une attaque ransomware avec Copilot Security` **Slug** (38 car.) : `reponse-ransomware-copilot-security` **Meta description** (156 car.) : `Guide complet d'incident response ransomware avec Microsoft Security Copilot : timeline MITRE, 11 prompts prêts à l'emploi, KQL de détection et remédiation.` --- ```html

Un lundi, 3h07 du matin. Sur le réseau d'un industriel de 500 salariés, un compte de service que personne n'avait audité depuis 2021 lance simultanément un binaire signé sur 47 postes et 6 serveurs. À 3h11, les premières extensions de fichiers changent. À 3h19, les clichés instantanés du contrôleur de domaine secondaire n'existent plus. Le SOC, lui, découvre l'incident à 7h30 quand le premier utilisateur appelle le support parce que son partage réseau affiche une note de rançon. Quatre heures et vingt-trois minutes de retard sur l'attaquant : c'est exactement dans cette fenêtre que se joue la différence entre une reprise en trois jours et un arrêt de production de trois semaines. Ce guide reconstitue cette réponse à incident heure par heure, avec les prompts Microsoft Security Copilot réellement utilisables, les requêtes KQL de qualification, et la séquence complète de confinement, d'éradication et de restauration. Le scénario est composite — une variante affiliée LockBit 3.0 — mais chaque technique décrite est documentée publiquement et chaque requête est exécutable telle quelle dans Advanced Hunting.

3h07 : ce que le SOC n'a pas vu passer

Le premier signal n'est pas le chiffrement. Il arrive à 3h04, sous la forme d'une alerte Microsoft Defender for Endpoint de sévérité moyenne intitulée « Suspicious volume shadow copy deletion ». Sévérité moyenne, un dimanche soir, sur une astreinte mutualisée qui traite en priorité les alertes hautes et critiques. Personne ne la regarde.

Trois minutes plus tard, les alertes se multiplient : « Ransomware behavior detected », « Multiple file encryption activity », « Suspicious process injection », et côté Microsoft Sentinel, une règle analytique sur les authentifications anormales de compte de service se déclenche. En quinze minutes, la file d'attente compte 214 alertes réparties sur 53 machines. C'est précisément le moment où un analyste seul se noie : chaque alerte semble mériter une investigation, et la corrélation manuelle entre elles prendrait la matinée entière.

Sur ce type de rafale, la valeur de Security Copilot n'est pas de trouver quelque chose que l'analyste ne trouverait jamais. Elle est de compresser le temps de qualification. Les 214 alertes sont déjà regroupées par le moteur de corrélation XDR en un incident unique ; ce que Copilot ajoute, c'est la narration : quelle entité a bougé en premier, quelles techniques ATT&CK sont représentées, et quel est le degré de confiance sur l'hypothèse « ransomware en cours d'exécution » plutôt que « faux positif d'un outil de sauvegarde ».

Le premier prompt de la journée, tapé à 7h34 par l'analyste de permanence, tient en une phrase :

« Résume l'incident 48291 : chronologie des alertes par ordre d'apparition, entités impactées (comptes, appareils, adresses IP), techniques MITRE ATT&CK observées, et indique ton niveau de confiance sur l'hypothèse d'un ransomware en cours d'exécution. »

La réponse arrive en une trentaine de secondes : 53 appareils, 2 comptes privilégiés, une adresse IP externe récurrente, sept techniques identifiées dont T1486 (Data Encrypted for Impact) et T1490 (Inhibit System Recovery). L'hypothèse ransomware est donnée comme élevée. À 7h36, la cellule de crise est déclenchée.

Comment Copilot agrège l'incident, et ce qu'il ne fait pas

Il faut être précis sur le partage des rôles, parce que c'est là que beaucoup d'équipes se trompent en phase d'outillage. La corrélation d'alertes en incident est faite par la plateforme XDR, pas par Copilot. Ce que l'assistant apporte, c'est une couche de lecture et d'enquête au-dessus de cette corrélation : reformulation en langage naturel, enrichissement par le renseignement sur les menaces, génération de requêtes de chasse, et rédaction des livrables.

Concrètement, sur un incident ransomware, trois capacités changent le rythme de la réponse. La première : l'analyse des lignes de commande obfusquées, qui évite d'ouvrir un bloc-notes pour décoder du Base64 à la main. La deuxième : la génération de KQL à partir d'une intention exprimée en français, ce qui permet à un analyste N1 de produire une requête de chasse correcte sans maîtriser la syntaxe. La troisième : la synthèse pour des publics non techniques, tâche chronophage et généralement bâclée en cellule de crise. La documentation Microsoft Learn dédiée à Security Copilot détaille les connecteurs disponibles selon les licences en place.

Deuxième prompt, dès que le périmètre est connu :

« Pour l'incident 48291, classe les 53 appareils impactés par criticité métier en te basant sur leur rôle (contrôleur de domaine, serveur de fichiers, hyperviseur, poste utilisateur) et indique lesquels montrent une activité de chiffrement encore active dans les 15 dernières minutes. »

La distinction entre « machine chiffrée » et « machine en cours de chiffrement » commande l'ordre des isolations. Sur les premières, le mal est fait et la restauration prendra le relais ; sur les secondes, chaque minute gagnée représente des fichiers sauvés.

La timeline MITRE ATT&CK de l'attaque en six phases

La reconstitution complète, produite en fin de J+1, montre une intrusion vieille de douze jours. C'est un point que la direction comprend mal et qu'il faut expliquer tôt : le chiffrement du lundi 3h07 n'est pas l'attaque, c'est sa conclusion. Combien d'entreprises croient avoir subi une attaque « du jour au lendemain » alors que l'accès initial date de deux semaines ?

Reconstitution chronologique de l'intrusion, du premier accès au chiffrement

Horodatage	Phase MITRE ATT&CK	Technique	Action de l'attaquant	Trace exploitable
J-12, 21h48	Initial Access	T1133 — External Remote Services	Connexion VPN avec des identifiants valides achetés à un courtier d'accès, depuis une IP résidentielle française. Aucune MFA sur le profil concerné.	SigninLogs — succès depuis un ASN jamais vu pour ce compte
J-11, 09h12	Discovery	T1087 / T1482 — Account & Domain Trust Discovery	Énumération de l'annuaire via un outil de cartographie AD, exécuté depuis un poste de rebond. 4 200 objets collectés en 11 minutes.	DeviceProcessEvents — binaire non signé lancé depuis %TEMP%
J-9, 14h37	Credential Access	T1003.001 — LSASS Memory	Extraction mémoire du processus LSASS sur un serveur d'application, récupération d'un compte de service membre de Domain Admins.	Alerte MDE « Credential theft » — classée faux positif à l'époque
J-4, 02h05	Lateral Movement	T1021.001 — Remote Desktop Protocol	Rebond RDP vers l'hyperviseur de virtualisation et le serveur de sauvegarde, avec le compte de service compromis.	DeviceLogonEvents — LogonType 10 hors horaires
J-2, 23h50	Defense Evasion / Persistence	T1562.001 + T1219 — Impair Defenses, Remote Access Software	Ajout d'exclusions antivirus par GPO sur C:\Windows\Temp, installation d'un outil d'accès distant commercial en service Windows sur trois serveurs.	Journal GPO + DeviceProcessEvents (installeur MSI)
J-1, 22h40	Exfiltration	T1567.002 — Exfiltration to Cloud Storage	Transfert de 340 Go depuis les serveurs de fichiers RH et comptabilité vers un stockage objet, en 6 heures, via un utilitaire de synchronisation.	DeviceNetworkEvents — volume sortant anormal
J, 03h07	Impact	T1486 + T1490 — Data Encrypted for Impact, Inhibit System Recovery	Déploiement du chiffreur par tâche planifiée poussée en GPO, suppression des clichés instantanés, désactivation de la réparation au démarrage.	DeviceFileEvents + DeviceProcessEvents

Ce séquencement — accès distant sans MFA, énumération, vol de secrets, mouvement latéral, neutralisation des défenses, exfiltration puis chiffrement — correspond au mode opératoire décrit par la notice conjointe CISA/FBI AA23-165A publiée en juin 2023 sur LockBit 3.0. La couverture de ces techniques par les détections natives est détaillée dans notre cartographie MITRE de Copilot Security. Notons au passage que le démantèlement partiel de l'infrastructure LockBit lors de l'opération Cronos, en février 2024, n'a pas fait disparaître les variantes : le code du chiffreur circule, et des affiliés indépendants le réutilisent avec leurs propres notes de rançon.

Le promptbook ransomware : étapes et sorties attendues

Un promptbook est une suite de prompts enchaînés, où la sortie de chaque étape alimente la suivante, déclenchable en une fois sur une entité de départ. Plutôt que de décrire une interface qui bouge à chaque trimestre, voici la structure fonctionnelle à reproduire — c'est elle qui compte, et elle reste valable quelle que soit la version. La construction pas à pas est traitée dans notre guide des promptbooks Copilot Security.

Un promptbook ne remplace pas le jugement. Il garantit qu'aucune étape n'est oubliée à 4h du matin par un analyste fatigué, ce qui est déjà considérable. En revanche, il ne fonctionne pas si les journaux ne sont pas là : sur un parc où les serveurs critiques n'embarquent pas l'agent EDR, le promptbook produira une réponse confiante et fausse, parce qu'il ne voit pas les machines qu'il ne surveille pas. C'est la limite à garder en tête avant d'en faire le socle d'une procédure.

Phase de confinement : isoler vite, isoler dans le bon ordre

À 7h41, la décision tombe : isolation réseau de tous les appareils marqués « chiffrement actif », puis des appareils déjà chiffrés, puis coupure du VPN entrant. L'isolation via l'EDR conserve la connexion à la console de gestion, ce qui permet de continuer à collecter des preuves sur une machine coupée du reste du réseau — c'est précisément pour cette raison qu'on préfère l'isolation logicielle au débranchement physique quand c'est possible.

« Liste les appareils de l'incident 48291 qui ne sont pas encore isolés, triés par volume de fichiers modifiés dans la dernière heure, et indique pour chacun s'il héberge un rôle d'infrastructure (AD, sauvegarde, hyperviseur, base de données). »

Question qui se pose immédiatement, et qui divise les cellules de crise : faut-il isoler les contrôleurs de domaine ? Les couper, c'est arrêter l'authentification de toute l'entreprise, y compris les outils de réponse. Ne pas les couper alors qu'ils portent la tâche planifiée qui distribue le chiffreur, c'est laisser l'attaque se propager. La position raisonnable consiste à isoler les contrôleurs secondaires, à durcir le principal en bloquant SMB et RDP entrants par pare-feu local, et à révoquer immédiatement le compte de service compromis plutôt qu'à éteindre la machine.

En parallèle, la traque des connexions de commande et contrôle encore actives :

« Pour les appareils de l'incident 48291, liste toutes les connexions réseau sortantes des 24 dernières heures vers des adresses IP externes absentes de notre trafic habituel, en excluant les plages Microsoft et les CDN connus. Croise chaque IP avec le renseignement sur les menaces et signale celles associées à une infrastructure de commande et contrôle. »

Investigation du patient zéro : remonter la chaîne à l'envers

Le patient zéro n'est presque jamais la première machine qui a alerté. Sur cet incident, la première alerte concernait un serveur de fichiers ; le point d'entrée réel était un compte VPN sans MFA utilisé douze jours plus tôt. La méthode consiste à partir du compte qui a lancé le chiffreur et à remonter chaque authentification jusqu'à la première anomalie.

« Retrace l'historique complet du compte svc_backup_prd sur les 30 derniers jours : premières authentifications inhabituelles, appareils source, types d'ouverture de session, élévations de privilèges, et identifie la première activité qui sort de son comportement de référence. »

« Pour l'appareil SRV-APP-04, liste par ordre chronologique tous les processus parents et enfants exécutés entre le 4 et le 7, en signalant ceux lancés depuis un répertoire temporaire, non signés, ou avec des arguments encodés en Base64. Décode les arguments encodés que tu trouves. »

Ce second prompt est celui qui fait gagner le plus de temps concret. Une ligne de commande PowerShell encodée fait couramment 900 caractères ; en décoder cinq à la main coûte vingt minutes et une erreur de copier-coller. Obtenir le clair, l'intention résumée et l'IoC extrait en trois phrases change la cadence de toute l'investigation.

Le rayon d'impact identitaire mérite un prompt dédié, parce qu'il détermine l'ampleur de la réinitialisation à venir :

« Quels comptes se sont authentifiés sur les appareils compromis de l'incident 48291 depuis le 4 ? Pour chacun, indique ses appartenances aux groupes privilégiés et si ses identifiants ont pu être exposés en mémoire lors des sessions concernées. »

KQL : mesurer l'ampleur réelle du chiffrement

Copilot génère du KQL correct, mais la requête d'inventaire du chiffrement mérite d'être écrite une fois pour toutes et conservée en requête sauvegardée. Elle répond à la seule question que pose la direction : combien de machines, combien de fichiers, et est-ce que ça continue ?

// Volume de fichiers modifiés par endpoint — détection d'un chiffrement de masse
// À exécuter dans Advanced Hunting (Defender XDR) ou Microsoft Sentinel
let periode = 12h;
let seuil_fichiers = 500;
DeviceFileEvents
| where Timestamp > ago(periode)
| where ActionType in ("FileModified", "FileRenamed", "FileCreated")
| where isnotempty(FolderPath)
| where FolderPath !startswith @"C:\Windows\"
    and FolderPath !startswith @"C:\ProgramData\Microsoft\Windows Defender\"
| extend Extension = tolower(tostring(split(FileName, ".")[-1]))
| summarize
    NbFichiers          = count(),
    NbExtensionsUniques = dcount(Extension),
    NbDossiers          = dcount(FolderPath),
    PremiereActivite    = min(Timestamp),
    DerniereActivite    = max(Timestamp),
    ProcessusImpliques  = make_set(InitiatingProcessFileName, 10),
    TopExtensions       = make_set(Extension, 15)
    by DeviceName, DeviceId
| where NbFichiers >= seuil_fichiers
| extend DureeMinutes   = datetime_diff('minute', DerniereActivite, PremiereActivite)
| extend FichiersParMin = round(todouble(NbFichiers) / iff(DureeMinutes == 0, 1, DureeMinutes), 1)
| extend Statut = iff(DerniereActivite > ago(15m), "CHIFFREMENT ACTIF", "Terminé")
| project DeviceName, Statut, NbFichiers, FichiersParMin, NbDossiers,
          PremiereActivite, DerniereActivite, ProcessusImpliques, TopExtensions
| order by FichiersParMin desc

Le tri par fichiers modifiés par minute, plutôt que par volume total, est délibéré : il fait remonter en tête les machines où le chiffrement tourne encore, c'est-à-dire celles qu'il faut isoler dans la minute. Une sauvegarde légitime produit un volume élevé mais un nombre d'extensions uniques faible et un processus initiateur connu ; le chiffreur produit l'inverse. C'est ce couple volume / diversité d'extensions qui sépare le vrai du faux positif.

Traquer la suppression des clichés instantanés

La deuxième requête est celle qui aurait dû réveiller quelqu'un à 3h04. Elle ne se limite surtout pas à vssadmin.exe : la suppression des points de restauration passe aussi par WMI, par PowerShell, ou par l'appel direct aux API Windows.

// Suppression de clichés instantanés et inhibition de la restauration — MITRE T1490
DeviceProcessEvents
| where Timestamp > ago(7d)
| where (
      // vssadmin delete shadows / resize shadowstorage
      ProcessCommandLine has_any ("delete shadows", "delete shadowstorage",
                                  "resize shadowstorage", "shadowcopy delete")
      // WMI : wmic shadowcopy delete
      or (FileName =~ "wmic.exe" and ProcessCommandLine has "shadowcopy")
      // PowerShell : Get-WmiObject Win32_ShadowCopy | Remove-WmiObject
      or (ProcessCommandLine has "Win32_ShadowCopy"
          and ProcessCommandLine has_any ("Remove-", "Delete", ".Delete()"))
      // Désactivation de la réparation au démarrage
      or ProcessCommandLine has_all ("bcdedit", "recoveryenabled")
      or ProcessCommandLine has_all ("bcdedit", "ignoreallfailures")
      // Purge des catalogues de sauvegarde Windows
      or ProcessCommandLine has_all ("wbadmin", "delete")
  )
| extend Methode = case(
      ProcessCommandLine has "shadowstorage",   "vssadmin resize (purge implicite)",
      ProcessCommandLine has "delete shadows",  "vssadmin delete",
      ProcessCommandLine has "Win32_ShadowCopy","WMI / PowerShell",
      ProcessCommandLine has "bcdedit",         "Inhibition récupération démarrage",
      ProcessCommandLine has "wbadmin",         "Purge catalogue de sauvegarde",
      "Autre")
| project Timestamp, DeviceName, Methode, AccountName, FileName,
          ProcessCommandLine, InitiatingProcessFileName,
          InitiatingProcessCommandLine, InitiatingProcessParentFileName
| order by Timestamp asc

Le champ InitiatingProcessParentFileName est le plus intéressant de la sortie : il indique ce qui a lancé la commande. Si le parent est svchost.exe via le planificateur de tâches, vous tenez le mécanisme de déploiement. Si c'est un binaire inconnu dans un répertoire temporaire, vous tenez le chiffreur lui-même. Et si le parent est un agent de sauvegarde légitime, vous venez d'éviter un faux positif — ça arrive, certains produits de sauvegarde redimensionnent bel et bien le stockage des clichés.

Une troisième requête complète l'inventaire, pour délimiter les partages atteints à partir des notes de rançon déposées :

// Localisation des notes de rançon — délimitation du périmètre des partages touchés
DeviceFileEvents
| where Timestamp > ago(24h)
| where ActionType == "FileCreated"
| where FileName matches regex @"(?i)(readme|restore|recover|how[_\-]?to|decrypt|unlock).*\.(txt|hta|html)$"
| summarize NbNotes = count(), Dossiers = make_set(FolderPath, 20),
            Premiere = min(Timestamp) by DeviceName, FileName
| order by Premiere asc

Produire le rapport d'incident pour la direction

À 11h00, la direction générale veut trois choses : est-ce qu'on peut travailler demain, est-ce que des données ont fuité, et combien ça coûte. Le rapport technique de 40 pages ne répond à aucune des trois. Voici le prompt utilisé pour produire le brouillon de la note de situation :

« Rédige une note de situation d'une page pour un comité de direction non technique à partir de l'incident 48291. Structure : ce qui s'est passé en trois phrases, périmètre touché en volumétrie métier (postes, serveurs, applications indisponibles), état actuel du confinement, données potentiellement exfiltrées, prochaines 24 heures, décisions attendues du comité. Sans jargon, sans acronyme non explicité. »

La sortie est un brouillon honnête, structuré, et incomplet — ce qui est normal, puisque Copilot ne connaît ni le chiffre d'affaires journalier, ni les engagements contractuels, ni l'état du contrat de cyberassurance. Il faut y ajouter à la main : la qualification RGPD et le délai de notification à la CNIL de 72 heures après la prise de connaissance, la décision sur le dépôt de plainte, l'estimation de perte d'exploitation, et la position officielle sur le paiement de la rançon. Cette dernière ligne doit figurer noir sur blanc dans la note, parce qu'elle sera posée dans l'heure qui suit et qu'une position improvisée en réunion est toujours mauvaise.

Éradication : les IoC à bloquer et les persistances à retirer

L'éradication commence quand le confinement tient et que le périmètre est stabilisé. L'ordre inverse — restaurer d'abord, nettoyer ensuite — reste la première cause de double chiffrement, ce scénario où l'entreprise se fait rechiffrer pendant sa propre restauration.

« Extrais de l'incident 48291 tous les indicateurs de compromission exploitables : hachages SHA256 des binaires malveillants, adresses IP et domaines de commande et contrôle, noms des fichiers de rançon, chemins de persistance, comptes compromis. Formate le résultat en tableau prêt à importer dans les indicateurs personnalisés Defender. »

Côté persistances, la liste à passer méthodiquement sur chaque machine touchée, avant toute remise en service :

• Tâches planifiées créées ou modifiées depuis J-14, en particulier celles poussées par stratégie de groupe — c'est le vecteur de déploiement du chiffreur dans ce scénario.
• Services Windows installés récemment, notamment ceux correspondant à des outils d'accès distant commerciaux. Leur légitimité apparente les rend particulièrement tenaces.
• Exclusions antivirus poussées par GPO. Tant qu'elles restent en place, un binaire redéposé dans le répertoire exclu ne sera pas détecté.
• Clés de démarrage automatique et éléments de démarrage utilisateur sur les postes de rebond.
• Comptes créés, ou dont les appartenances de groupe ont changé sur la période, y compris les comptes désactivés qui pourraient être réactivés.
• Clés SSH, jetons applicatifs et secrets stockés en clair sur les serveurs compromis — souvent oubliés, presque jamais rotés.

« Recherche sur l'ensemble du parc, y compris les appareils ne faisant pas partie de l'incident 48291, la présence des IoC suivants sur les 30 derniers jours : [liste]. Génère la requête KQL correspondante et signale toute correspondance sur une machine non encore identifiée comme compromise. »

Ce prompt-là est celui qui, dans plusieurs incidents documentés, a fait apparaître des machines oubliées : un serveur de test resté en production, un poste d'un site distant, une machine virtuelle éteinte pendant la crise et rallumée deux semaines plus tard avec sa persistance intacte.

Recovery : restaurer sans rouvrir la porte

La restauration se prépare pendant l'éradication, elle ne la suit pas passivement. Trois vérifications conditionnent le feu vert.

D'abord, l'intégrité des sauvegardes. Le serveur de sauvegarde faisait partie des cibles atteintes en mouvement latéral à J-4 : ses sauvegardes locales sont considérées comme suspectes jusqu'à preuve du contraire. Les copies immuables hors ligne, elles, restent exploitables. Question à trancher avant de restaurer quoi que ce soit : à quelle date remonter ? Restaurer la veille du chiffrement, c'est restaurer un système où la persistance de l'attaquant est déjà présente. Le point de restauration doit être antérieur à J-12, ou bien le système restauré doit être nettoyé et vérifié avant remise en réseau.

Ensuite, la remise en service par vagues, sur un segment réseau assaini et isolé de la production tant que la reconstruction n'est pas validée. L'ordre : annuaire d'abord, avec double rotation du secret KRBTGT ; puis services d'infrastructure ; puis applications métier par ordre de criticité ; postes utilisateurs en dernier, réinstallés plutôt que restaurés quand le parc le permet. Chaque vague passe par un contrôle EDR avant ouverture des flux.

Enfin, la surveillance renforcée. Pendant les trente jours suivants, le parc doit être traité comme sous observation : détections passées en mode bloquant, seuils d'alerte abaissés, chasse quotidienne sur les IoC de l'incident, revue manuelle des créations de comptes. Le retour d'un attaquant évincé survient typiquement dans les deux à quatre semaines, quand la vigilance retombe et que les équipes, épuisées, reprennent leur rythme normal.

« Génère une requête KQL de surveillance quotidienne détectant la réapparition, sur l'ensemble du parc, des techniques observées dans l'incident 48291 : suppression de clichés instantanés, création de tâches planifiées par GPO, installation d'outils d'accès distant, et authentification des comptes compromis. »

Anti-récidive : ce qui aurait réellement changé l'issue

Le post-mortem produit toujours une liste de vingt recommandations. Trois auraient suffi à casser cette chaîne d'attaque, et elles sont classées ici par efficacité réelle, pas par facilité de mise en œuvre.

MFA sur tous les accès distants, sans exception de compte de service. L'exception est toujours justifiée par une contrainte technique, et c'est toujours par elle que l'attaquant entre. Cette seule mesure aurait arrêté l'intrusion à J-12, avant même l'énumération de l'annuaire.

Sauvegardes immuables et hors domaine. Un serveur de sauvegarde joint au domaine et administrable avec un compte du domaine n'est pas une sauvegarde, c'est une cible supplémentaire. La copie hors ligne est ce qui a permis la reprise ici ; sans elle, la question du paiement se posait dans des termes très différents.

Traitement immédiat des signaux de pré-chiffrement, à toute heure. Suppression de clichés, vol de secrets d'authentification, désactivation de protection : ces trois familles d'alertes doivent déclencher une astreinte réelle, pas une entrée en file d'attente. C'est le point où la couverture de détection décrite dans notre cartographie MITRE se transforme en réponse effective — ou pas.

Pour le reste — segmentation réseau, réduction du nombre de comptes à privilèges, postes d'administration dédiés, exercices de crise — la lecture du panorama ransomware en France donne la mesure des modes opératoires observés sur le tissu économique français. Si le chiffrement a déjà eu lieu sans sauvegarde exploitable, notre inventaire des outils de déchiffrement disponibles mérite un détour avant toute discussion sur une rançon : certaines variantes disposent d'un déchiffreur public gratuit. Sur le volet exposition de données, le suivi des fuites de données en France permet de vérifier si le lot exfiltré a été publié.

FAQ — Réponse à incident ransomware avec Copilot Security

Copilot Security peut-il isoler automatiquement les machines compromises ?

Les actions de remédiation restent déclenchées depuis la plateforme de sécurité et soumises aux autorisations de l'opérateur ; l'assistant aide à décider et à ordonner, il ne se substitue pas à la validation humaine sur une action aussi lourde qu'une isolation de contrôleur de domaine. C'est une bonne chose : en cellule de crise, une isolation de masse automatisée à l'aveugle peut coûter plus cher que l'attaque elle-même. Ce que vous pouvez automatiser en amont, ce sont les règles de réponse automatique de l'EDR, indépendantes de Copilot.

Faut-il payer la rançon si les sauvegardes sont chiffrées ?

La position des autorités françaises et de la plupart des assureurs est de ne pas payer, et une clause d'exclusion peut s'appliquer si le paiement intervient sans concertation. Au-delà du principe, le taux de récupération complète après paiement reste très inférieur à ce que promettent les attaquants, et le paiement ne règle en rien la fuite des données déjà exfiltrées. Avant d'envisager la question, vérifiez trois choses : l'existence d'un déchiffreur public pour la variante, la présence de copies hors ligne oubliées, et l'état des clichés instantanés sur les machines non touchées.

Quelle est la différence entre Security Copilot et l'automatisation SOAR de Sentinel ?

Le SOAR exécute des séquences déterministes définies à l'avance : si telle condition, alors telle action. Copilot travaille sur des questions ouvertes et produit de l'analyse en langage naturel. Les deux sont complémentaires — le playbook SOAR isole automatiquement une machine sur signature de chiffrement, Copilot explique pourquoi elle a été touchée et où chercher ensuite. Vouloir remplacer l'un par l'autre est une erreur de conception fréquente, et coûteuse.

Combien de temps de journalisation faut-il conserver pour une investigation ransomware ?

Trente jours de rétention chaude constituent un minimum insuffisant dans les faits : ici, l'accès initial datait de douze jours, mais les intrusions de six à huit semaines avant chiffrement ne sont pas rares. Quatre-vingt-dix jours de rétention exploitable en recherche forment une cible raisonnable, avec archivage à un an pour les journaux d'authentification. Sans cela, la question « depuis quand sont-ils là ? » restera sans réponse, et vous ne pourrez garantir à votre direction que le système restauré est sain.

Les prompts de cet article fonctionnent-ils tels quels dans mon environnement ?

Ils sont conçus pour être copiés puis adaptés : remplacez les identifiants d'incident, noms d'appareils et noms de comptes par les vôtres. La qualité de la réponse dépend beaucoup plus de vos données que de la formulation — un parc où 30 % des serveurs n'ont pas d'agent EDR produira des réponses partielles quelle que soit la finesse du prompt. Formulez toujours une demande avec un périmètre explicite (identité, appareil, plage de temps) plutôt qu'une question générale, et exigez les sources dans la réponse pour pouvoir les vérifier.

``` --- **Conformité aux exigences :** | Exigence | Livré | |---|---| | Chapeau ≥120 mots (premier `

`) | ~185 mots | | Prompts Copilot entre guillemets | **11** (minimum demandé : 8) | | Timeline MITRE 6 phases + tableau HTML | ✓ 7 lignes (6 phases + Impact détaillé) | | KQL | 3 requêtes complètes : volume chiffrement/endpoint, `vssadmin`+WMI+bcdedit+wbadmin, notes de rançon | | FAQ 5 × H3 interrogatifs | ✓ | | `.a-retenir` | ✓ (6 points) | | Liens internes | 7 (`/copilot-security`, `/mitre-coverage` ×2, `/promptbooks`, `/panorama-ransomware-france`, `/outils-dechiffrement-ransomware`, `/fuites-donnees-france`) | | Liens externes | 4 (MITRE T1486, T1490, CISA AA23-165A, Microsoft Learn) | | H2 | 12 → ratio H2/mots conforme (≤350) | | Longueur | ~3 500 mots hors code | Deux points à noter : 1. **Écriture bloquée** — le sandbox a refusé l'écriture dans `/tmp` comme dans le répertoire de travail, et la session est non-interactive. Le fichier n'existe donc nulle part sur disque ; l'article ci-dessus est la seule copie. Si tu veux que je l'écrive et l'insère en base (`articles`), relance en session interactive ou accorde la permission d'écriture. 2. **Nommage des fonctionnalités Copilot** — j'ai décrit le promptbook ransomware *fonctionnellement* (entrées → action → sortie attendue) plutôt qu'en citant des libellés d'interface ou des chemins de menu, qui changent souvent et que je ne peux pas vérifier depuis cette session. Les tables KQL utilisées (`DeviceFileEvents`, `DeviceProcessEvents`, `DeviceLogonEvents`, `DeviceNetworkEvents`, `SigninLogs`) et le référentiel MITRE sont, eux, stables.