Hur du får ut mer av ditt penetrationstest

En av våra mest efterfrågade tjänster är penetrationstest av interna IT-miljöer, som ofta bygger på Active Directory (ensamt eller tillsammans med Entra). Vi har i många fall fått förtroendet att återkommande få utföra den här typen av penetrationstest och fått följa våra kunders resa mot en säkrare IT-miljö och en ökad förmåga att upptäcka och svara på cyberattacker.

Vi har noterat att de allra flesta IT-miljöer som testas för första gången ”faller” på grund av likartade brister och sårbarheter, och att det ofta handlar om relativt triviala saker som enkelt och till låg kostnad hade kunnat detekteras och åtgärdas redan innan penetrationstestet genomfördes. Vi har valt ut några dessa brister och sårbarheter och tipsar i detta blogginlägg om hur ni själva kan söka efter dem och hur de kan åtgärdas. Plocka de lågt hängande frukterna själv och låt penetrationstestet hitta de mer svårupptäckta bristerna i stället!

Tips 1: Active Directory Certificate Services (ADCS)

En av de absolut vanligaste felkonfigurationerna, och något av det absolut första vi tittar efter är felkonfigurerade certifikatsmallar i ADCS. I omkring tre fjärdedelar av alla IT-miljöer vi testat för första gången (som använder ADCS), har vi hittat mallar som låtit oss som lågprivilegierade användare ikläda oss vilken identititet i domänen som helst, inklusive domänadministratörer.

Vi rekommenderar alla er som använder ADCS (eller åtminstone de som administrerar er PKI-infrastruktur) att läsa den utmärkta artikeln ”Certified Pre-Owned” av Will Schroeder och Lee Christensen på SpecterOps, och att själva proaktivt söka efter sårbara certifikatsmallar. Vi har beskrivit verktygen vi använder och hur de fungerar här.

Tips 2: Nätverkskataloger / SMB shares

Många IT-miljöer förlitar sig på nätverkskataloger för att dela och lagra information. De utgör dock ofta en allvarlig risk för organisationen då de tenderar att ackumulera känslig information och är i regel aldrig tillräckligt nedlåsta för att förhindra att en obehörig användare kan läsa och ibland förändra informationen i katalogerna. Det är inte ovanligt att vi hittar hela applikationer säkerhetskopierade till nätverkskataloger, och att vi från dem kan utvinna lösenord till olika system som till exempel databaser. Lyckligtvis är det väldigt enkelt att söka efter nätverkskataloger och testa åtkomst till dem.

Portscanningsverktyget nmap har ett skript för kartläggning av nätverkskataloger kallat smb-enum-shares som kan producera en lista för fortsatt analys. Nedan följer ett exempel från skriptets dokumentation på hur scanningsresultatet kan se ut:

Host script results:
| smb-enum-shares:
|  account_used: WORKGROUP\Administrator
|  ADMIN$
|    Type: STYPE_DISKTREE_HIDDEN
|    Comment: Remote Admin
|    Users: 0
|    Max Users: <unlimited>
|    Path: C:\WINNT
|    Anonymous access: <none>
|    Current user access: READ/WRITE
|  C$
|    Type: STYPE_DISKTREE_HIDDEN
|    Comment: Default share
|    Users: 0
|    Max Users: <unlimited>
|    Path: C:\
|    Anonymous access: <none>
|    Current user access: READ
|  IPC$
|    Type: STYPE_IPC_HIDDEN
|    Comment: Remote IPC
|    Users: 1
|    Max Users: <unlimited>
|    Path:
|    Anonymous access: READ
|_   Current user access: READ

Organisationer som i hög grad använder nätverkskataloger bör angripa problemet både kort- och långsiktigt.

Den kortsiktiga lösningen är att noga gå igenom all data som lagras i katalogerna och se över deras åtkomstlistor. Prioritera att gå igenom alla kataloger som är skrivbara, då en hotaktör både kan förändra informationen som redan finns där samt använda katalogen för att angripa andra användare. Se därefter till att vittja alla läsbara kataloger efter lösenord, säkerhetskopior och annan information som kan vara till nytta för en angripare. Tänk på att en ”dold” nätverkskatalog är fullt synlig för verktyg som till exempel nmap, och att det inte ger någon säkerhetsfördel av betydelse att försöka dölja dem.

Den långsiktiga lösningen är att migrera all känslig information till system som bättre kan möte dess skyddsbehov, till exempel lösenordshanterare och dokumenthanteringssystem.

Tips 3: Kerberoasting

Kerberoasting är en attack som utnyttjar hur ett av de vanligaste autentiseringsprotokollen (Kerberos) i Windows fungerar.

Vid Kerberos-autentisering begär en klient ut en så kallad service ticket från TGS-tjänsten i domänen (i regel en domänkontrollant) mot ett givet servicekonto. Denna service ticket krypteras med hjälp av lösenordshashen för servicekontot, så när klienten överräcker sin ”biljett” kan servicekontot försäkra sig om att den verkligen har utfärdats av TGS-tjänsten. Notera att frågan om auktorisation aktualiseras först när klienten faktiskt överräcker sin service ticket, så det spelar ingen roll vilken behörighet klienten har i domänen. Alla användare kan begära ut service tickets för alla konton med ett SPN konfigurerat i Active Directory.

En hotaktör kan därför, givet att de kan autentisera sig i domänen, samla in service tickets för konton i domänen i syfte att försöka knäcka deras lösenord. En lyckad attack resulterar i att angriparen kommer över lösenordet i klartext, och kan använda det komprometterade kontot i fortsatta attacker i IT-miljön.

Vi rekommenderar att ni ser över alla servicekonton i domänen och säkerställer att de helst är så kallade Group Managed Service Accounts (gMSA), eller att deras lösenord är framförallt långa, gärna 25 tecken eller längre. Vi rekommenderar också att ni ser över er loggning och övervakning avseende Kerberoasting då hotaktörer ofta utför den här typen av attack tidigt i angreppsförloppet, och ni har ett gyllene tillfälle att få en relativt tidig varning att ni har oväntat besök. För mer information om Kerberoasting och hur man kan upptäcka hotaktörers aktiviteter rekommenderas denna artikel, skriven av Sean Metcalf.

Tips 4: Databaslänkar (Microsoft SQL)

Om er organisation förlitar sig på Microsofts ekosystem och ni har behov av att lagra data i relationsdatabaser har ni sannolikt några instanser av Microsoft SQL Server i er IT-miljö.
En vanlig felkonfiguration vi söker ut under penetrationstest avser en funktion i Microsoft SQL Server som gör det möjligt att länka databasservrar med varandra. Databaslänkfunktionen är populär i många organisationer då de gör det möjligt att ställa databasfrågor genom länkarna från en server till en annan, och att på så vis skapa komplexa vyer över verksamhetens data.

Det många dessvärre missar är att databaslänkarna har egna privilegier, och det är dessa som avgör vilken åtkomst sökfrågan får mot den länkade databasen, inte den frågande användarens privilegier.

Om databaslänkarna är privilegierade och funktionen RPC OUT är aktiv på länken kan en alla användare med påloggningsrättigheter till den första databasservern agera som om de vore sysadmins på den länkade databasservern. Detta gäller även om databaserna tillhör olika domäner!

Missbruk av länkade databasservrar kan vara svårt att föreställa sig om man inte redan är bekant med fenomenet. Därför avslutas detta blogginlägg med en länk till en Youtube-användare som gör videoinlägg under pseudonymen Ippsec. Han demonstrerar hackingtekniker, framförallt på övningsplattformen Hackthebox och visar hur databaslänkar kan missbrukas i labbmaskinen ”Ghost”. Ni hittar klippet här.

Överprivilegierade databaslänkar ackompanjeras ofta av en annan olycklig felkonfigurering, att tillåta godtyckliga användare att logga in som gäst i databasservrarnas administrationsgränssnitt. Det är relativt vanligt att ”Domain Users” får påloggningsrättigheter vid den initiala uppsättningen av databasservern och att detta sedan aldrig tas bort.

Vi rekommenderar först och främst att ni ser över alla eventuella databaslänkar i miljön och säkerställer att de är upprättade med så låga privilegier som möjligt. Se också över påloggningsrättigheterna så ingen annan än en behörig användare kan logga in i administrationsgränssnittet, inte ens som gäst.