Amazon SCS-C02: Réponse aux incidents et analyse forensique — Guide d'étude

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Fait partie du AWS Security Specialty SCS-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Isolation des instances EC2 compromises

Le premier objectif opérationnel lorsqu’une instance EC2 est suspectée d’être compromise est le confinement sans destruction des preuves. Le confinement sur AWS est une activité à plusieurs niveaux qui touche à l’exposition réseau de l’instance, à ses liens avec le cycle de vie et à son accessibilité pour les intervenants.

La séquence d’isolation canonique commence par le resserrement du groupe de sécurité de l’instance. Comme chaque instance dispose idéalement de son propre groupe de sécurité dédié, vous pouvez remplacer les règles d’entrée (ingress) et de sortie (egress) par un ensemble minimal qui ne permet qu’à l’équipe d’investigation numérique (ou à un groupe de sécurité de diagnostic dédié) de l’atteindre. Si l’instance se trouve derrière un Application Load Balancer ou dans un groupe cible, désenregistrez-la d’abord ; si elle est membre d’un groupe Auto Scaling, détachez-la avec l’indicateur --should-decrement-desired-capacity afin que l’ASG ne lance pas immédiatement un remplacement ou, pire, ne résilie l’instance « défectueuse » en pleine investigation.

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

L’activation de la protection contre la résiliation est essentielle car un opérateur bien intentionné, un script d’automatisation ou un événement de scale-in de l’ASG peut autrement détruire les volumes mêmes que vous essayez de préserver. La protection contre la résiliation ne remplace pas le détachement de l’ASG — un ASG peut toujours résilier des instances protégées lors d’un scale-in, à moins que vous ne retiriez également l’instance du périmètre du groupe.

Pour un confinement au niveau du sous-réseau lorsque vous avez besoin d’une coupure immédiate du trafic sortant (par exemple, une instance communiquant avec des adresses IP malveillantes connues), vous pouvez ajouter une règle de refus explicite de tout le trafic sortant à la NACL du sous-réseau en tant que règle avec le premier numéro. Cette opération est sans état (stateless) et prend effet instantanément sur tous les flux, contrairement aux modifications de groupe de sécurité qui n’affectent que les nouveaux flux. Une fois que votre chemin d’accès pour l’investigation est en place via un SG de diagnostic, le refus de la NACL peut être supprimé afin que le sous-réseau des intervenants puisse atteindre la cible via la liste d’autorisation du SG.

Préservation des preuves volatiles et non volatiles

Les preuves volatiles — listes de processus, sockets réseau ouverts, modules de noyau chargés, contenu de la mémoire, contenu de tmpfs — sont détruites dès que l’instance s’arrête. Les preuves non volatiles résident sur EBS et survivent aux arrêts/démarrages, mais peuvent tout de même être perdues si les volumes sont détachés ou si l’instance est résiliée sans snapshots. L’ordre des opérations : collecter d’abord les artéfacts volatils pendant que l’instance est encore en cours d’exécution, puis créer un snapshot EBS.

La collecte des données volatiles doit être scénarisée et exécutée via SSM Run Command plutôt que par un humain tapant dans un shell interactif. Run Command enregistre l’appel, les paramètres, le principal exécutant et la sortie dans CloudWatch Logs ou S3, ce qui devient en soi une partie de l’enregistrement de la chaîne de possession.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial exécute ses applications web destinées aux clients dans un seul compte AWS sur plusieurs VPC, en utilisant des groupes Auto Scaling derrière des Application Load Balancers, des instances EC2 basées sur EBS, une journalisation centralisée avec CloudTrail et CloudWatch, GuardDuty, et une archive de journaux basée sur S3 chiffrée avec KMS. L’équipe des opérations de sécurité utilise AWS Systems Manager pour la gestion à distance et stocke les sauvegardes et les snapshots dans un compte de récupération désigné.

Défi : Une instance EC2 de production présente des signes de compromission avec un trafic sortant suspect et une activité de processus inattendue ; l’équipe doit isoler l’instance et préserver à la fois les preuves volatiles de la mémoire et les preuves non volatiles du disque pour une analyse forensique sans détruire les pistes d’audit.

Approche recommandée :

1. Utiliser les API Auto Scaling et ELB pour détacher l’instance des groupes cibles et suspendre les processus Auto Scaling, puis appliquer un groupe de sécurité restrictif (refuser tout le trafic entrant/sortant) et mettre à jour les règles de la NACL de l’instance pour isoler l’accès réseau tout en conservant la gestion via AWS Systems Manager Session Manager.
2. Utiliser AWS Systems Manager Run Command pour exécuter une capture de la mémoire au sein de l’OS invité (par ex., LiME) qui écrit le vidage de la RAM sur un volume EBS attaché et chiffré ou directement dans un compartiment S3 chiffré avec SSE-KMS et avec S3 Object Lock activé pour la rétention.
3. Utiliser EC2 CreateSnapshot (ou CreateImage) pour capturer des snapshots EBS à un instant T de tous les volumes attachés, puis copier ces snapshots vers un compte AWS distinct ou une autre région pour préserver la chaîne de possession et empêcher toute altération.
4. Activer ou récupérer la mise en miroir du trafic VPC (VPC Traffic Mirroring) pour l’ENI de l’instance afin de collecter des captures de paquets vers une EC2 de surveillance dédiée, et exporter simultanément les VPC Flow Logs, les journaux d’accès ELB, CloudTrail, CloudWatch Logs et les résultats GuardDuty vers l’archive S3 sécurisée.
5. Étiqueter et inventorier tous les artéfacts collectés dans AWS Security Hub ou un système de tickets, s’assurer que les objets S3 sont chiffrés et que Object Lock est activé, et restreindre l’accès IAM à une petite équipe d’investigation tout en journalisant tous les accès via CloudTrail.

Justification : Isoler l’accès réseau avant de prendre des images empêche toute contamination supplémentaire, tandis que l’utilisation de SSM évite d’ouvrir de nouveaux vecteurs réseau ; la capture de la mémoire volatile en premier et la création de snapshots EBS immuables et d’archives S3 sécurisées préservent l’intégrité des preuves et la chaîne de possession, conformément aux meilleures pratiques de réponse aux incidents d’AWS.

# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

Immédiatement après la capture des données volatiles, créez un snapshot de chaque volume EBS attaché. Étiquetez les snapshots avec l’identifiant de l’incident afin qu’ils soient liés sans ambiguïté au cas.

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

Étiquetez l’instance elle-même avec le même ticket d’incident, le nom de l’enquêteur et une étiquette de statut telle que Quarantine. L’étiquetage cohérent des métadonnées est le mécanisme natif d’AWS pour la chaîne de possession — il est interrogeable, immuable via les clés de condition IAM, et apparaît dans chaque événement CloudTrail concernant la ressource.

Intervention en direct avec Session Manager et Run Command

Un point subtil mais crucial pour l’examen : les sessions SSH existantes survivent à la suppression des règles de groupe de sécurité. Les groupes de sécurité sont avec état (stateful) et évaluent les règles lors de l’établissement de la connexion ; une session TCP déjà établie continue de circuler même après la suppression de la règle d’entrée qui l’a autorisée. Si un intervenant isole une instance en supprimant les règles de SG tout en dépendant de sa propre session SSH pour y accéder, cette session fonctionne — jusqu’à ce qu’elle soit interrompue, moment auquel il est bloqué à l’extérieur et toute nouvelle tentative d’accès par bastion ou par clé est désormais impossible.

La bonne pratique est d’accorder à l’équipe forensique un accès via SSM Session Manager, qui ne nécessite l’ouverture d’aucun port entrant. Session Manager fonctionne via la connexion sortante de l’agent SSM vers les points de terminaison SSM, EC2 Messages et SSM Messages (idéalement via des points de terminaison d’interface VPC afin que l’instance isolée n’ait besoin d’aucune route Internet). Attachez un profil d’instance autorisant ssm:UpdateInstanceInformation et les API de messagerie, et accordez aux intervenants la permission ssm:StartSession limitée par tag à l’instance mise en quarantaine.

Comme les sessions Session Manager sont gérées par le plan de contrôle SSM, le resserrement ou la suppression complète des règles d’entrée du groupe de sécurité ne les perturbe pas, et chaque frappe au clavier peut être journalisée dans S3 ou CloudWatch Logs — une session interactive auditable, et non une boîte noire.

Récupération inter-comptes de snapshots chiffrés

Les environnements matures acheminent les snapshots forensiques vers un compte forensique dédié, isolé du compte de la charge de travail compromise. Le partage de snapshots entre comptes nécessite deux choses : le snapshot doit être partagé avec le compte cible (modify-snapshot-attribute --create-volume-permission), et si le snapshot est chiffré avec une clé KMS gérée par le client (CMK), la politique de la clé KMS doit accorder aux principaux du compte forensique les permissions kms:Decrypt, kms:CreateGrant et kms:DescribeKey. Les snapshots chiffrés avec la clé aws/ebs gérée par AWS ne peuvent pas être partagés entre comptes — vous devez d’abord les ré-chiffrer avec une CMK via une opération de copie. Dans le compte forensique, copiez le snapshot partagé et ré-chiffrez-le avec une CMK forensique locale afin que la création de volumes ultérieure ne dépende pas du compte source.

Conception de playbooks et minimisation de la charge

Codifiez les étapes de confinement sous forme de document SSM Automation ou de workflow Step Functions déclenché par des résultats GuardDuty ou Security Hub via EventBridge. Une seule automatisation devrait : (1) capturer les données volatiles via Run Command, (2) créer des snapshots des volumes avec des tags d’incident, (3) activer la protection contre la terminaison, (4) détacher de l’ASG et désenregistrer des cibles ELB, (5) remplacer le SG par le SG de quarantaine, et (6) taguer l’instance avec l’ID du ticket. Garder l’instance en cours d’exécution préserve les preuves vivantes et permet une investigation interactive via Session Manager — la mise hors tension devrait être une étape ultérieure délibérée, et non faire partie du confinement automatique, car l’arrêt efface les preuves volatiles et peut déclencher une logique de nettoyage intégrée au logiciel malveillant.

Les pièges à retenir : supprimer les règles de SG tout en se fiant à une session SSH existante laisse l’intervenant aveugle et donne un faux sentiment de confiance dans l’isolement ; effectuer une remédiation sur place avant de créer des snapshots détruit les artéfacts qui répondent à la question comment l’intrusion s’est produite ; et laisser l’instance dans son ASG ou son groupe cible provoque une terminaison automatisée ou, pire, un remplacement silencieux qui masque l’étendue de l’incident.

Confinement immédiat

Lorsqu’une charge de travail est suspectée d’être compromise, la première décision est de l’isoler sur place ou de la retirer du service. La retirer — l’arrêter ou la terminer — détruit les preuves volatiles telles que le contenu de la RAM, les processus en cours, les sockets ouverts, et tout logiciel malveillant qui ne réside qu’en mémoire. Le confinement sur place est presque toujours la bonne première étape, et il doit se produire assez rapidement pour qu’un attaquant ne puisse pas exfiltrer de données supplémentaires ou effectuer un mouvement latéral avant que les contrôles ne prennent effet.

Deux contrôles natifs d’AWS opèrent à des couches différentes, et la distinction est importante. Les groupes de sécurité sont avec état (stateful) et attachés aux interfaces réseau élastiques (ENI) ; les ACL réseau (NACL) sont sans état (stateless) et attachées aux sous-réseaux. Remplacer les groupes de sécurité d’une instance par un SG de « quarantaine » verrouillé est l’approche chirurgicale — cela isole une ENI sans perturber les autres charges de travail dans le même sous-réseau et préserve l’état d’exécution de l’instance. Cependant, les modifications de groupe de sécurité n’affectent que les nouveaux flux qui atteignent l’ENI, et si l’instance compromise détient déjà des connexions sortantes de longue durée, l’état existant peut persister. Les règles de refus NACL prennent effet immédiatement à la frontière du sous-réseau et peuvent couper le trafic encore plus rapidement lorsque la vitesse est plus importante que la précision chirurgicale — par exemple, lorsque plusieurs instances dans le même sous-réseau sont impliquées, ou lorsqu’une session active d’un attaquant doit être coupée instantanément. Les NACL sont également utiles lorsque la politique interdit de modifier directement une instance.

Le SG de quarantaine canonique n’autorise aucun trafic entrant et le trafic sortant uniquement vers les points de terminaison d’interface VPC pour com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages et com.amazonaws.<region>.ec2messages. Cela préserve l’accès à Systems Manager Session Manager tout en bloquant les canaux C2, l’exfiltration de données et le mouvement latéral.

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

Ordre de préservation des preuves

La valeur forensique se dégrade du plus volatil au moins volatil, donc l’ordre des opérations est fixe et non négociable :

• Activer d’abord la protection contre la terminaison. Définir DisableApiTermination=true empêche un événement Auto Scaling, une erreur d’opérateur ou une action planifiée de détruire l’instance en pleine investigation. Détachez également l’instance de son groupe Auto Scaling afin que les vérifications de santé de l’ASG ne puissent pas la remplacer.

• Détacher ou protéger de l’Auto Scaling. Utilisez EnterStandby ou détachez l’instance pour que l’ASG ne la termine pas parce qu’elle est défectueuse.

• Créer un snapshot de chaque volume EBS attaché. CreateSnapshot (ou CreateSnapshots pour une capture atomique multi-volume) produit un artefact forensique immuable et chiffré. Taguez les snapshots avec l’ID de l’incident, l’ID de l’instance source, l’horodatage et l’analyste. Copiez les snapshots vers un compte forensique dédié appartenant à l’équipe de sécurité afin qu’ils survivent à une compromission du compte.

• Capturer la mémoire. Utilisez un document SSM RunCommand pour invoquer un outil d’acquisition de mémoire (LiME, AVML sur Linux ; WinPMEM sur Windows) et diffuser l’image vers un bucket S3 forensique avec Object Lock en mode conformité. La mémoire doit être capturée pendant que l’instance est encore en cours d’exécution — une instance arrêtée n’a pas de RAM à acquérir.

• Collecter les métadonnées. Enregistrez l’ID de l’instance, l’AMI, le profil d’instance IAM, le VPC/sous-réseau, les ID d’ENI, les tags, la liste des processus en cours, la sortie de netstat et le contenu de l’IMDS. Taguez l’instance Status=Quarantined et IncidentId=<id> pour que l’automatisation en aval et les opérateurs humains reconnaissent son état.

• Ce n’est qu’ensuite que vous arrêtez l’instance si l’investigation nécessite une analyse de disque hors ligne. L’arrêt efface la mémoire, c’est donc toujours la dernière étape.

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

Workflows de réponse aux incidents automatisés

Les résultats de GuardDuty devraient déclencher le confinement en quelques secondes, pas en quelques heures. Le pipeline canonique est EventBridge → Lambda → SSM Automation, avec SNS pour les notifications.

Une règle EventBridge correspond à source: aws.guardduty avec un detail-type de GuardDuty Finding et un modèle filtrant sur les types de résultats pertinents pour EC2 tels que UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/*, et CryptoCurrency:EC2/*.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

La cible Lambda extrait l’ID de l’instance de detail.resource.instanceDetails.instanceId, puis invoque un document SSM Automation (ou appelle directement le SDK) pour : activer la protection contre la terminaison, remplacer les groupes de sécurité de l’ENI par le SG de quarantaine via ModifyNetworkInterfaceAttribute, créer des snapshots de tous les volumes attachés, taguer l’instance et publier un message SNS sur le canal du SOC. L’utilisation de SSM Automation plutôt que d’appels SDK bruts fournit des pistes d’audit détaillées dans l’historique d’exécution d’Automation.

Journalisation pour l’analyse de l’exfiltration et du C2

Le confinement sans télémétrie n’est que pure conjecture. Les VPC Flow Logs doivent être activés au niveau du VPC ou du sous-réseau avec le type de trafic défini sur ALL (à la fois ACCEPT et REJECT). Les enregistrements REJECT révèlent le balayage, les tentatives d’exfiltration bloquées et les balises C2 essayant d’atteindre des IP malveillantes connues ; les enregistrements ACCEPT montrent quels flux ont réussi. Acheminez les journaux de flux vers CloudWatch Logs pour des requêtes en temps réel et vers S3 pour une conservation à long terme avec Object Lock. CloudTrail avec les événements de données sur le bucket S3 forensique et KMS fournit la chaîne d’audit pour la gestion des preuves. Combinez cela avec la journalisation des requêtes DNS (Route 53 Resolver) pour attraper le DGA et le tunneling DNS que les journaux de flux seuls manqueraient.

Accès forensique contrôlé via Session Manager

Session Manager élimine le besoin de clés SSH, de bastions ou de ports 22/3389 ouverts, ce qui est précisément la raison pour laquelle le SG de quarantaine peut bloquer tout accès traditionnel. Activez la journalisation des sessions vers un bucket S3 avec SSE-KMS et vers CloudWatch Logs ; imposez EnforceEncryption=true dans les préférences de session afin qu’aucune session ne s’exécute sans TLS et sans chiffrement des journaux. Les politiques IAM sur ssm:StartSession doivent être limitées aux instances avec le tag tag:Status=Quarantined et accordées uniquement au rôle de réponse aux incidents.

Pièges courants et leurs conséquences

• Arrêter ou terminer l’instance en premier. L’arrêt libère la mémoire, interrompt les connexions actives et élimine la possibilité de capturer les artefacts volatils. La terminaison libère en plus le volume racine, sauf si DeleteOnTermination=false, et même dans ce cas, vous perdez l’état d’exécution. Confinez toujours sur place avant tout changement d’état d’alimentation.

• Se fier uniquement aux groupes de sécurité alors que les NACL sont plus rapides. Les modifications de SG sont chirurgicales mais n’affectent que l’ENI à laquelle ils sont attachés et ne régissent que les nouveaux flux. Lorsque plusieurs instances dans un sous-réseau sont impliquées, ou lorsqu’une session sortante existante d’un attaquant doit être coupée immédiatement, une règle de refus (deny) au niveau du NACL du sous-réseau ferme la porte plus rapidement car les NACL sont sans état (stateless) et bloquent chaque paquet quel que soit son état antérieur.

• Remédier avant de créer des snapshots. Recréer l’image, appliquer des correctifs ou remplacer l’instance avant de créer des snapshots EBS détruit les preuves résidant sur le disque — binaires malveillants, mécanismes de persistance, journaux, horodatages. Les snapshots sont peu coûteux et immuables ; créez-les avant toute action de remédiation, et copiez-les sur un compte d’investigation numérique (forensics) dédié afin qu’un compte de production compromis ne puisse pas les supprimer.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial gère un environnement AWS multi-comptes avec des charges de travail de production dans un compte dédié : des services EC2 et EKS hébergeant des données clients, des buckets S3 pour les archives, une journalisation centralisée dans un compte de sécurité avec CloudTrail, GuardDuty, Security Hub et Config activés, et un pipeline CI/CD pour les déploiements. Leur équipe des opérations utilise Systems Manager pour l’application de correctifs et la maintenance, et Route 53/ALB pour les points de terminaison publics.

Défi : Une découverte GuardDuty et des pics de trafic sortant inattendus indiquent une instance EC2 probablement compromise, se livrant à de l’exfiltration de données et à des appels d’API IAM suspects. Cela nécessite un confinement immédiat tout en préservant les preuves pour l’investigation numérique et en maintenant un accès auditable pour les enquêteurs.

Approche recommandée :

1. Déclencher un confinement immédiat via EventBridge sur la découverte GuardDuty pour invoquer un workflow Step Functions qui utilise une automatisation Lambda/SSM pour attacher un groupe de sécurité de quarantaine, supprimer les adresses IP publiques ou détacher l’ENI, et révoquer/alterner les informations d’identification IAM impliquées via IAM.
2. Préserver les preuves volatiles et persistantes en exécutant un document SSM Automation pour créer un snapshot EBS et une AMI de l’instance, copier les snapshots vers un compte AWS d’investigation numérique dédié, et stocker les artefacts exportés dans un bucket S3 avec S3 Object Lock (mode conformité) et le chiffrement KMS.
3. Capturer la journalisation pour l’analyse de l’exfiltration et du C2 en s’assurant que les événements de gestion et de données CloudTrail (S3, Lambda) sont activés, en transférant les VPC Flow Logs, les journaux d’accès ALB/NGINX et les journaux de requêtes Route 53 vers le compte de sécurité central, et en transmettant la découverte à Amazon Detective pour la corrélation chronologique.
4. Automatiser l’orchestration et les notifications en utilisant EventBridge -> Step Functions -> Lambda pour coordonner le confinement, la copie des preuves, les notifications SNS aux responsables d’incidents et la création de tickets dans le système ITSM existant.
5. Fournir un accès contrôlé pour l’investigation numérique en exigeant AWS Systems Manager Session Manager pour les sessions d’enquête en direct, avec journalisation des sessions dans CloudWatch Logs et le bucket S3 d’investigation, autorisé uniquement pour un rôle IAM d’investigation désigné avec MFA et des informations d’identification temporaires.

Justification : Cette approche isole rapidement la menace, préserve les artefacts immuables et les journaux centralisés pour l’analyse, automatise les étapes de réponse reproductibles pour réduire le temps de confinement, et impose un accès d’investigation auditable et à moindre privilège via Session Manager, conformément aux meilleures pratiques AWS.

← Sécurité des conteneurs et serverless · Tous les domaines

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →