Tilganger på avveie - tiltak mot PtH.png

Et stort fokusområde på Microsoft sin Ignite konferanse i Atlanta i september var sikring av privilegerte brukerkontoer og integriteten til disse.

De siste årene har det blitt snakket mye om pass the hash, eller pass the ticket hacking-teknikker for å tilegne en konto eleverte tilganger på en Windows server eller klient, enten lokalt eller via remote desktop. Endelig har Microsoft gjort en god del tiltak for å forhindre dette. Man vil ikke kunne hindre pass the hash i utgangspunktet, da PtH utnytter single sign-on funksjonaliteten i Windows.

Microsoft sikkerhetsanbefalinger innebærer en god del tekniske anbefalinger og løsninger, men det er vel så viktig å tenke på sikkerhet i hverdagen og endre hele sin mentalitet til hvordan man jobber. Microsoft kaller dette ‘’Assume breach’’

En god del har blitt skrevet om emnet allerede og for alle som ser dette for første gang, anbefaler jeg å se på Paula Januszkiewicz sin Cyber Academy eller delta på hennes seminarer. (Ignite, NIC, TechFuse, Hacker Fest, etc) https://cqureacademy.com/blog

Microsoft har også en informativ side med forskjellige tiltak og beskrivelser om emnet:
https://technet.microsoft.com/en-us/security/dn785092

Men det er egentlig bare å sette i gang med tiltak for å minimere eller forhindre innbrudd av denne typen. Hvis du følger de 3 rundene beskrevet nedenfor, vil du ha gjennomført det som er mulig fra et teknologisk ståsted for å forhindre et PtH innbrudd (per dags dato).

Første runde med tiltak bør se ut som dette (Tidsbruk 2-4 uker):

Første runde innebærer å forhindre at en uønsket bruker som innehar lokale adminstrative rettigheter på en server/klient kan gi seg selv eleverte rettigheter og for flytte seg videre innover i nettverket med rettigheter som f.eks. domain admin. Dette er mulig så lenge man benytter seg av samme lokale administrator passord på flere servere eller klienter. Microsoft har utviklet er relativt enkelt og funksjonelt verktøy som heter Local Administrator Password Solution (LAPS). Dette er en software som installeres på domenekontrollere og oppretter en GPO. Tjenesten vil da være ansvarlig for å bytte det lokale administrator passordet med tilfeldig unike passord ved jevne mellomrom og lagre dette i active directory. På denne måten vil man han full kontroll over lokal administrator kontoene og ikke minst en sentral oversikt over alle passord. Det vil mulig å logge inn på servere selv om ikke serveren har kontakt med active directory.

Ignite, Microsoft

 

1. Separate kontoer for administrative oppgaver 

Bruk separate kontoer for administrative oppgaver og daglig bruk. Dette vil hjelpe til med at den administrative brukerens hash blir liggende igjen på servere/klienter man ikke har kontroll på.

2. Privileged Access Workstations (PAW), første steg: Active Directory Admins

Opprett en dedikert workstation som benyttes av brukere med Active Directory admin rettigheter. Dette er de mest kraftfulle tilganger man kan få tildelt i et domene, og bør sikres først. Senere vil man også sikre generelle administrative kontoer. Denne workstation skal brukes som en slags jumpstation videre mot andre servere og som en admin server hvor man åpner opp ADUC, MMC, powershell osv. Man er på denne måten mere beskyttet mot fishing angrep, epost malware, keylogging osv.

For mer informasjon om om PAW finnes her: http://aka.ms/CyberPAW

3. Endre til unike passord for lokal administrator på servere

Installer og konfigurer LAPS for å sentralt styre de lokale administrator passord på alle servere.

4. Endre til unike passord for lokal administrator på alle klienter

Det er like viktig at klienter ikke benytter samme lokale administrator passord, sannsynligheten for at en bruker med eleverte rettigheter logger på en klient en like stor.

Når første runde er gjennomført, bør disse tiltakene gjennomføres (1-3 mnd):

Runde to er en god del mer omfattende og vil innebære Server 2016/Windows 10 funksjonalitet. Her anbefales det å ta i bruk PAM og multi-factor. Denne fasen vil typisk gjennomføres i ett 1-3 mnd perspektiv.

Ignite, Microsoft 1

1. PAW for alle administratorer

Utvid bruken av Privileged Access Workstations for alle administratorbrukere. Disse dedikerte klientene kan være utstyrt med Credential guard (Win10) og RDP Restricted admin.

Credential guard er en funksjon i Win10/Server2016 som bruker virtualiserings basert teknikker, for å forhindre angrep mot NTLM passordet og Kerberos ticketene (KTGT). Styres via GPO, powershell eller cmd. Bruker nå en isolert LSA prosess for å lagre hashene, LSA kommuniserer den isolerte LSA prosessen via RPC. Krever et bestemt nivå av hw og sw/fw på maskinen. Mer info her

RDP RestrictedAdmin mode er en funksjon som kom i server 2008 R2/win 7 som gjør at en brukers brukernavn/passord (hash) ikke blir liggende igjen når du logger ut av en RDP sesjon. Dette krever at du er medlem av den lokale administrator gruppen på maskinen du logger deg på. Konfigureres via en reg nøkkel og man må benytte denne cmd når man starter RDP sesjonen:
Mstsc.exe /RestrictedAdmin Mer info her

Men vi anbefaler ikke å enable denne featuren på Server 2012 R2 eller Win 8.1, da dette faktisk innebærer at PtH faktisk blir utnyttet med for eksempel pth-winexe og FreeRDP, mer info her

2. Tidsbegrenset administrator rettigheter

Dette innebærer å ta i bruk PAM (Privileges Access Manager) i MIM (Microsoft Identity Manager), eller Azure PIM (Privileged Identity Manager) for Azure AD.

PAM er en løsning som bygger på JIT (Just In Time Administration) og JEA (Just Enough Administration). JEA er et powershell kit som gjør at en administrator kan gi brukere administrative rettigheter i en tidsbegrenset periode. Som dere skjønner vil det ikke da være mulig å stjele access fra en bruker etter at dette tidsrommet er over.

PAM i AD DS fungerer ved at det opprettes en ekstra AD forest som benyttes som en såkalt bastion forest (samme SID i begge Forests). Eller en forest hvor de faktiske tilganger finnes og som har et trust mot den opprinnelige AD forest. Det er vanlig å benytte MIM sammen med PAM, ellers er det en lite brukervennlig og tilgjengelig løsning (Web portal vs powershell). Dette fungerer ved at brukeren får time-limited ticket-granting tickets (TGTs) som har en viss levetid.

3. Multi-factor

For å gjøre den tidsbegrensede tilgangen enda sikrere kan det innføres MFA. Gjennom MIM PAM og Azure AD PIM ved bruk av Azure Multi-factor authentication (MFA). Krever Premium Azure AD lisens.

4. JEA for DC vedlikehold og drift

Man bør ta i bruk JEA for de brukerne som skal jobbe med p vedlikeholde domenekontrollerene. På denne måten kan utvalgte brukere få tilgang til utvalgte funksjoner på DC’er uten å være administrator. Dette tilbys via powershell.

5. Minste angreps overflate til DC

Man bør minimere mulighetene og metodene som kan brukes for å få kontroll over AD forest og objektene. Dette er en samling av flere generelle metoder, beskrevet nærmere her

6. Oppdage angrepet (ATA)

Ok, hva skjer når man blir angrepet eller kompromittert? Gjennomsnittstiden før et angrep er blitt oppdaget er 243 dager! Microsoft har derfor utviklet er produkt for å avdekke abnormal oppførsel basert på hvilke enheter en bruker normal benytter for å aksessere systemene/informasjonen i selskapet. Dette produktet heter ATA (Advanced Threat Analytics) og er en on-premise plattform som samler data fra ulike systemer (SIEM, Eventlog, DNS, nettverkstrafikk) og lager en profil basert på oppførsel på brukere og andre entiteter. ATA baserer seg på machine learning.

Løsningen består av enten ATA Gateways som videresender eventlogger og nettverkstrafikk eller gateway agenter installert på alle DC’er. Disse gatewayene forwarder informasjonen til ATA Center. Her har man konsoll for administrasjon og bruk, sette opp notifications og alerts osv. NB! Ett ATA Center per AD Forest.

Her ser man arkitekturen på løsningen:

Ignite, Microsoft2

 

PtH angrep blir oppdaget:

Ignite, Microsoft4

Mer info her

Hvis man er så uheldig og blir angrepet bør man ha en plan for hvordan man takler og følger opp et innbrudd.  Les denne pdf fra Microsoft som beskriver tiltak.
http://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating-Pass-the-Hash-Attacks-and-Other-Credential-Theft-Version-2.pdf

 

Runde 3.

Siste del av strategien er en mer proaktiv tilnærming til problemet, men den bygger på tiltakene i runde 1 og 2.

Ignite, Microsoft 5

1. Bruke en modell med definerte roller og delegering av rettigheter

For å redusere sikkerhets fare, bør man gjøre et redesign av modellen for roller og delegeringer i bedriften. Denne modellen bør være i tråd med nivå modellen, dvs at man for eksempel har en cloud service administrator rolle og en tenant administrator. Denne modellen bør ivareta JIT og JEA som er beskrevet lenger opp.

2. Alle Azure administratorer bør bruke smartcard eller Passport authentication.

Man bør innføre sikker autentisering for alle administratorer om er hosted i Azure, og alle on-premise kontoer som har administrative rettigheter i Azure.

3. Egen admin AD forest for administratorer

For å sette opp den beste beskyttelsen for dine administratorer bør det vurderes å sette opp en egen admin AD forest som ikke har noen avhengigheter med produksjons AD. Men som bare benyttes til de mest kritiske systemene i ditt produksjons miljø. Microsoft har beskrevet det inngående her

4. Kode integritet for alle DC’er (Bare for Server 2016)

I server 2016 har man mulighet til å sette på en sperre for bare godkjente kernel drivers og bruker applikasjoner kan kjøres. Dette er en ekstra sikkerhet for å unngå at uautoriserte programvare kan kjøres på DC’ene.

5. Shielded VM’s for virtuelle DC’s (Server 2016 Hyper-v)

I Server 2016 Hyper-v har fått en funksjon som heter Shielded vm’s. Dette kan enables på vm’er man ønsker ekstra sikkerhet på, spesielt på ROBO sites eller på lokasjoner hvor man ikke stoler på administratoren.

Shielded vm’s gjør at man ikke kan åpne konsollet på vm’em fra hyper-v manager eller SCVMM, det er heller ikke mulig å mounte eller åpne vhd filen til vm’en. På denne måten kan ingen mounte NTDS.dit filen og hente ut informasjon på den måten.

Oppsummering

Dette var en meget lang liste med tiltak som bør gjennomføres, men så lenge runde 1 blir gjennomført og runde 2 og 3 ligger i roadmappen vil man ha satt mange kjepper i hjulene til eventuelle hackere og inntrengere.

Tags: Teknisk blogg

Kontakt oss: Ønsker du å ta en prat med oss?