RB-ANALYSIS-011: Aanvullende gecompromitteerde accounts vaststellen

Documentbeheer

1. Vereisten

• Een onderzoek naar een bekende gecompromitteerde identiteit (menselijke gebruiker, service account, workload identity, API-sleutel, OAuth-app)
• Indicatoren uit de bekende compromittering: bron-IP's / ASN's, user-agents, apparaat-ID's, sessie-/token-ID's, OAuth-grants
• Het tijdvenster van het incident (verleng dat minstens 7 dagen terug om activiteit van vóór het incident mee te nemen)
• Toegang tot authenticatie- en sessietelemetrie van elk platform dat de identiteit gebruikt:
  • Identity providers (IdP / SSO)
  • SaaS- / applicatieplatforms (voor lokale accounts en workload-activiteit)
  • Control plane van de cloudprovider (CloudTrail / Azure Activity / GCP Admin Activity / OCI Audit) — voor activiteit van workload identities, instance roles en service accounts
  • VPN- / RADIUS- / TACACS+- / bastionlogs (waar van toepassing)
• Toegang tot endpoint-telemetrie (EDR) als on-prem hosts binnen de scope vallen
• Toegang tot een SIEM waarin al het bovenstaande is geïndexeerd

2. Stap-voor-stap-instructies

1. Zoek dezelfde indicatoren bij alle identiteiten Zoek voor elke indicator uit de bekende compromittering in elke authenticatie-/activiteitenlog binnen de scope naar dezelfde waarde:

   • Bron-IP's / ASN's / geolocatie
   • User-agent-strings
   • Apparaat-ID's / browserfingerprints
   • Sessie-, refresh- of access tokens
   • OAuth-client-ID's / ID's van API-sleutels Vergelijk met: menselijke gebruikers in de IdP, lokale accounts in SaaS / applicaties, workload identities (instance roles, service accounts, managed identities) en API-sleutels.

2. Hunt naar vergelijkbaar authenticatie- / autorisatiegedrag Zoek naar andere identiteiten met dezelfde patronen als de bekende compromittering:

   • Impossible travel, ongebruikelijke geo / ASN of ongebruikelijk apparaat
   • MFA fatigue, omzeiling van MFA of ongeautoriseerde MFA-registratie
   • Patronen in aanmeldtijden (buiten kantoortijd, uitbarstingen)
   • Reeksen van mislukte gevolgd door geslaagde authenticatie
   • Afwijkende patronen in API-aanroepen door workload identities (nieuwe regio, nieuwe user-agent, nieuwe doeldiensten)

3. Review gedeelde infrastructuur en vertrouwensrelaties Controleer voor elke tot nu toe gevonden identiteit of die gedeeld wordt met:

   • On-prem: endpoints, VPN-gateways, jump- / bastionhosts, gedeelde mailboxen
   • Cloud: instance roles, federatievertrouwen, toegang over accounts / tenants heen, workload identity federation, gedeelde service accounts
   • SaaS: gedeelde integraties, gedeelde OAuth-apps, gedeelde API-sleutels

4. Stel blootstelling via beheerrelaties vast Stel vast waar de bekende compromittering toegang heeft tot andere identiteiten via:

   • Gedeelde geprivilegieerde groepen of roltoewijzingen (on-prem AD, cloud-IAM, beheerrollen in SaaS)
   • Gedelegeerd beheer (on-prem OU's, Entra ID-rolgroepen, AWS Organizations, GCP-folders, OCI-compartments)
   • Gedeelde mailbox- / gemachtigdentoegang
   • Gedeelde API-sleutels, credentials van service principals of scopes van workload identities

5. Review hergebruik van OAuth, tokens en credentials Zoek naar:

   • Gedeelde OAuth-grants en applicaties met consent van een beheerder
   • Gedeelde refresh- / access- / sessietokens
   • Verdachte gedelegeerde rechten (mailbox, bestanden, beheer)
   • Tokenactiviteit over accounts / tenants heen (AssumeRole, gefedereerde toegang, B2B-aanmeldingen)
   • API-sleutels of secrets van service principals die bij meerdere identiteiten of bronnen in gebruik zijn

3. Na afloop

• Documenteer alle nieuw gevonden gecompromitteerde accounts uit het onderzoek in het incidentticket
• Leg nieuwe IOC's (hashes, IP's, domeinen, accounts, tokens, signaturen) vast in het incidentticket

Bijdrager

Vishal Thakur
GitHub: https://github.com/malienist

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

Heeft bijgedragen aan het Arcana Incident Response Documentation Framework.