Slik har vi kontroll på endringer av viktige sikkerhetsgrupper i Active Directory 

Her må man huske på at sikkerhets grupper i AD kommer i forskjellige typer, lokale, globale og universale. Disse har alle forskjellige Event ID’er for alle handlinger en trenger å ha kontroll på. For eksempel vil Event ID 4728 fortelle deg at en ny bruker er lagt til i en global sikkerhetsgruppe, og det er viktig å ha kontroll på dette når det kommer til f.eks Domain Admin. Men hva om gruppen du ønsker å ha kontroll på er en lokal gruppe som for eksempel Administrator kontoen lokalt på en server? Eller om det er en sikkerhets gruppe som er satt til universal? Ingen av disse vil gi Event ID 4728 om det legges til en ny bruker. 

Det er også viktig å begrense hvilke sikkerhetsgrupper en vil følge med på, det er langt fra alle grupper som er like interessante. Artikkelen inneholder presentasjon av noen grupper som jeg mener dere i hvert fall må ha kontroll på. 
Det er også viktig å tenke på at det finnes situasjoner hvor det er naturlig at det tildeles privilegerte sikkerhetsgrupper, men at dette gjøres via f.eks IAM/PAM løsningen og må hensyntas.

For å ivareta kontroll bør disse gruppene overvåkes som et minimum.

  • Domain Admin: Denne gruppen har full kontroll over hele Active Directory-domenet og alle ressursene i det. Overvåking av endringer i medlemskap og aktivitet innenfor denne gruppen er avgjørende for å opprettholde sikkerheten til domenet.
  • Enterprise Admin: Denne gruppen har samme rettigheter som Domain Admin, men brukes til å administrere flere domener i en forest. Eventuelle endringer i denne gruppen bør overvåkes nøye. 
  • Schema Admins: Denne gruppen har muligheten til å endre Active Directory schema, som er styrende for hvordan objekter er definert i AD. Uautoriserte endringer i schema kan ha en betydelig innvirkning på organisasjonens IT-infrastruktur, så det er viktig å overvåke endringer i denne gruppen. 
  • Administrators: Denne gruppen har administrative rettigheter på individuelle datamaskiner i domenet. Overvåking av endringer i denne gruppen kan bidra til å oppdage mulige sikkerhetsbrudd. 
  • Service Accounts: Tjenestekontorer brukes til å kjøre applikasjoner eller tjenester innenfor domenet. Det er viktig å overvåke aktiviteten og endringene i tjenestekontoer for å oppdage eventuell uautorisert bruk av disse kontoene. 
  • Sikkerhetsgrupper med sensitive tillatelser: Enhver sikkerhetsgruppe som har sensitive tillatelser, for eksempel tilgang til økonomiske data, konfidensiell informasjon eller kritiske systemer, bør overvåkes nøye. 
  • Group Policy Creators Owners: Medlemmer av denne gruppen kan opprette og endre gruppepolicyobjekter (GPOer), som brukes til å konfigurere innstillinger på domene tilknyttede datamaskiner. Overvåking av endringer i denne gruppen kan bidra til å forhindre uautoriserte endringer i GPOer. 

Ved å overvåke endringer i disse Active Directory-gruppene, kan organisasjoner identifisere mulige sikkerhetsbrudd og reagere raskt for å forhindre ytterligere skade. 

Disse Eventene må du overvåke for å ha kontroll på dine viktige sikkerhetsgrupper 

Først og fremst så vil vi gjerne ha kontroll på innmelding av brukere i disse sikkerhetsgruppene. Til dette så bruker vi Event ID’ene 4732, 4728 og 4756. 
Deretter så trenger vi å følge med på hvem som blir fjernet fra sikkerhetsgruppene. Til dette så bruker vi Event ID’ene 4733, 4729 og 4757. 
Dersom du også skulle ønske å følge med på om det gjøres andre endringer på disse gruppene enn å melde objekter inn eller ut så kan det benyttes Event ID’ene 4737, 4735 og 4745. 

Når du er klar for å sette i gang å overvåke disse gruppene så må du gå igjennom hvem som allerede har tilgang og om de skal ha tilgang. Lag en baseline på hva som er riktig tilgangsbilde, også lar vi Splunk varsle når det er endringer på tilganger.  
Til å liste ut hvem som har tilgang til en AD gruppe kan du benytte en enkelt spørring i PowerShell som lister ut alle medlemmer av en gruppe til en csv fil.
Powershell koden under her kan benyttes for å hente ut medlemmer av Domain Admin gruppen. Bare endre navn på hvilken sikkerhetsgruppe og sti\filnavn på eksporten så det passer til dine behov og gjenta for alle sikkerhetsgrupper du ønsker.

Get-ADGroupMember -Identity "Domain Admin" | select saamAccountName, DisplayName | Export-Csv "c:\temp\DomainAdminUsers.csv" -Delimiter ";" -Encoding utf8 -NoTypeInformation 

Slik setter du opp alertene i Splunk

For varsling når det meldes et objekt inn i en av de overvåkede sikkerhetsgruppene så kan du benytte deg av denne Splunk spørringen.
Endre index og AIM_servicekonto til det som passer for ditt miljø. 

index=<your_index> sourcetype=wineventlog EventCode IN (4732, 4728, 4756)  
| convert timeformat="%Y-%m-%d %H:%M:%S" ctime(_time) as Tidspunkt  
| search Group_Name IN (Domain Admins, Enterprise Admins, Administrator, DHCP Administrators, DnsAdmins, Hyper-V Administrators, Schema Admins)  
| eval Message=split(Message,".")  
| eval Melding=mvindex(Message,0)  
| eval admin=mvindex(Account_Name,0)  
| eval user=mvindex(Account_Name,1)  
| search admin!=<AIM_Servicekonto>  
| table Tidspunkt EventCode Melding admin user Member_Security_ID  
| rename admin as "Tilgang gitt av:" user as "Tilgang til bruker" Member_Security_ID as "Tilgang til Security ID" EventCode as "Event ID"  
| sort – Tidspunkt 

For brukere som er fjernet fra de overvåkede sikkerhetsgruppene så er det bare å bruke koden over og bytte ut Event ID’ene 4732, 4728 og 4756 med 4733, 4729 og 4757. 
Avhengig av hvor hyppig du vil at Splunk skal kontrollere og varsle så settes alerten opp deretter, jeg tenker at det her kan være greit å starte med en alert som går en gang i døgnet frem til du har kontroll på falske positive, deretter kan den endres til for eksempel å kjøre en gang i timer på data fra siste time.