Forensique Cloud : Analyser les Logs CloudTrail, Azure et GCP

Introduction : le DFIR cloud, un paradigme différent

La forensique cloud représente un changement de paradigme fondamental par rapport à la forensique traditionnelle. En environnement on-premise, l'analyste peut saisir des disques durs, capturer la mémoire vive et analyser les artefacts du système de fichiers à loisir. Dans le cloud, il n'y a pas de disque physique à saisir, les instances sont éphémères, l'auto-scaling détruit automatiquement les ressources, et les données forensiques sont dispersées entre les logs du provider, les logs applicatifs et les métadonnées de configuration. Le DFIR cloud exige une nouvelle méthodologie, de nouveaux outils et une compréhension approfondie des mécanismes de journalisation propres à chaque cloud provider.

Les trois hyperscalers -- AWS, Microsoft Azure et Google Cloud Platform -- proposent chacun leur propre écosystème de journalisation avec des nomenclatures, des formats et des niveaux de détail différents. AWS utilise CloudTrail pour les appels API, VPC Flow Logs pour le réseau et S3 Access Logs pour le stockage. Azure s'appuie sur Activity Logs, Sign-in Logs et Diagnostic Logs. GCP propose Admin Activity Logs, Data Access Logs et Cloud Logging. Comprendre ces différences et savoir où chercher l'information pertinente est la compétence fondamentale du forensiqueur cloud.

Cet article propose un guide complet de forensique cloud couvrant les trois providers majeurs. Nous examinerons en détail les sources de logs disponibles, les techniques de requêtage et d'analyse, la méthodologie DFIR adaptée au cloud, l'investigation des compromissions IAM, les outils spécialisés et un cas pratique complet sur AWS. L'objectif est de fournir aux analystes DFIR les connaissances nécessaires pour mener des investigations efficaces dans des environnements cloud, qu'ils soient mono-cloud ou multi-cloud.

Point clé : en forensique cloud, la préparation est tout. Si la journalisation n'est pas correctement configurée avant l'incident, les données forensiques nécessaires à l'investigation n'existeront tout simplement pas. La forensique cloud commence par la gouvernance.

AWS CloudTrail : la pierre angulaire de la forensique AWS

Architecture de CloudTrail

AWS CloudTrail enregistre chaque appel API effectué dans un compte AWS, qu'il provienne de la console, du CLI, du SDK ou d'un service AWS. Chaque entrée CloudTrail contient l'identité de l'appelant (ARN de l'utilisateur ou du rôle), l'action effectuée (nom de l'API), les paramètres de la requête, la réponse, l'adresse IP source, l'User-Agent et un horodatage précis. CloudTrail distingue trois types d'événements :

Type d'événement	Description	Exemples	Activation
Management Events	Actions sur les ressources AWS (plan de contrôle)	CreateUser, RunInstances, PutBucketPolicy	Activé par défaut
Data Events	Actions sur les données (plan de données)	GetObject (S3), Invoke (Lambda)	Désactivé par défaut (coût)
Insights Events	Détection automatique d'anomalies d'utilisation API	Pic d'appels DeleteObject	Optionnel (payant)

Requêtage avec Amazon Athena

Pour les investigations portant sur de grandes périodes ou des volumes importants de logs, Amazon Athena permet de requêter les fichiers CloudTrail stockés dans S3 avec du SQL standard. La première étape consiste à créer une table Athena pointant vers le bucket CloudTrail :

-- Création de la table Athena pour CloudTrail
CREATE EXTERNAL TABLE cloudtrail_logs (
    eventVersion STRING,
    userIdentity STRUCT<
        type: STRING,
        principalId: STRING,
        arn: STRING,
        accountId: STRING,
        invokedBy: STRING,
        accessKeyId: STRING,
        userName: STRING,
        sessionContext: STRUCT<
            attributes: STRUCT,
            sessionIssuer: STRUCT
        >
    >,
    eventTime STRING,
    eventSource STRING,
    eventName STRING,
    awsRegion STRING,
    sourceIPAddress STRING,
    userAgent STRING,
    errorCode STRING,
    errorMessage STRING,
    requestParameters STRING,
    responseElements STRING,
    resources ARRAY>
)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
LOCATION 's3://mon-bucket-cloudtrail/AWSLogs/123456789012/CloudTrail/'

-- Requête : toutes les actions d'un utilisateur compromis
SELECT eventTime, eventName, sourceIPAddress, userAgent, errorCode
FROM cloudtrail_logs
WHERE userIdentity.arn LIKE '%compromised-user%'
AND eventTime BETWEEN '2026-01-15T00:00:00Z' AND '2026-02-01T00:00:00Z'
ORDER BY eventTime;

-- Requête : connexions depuis des IPs inhabituelles
SELECT sourceIPAddress, COUNT(*) as nb_events,
       MIN(eventTime) as first_seen, MAX(eventTime) as last_seen,
       ARRAY_AGG(DISTINCT eventName) as actions
FROM cloudtrail_logs
WHERE userIdentity.arn LIKE '%admin%'
AND eventTime > '2026-01-01'
GROUP BY sourceIPAddress
ORDER BY nb_events DESC;

Sources complémentaires AWS

VPC Flow Logs capturent les métadonnées des flux réseau (IP source/destination, ports, protocole, bytes, action accept/reject) au niveau de l'interface réseau (ENI), du sous-réseau ou du VPC. Ils sont essentiels pour détecter les mouvements latéraux entre instances, les connexions vers des IP de C2 et l'exfiltration de données. Les Flow Logs peuvent être publiés vers CloudWatch Logs, S3 ou Kinesis Data Firehose.

S3 Access Logs fournissent un détail des requêtes effectuées sur chaque bucket (méthode HTTP, clé d'objet, statut HTTP, bytes transférés). Ils complètent les Data Events de CloudTrail avec des métadonnées supplémentaires comme le referer et les headers HTTP.

Amazon GuardDuty est un service de détection de menaces qui analyse automatiquement les logs CloudTrail, VPC Flow Logs et DNS pour identifier les comportements suspects. Les findings GuardDuty constituent un point de départ précieux pour l'investigation : chaque finding contient un type de menace, un score de sévérité, les ressources affectées et les détails techniques. Pour la forensique, les findings de type UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B, Exfiltration:S3/MaliciousIPCaller ou PrivilegeEscalation:IAMUser/AnomalousBehavior sont particulièrement pertinents.

Azure : Activity Logs, Sign-in Logs et Sentinel

Architecture de journalisation Azure

Microsoft Azure propose un écosystème de journalisation multi-couches centré autour d'Azure Monitor. Les principales sources forensiques sont :

Azure Activity Log (anciennement Audit Log) enregistre les opérations effectuées sur les ressources Azure au niveau du plan de contrôle : création, modification et suppression de ressources, affectation de rôles RBAC, déploiements ARM. Chaque entrée contient l'identité de l'appelant, l'opération, le statut, les propriétés de la ressource et un horodatage. Les Activity Logs sont conservés 90 jours par défaut et peuvent être exportés vers un Log Analytics Workspace pour une rétention plus longue.

Azure AD (Entra ID) Sign-in Logs constituent la source la plus critique pour la forensique d'identité dans Azure. Ils enregistrent chaque authentification (réussie ou échouée) avec des détails précieux : adresse IP, localisation géographique, appareil utilisé, application cliente, résultat des politiques de Conditional Access, statut MFA, et la raison de l'échec le cas échéant. Les Sign-in Logs distinguent les connexions interactives des connexions non-interactives (service principals, applications), ce qui est essentiel pour détecter les abus de service principals.

Diagnostic Logs fournissent la journalisation au niveau des ressources individuelles : accès aux Key Vaults, requêtes sur les bases de données SQL, opérations sur les Storage Accounts. Chaque type de ressource Azure a ses propres catégories de diagnostic qui doivent être explicitement activées et routées vers un Log Analytics Workspace ou un Event Hub.

Requêtage avec KQL (Kusto Query Language)

KQL (Kusto Query Language) est le langage de requête natif d'Azure Monitor et Microsoft Sentinel. Sa syntaxe pipe-based est particulièrement adaptée à l'investigation forensique :

// Connexions suspectes : échecs suivis de succès (password spray réussi)
SigninLogs
| where TimeGenerated > ago(30d)
| summarize 
    FailedCount = countif(ResultType != "0"),
    SuccessCount = countif(ResultType == "0"),
    DistinctIPs = dcount(IPAddress),
    IPList = make_set(IPAddress)
  by UserPrincipalName
| where FailedCount > 50 and SuccessCount > 0
| sort by FailedCount desc

// Détection de connexion impossible (impossible travel)
SigninLogs
| where ResultType == "0"
| project TimeGenerated, UserPrincipalName, IPAddress, Location
| sort by UserPrincipalName, TimeGenerated
| extend PrevTime = prev(TimeGenerated, 1), PrevLocation = prev(Location, 1), PrevUser = prev(UserPrincipalName, 1)
| where UserPrincipalName == PrevUser
| extend TimeDiffMinutes = datetime_diff('minute', TimeGenerated, PrevTime)
| where TimeDiffMinutes < 60 and Location != PrevLocation and PrevLocation != ""
| project TimeGenerated, UserPrincipalName, Location, PrevLocation, TimeDiffMinutes, IPAddress

// Opérations sensibles sur les rôles RBAC
AzureActivity
| where OperationNameValue has_any ("Microsoft.Authorization/roleAssignments/write", 
    "Microsoft.Authorization/roleDefinitions/write")
| where ActivityStatusValue == "Success"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, Properties
| sort by TimeGenerated desc

// Investigation Key Vault : accès aux secrets
AzureDiagnostics
| where ResourceType == "VAULTS"
| where OperationName in ("SecretGet", "SecretList", "KeyGet", "CertificateGet")
| project TimeGenerated, CallerIPAddress, identity_claim_upn_s, OperationName, id_s
| sort by TimeGenerated desc

Microsoft Sentinel pour la forensique

Microsoft Sentinel est le SIEM cloud-native d'Azure qui centralise les logs de l'ensemble de l'écosystème Microsoft (Azure, M365, Entra ID, Defender) et de sources tierces. Pour la forensique cloud, Sentinel offre plusieurs avantages : la corrélation automatique entre les logs Azure et les logs Microsoft 365 (Exchange Online, SharePoint, Teams), les workbooks de visualisation prêts à l'emploi, et les capacités de hunting avec les requêtes KQL. Les tables Sentinel les plus pertinentes pour la forensique sont SigninLogs, AuditLogs, AzureActivity, SecurityAlert et OfficeActivity.

L'API Microsoft Graph complète les sources de logs en donnant accès programmatique aux audit logs d'Entra ID, aux sign-in logs et aux détections Identity Protection. Pour une investigation approfondie, l'API Graph permet de récupérer les détails des applications enregistrées (app registrations), des consentements OAuth accordés et des configurations de service principal -- des éléments essentiels pour comprendre les attaques par abus d'applications.

GCP : Audit Logs et Cloud Logging

Architecture de journalisation GCP

Google Cloud Platform organise sa journalisation autour de Cloud Logging (anciennement Stackdriver), qui centralise quatre types de logs d'audit :

Admin Activity Logs enregistrent les opérations qui modifient la configuration ou les métadonnées des ressources GCP : création de VMs, modification de règles firewall, changement de permissions IAM. Ces logs sont toujours activés, gratuits et conservés 400 jours. Ils sont l'équivalent GCP des Management Events de CloudTrail.

Data Access Logs enregistrent les opérations de lecture de données et de métadonnées : lecture d'objets Cloud Storage, requêtes BigQuery, accès aux secrets Secret Manager. Comme les Data Events de CloudTrail, ils sont désactivés par défaut en raison de leur volume potentiel et doivent être explicitement activés par service.

System Event Logs sont générés par Google Cloud lui-même pour les actions système automatiques comme le live migration de VMs ou la mise à jour de quotas. Policy Denied Logs enregistrent les tentatives d'accès refusées par les VPC Service Controls ou les Organization Policies.

# Requête Cloud Logging : activité suspecte sur IAM
gcloud logging read 'resource.type="project" AND
protoPayload.methodName=("google.iam.admin.v1.CreateServiceAccountKey" OR
"google.iam.admin.v1.SetIamPolicy" OR
"SetIamPolicy") AND
timestamp>="2026-01-15T00:00:00Z"' \
--project=mon-projet --format=json | jq '.[] | {
    timestamp: .timestamp,
    caller: .protoPayload.authenticationInfo.principalEmail,
    method: .protoPayload.methodName,
    resource: .protoPayload.resourceName,
    ip: .protoPayload.requestMetadata.callerIp
}'

# Détection de création de clés de service account (persistence)
gcloud logging read 'protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"
AND timestamp>="2026-01-01T00:00:00Z"' \
--project=mon-projet --format=json

# Accès aux secrets (exfiltration potentielle)
gcloud logging read 'protoPayload.methodName="google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion"
AND timestamp>="2026-01-15T00:00:00Z"' \
--project=mon-projet --format=json

Chronicle (Google SecOps)

Chronicle (maintenant intégré dans Google Security Operations) est la plateforme SIEM de Google qui offre une rétention de 12 mois des logs à coût fixe, indépendamment du volume ingéré. Pour la forensique GCP, Chronicle permet d'ingérer les Cloud Audit Logs, les VPC Flow Logs et les logs Cloud DNS, puis de les corréler avec les détections Security Command Center (SCC). La fonctionnalité "Entity Graph" de Chronicle visualise les relations entre utilisateurs, adresses IP, domaines et ressources, facilitant l'identification des mouvements latéraux dans l'environnement GCP.

Méthodologie DFIR Cloud : Preserve, Collect, Analyze

Les défis spécifiques du cloud

La forensique cloud présente des défis qui n'existent pas en environnement on-premise. Le premier est l'éphémérité des ressources : une instance EC2 lancée dans un Auto Scaling Group peut être terminée automatiquement quelques minutes après un incident, emportant avec elle ses logs locaux, sa mémoire et ses artefacts disque. Un conteneur Fargate ou Cloud Run peut avoir une durée de vie de quelques secondes. Un pod Kubernetes peut être recyclé par un rolling update. Si la collecte forensique n'est pas automatisée et proactive, les preuves disparaissent.

Le deuxième défi est le modèle de responsabilité partagée. Les logs de l'infrastructure sous-jacente (hyperviseur, réseau physique, stockage) sont gérés par le cloud provider et ne sont généralement pas accessibles au client. Pour les services managés (RDS, Lambda, Cloud Functions, App Service), le client n'a accès qu'aux logs applicatifs exposés par le service, pas aux logs système du serveur sous-jacent. Cela crée des zones d'ombre dans l'investigation.

Le troisième défi est la dispersion des données. Un incident cloud typique peut impliquer des logs répartis entre CloudTrail (appels API), VPC Flow Logs (réseau), CloudWatch Logs (applicatif), S3 Access Logs (stockage), GuardDuty findings (détection), et les logs des services tiers (WAF, CDN, DNS). Chaque source a son propre format, sa propre rétention et son propre mécanisme d'accès.

Phase 1 : Preserve (Préserver)

La préservation est la première et la plus urgente des étapes. Elle doit commencer dans les minutes qui suivent la détection de l'incident :

• Snapshots des volumes EBS / Disques managés : capturer l'état du disque des instances suspectes avant toute intervention. Sur AWS : aws ec2 create-snapshot. Sur Azure : az snapshot create. Sur GCP : gcloud compute disks snapshot.
• Capture mémoire : utiliser SSM Run Command (AWS) ou une extension VM (Azure/GCP) pour déclencher une capture mémoire via LiME ou AVML avant de toucher à l'instance.
• Isolation réseau : appliquer un Security Group restrictif (AWS), un NSG vide (Azure) ou une règle firewall deny-all (GCP) à l'instance compromise pour stopper la communication avec le C2 sans la terminer.
• Protection des logs : vérifier que les logs CloudTrail/Activity/Audit ne peuvent pas être supprimés par l'attaquant (Object Lock S3, immutable storage Azure, bucket lock GCP).
• Sauvegarde des métadonnées : exporter la configuration actuelle de toutes les ressources impliquées via AWS Config, Azure Resource Graph ou GCP Asset Inventory.

# AWS : Préservation d'urgence d'une instance compromise
# 1. Snapshot du volume
INSTANCE_ID="i-0123456789abcdef0"
VOLUME_ID=$(aws ec2 describe-instances --instance-ids $INSTANCE_ID \
  --query 'Reservations[].Instances[].BlockDeviceMappings[].Ebs.VolumeId' --output text)
aws ec2 create-snapshot --volume-id $VOLUME_ID --description "DFIR-$(date +%Y%m%d)-$INSTANCE_ID"

# 2. Isolation réseau (Security Group deny-all)
ISOLATION_SG=$(aws ec2 create-security-group --group-name "DFIR-Isolation-$(date +%s)" \
  --description "Forensic isolation" --vpc-id vpc-xxx --output text)
aws ec2 modify-instance-attribute --instance-id $INSTANCE_ID --groups $ISOLATION_SG

# 3. Capture de la console output
aws ec2 get-console-output --instance-id $INSTANCE_ID --output text > console_output.txt

# 4. Export des métadonnées de l'instance
aws ec2 describe-instances --instance-ids $INSTANCE_ID > instance_metadata.json

Phase 2 : Collect (Collecter)

La collecte rassemble toutes les données forensiques pertinentes dans un environnement d'analyse sécurisé. Pour la forensique cloud, la collecte couvre trois dimensions :

Logs du cloud provider : exporter les logs CloudTrail, Activity Logs ou Cloud Audit Logs pour la période d'investigation (typiquement, 90 jours avant la détection). Pour AWS, les logs sont déjà dans S3 si un trail est configuré. Pour Azure, il faut exporter le Log Analytics Workspace. Pour GCP, utiliser gcloud logging read avec des filtres temporels ou configurer un sink vers BigQuery pour l'analyse.

Artefacts système : à partir des snapshots préservés, créer un volume et le monter sur une instance d'analyse pour extraire les logs système, les configurations, les binaires suspects et les artefacts forensiques classiques (crontab, authorized_keys, bash_history, journalctl).

Configuration et état : collecter l'état actuel de la configuration IAM (politiques, rôles, utilisateurs, clés d'accès), des Security Groups, des bucket policies, des VPC et de tous les éléments de configuration qui auraient pu être modifiés par l'attaquant.

Investigation IAM : l'axe principal du DFIR cloud

Abus de credentials

Dans le cloud, l'identité est le nouveau périmètre. La majorité des incidents cloud impliquent un abus de credentials : clés d'accès IAM compromises (via un dépôt Git public, un fichier de configuration exposé, ou un infostealer), tokens de session volés, ou exploitation d'un rôle IAM trop permissif. L'investigation IAM est donc l'axe principal de la forensique cloud.

Pour investiguer un abus de credentials AWS, l'analyste doit d'abord identifier la clé d'accès compromise (Access Key ID). CloudTrail enregistre cette information dans le champ userIdentity.accessKeyId. Une fois la clé identifiée, il faut rechercher toutes les actions effectuées avec cette clé, les adresses IP sources, les régions utilisées et les services accédés. Un pattern classique de credential compromise est l'apparition soudaine d'appels API depuis une adresse IP géographiquement éloignée ou depuis un User-Agent inhabituel (par exemple, un outil de pentest alors que l'utilisateur légitime utilise la console).

-- Athena : Toutes les actions d'une clé d'accès compromise
SELECT eventTime, eventName, eventSource, sourceIPAddress, userAgent,
       errorCode, awsRegion
FROM cloudtrail_logs
WHERE userIdentity.accessKeyId = 'AKIAIOSFODNN7EXAMPLE'
AND eventTime > '2026-01-15'
ORDER BY eventTime;

-- Athena : Détection d'utilisation multi-IP d'une même clé
SELECT userIdentity.accessKeyId,
       ARRAY_AGG(DISTINCT sourceIPAddress) as ips,
       COUNT(DISTINCT sourceIPAddress) as ip_count,
       COUNT(*) as total_events
FROM cloudtrail_logs
WHERE eventTime > '2026-01-01'
GROUP BY userIdentity.accessKeyId
HAVING COUNT(DISTINCT sourceIPAddress) > 5
ORDER BY ip_count DESC;

Role assumption et mouvement latéral

Le mouvement latéral dans le cloud passe principalement par l'assumption de rôles (sts:AssumeRole sur AWS, az role assignment sur Azure). Un attaquant qui compromet un compte avec la permission sts:AssumeRole peut pivoter vers d'autres comptes AWS membres d'une organisation, potentiellement avec des privilèges différents (et souvent plus élevés) que le compte initial.

L'investigation de la chaîne d'assumption de rôles requiert de tracer les événements AssumeRole dans CloudTrail en suivant les champs userIdentity.sessionContext.sessionIssuer qui révèlent le rôle source, et requestParameters.roleArn qui indique le rôle cible. Dans les environnements multi-comptes, l'attaquant peut enchaîner plusieurs assumptions de rôles (role chaining), créant une chaîne de pivots qui traverse les frontières de comptes.

Sur Azure, le mouvement latéral IAM passe par l'attribution de rôles RBAC (Microsoft.Authorization/roleAssignments/write), la création de service principals avec des permissions sur d'autres abonnements, ou l'exploitation de consentements OAuth mal contrôlés. Sur GCP, le mécanisme équivalent est l'impersonation de service accounts (iam.serviceAccounts.actAs) et la création de clés de service account pour la persistence.

Outils spécialisés pour la forensique cloud

Prowler : audit de sécurité et forensique AWS

Prowler est un outil open source d'audit de sécurité AWS, Azure et GCP qui exécute des centaines de vérifications basées sur les benchmarks CIS, PCI-DSS, HIPAA et les bonnes pratiques AWS. Pour la forensique, Prowler permet de rapidement évaluer la posture de sécurité d'un compte compromis : CloudTrail est-il activé dans toutes les régions ? Les Data Events sont-ils collectés ? Les logs sont-ils protégés contre la suppression ? Les clés d'accès sont-elles rotées ? L'exécution de Prowler en début d'investigation fournit un état des lieux de la configuration de sécurité qui aide à comprendre les lacunes exploitées par l'attaquant.

# Prowler : audit rapide de la posture forensique AWS
prowler aws --severity critical high --service cloudtrail iam s3 guardduty

# Prowler : vérification spécifique de la configuration CloudTrail
prowler aws -c cloudtrail_multi_region_enabled cloudtrail_s3_dataevents_enabled \
  cloudtrail_log_file_validation_enabled cloudtrail_logs_s3_bucket_is_not_publicly_accessible

ScoutSuite : audit multi-cloud

ScoutSuite est un outil d'audit multi-cloud open source (NCC Group) qui collecte la configuration de sécurité d'un compte AWS, Azure ou GCP et produit un rapport HTML interactif. Pour la forensique, ScoutSuite est précieux pour cartographier rapidement les permissions IAM excessives, les ressources mal configurées et les points d'exposition qui auraient pu faciliter l'intrusion. Son rapport identifie les "dangers" (configurations à risque critique) et les "warnings" (configurations sous-optimales) qui orientent l'investigation.

CloudQuery : collecte structurée de configuration

CloudQuery est un outil ETL (Extract-Transform-Load) qui collecte la configuration de toutes les ressources cloud dans une base de données relationnelle (PostgreSQL) ou un data lake. Pour la forensique cloud, CloudQuery permet de capturer un snapshot complet de la configuration du compte au moment de l'incident, puis de requêter cette base avec SQL pour identifier les modifications suspectes. La comparaison entre un snapshot pré-incident (s'il existe) et le snapshot post-incident révèle les changements effectués par l'attaquant.

Invictus IR : framework de réponse cloud

Invictus IR est un framework open source spécialement conçu pour la réponse à incident dans le cloud. Il automatise la collecte des logs CloudTrail, la création de snapshots, l'extraction des artefacts et la génération de rapports. Invictus IR est particulièrement utile pour les équipes qui ne disposent pas d'un playbook de réponse cloud mature. Le framework implémente les meilleures pratiques DFIR cloud, notamment la préservation des preuves avant toute action de remédiation.

Cas pratique : investigation d'un incident AWS

Reconstituons l'investigation d'un incident réel (anonymisé) sur AWS. L'alerte initiale provient de GuardDuty qui détecte un finding UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS indiquant que des credentials de rôle EC2 sont utilisées depuis une adresse IP externe au réseau AWS.

Étape 1 : Identification du vecteur d'entrée

L'analyse de GuardDuty révèle que les credentials exfiltrées appartiennent au rôle EC2-WebApp-Role attaché à l'instance i-0abc123def456789. La requête CloudTrail montre que ces credentials sont utilisées depuis l'IP 185.220.x.x (noeud de sortie Tor) alors que l'instance se trouve dans le VPC avec l'IP privée 10.0.1.42.

L'examen des logs applicatifs de l'instance (un serveur web Node.js) révèle une vulnérabilité SSRF exploitée le 20 janvier à 14h23 UTC. L'attaquant a envoyé une requête à /api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2-WebApp-Role, récupérant les credentials temporaires du rôle EC2 via le service de métadonnées d'instance (IMDSv1).

Étape 2 : Reconstitution de la timeline

# Timeline de l'incident AWS
2026-01-20 14:23 UTC | SSRF exploitation → credentials du rôle EC2 exfiltrées
2026-01-20 14:25 UTC | sts:GetCallerIdentity depuis 185.220.x.x (vérification)
2026-01-20 14:28 UTC | s3:ListBuckets → enumeration de 47 buckets
2026-01-20 14:30 UTC | s3:ListObjectsV2 sur s3://company-confidential-data/
2026-01-20 14:32 UTC | s3:GetObject × 2847 → exfiltration de 12 GB de données
2026-01-20 14:45 UTC | iam:CreateUser "backup-service" (persistence)
2026-01-20 14:46 UTC | iam:CreateAccessKey pour "backup-service"
2026-01-20 14:47 UTC | iam:AttachUserPolicy → AdministratorAccess (!!)
2026-01-20 15:10 UTC | ec2:RunInstances × 20 → instances c5.4xlarge (cryptomining)
2026-01-20 15:15 UTC | GuardDuty finding: InstanceCredentialExfiltration.OutsideAWS
2026-01-20 15:30 UTC | GuardDuty finding: CryptoCurrency:EC2/BitcoinTool.B

Étape 3 : Évaluation de l'impact

L'analyse des Data Events CloudTrail pour S3 révèle que l'attaquant a téléchargé 2 847 objets du bucket company-confidential-data pour un total de 12 GB. L'examen du contenu du bucket montre qu'il contenait des contrats clients, des données financières et des informations personnelles, classifiant cet incident comme une fuite de données soumise à notification RGPD.

L'attaquant a également créé un utilisateur IAM backup-service avec la politique AdministratorAccess comme mécanisme de persistence. Cet utilisateur n'a pas encore été utilisé au moment de la détection, ce qui aurait pu permettre à l'attaquant de revenir ultérieurement, même après la rotation des credentials SSRF.

Étape 4 : Remédiation

Les actions de remédiation immédiates incluent : suppression de l'utilisateur backup-service, rotation de toutes les clés d'accès du compte, activation de IMDSv2 sur toutes les instances EC2, correction de la vulnérabilité SSRF dans l'application, mise en place de S3 VPC Endpoints avec des politiques restrictives, activation des Data Events CloudTrail sur tous les buckets sensibles, et terminaison des instances de cryptomining.

Conclusion

La forensique cloud est une discipline en pleine maturation qui requiert un ensemble de compétences distinct de la forensique traditionnelle. L'analyste cloud doit maîtriser les architectures de journalisation de chaque provider, comprendre les modèles IAM complexes (rôles, politiques, trust relationships, service principals), savoir requêter efficacement de grands volumes de logs (Athena SQL, KQL, Cloud Logging), et connaître les patterns d'attaque spécifiques au cloud (SSRF vers IMDS, abus d'AssumeRole, credential stuffing sur la console, exploitation de Lambda/Functions).

Le point le plus critique est la préparation. Contrairement à l'on-premise où de nombreux artefacts forensiques existent par défaut (MFT, Event Logs, Prefetch), dans le cloud, la plupart des sources de données forensiques doivent être explicitement activées et configurées avant l'incident. Un compte AWS sans Data Events CloudTrail, un tenant Azure sans export des Sign-in Logs vers un Log Analytics Workspace, ou un projet GCP sans Data Access Logs activés laissent des angles morts considérables dans l'investigation.

Les organisations multi-cloud font face à un défi supplémentaire : la corrélation d'événements entre des systèmes de logs fondamentalement différents. Les outils comme Prowler (multi-cloud), ScoutSuite et CloudQuery facilitent cette corrélation, mais la compétence de l'analyste à naviguer entre les trois écosystèmes reste irremplaçable. L'investissement dans la formation continue et les exercices pratiques de forensique cloud est la meilleure garantie de préparation face aux incidents inévitables.

Recommandation finale : mettez en place dès aujourd'hui un baseline de journalisation cloud couvrant les trois piliers : (1) logs d'API/management dans toutes les régions avec rétention longue, (2) Data Events/Access Logs sur les services contenant des données sensibles, et (3) alertes automatisées sur les actions de désactivation de la journalisation. Le coût de cette préparation est négligeable par rapport au coût d'une investigation à l'aveugle.

Partagez cet Article

Cet article vous a été utile ? Partagez-le avec votre réseau professionnel !

Partager sur X Partager sur LinkedIn Copier le Lien

Ressources & Références Officielles

Documentations officielles et outils de la communauté DFIR cloud

AWS CloudTrail Documentation

docs.aws.amazon.com

Azure Monitor & Sentinel

learn.microsoft.com

Prowler - Cloud Security Tool

github.com/prowler-cloud