Artikel top billede

Sådan stoppede vi et Active Directory-angreb under fuld udblæsning

Klumme: Få timer efter at angrebet blev opdaget, samledes kunden, kundens it-sikkerhedspartner og vi virtuelt for at etablere en reaktionsplan, som vi sammen kunne eksekvere på. På det tidspunkt havde hackeren allerede brugt et redskab, der gav adgang til administratorrettighederne og havde stjålet en af virksomhedens domæneadministratorkoder.

Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.

Tidligere på året var jeg en del af en intens og dramatisk sag, hvor et stort europæisk forsikringsselskab skulle stoppe et igangværende angreb på deres Active Directory (AD) miljø (hvorfra man styrer alle de digitale identiteter).

Som ekstern it-sikkerhedsekspert blev jeg glad for at se, at de anvendte metoder til afhjælpning og genopretning var effektive og fik virksomheden tilbage i drift igen.

Herunder vil jeg gennemgå angrebet og indsatsen. Forhåbentligt kan det hjælpe andre it- og sikkerhedsteams finpudse deres beredskabsplan.

Engagér eksperterne

I det øjeblik, forsikringsselskabet opdagede at det var under angreb, tog det affære og fik fat på selskabets it-sikkerhedspartner – en global konsulentvirksomhed.

De fandt ud af, at angrebet var målrettet forsikringsselskabets AD, og da de ikke selv besad den fornødne AD-specifikke sikkerhedsekspertise, tog de fat i os.

Få timer efter, at angrebet blev opdaget, samledes kunden, deres it-sikkerhedspartner og vi virtuelt for at etablere en reaktionsplan, vi sammen kunne eksekvere på.

På det tidspunkt havde hackeren allerede brugt et redskab, der gav adgang til administratorrettighederne og havde stjålet en af virksomhedens domæneadministratorkoder.

Hackeren brugte sin nye adgang til at oprette en brugerkonto, som blev en del af domæneadministratorgruppen.

Det er en ret almindelig metode til at angribe AD-domænet med og kunne blive derinde.

Forsikringsselskabet have flere dataskove som alle var forbundet med en full-trust-mesh. Dog foregik angrebet kun på én af dataskovene på dette tidspunkt.

Forsikringsselskabets it-sikkerhedsteam var allerede underrettet om den verserende trussel via de it-sikkerhedsløsninger, der kørte på enhederne (endpoints).

Men de manglede specifikke redskaber til at kunne beskytte deres AD indefra. De manglede en sikkerhedsløsning, der kunne underrette dem om direkte ændringer i domæneadministratorgruppen.

Trods dette, reagerede de hurtigt på notifikationen om det mistænkte sikkerhedsbrud og advarslen om, at en ny domæneadministrator var blevet oprettet til den kompromitterede brugerkonto.

Hurtigt fik de blokeret hackerens konti – både den nyoprettede og den gamle kompromitterede brugerkonto, som blev brugt til at oprette den nye. De oprettede også øjeblikkeligt nye administratorkonti til dataskoven og lukkede de gamle privilegerede brugerkonti.

Netværksafdelingen sporede hackeren til en virtuel server, som hackeren havde fået adgang til via Remote Desktop Protocol (RDP). Hackeren have allerede ”ringet hjem” til en IP-adresse i Rusland og var i gang med at downloade ransomware med et krypteret Dynamic Link Library (DLL).

Netværksafdelingen afbrød med det samme netværket på den virtuelle server, hvilket var et smart træk.

Spændingen steg til nye højder, som angrebet fortsatte

Da alle tre parter mødtes i forsikringsselskabet ’war room’, var spændingen til at føle på.

Vores førsteprioritet var at forstå, hvordan hackeren havde fået adgang og hvordan vi kunne inddæmme skaden. På det tidspunkt var der ingen, der vidste om der var downloadet en ondsindet tidsbombe i nogle af de andre systemer.

Var der stadig risiko for, at en crypto-locker-proces pludselig gik i gang og krypterede hele it-infrastrukturen?

Ville der ske det samme som da Mærsk blev angrebet med NotPetya for nogle få år siden, hvor alle AD domæne-controllers blev låst?

Ville det hele eskalere og i så fald hvornår? Var der sikre backups af alle domæner i alle dataskove, såfremt de blev gendannet?

Lå der en beredskabsplan klar, hvis det blev nødvendigt? Hvilke andre indgange til forsikringsselskabet AD var stadig åbne?

Forsikringsselskabet it-sikkerhedspartner, deres forsikringsselskab og vores eksperter arbejdede tæt sammen og fik skabt en liste over de initiativer, der skulle sikre it-miljøet, hvis hackeren stadig var aktiv og inde. Her er vores liste:

• Sikre at SID-filtreringen er aktiv på tværs af alle AD-dataskove: Det skulle forhindre at angrebene kunne sprede sig fra én dataskov til en anden ved at tilføje en privilegeret gruppe til SID-historikken på en bruger i det kompromitterede domæne.

• Dobbelt re-set/gendannelse af KRBTGT-kontoen i hvert domæne: Gendannelsesproceduren skulle forhindre hackere i at danne valide Kerberos Ticket Granting Tickets (TGT), også kaldet ’Golden Tickets’, hvis de allerede havde adgang til KRBTGT-kontoen.

• Slå Windows Print Spooler service fra på alle domænekontroller (DC): Dermed forhindres man, at en hacker kan tvinge en DC til at godkende andre inficerede brugere via en ”printer bug”, hvilket er en banal øvelse, hvis hackeren får adgang til en computer, der er konfigureret til at tillade ubegrænset delegation.

• Tilføj alle privilegerede brugere til gruppen af ”beskyttede brugere” (Protected Users) på deres respektive domæner: Denne sikkerhedsforanstaltning minimerer eksponeringen af disse konti ved ikke længere at tillade godkendelse via NTLM (kun Kerberos) eller ved at bruge DES eller RC4 til Kerberos-forudgodkendelse. Brugere i denne gruppe kan heller ikke tildeles begrænset eller ubegrænset delegering.

• Sikr, at en nylig sikkerhedskopi af hvert domæne i hver dataskov bliver gemt sikkert offline: Sikkerhedskopierne bliver nødvendige, hvis dataskovene skal gendannes, i tilfælde af, at en krypto-locker-proces startes i miljøet.

Dækning af resterende Active Directory-sikkerhedshuller

Da vi foretog ændringerne, brugte vi sikkerhedsværktøjet Purple Knight.

Det gjorde vi for at få en forståelse for andre potentielle svagheder, der muligvis stadig eksisterede i virksomhedens AD-dataskove.

De, der har oplevet Purple Knight i aktion, bliver nogle gange overraskede over, hvad værktøjet kan afsløre med en uprivilegeret konto.

Dette er naturligvis kun muligt på grund af Active Directorys open base design, som tillader et chokerende antal læseadgange for alle godkendte brugere.

Det er netop dette niveau af synlighed, der gør Active Directory til et så attraktivt mål for cyberkriminelle.

Efter at have gennemført en scanning for at afdække AD-sårbarheder, havde vi en lang liste over indikatorer for mulige eksponeringer (IOE'er) og sårbarheder (IOC'er) som skulle løses.

Nogle af de faktorer, som forsikringsselskabet øjeblikkeligt skulle adressere var:

• Konfigurering af computere med ubegrænset delegering - et oplagt mål for hackere, som øjeblikkeligt skulle stoppes

• Potentielt misbrug af domænernes indbyggede administratorkonti, som kan bruges som en servicekonto til forskellige SQL-databaser, hvilket var tydeligt qua alle de SPN'er, der var registreret på kontoen

• Forskellige højrisiko tilladelser, som var konfigureret på domæneniveau

• Nedbringe antallet af administorkonti (som der var alt for mange af i første omgang) og som havde adgangskoder, der ikke var blevet ændret i flere år.

Det sidste trin i vores indsats var den notorisk vanskelige proces med at gendanne AD-dataskoven.

For det første satte vi et sikkerhedsnet op under de forskellige dataskove, da ingen vidste, om der var skjult malware i sikkerhedskopierne.

Hverken forsikringsselskab eller it-sikkerhedsselskabet havde forberedt sig på – eller øvet sig på – hvordan en gendannelse af AD-dataskoven skulle gennemføres.

Dernæst konfigurerede vi DC-backups for hver af forsikringsselskabets fire AD-dataskove.

Vi sikkerhedskopierede AD-data udelukkende fra domænecontrollere og ikke det resterende styresystem.

Med denne tilgang var sikkerhedskopierne ekstremt små og transportable men fuldt krypterede, og vi havde sikret os en modstandsdygtig backup-løsning.

Fuldt gendannet Active Directory giver ro i sindet

På tredjedagen ville vi berolige forsikringsselskabet og hjalp dem derfor med at lave en kopi af deres produktions-AD-dataskove i et fuldstændigt isoleret, separat sandbox-miljø med en nyimplementeret og malware-fri Windows Server VM i Azure.

Det sikrede, at vi ikke blot kunne danne sikkerhedskopier af dataskovene, men også, at kunden nu var i stand til at gendanne dem, hvis det blev nødvendigt.

Enhver virksomhed, der oplever et angreb, der er i fuld gang, kan bruge disse råd og lade sig vejlede til, hvordan man effektivt kan inddæmme skaden, vurdere miljøet for sårbarheder og foretage en hurtig, ren genopretning af AD, der ikke introducerer ny malware.

Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.

Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?

Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.