RB-EVIDENCE-003: Acquisitie van identity- en authenticatielogs

Documentbeheer

1. Vereisten

• Getroffen identiteit (UPN/e-mailadres, gebruikers-ID, ID van de service principal, naam van het service account of ID van de API-sleutel)
• Incidentvenster (de periode waarover activiteit moet worden gereviewd)
• Toestemming om identity- en SaaS-/applicatielogs voor de getroffen identiteit te doorzoeken
• Toegang tot de systemen met de authenticatie- en activiteitslogs van de identiteit, waaronder mogelijk:
  • De identity provider (IdP) waarmee de identiteit wordt beheerd als die gefedereerd is (bijv. Microsoft Entra ID, Okta, Google Workspace, Ping, Auth0, AWS IAM Identity Center)
  • De SaaS- / cloudplatforms waar de identiteit toegang toe heeft (bijv. Microsoft 365, Google Workspace, Salesforce, Slack, GitHub, AWS, Azure, GCP)
  • Het SaaS- / applicatieplatform waar het account bij hoort, als het een lokaal account zonder SSO is (bijv. een los Salesforce-account, een persoonlijk GitHub-account)
  • De VPN- / netwerkappliance waarlangs het account zich aanmeldt, indien van toepassing (bijv. VPN-concentrator, RADIUS-server, bastion host)
  • On-premises Active Directory en de auditlogs daarvan als de identiteit in AD wordt beheerd
  • De SIEM / het centrale logplatform als identity- of authenticatielogs daarheen worden doorgestuurd

Benodigde tools:

• Beheerconsole en/of API van de IdP (bijv. Microsoft Graph, Okta API, Google Admin SDK, AWS CLI/IAM Identity Center API)
• Beheerconsole en/of auditlog-API van elk SaaS- / applicatieplatform binnen de scope
• Beheerinterface van de netwerk- / VPN- / bastion-appliance (indien van toepassing)
• Query-interface van de SIEM

2. Stap-voor-stap-instructies

Veelgemaakte fouten

• Alleen de aanmeldlogs van de IdP ophalen en de auditlogs van de achterliggende SaaS missen (waar de eigenlijke acties van de aanvaller plaatsvonden)
• Aannemen dat een IdP de authenticatielog heeft terwijl het account lokaal is bij de SaaS / applicatie (geen SSO)
• Niet-menselijke identiteiten vergeten (service principals, service accounts, workload identities, API-sleutels)
• Logs missen die al buiten de korte bewaartermijn van het platform vallen (bijv. aanmeldlogs van Entra ID standaard 30 dagen)
• Activiteit over tenants heen of via federatie niet meenemen (B2B-gasttoegang, federated identity, achterliggende SSO-apps)
• Alleen geslaagde authenticaties doorzoeken en het patroon in het volume aan mislukte pogingen missen dat brute force, password spraying of credential stuffing bevestigt
• De verdachte identiteit logs laten wijzigen of verwijderen door niet eerst een snapshot te maken als compromittering van een beheerder wordt vermoed

1. Valideer de noodzaak en scope van de logacquisitie

   • Bevestig dat de identiteit binnen de scope van het incident valt en stel het relevante tijdvenster vast
   • Stel vast of de identiteit menselijk of niet-menselijk is (service principal, service account, workload identity, API-sleutel, OAuth-app), want dat bepaalt welke logcategorieën van toepassing zijn
   • Stel het authenticatiepad van het getroffen account vast, want dat bepaalt waar de authenticatielog staat:
     • Gefedereerd / SSO (via een IdP) — de IdP heeft de authenticatielog; de achterliggende SaaS heeft de activiteitslogs
     • Lokaal SaaS- / applicatieaccount (geen SSO) — het SaaS- / applicatieplatform heeft zowel de authenticatie- als de activiteitslogs
     • Netwerk- / VPN- / RADIUS- / bastion-account — de appliance heeft de authenticatielog
     • API- / programmatische credential (token, sleutel, secret) — de API- / auditlog van het platform bevat de authenticatiegebeurtenis
   • Maak een lijst van alle platforms waar de identiteit toegang toe heeft; die vallen allemaal binnen de scope
   • Stel logs waar mogelijk eerst centraal veilig (SIEM, IdP, SaaS-audit) om je in te dekken tegen manipulatie, vooral als compromittering op beheer- of IdP-niveau wordt vermoed

2. Verzamel relevante logs van identity-activiteit

   • Stel vast welke categorieën activiteit relevant zijn voor het incident en verzamel die uit de bron waar ze staan (IdP, SaaS-/applicatie-audit, netwerkappliance, SIEM). Veelvoorkomende categorieën en waar ze meestal staan:
     • Authenticatie- / aanmeldgebeurtenissen (geslaagd, mislukt, met risicoscore, beslissingen van conditional access, bron-IP/ASN/geo, user-agent, apparaat-ID, sessie-ID)
       • Bij federatie (SSO): aanmeldlogs van de IdP (Entra ID Sign-ins, Okta System Log, Google Login Audit, Auth0-logs, AWS CloudTrail ConsoleLogin, aanmeldingen bij AWS IAM Identity Center)
       • Bij een lokaal SaaS- / applicatieaccount: de eigen authenticatielog van het platform (bijv. Salesforce LoginHistory, GitHub user.login, Slack user_login, WordPress-aanmeldlog, toegangslog van de applicatie)
       • Bij netwerk / VPN / bastion: authenticatielog van de appliance (RADIUS, TACACS+, VPN-appliancelog, sessielog van de bastion)
       • Bij een API- / programmatische credential: API-audit van het platform (CloudTrail, Azure Activity, GCP Audit Logs, GitHub Audit, M365 Unified Audit) — zoek naar de principal van de API-sleutel / het token in het actor-veld
     • Patronen van brute force / spraying / stuffing (veel mislukte authenticaties tegen één of veel accounts)
       • Alle paden: dezelfde authenticatielogs als hierboven, maar doorzocht op het volume en de frequentie van mislukte pogingen, de diversiteit van bron-IP's en de diversiteit van accounts in plaats van op losse geslaagde/mislukte gebeurtenissen
       • Zoek naar patronen van eerst mislukt en dan geslaagd (bevestiging van compromittering), low-and-slow-patronen en concentratie op geo/ASN
     • MFA-gebeurtenissen (gebruikte factor, aangevraagde/geweigerde factor, registratie van een factor, verwijdering van een factor, patronen van MFA fatigue)
       • Bij federatie: MFA-logs van de IdP (Entra ID Authentication Methods + Sign-ins, MFA-gebeurtenissen in de Okta System Log, Google 2SV-logs)
       • Bij een lokaal SaaS- / applicatieaccount: de eigen MFA-log van het platform (bijv. 2FA-gebeurtenissen in GitHub, MFA-gebeurtenissen van AWS in CloudTrail, TOTP/U2F-logs per app)
       • Als het account geen MFA heeft: leg dit vast als bevinding — het ontbreken van MFA is zelf belangrijk bewijs en een hardening-eis bij de recovery
     • Sessie- en tokengebeurtenissen (uitgifte, vernieuwing en intrekking van tokens, afmelden, verdacht hergebruik van tokens)
       • Bij federatie: tokenlogs van de IdP (tokenuitgifte in Entra ID via Sign-ins, Okta-tokengebeurtenissen, Google OAuth-tokenlogs)
       • Bij een lokaal SaaS- / applicatieaccount: de sessielog van het platform (aanmaken / verlopen / intrekken van sessies in de auditlogs van de app)
       • Bij een API- / programmatische credential: uitgifte- / vernieuwingsgebeurtenissen van tokens in de auditlog van het platform
     • OAuth / consent / toegang van applicaties (consent grants, admin consent, toegang van applicaties, aanmeldingen van service principals, toewijzingen van app-rollen)
       • Bij federatie: consentlogs van de IdP (Entra ID Audit + Sign-ins voor service principals, Okta OAuth-gebeurtenissen, Google OAuth Token-audit)
       • Bij een lokaal SaaS- / applicatieaccount: toegangslogs per app waar de SaaS activiteit van apps van derden vastlegt (bijv. GitHub OAuth-app-autorisaties, Slack-app-installaties)
     • Directory- / identitybeheergebeurtenissen (account aanmaken / verwijderen / uitschakelen, wachtwoordreset, roltoewijzing, wijziging van groepslidmaatschap, activering van een geprivilegieerde rol, wijzigingen in federatie / vertrouwensrelaties, activiteit van sync-accounts)
       • Bij federatie: auditlogs van de IdP (Entra ID Audit, Okta System Log, Google Admin Audit, AWS IAM CloudTrail)
       • Bij een lokaal SaaS- / applicatieaccount: de beheer- / auditlog van het platform (bijv. GitHub-auditlog voor wijzigingen in org-/reporechten, Salesforce Setup Audit Trail, Slack Audit Logs API voor beheeracties)
       • Bij on-premises Active Directory: Security-log (4720/4722/4723/4724/4725/4726/4728/4732/4738/4756), Directory Service-log
     • SaaS- / applicatieactiviteit (acties van de identiteit binnen het platform — bestandstoegang, delen, configuratiewijzigingen, data-exports, beheeracties)
       • De auditlog van het platform (M365 Unified Audit Log, Google Workspace Drive/Admin Audit, Salesforce Setup Audit Trail, Slack Audit Logs API, GitHub Audit Log, AWS CloudTrail data events)
     • Mailboxspecifieke gebeurtenissen (wijzigingen in inbox rules en doorstuurregels, gedelegeerde toegang, wijzigingen in mailboxrechten, verzenden / lezen van berichten vanuit nieuwe bronnen)
       • Audit van het e-mailplatform (M365 Exchange Audit / Unified Audit Log, Google Workspace Gmail-audit)
     • Beslissingen van conditional access / beleid (toegepast beleid, beleidsresultaat, MFA vereist, blokkade, toegepaste sessiebeperking)
       • Bij federatie: logs van conditional access van de IdP (details over conditional access in Entra ID Sign-ins, beleidsevaluatie in Okta)
       • Bij een lokaal SaaS- / applicatieaccount: logs van toegangsbeleid aan de kant van het platform waar beschikbaar (bijv. weigeringen door een IP-allowlist)
     • Risico- en detectiesignalen van de identity protection van de IdP / het platform (risicovolle gebruiker, risicovolle aanmelding, gelekte credentials, afwijkende reisbewegingen, afwijkend tokengebruik)
       • Bij federatie: identity protection van de IdP (Entra ID Identity Protection, Okta ThreatInsight, Google Security Center)
       • Bij een lokaal SaaS- / applicatieaccount: eigen securitysignalen van het platform (bijv. GitHub-alerts over gelekte secrets, threat events in Salesforce Real-Time Event Monitoring)
   • Doorzoek of exporteer per relevante categorie bij voorkeur uit de SIEM / IdP / beheerconsole van het platform waar de data centraal staat; doorzoek categorieën die niet centraal staan direct via de API
   • Leg per verzamelde categorie de query, het tijdvak en de toegangslocatie vast

3. Verzamel centrale logs uit de SIEM

   • Exporteer de overeenkomende gebeurtenissen voor de getroffen identiteit over het incidentvenster uit de SIEM of het centrale logplatform
   • Neem eventuele verrijkte of gecorreleerde identity-alerts voor de getroffen identiteit mee
   • Leg de query, het tijdvak en de exportlocatie vast

4. Breid de scope uit naar aangrenzende identiteiten en gedeelde indicatoren

   • Stel gedeelde indicatoren vast uit de activiteit van de getroffen identiteit (bron-IP's, ASN's, user-agents, apparaat-ID's, ID's van OAuth-applicaties, metadata van MFA-factoren, sessie-/correlatie-ID's)
   • Voer de relevante queries opnieuw uit over de IdP en de SaaS-/applicatie-auditlogs met deze indicatoren om aangrenzende gecompromitteerde identiteiten te vinden
   • Leg de bevindingen vast en neem ze mee in de scope van het incident

3. Na afloop

• Zet logs die als bestanden zijn geëxporteerd via een veilig pad over naar de aangewezen opslaglocatie voor bewijsmateriaal; verifieer dat de SHA-256-hashes vóór en na de overdracht overeenkomen
• Leg de metadata van de acquisitie vast: uitvoerder, tijdstip, identiteit, verzamelde bronnen, tijdvak, gebruikte tools / queries en (voor geëxporteerde bestanden) de SHA-256-hash van het resulterende archief
• Bevestig dat de chain of custody van begin tot eind is vastgelegd waar bestanden zijn geëxporteerd (verzamelen → overdracht → opslag)
• Draag over aan de analist die de logs gaat reviewen en werk het incidentticket bij met de verwijzing naar het bewijsmateriaal

Bijdrager

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

Heeft bijgedragen aan het Arcana Incident Response Documentation Framework.