Connexion VPN puis rançongiciel : ce que les preuves étayent
Une connexion à 02:14 et des fichiers chiffrés à 03:02 forment une séquence qui mérite une enquête, pas un point d’entrée. Gardez séparées les preuves d’authentification, de session et d’hôte.
Tout ce qui suit s’appuie sur un enregistrement hypothétique, assemblé pour montrer une forme et non pour décrire un cas réel. Il se lit comme une chaîne : une authentification sur la passerelle à 02:14, une session de bureau à 02:19, un changement de compte privilégié à 02:41 et des fichiers chiffrés découverts à 03:02. La première ligne ressemble à la réponse, et le rapport est souvent écrit comme si elle l’était. Une connexion est un événement qu’une passerelle a enregistré, pas une conclusion sur la manière dont quelqu’un est entré, et cette différence décide de ce que vous ferez ensuite.
Le symptôme : une connexion qui ressemble à la réponse
Les journaux d’authentification sont les preuves les plus faciles à obtenir et les plus faciles à surinterpréter. Ils montrent que le service a accepté un identifiant à un moment, depuis une adresse, pour un compte. Ils ne montrent pas qui contrôlait l’identifiant, si la passerelle a été exploitée ou si l’appareil du titulaire du compte était déjà compromis.
Trois explications correspondent à la même ligne de connexion. Quelqu’un a utilisé un mot de passe volé, et la passerelle a fait exactement ce pour quoi elle est conçue. Un ordinateur portable compromis plus tôt s’est simplement connecté comme d’habitude. Un service exposé sans rapport a fourni la véritable entrée, et la session VPN est une action ultérieure et distincte du même acteur.
Chaque explication prédit des preuves différentes ailleurs dans l’environnement, c’est pourquoi l’enquête doit chercher ces prédictions et non la confirmation de la première qui convient. Un mot de passe volé prédit une géographie ou un moment d’authentification inhabituels. Un ordinateur portable compromis prédit des artefacts d’hôte avant la connexion. Un point d’entrée sans rapport prédit une activité qui n’a rien à voir avec la passerelle.
Séparez les événements avant de les raconter
Écrivez les événements séparément avant qu’un récit existe, car un récit invite à ordonner la chronologie autour d’un suspect. Chaque ligne doit dire ce que cet enregistrement établit et, séparément, ce qu’il ne peut pas établir seul. Au moment où deux lignes fusionnent en une phrase, une interprétation a déjà gagné.
Remarquez que le dernier événement concerne la détection et non l’attaquant. Le moment de la découverte et le moment de la compromission sont couramment séparés de plusieurs heures ou semaines, et un rapport qui les assimile induira en erreur tout lecteur qui viendra après vous.
Notez d’où vient chaque horodatage, pas seulement ce qu’il dit. L’heure de réception d’un collecteur, l’heure d’un événement et l’heure de détection sont trois nombres différents, et les normaliser silencieusement en une seule colonne est la façon dont une chronologie acquiert une forme que les preuves n’ont jamais eue.
Ne joignez des enregistrements que là où les identifiants concordent
Fusionner des enregistrements est une hypothèse, pas une étape de mise en forme. Le nom du compte, l’adresse VPN attribuée, l’hôte cible et l’identifiant de session doivent concorder avant que deux lignes ne deviennent une histoire. Une adresse publique partagée ne suffit pas, car elle est partagée par conception.
| Record source | Join key that must match | What breaks when the key is missing |
|---|---|---|
| File-share or backup record | file path and modification time | impact cannot be ordered against any session |
| Host process record, EDR or audit log | host name and process start time | the process cannot be placed inside a session |
| Session broker or remote-desktop log | session identifier and target host | the session cannot be traced back to a gateway login |
| Gateway authentication log | account name and assigned VPN address | the session cannot be followed past the gateway |
Lisez le tableau de bas en haut lorsque vous remontez une entrée, et de haut en bas lorsque vous délimitez l’impact, car les deux questions exigent des directions opposées. Là où les identifiants concordent vraiment, dites-le et citez les deux enregistrements. Là où ils ne concordent pas, laissez l’écart visible plutôt que de le combler par une supposition.
C’est aussi là qu’un nom d’utilisateur familier trompe. Le même compte peut être utilisé par le titulaire légitime le matin et par quelqu’un d’autre la nuit, et le nom du compte seul ne peut pas les distinguer. Attribuez le compte, puis attribuez la personne séparément, et seulement quand quelque chose le soutient. La plupart des chronologies qui s’effondrent en relecture ont fait exactement cette étape trop vite.
Les journaux manquants sont une lacune, pas une preuve négative
L’absence d’événements de mot de passe échoué ne prouve pas que la connexion réussie était légitime. Des identifiants volés valides produisent un enregistrement d’authentification réussi et aucun échec, et c’est exactement ce qui rend le vol d’identifiants attractif.
De même, un port fermé aujourd’hui dit quelque chose sur aujourd’hui. Il ne dit rien sur le fait que ce service était exposé alors, qu’il était vulnérable alors ou qu’il a porté l’attaque. La configuration historique et les preuves du service sont le seul moyen de combler cette lacune.
Énoncez la lacune explicitement dans le rapport. « Nous n’avons pas d’enregistrements pour cet intervalle » est une phrase défendable ; « rien d’autre ne s’est produit » ne l’est pas, et on vous la citera en retour. Les lacunes ont aussi des responsables : nommez le système qui aurait dû produire l’enregistrement et pourquoi il ne l’a pas fait. Cette ligne transforme une omission en point de remédiation.
Écrivez les conclusions au niveau que les preuves étayent
Coordonnez la préservation, le confinement et la restauration par l’intermédiaire du responsable de l’incident, et non en le contournant. Les recommandations techniques de la CISA soulignent la collecte des artefacts et journaux pertinents avant que la remédiation ne modifie ce qui reste disponible, et cet ordre compte plus que n’importe quel outil isolé.
Réexécuter un exploit suspect contre du matériel en production pour combler la lacune ne vaut pas le risque ajouté. Un test qui montre qu’une attaque pourrait fonctionner n’est pas la preuve qu’elle a fonctionné, et la différence entre ces deux affirmations est toute la discipline de l’exercice.
Terminez par quatre listes : ce qui a été observé, quelles relations les enregistrements étayent, ce qui reste une hypothèse et quels enregistrements sont indisponibles. « Un compte VPN a été utilisé pendant l’incident » appartient à la deuxième liste lorsque les enregistrements l’étayent. « Le VPN a causé le rançongiciel » n’appartient nulle part tant que quelque chose n’établit pas la causalité.