Cloud Forensics : Investigation AWS et Azure : Guide Complet

Le cloud forensics AWS Azure est devenu l'une des compétences les plus critiques pour les équipes DFIR (Digital Forensics and Incident Response) en 2026. Quand une entreprise découvre une intrusion dans son infrastructure cloud, chaque minute compte : les instances EC2 peuvent être terminées, les logs CloudTrail peuvent être désactivés, et les attaquants peuvent pivoter entre comptes en quelques secondes via des rôles IAM compromis. L'investigation forensique dans le cloud ne ressemble en rien à ce que font vos analystes sur un serveur physique ou une VM on-premise. Il n'y a pas de disque dur à saisir, pas de RAM à dumper directement, et la chaîne de custody traditionnelle doit être entièrement repensée. Les incidents SolarWinds, Log4Shell, et plus récemment les compromissions massives de buckets S3 exposés ont prouvé que sans une stratégie forensique cloud définie avant l'incident, la réponse sera chaotique. Les équipes SOC françaises qui ont géré des incidents AWS en 2024-2025 l'ont appris à leurs dépens : les preuves avaient disparu avant même que le ticket d'incident soit ouvert. Ce guide donne les outils, les commandes concrètes et la méthodologie pour mener une investigation cloud forensique complète sur AWS et Azure, en respectant les contraintes légales françaises et les standards NIST SP 800-86.

Pourquoi le cloud forensics défie toutes vos certitudes ?

Si vous avez l'habitude de l'investigation forensique classique — saisie de disque, analyse mémoire, timeline NTFS — le cloud va vous forcer à désapprendre la moitié de vos réflexes. Les défis sont fondamentaux, pas juste opérationnels.

L'éphémérité des ressources est le problème numéro un. Une instance EC2 de type spot peut être terminée par AWS elle-même en deux minutes. Un conteneur Kubernetes peut être recyclé avant même que vous ayez reçu l'alerte. Dans une architecture serverless Lambda, il n'y a aucune instance persistante à analyser. Chaque configuration cloud doit donc inclure des mécanismes de préservation automatique déclenchés dès qu'une alerte de sécurité critique apparaît.

Le multi-tenancy crée une frontière que même votre fournisseur cloud ne peut pas franchir sans procédure légale. Vous partagez de l'hyperviseur avec d'autres clients, et AWS ou Azure ne vous donneront jamais accès aux logs de leur infrastructure physique. Vous êtes limité aux logs que votre compte génère.

La dispersion géographique et la juridiction complexifient la collecte. Un incident peut toucher des ressources en eu-west-1 (Irlande), us-east-1 (Virginie) et ap-southeast-1 (Singapour) simultanément. Chaque région relève d'une juridiction différente pour les réquisitions légales. Le RGPD s'applique aux données de ressortissants européens quelle que soit la région AWS hébergeant les logs.

Enfin, l'accès aux logs est limité et dépend de la configuration préexistante. Si CloudTrail n'était pas activé sur toutes les régions avant l'incident, vous n'avez pas de logs pour ces régions. Si les VPC Flow Logs n'étaient pas activés, le trafic réseau est invisible. Une règle d'or : configurez votre stack de logging forensic-ready avant d'en avoir besoin.

AWS CloudTrail — analyser les logs d'audit qui comptent vraiment

AWS CloudTrail est votre principale source de vérité pour reconstruire ce qu'un attaquant a fait dans votre compte AWS. Chaque appel API est enregistré : qui a appelé quoi, depuis quelle IP, à quel moment. Les événements les plus critiques à surveiller sont ConsoleLogin, AssumeRole, CreateUser, DeleteTrail, PutBucketPolicy, AttachRolePolicy.

Voici comment extraire les événements suspects avec AWS CloudTrail via boto3 :

import boto3
from datetime import datetime, timedelta, timezone
import json

# Client CloudTrail — spécifier la région cible
ct = boto3.client('cloudtrail', region_name='eu-west-1')

# Événements suspects sur les 7 derniers jours
start_time = datetime.now(timezone.utc) - timedelta(days=7)

# Événements critiques à investiguer en priorité
critical_events = [
    'AssumeRole', 'AssumeRoleWithWebIdentity',
    'CreateUser', 'CreateAccessKey', 'AttachUserPolicy',
    'PutRolePolicy', 'AttachRolePolicy',
    'DeleteTrail', 'StopLogging', 'UpdateTrail',
    'ConsoleLogin', 'GetSecretValue'
]

for event_name in critical_events:
    paginator = ct.get_paginator('lookup_events')
    pages = paginator.paginate(
        LookupAttributes=[{
            'AttributeKey': 'EventName',
            'AttributeValue': event_name
        }],
        StartTime=start_time,
    )

    for page in pages:
        for event in page['Events']:
            ct_event = json.loads(event.get('CloudTrailEvent', '{}'))
            user_identity = ct_event.get('userIdentity', {})
            source_ip = ct_event.get('sourceIPAddress', 'inconnu')

            # Filtrer les IPs internes légitimes
            if source_ip not in ['AWS Internal', '10.0.0.0/8']:
                print(f"[!] {event_name} | {event['EventTime']} | "
                      f"IP: {source_ip} | "
                      f"User: {user_identity.get('arn', 'N/A')}")

Les logs CloudTrail ont un format JSON standardisé. Un événement AssumeRole légitime depuis une instance EC2 aura un userIdentity.type à AssumedRole et un sourceIPAddress correspondant à l'IP interne AWS. Un AssumeRole depuis une IP géolocalisée en Russie ou en Chine, à 3h du matin, mérite une investigation immédiate. Pensez à activer CloudTrail Insights qui détecte automatiquement les anomalies d'API (pic de CreateUser, appels massifs à GetSecretValue).

VPC Flow Logs et S3 Access Logs — tracer l'exfiltration de données

CloudTrail vous dit quelles APIs ont été appelées. Les VPC Flow Logs vous disent quel trafic réseau a circulé. Ces deux sources sont complémentaires et indispensables pour détecter une exfiltration de données.

Les VPC Flow Logs capturent : IP source/destination, port source/destination, protocole, volume de bytes, statut ACCEPT/REJECT. Pour analyser des volumes massifs (des millions de lignes par heure dans les environnements de production), Amazon Athena est la solution :

# Créer une table Athena pour les VPC Flow Logs depuis S3
# Remplacer VOTRE-BUCKET et VOTRE-ACCOUNT-ID
aws athena start-query-execution \
  --query-string "
    CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
      version INT, account STRING, interfaceid STRING,
      sourceaddress STRING, destinationaddress STRING,
      sourceport INT, destinationport INT, protocol INT,
      numpackets INT, numbytes BIGINT,
      starttime INT, endtime INT, action STRING, logstatus STRING
    )
    PARTITIONED BY (dt STRING)
    ROW FORMAT DELIMITED FIELDS TERMINATED BY ' '
    LOCATION 's3://VOTRE-BUCKET/AWSLogs/VOTRE-ACCOUNT-ID/vpcflowlogs/eu-west-1/'
    TBLPROPERTIES ('has_encrypted_data'='false')
  " \
  --result-configuration "OutputLocation=s3://VOTRE-BUCKET/athena-results/"

# Requête Athena pour détecter une exfiltration (gros volumes vers IPs externes)
aws athena start-query-execution \
  --query-string "
    SELECT destinationaddress, SUM(numbytes) AS total_bytes,
           COUNT(*) AS connexions, MIN(from_unixtime(starttime)) AS premiere_connexion
    FROM vpc_flow_logs
    WHERE dt = '2026-07-15'
      AND action = 'ACCEPT'
      AND NOT (destinationaddress LIKE '10.%'
               OR destinationaddress LIKE '172.16.%'
               OR destinationaddress LIKE '192.168.%')
    GROUP BY destinationaddress
    HAVING SUM(numbytes) > 100000000  -- > 100 MB vers une même IP externe
    ORDER BY total_bytes DESC
    LIMIT 50
  " \
  --result-configuration "OutputLocation=s3://VOTRE-BUCKET/athena-results/"

Pour les S3 Access Logs, activez-les sur chaque bucket contenant des données sensibles. Ils enregistrent chaque requête GET/PUT/DELETE avec l'IP source et l'identité requérante. Un pattern d'exfiltration typique : des milliers de requêtes GetObject depuis une IP externe inconnue en quelques heures.

Amazon GuardDuty — exploiter les findings en investigation

GuardDuty est souvent configuré mais peu exploité lors des investigations. C'est une erreur : ses findings constituent une timeline pré-construite de l'attaque, corrélant CloudTrail, VPC Flow Logs et DNS. Les findings à valeur forensique maximale incluent UnauthorizedAccess:IAMUser/MaliciousIPCaller, Backdoor:EC2/C&CActivity.B, CryptoCurrency:EC2/BitcoinTool.B, et surtout Impact:S3/MaliciousIPCaller.Custom.

# Extraire tous les findings GuardDuty HIGH et CRITICAL des 30 derniers jours
aws guardduty list-detectors --query 'DetectorIds[0]' --output text | xargs -I{} \
  aws guardduty list-findings \
    --detector-id {} \
    --finding-criteria '{
      "Criterion": {
        "severity": {"Gte": 7},
        "updatedAt": {"Gte": '$(date -d "30 days ago" +%s000)'}
      }
    }' \
    --query 'FindingIds' --output text | \
  xargs -I{} aws guardduty get-findings \
    --detector-id VOTRE-DETECTOR-ID \
    --finding-ids {} \
    --output json > guardduty_findings.json

# Parser les findings pour extraction de la timeline
python3 -c "
import json
with open('guardduty_findings.json') as f:
    data = json.load(f)
for finding in data.get('Findings', []):
    print(f\"{finding['UpdatedAt']} | Sév: {finding['Severity']} | {finding['Type']} | {finding.get('Title', '')}\")
" | sort

Azure Monitor et Sentinel — investigation KQL

Sur Azure, Azure Monitor et Log Analytics Workspace jouent le rôle de CloudTrail. Les Azure Activity Logs enregistrent toutes les opérations Azure Resource Manager (création/modification/suppression de ressources). Les Azure AD Sign-in Logs et Audit Logs tracent les authentifications et modifications d'identités. Microsoft Sentinel centralise ces sources et permet des requêtes KQL (Kusto Query Language) sophistiquées.

Voici des requêtes KQL essentielles pour investiguer un incident Azure :

# KQL — Connexions depuis des IPs inhabituelles (30 derniers jours)
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "0"  // Connexion réussie
| summarize count(), make_set(IPAddress) by UserPrincipalName, Location
| where array_length(set_IPAddress) > 3  // Connexions depuis plus de 3 IPs différentes
| order by count_ desc

# KQL — Élévation de privilèges Azure AD (ajout aux rôles admin)
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName contains "Add member to role"
| where TargetResources[0].modifiedProperties has "Global Administrator"
       or TargetResources[0].modifiedProperties has "Privileged Role Administrator"
| project TimeGenerated, InitiatedBy, TargetResources, Result
| order by TimeGenerated desc

# KQL — Modifications de règles firewall NSG (détection évasion)
AzureActivity
| where TimeGenerated > ago(7d)
| where OperationNameValue contains "MICROSOFT.NETWORK/NETWORKSECURITYGROUPS"
| where ActivityStatusValue == "Success"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, Properties
| order by TimeGenerated desc

La corrélation entre Azure AD Audit Logs, Activity Logs, et Microsoft Defender for Cloud alerts dans Sentinel permet de reconstituer une kill chain complète. Pour les investigations avancées, le threat hunting Microsoft 365 avec Sentinel couvre les techniques de chasse aux menaces persistantes dans les environnements hybrides.

Microsoft Defender for Cloud — lire les alertes comme un analyste

Microsoft Defender for Cloud (anciennement Azure Security Center) génère des alertes de sécurité classifiées par sévérité et MITRE ATT&CK. Lors d'une investigation, ces alertes constituent un point de départ précieux mais pas infaillible — les faux positifs existent, et les attaquants sophistiqués savent contourner les détections basées sur des règles.

Les alertes critiques à prioriser en investigation : Suspicious authentication activity (credential stuffing détecté), Azure DNS suspicious activity (DNS tunneling potentiel), Possible data exfiltration, Fileless attack technique detected. Chaque alerte contient des entités associées (VM, utilisateur, IP) qui servent de pivot pour l'investigation. Utilisez le bouton "Investigate" dans le portail pour accéder au graphe d'investigation automatisé qui corrèle les entités entre elles.

Pour automatiser la récupération des alertes : les playbooks d'incident response automatisés avec IA permettent de déclencher des workflows Logic Apps ou Azure Functions dès qu'une alerte Defender for Cloud atteint un niveau de sévérité défini.

Préservation des preuves cloud — agir avant que tout disparaisse

La préservation est l'action numéro un avant toute investigation. Si une instance EC2 est compromise et que vous commencez à l'analyser sans d'abord prendre un snapshot, le risque de perte de preuves est réel. Voici le workflow de préservation AWS :

import boto3
import hashlib
import json
from datetime import datetime, timezone

def preserve_ec2_instance(instance_id: str, region: str = 'eu-west-1'):
    """
    Préservation forensique d'une instance EC2 :
    1. Isolation réseau (groupe de sécurité vide)
    2. Snapshot de tous les volumes EBS
    3. Export des métadonnées et tags
    4. Calcul du hash de vérification
    """
    ec2 = boto3.client('ec2', region_name=region)
    timestamp = datetime.now(timezone.utc).strftime('%Y%m%d-%H%M%S')

    # 1. Isoler l'instance — créer un SG vide et l'attacher
    isolation_sg = ec2.create_security_group(
        GroupName=f'forensic-isolation-{timestamp}',
        Description='Groupe isolement forensique - aucune règle ingress/egress',
        VpcId='vpc-XXXXXX'  # Remplacer par votre VPC ID
    )
    sg_id = isolation_sg['GroupId']

    # Récupérer les volumes attachés
    instance = ec2.describe_instances(InstanceIds=[instance_id])
    volumes = []
    for reservation in instance['Reservations']:
        for inst in reservation['Instances']:
            for bdm in inst.get('BlockDeviceMappings', []):
                volumes.append(bdm['Ebs']['VolumeId'])

    # 2. Snapshot de chaque volume EBS
    snapshots = []
    for vol_id in volumes:
        snap = ec2.create_snapshot(
            VolumeId=vol_id,
            Description=f'FORENSIC-{instance_id}-{timestamp}',
            TagSpecifications=[{
                'ResourceType': 'snapshot',
                'Tags': [
                    {'Key': 'forensic', 'Value': 'true'},
                    {'Key': 'source-instance', 'Value': instance_id},
                    {'Key': 'collection-time-utc', 'Value': timestamp}
                ]
            }]
        )
        snapshots.append({
            'volume_id': vol_id,
            'snapshot_id': snap['SnapshotId'],
            'state': snap['State']
        })
        print(f"[+] Snapshot {snap['SnapshotId']} créé pour le volume {vol_id}")

    # 3. Export des métadonnées (chain of custody)
    custody_record = {
        'instance_id': instance_id,
        'region': region,
        'collection_time_utc': timestamp,
        'snapshots': snapshots,
        'analyst': 'DFIR-Team'  # À personnaliser
    }

    # Sérialiser et calculer le hash SHA-256
    custody_json = json.dumps(custody_record, sort_keys=True)
    sha256 = hashlib.sha256(custody_json.encode()).hexdigest()
    custody_record['record_sha256'] = sha256

    print(f"[+] Chain of custody SHA-256: {sha256}")
    return custody_record

# Usage
record = preserve_ec2_instance('i-0abc123def456', 'eu-west-1')
print(json.dumps(record, indent=2))

Sur Azure, la préservation d'un disque managé s'effectue via :

# Azure CLI — snapshot d'un disque managé pour préservation forensique
RESOURCE_GROUP="rg-production"
DISK_NAME="vm-compromise-OsDisk"
SNAPSHOT_NAME="forensic-snapshot-$(date +%Y%m%d-%H%M%S)"

az snapshot create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$SNAPSHOT_NAME" \
  --source "$DISK_NAME" \
  --tags forensic=true incident-date="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

echo "[+] Snapshot créé : $SNAPSHOT_NAME"

Consultez également notre guide forensics Windows expert pour les techniques d'analyse des images disque une fois les snapshots collectés.

Chaîne de custody numérique pour les preuves cloud

La recevabilité juridique des preuves numériques cloud repose sur une chaîne de custody irréprochable. En France, les exigences du Code de procédure pénale (Article 706-54 et suivants) s'appliquent aux réquisitions informatiques, et le Règlement e-Evidence (2024) facilite les demandes transfrontalières directement auprès des fournisseurs.

Chaque artefact collecté doit être documenté avec : horodatage UTC précis (pas de timezone locale), hash SHA-256 calculé immédiatement après la collecte, identité du collecteur, méthode de collecte, et traçabilité de chaque accès ultérieur. L'outil RFC 3161 Time-Stamp Protocol permet de horodater cryptographiquement chaque preuve auprès d'une autorité de timestamping reconnue.

Pour l'automatisation de la collecte et la création de la chain of custody, automatiser sa veille threat intelligence présente des patterns d'automatisation réutilisables pour la gestion des incidents.

GCP Cloud Audit Logs — comparaison rapide pour les environnements multi-cloud

Les organisations multi-cloud doivent maîtriser les équivalents GCP. Cloud Audit Logs sur GCP se décompose en Admin Activity Logs (équivalent CloudTrail management events), Data Access Logs (équivalent S3 Access Logs), et System Event Logs. L'export vers BigQuery permet des analyses SQL massives similaires à Athena :

# BigQuery — anomalies d'accès sur GCP (exemple de requête)
bq query --use_legacy_sql=false '
  SELECT
    protopayload_auditlog.authenticationInfo.principalEmail AS user,
    COUNT(*) AS api_calls,
    COUNTIF(protopayload_auditlog.status.code != 0) AS errors
  FROM `projet.dataset.cloudaudit_googleapis_com_activity_*`
  WHERE _TABLE_SUFFIX = FORMAT_DATE("%Y%m%d", CURRENT_DATE())
    AND protopayload_auditlog.methodName LIKE "%delete%"
  GROUP BY user
  HAVING errors > 10
  ORDER BY errors DESC
'

Tableau comparatif des capacités forensiques AWS vs Azure vs GCP

Aspects légaux du cloud forensics en France

La CISA Cloud Incident Response fournit un cadre de référence reconnu internationalement. En France, la collecte de preuves cloud obéit au Code de procédure pénale et au RGPD. Les points clés :

• RGPD et logs : les logs contenant des IPs, identifiants ou emails sont des données personnelles. La base légale pour les traiter en investigation est l'Article 6(1)(c) CPP (obligation légale) ou 6(1)(f) (intérêts légitimes).
• Conservation : la prescription pénale (20 ans pour les crimes, 6 ans pour les délits) dicte les durées minimales de conservation des preuves.
• Réquisitions transfrontalières : le Règlement e-Evidence (2024) permet des demandes directes aux fournisseurs cloud sans passer par l'entraide judiciaire classique — délais réduits de 18 mois à 10 jours pour les urgences.

Le standard NIST SP 800-86 "Guide to Integrating Forensic Techniques into Incident Response" reste la référence méthodologique internationale pour structurer vos investigations forensiques cloud.

Questions fréquentes

Combien de temps AWS conserve-t-il les logs CloudTrail ?

Par défaut, AWS CloudTrail conserve les événements de management 90 jours dans la console CloudTrail. Pour une rétention longue durée, configurez CloudTrail pour exporter vers un bucket S3 avec des règles de lifecycle. En pratique, les équipes DFIR configurent une rétention de 1 à 3 ans sur S3 Glacier pour les comptes de production. Sans configuration explicite, les logs antérieurs à 90 jours sont irrécupérables — une contrainte majeure pour les investigations tardives.

Comment prouver l'intégrité d'un snapshot EBS en contexte judiciaire ?

Un snapshot EBS seul ne suffit pas en contexte judiciaire. Il faut enregistrer l'ID du snapshot, son horodatage de création (UTC), le hash SHA-256 d'une image disk exportée depuis le snapshot, et utiliser un service d'horodatage RFC 3161. L'export en format E01 (EnCase) via des outils comme Cado Response ou FTK Imager est recommandé pour la recevabilité devant les juridictions françaises.

Peut-on analyser la mémoire RAM d'une instance EC2 en cours d'exécution ?

Pas directement via les APIs AWS standard. AWS Systems Manager (SSM) permet d'exécuter des scripts sur les instances — vous pouvez utiliser ssm:SendCommand pour déclencher un dump mémoire avec Volatility ou LiME sur l'instance. Les outils comme Cado Response automatisent ce processus. Sur Azure, l'équivalent est Azure Run Command sur les VMs. Attention : déclencher un dump mémoire modifie légèrement l'état de la RAM — documentez précisément cette action dans la chain of custody.

GuardDuty est-il disponible dans toutes les régions AWS ?

GuardDuty doit être activé manuellement dans chaque région AWS. Une lacune fréquente en investigation : GuardDuty n'était activé que dans les régions principales (eu-west-1, us-east-1) mais pas dans les régions secondaires où l'attaquant a créé des ressources furtives. Utilisez AWS Organizations et GuardDuty delegated administrator pour activer GuardDuty dans toutes les régions de tous les comptes de l'organisation en une seule opération.

Comment investiguer un incident sur AWS Lambda (serverless) ?

Les fonctions Lambda ne laissent pas d'artefact système traditionnel. L'investigation repose entièrement sur CloudTrail (appels API Lambda), CloudWatch Logs (logs applicatifs de la fonction), et X-Ray (traces de performance). Activez AWS Lambda Insights pour obtenir des métriques détaillées (CPU, mémoire, erreurs). Si la fonction a exécuté du code malveillant, les traces seront dans CloudWatch Logs — vérifiez la rétention configurée. Consultez notre guide AWS Lambda Security pour les vecteurs d'attaque spécifiques aux fonctions serverless.

Conclusion

Le cloud forensics AWS et Azure n'est pas une discipline réservée aux grands cabinets DFIR — toute équipe SOC opérant dans le cloud doit maîtriser ces techniques. La clé est la préparation : activer CloudTrail multi-régions, configurer les VPC Flow Logs, déployer GuardDuty et Microsoft Defender for Cloud avant l'incident. Les scripts boto3 et les requêtes KQL présentés ici sont opérationnels — adaptez-les à vos environnements et intégrez-les dans vos runbooks d'incident response. Pour aller plus loin sur l'automatisation de la réponse aux incidents, consultez nos playbooks d'incident response assistés par IA.