RB-EVIDENCE-004: Acquisitie van control plane-logs in de cloud

Documentbeheer

1. Vereisten

• Identificatie van het getroffen cloudaccount / de subscription / het project / de tenancy
• Het incidentvenster (begin- en eindtijdstip in UTC)
• Leestoegang tot de auditlog van de cloud control plane (CloudTrail / Azure Activity / GCP Admin Activity / Oracle Audit)
• Leestoegang tot de SIEM waarheen de cloudtelemetrie wordt doorgestuurd
• Een aparte forensische bestemming (account / project / regio) voor geëxporteerde logs
• Console of CLI van de cloudprovider (AWS CLI, Azure CLI, gcloud, OCI CLI)
• Query-interface van de SIEM
• Hashingtool (bijv. sha256sum) voor geëxporteerde logarchieven

2. Stap-voor-stap-instructies

Veelgemaakte fouten

• Alleen vertrouwen op de cloud-native console (die toont vaak alleen recente activiteit - de echte forensische bron is de ruwe auditlog of de SIEM-index)
• Activiteit in andere regio's missen - de meeste providers loggen control plane-activiteit per regio; een aanvaller kan naar andere regio's pivoteren en de log van de thuisregio laat dat niet zien
• Activiteit op organisatie- / management-accountniveau missen (AWS Organizations, Azure Management Groups, GCP Organization, OCI tenancy-gebeurtenissen) - dit zijn aparte logs naast de activiteit per account
• Data plane-gebeurtenissen vergeten (bijv. toegang tot S3-objecten, KMS Decrypt-aanroepen) - bij sommige providers staan die standaard uit en moeten ze specifiek worden aangezet / doorzocht

1. Valideer de scope

   • Bevestig de ID's van het getroffen account / de subscription / het project / de tenancy
   • Bevestig het incidentvenster (verleng het minstens 7 dagen terug vanaf de vroegste indicator om verkenning vóór het incident mee te nemen)
   • Stel alle regio's / locaties binnen de scope vast (de aanvaller kan naar andere regio's zijn gepivoteerd)

2. Verzamel relevante control plane-activiteit

   Doorzoek per relevante categorie bij voorkeur de SIEM waar de data al is geïndexeerd; val zo nodig terug op de eigen log van de provider.

   Categorie	AWS	Azure	GCP	Oracle Cloud (OCI)
   Management-API-aanroepen	CloudTrail Management Events	Activity Log	Admin Activity-auditlog	Auditlog (audit.log)
   Data plane-API-aanroepen	CloudTrail Data Events (S3, KMS, Lambda)	Diagnostic Settings per dienst	Data Access-auditlog	Auditlog (data access-gebeurtenissen)
   IAM-wijzigingen	CloudTrail (iam:*, sts:AssumeRole)	Activity Log + Entra ID-audit (Microsoft.Authorization)	Admin Activity (SetIamPolicy)	Auditlog (identity:*)
   Aanmaken / wijzigen van resources	CloudTrail (Run*, Create*, Modify*, Delete*)	Activity Log	Admin Activity	Auditlog
   Sabotage van securitydiensten	CloudTrail (guardduty:*, cloudtrail:Stop*, config:*)	Activity Log (wijzigingen in Defender for Cloud, Sentinel)	Admin Activity (SCC mute/disable)	Auditlog (Cloud Guard uitgeschakeld)
   Gebeurtenissen op organisatie- / tenancyniveau	CloudTrail in het management-account	Activiteit van Management Group / Tenant Root	Auditlog van de organisatie	Audit op tenancyniveau
   Toegang over accounts / tenants heen	CloudTrail (sts:AssumeRole, external ID's)	Activity Log (Lighthouse, B2B)	Admin Activity (gedelegeerde toegang)	Auditlog (over tenancies heen)

3. Voer gerichte queries uit

   • Zoek op identiteit (ARN van gebruiker / rol / service account / workload identity)
   • Zoek op bron-IP / user-agent / regio
   • Zoek op patronen van eventnamen die relevant zijn voor het incident (bijv. iam:Create*, *:Delete*, *:StopLogging)
   • Leg per query de querytekst, het tijdvak en het aantal resultaten vast in het incidentrecord

4. Stel logs van de hele organisatie en het management-account veilig

   • Haal de vergelijkbare logs op uit de organisatie / het management-account / de tenancy root (een aparte scope naast de afzonderlijke accounts)
   • Bevestig dat een eventueel centraal archief van auditlogs (bijv. de CloudTrail-S3-bucket voor de hele organisatie, de centrale Log Analytics-workspace) intact en niet gemanipuleerd is

5. Exporteer en hash waar nodig voor de chain of custody

   • Kunnen logs nodig zijn buiten de SIEM (Legal, toezichthouder, externe forensisch onderzoekers), exporteer dan het relevante deel als één archief
   • Bereken de SHA-256 van het archief en leg de hash vast
   • Zet het over naar de aparte forensische bestemming

3. Na afloop

• Leg querytekst, tijdvakken, bronnen en eventuele exporthashes vast in het incidentticket
• Bevestig dat de loggingdiensten en centrale archieven intact zijn en tijdens het incidentvenster niet zijn gemanipuleerd

Bijdrager

Jayden Vo GitHub: https://github.com/jayden-vo

Heeft bijgedragen aan het Arcana Incident Response Documentation Framework.