Clé SSH ajoutée : relier le changement aux accès réels dans une enquête SOC

Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.

Une alerte signale une modification du fichier des clés SSH autorisées sur un serveur Linux. Une rotation prévue, une automatisation mal documentée ou une tentative de maintien d’accès peuvent produire un signal comparable. Pour trancher, le SOC doit reconstruire le changement et rechercher ce que la clé a effectivement permis de faire.

Périmètre : cette méthode concerne les environnements utilisant OpenSSH. Elle reste indépendante de l’outil qui collecte les événements et ne suppose aucun connecteur particulier disponible dans Seculogik. Les comportements cités doivent être vérifiés pour la version et la configuration déployées.

1. Définir précisément ce qui a changé

MITRE ATT&CK décrit l’ajout de clés SSH autorisées comme un mécanisme possible de persistance. Cette correspondance aide à formuler une hypothèse ; elle ne qualifie pas à elle seule chaque modification de malveillante. Source : MITRE ATT&CK, T1098.004

Notre recommandation : ouvrir le dossier avec une observation vérifiable. Quel hôte, quel compte cible, quel fichier, quelle différence entre les versions ? Une ligne ajoutée, une clé remplacée et des restrictions retirées méritent des descriptions distinctes.

Conservez, selon vos procédures, la version observée, la version antérieure disponible et les références des événements sources. Notez l’heure de collecte, les métadonnées du fichier et les limites de l’historique. Sans version antérieure, indiquez « clé présente au moment de la collecte » plutôt que d’affirmer quand elle a été ajoutée.

Le premier livrable doit permettre à un second analyste de retrouver le changement sans refaire toute la recherche. Évitez de réduire le dossier à une capture d’écran ou au seul nom du fichier.

2. Vérifier le chemin d’autorisation réellement utilisé

OpenSSH peut lire plusieurs fichiers définis par AuthorizedKeysFile, utiliser AuthorizedKeysCommand pour rechercher des clés, ou accepter des certificats via TrustedUserCAKeys. Des conditions Match peuvent modifier la configuration applicable. Source : OpenSSH, configuration du serveur

Notre recommandation : identifier l’instance du service concernée, son fichier de configuration, les fichiers inclus et le compte visé. Faites vérifier par l’équipe système la configuration effective pour le contexte de connexion étudié. Une lecture isolée du fichier principal peut laisser une partie du périmètre inexpliquée.

Demandez aussi qui administre cette autorisation : équipe système, outil de configuration ou service central. Si un mécanisme réapplique automatiquement les clés, la mesure corrective devra traiter cette source. Inscrivez son propriétaire dans le dossier avant de décider une modification locale.

Gardez une distinction explicite entre l’état actuel et l’état pendant la période suspecte. Lorsque la configuration historique manque, cette incertitude doit accompagner la conclusion.

3. Identifier la clé et examiner ses restrictions

Le commentaire d’une ligne des clés SSH autorisées n’est pas utilisé pour authentifier son propriétaire. Des options associées à la clé peuvent limiter son usage, notamment sa provenance ou la commande exécutée. Source : OpenSSH, format des clés SSH autorisées

L’outil ssh-keygen permet d’afficher l’empreinte d’une clé publique avec l’option -l. Source : OpenSSH, ssh-keygen

Notre recommandation : comparer les empreintes selon un même algorithme et les rattacher à un inventaire d’accès validé. Un commentaire comme « sauvegarde » reste une déclaration à vérifier auprès du responsable du service.

Conservez séparément la clé et ses options. Une empreinte déjà connue peut apparaître dans une nouvelle ligne avec des restrictions différentes. Posez donc deux questions : reconnaît-on cette clé et reconnaît-on cet usage sur ce compte et ce serveur ?

La collecte d’une clé privée n’est pas nécessaire pour identifier une clé publique. N’en demandez pas au propriétaire et n’en copiez pas dans un ticket ou un assistant IA. Si une investigation spécialisée en découvre une, appliquez la procédure de traitement des secrets.

4. Reconstituer l’origine du changement

Cherchez une chaîne cohérente entre demande de changement, exécution technique et état obtenu. Examinez les traces disponibles de l’outil de déploiement, de l’administration du serveur et de la surveillance de fichiers.

Pour chaque rapprochement, relevez :

• l’identité technique observée et son rôle ;
• le processus ou le travail d’automatisation, si la source le fournit ;
• la cible exacte et l’heure avec son fuseau ;
• le résultat rapporté et la différence réellement constatée ;
• la référence de l’autorisation métier ou opérationnelle.

Un compte technique partagé demande une investigation supplémentaire pour retrouver l’origine humaine ou le travail automatisé. L’identité qui possède le fichier ne suffit pas à attribuer sa modification.

Notre recommandation : demander une confirmation par un canal approprié, sans dépendre uniquement du compte potentiellement compromis. Comparez la réponse avec des traces indépendantes. Si l’équipe reconnaît une rotation mais ne retrouve aucune demande ni exécution correspondante, gardez cette explication au stade d’hypothèse.

5. Chercher l’utilisation, puis les actions

Construisez une seconde chronologie consacrée aux connexions : compte cible, serveur, résultat, provenance et empreinte lorsque la journalisation la fournit. Documentez ce qui est effectivement collecté et la période couverte avant d’interpréter une absence de résultat.

Notre recommandation : rapprocher les événements par hôte, compte, temps et identifiants disponibles. Une même adresse IP ne prouve pas une même personne ; un bastion ou une traduction d’adresses peut masquer plusieurs origines. Si seule la proximité temporelle relie une connexion au changement, dites-le.

Poursuivez avec les activités disponibles après l’accès : processus, élévations de privilèges, fichiers modifiés et connexions sortantes. Pour chacune, indiquez la preuve et le degré de rattachement à la session étudiée. Ne transformez pas une connexion réussie en preuve d’exécution d’une commande précise.

Une recherche infructueuse doit se conclure par « aucune utilisation retrouvée dans les sources et la période examinées ». Ajoutez les angles morts qui empêchent d’aller plus loin et la décision attendue : collecte complémentaire, escalade ou clôture justifiée.

6. Définir un confinement dont on peut vérifier l’effet

Le protocole SSH distingue la phase d’authentification de la connexion qui suit. Une modification des autorisations de connexion ne constitue donc pas, à elle seule, une preuve de fermeture des accès déjà établis. Source : RFC 4252, fin de l’authentification

Notre recommandation : séparer trois objectifs dans la décision de réponse : empêcher de nouvelles connexions non autorisées, examiner les accès déjà ouverts et supprimer la cause qui permettrait de réintroduire la clé.

Avant une action, identifiez le responsable habilité, l’impact possible sur les sauvegardes ou déploiements et un accès d’administration de secours validé. Préservez les éléments utiles si l’urgence le permet. Consignez les exceptions lorsque la protection du service impose d’agir d’abord.

Après la mesure autorisée, vérifiez l’état sur les hôtes concernés et dans la source qui distribue les clés. Contrôlez séparément le traitement des connexions et activités existantes. Un test d’accès doit être préparé avec l’équipe responsable, sur un périmètre approuvé ; il ne justifie pas de récupérer une clé privée suspecte.

Un exercice pour éprouver le dossier

Exemple fictif : une clé inconnue apparaît sur le compte d’un service de sauvegarde. L’équipe infrastructure reconnaît une rotation prévue. Une connexion du même compte est observée ensuite, mais son empreinte manque dans les logs collectés.

Le dossier doit alors permettre de répondre à cinq questions :

1. La différence entre les fichiers et la configuration applicable sont-elles établies ?
2. L’empreinte correspond-elle à celle que l’équipe avait approuvée ?
3. L’exécution de la rotation est-elle retrouvée dans une source indépendante ?
4. Que peut-on rattacher à la connexion, et que reste-t-il impossible d’attribuer à cette clé ?
5. Quelle preuve justifie la clôture ou quelle vérification manque encore ?

Faites relire le dossier par un analyste qui n’a pas participé à l’exercice. Il doit pouvoir distinguer les faits, l’explication proposée et les limites restantes. Une conclusion utile décrit le changement autorisé ou l’accès suspect, son périmètre et la prochaine décision à prendre.

Pour préparer ce travail, utilisez le carnet d’investigation. Pour discuter de votre collecte et de vos procédures, échangeons sur votre projet.