Morten Schenk bloghoved

Følg et phishing-angreb trin for trin

Kompromittering og efterfølgende udnyttelse af IT systemer er hyppige hændelser. Mange angreb starter på den samme måde; en bruger får tilsendt en mail med en vedhæftet fil og en overbevisende historie om at downloade og åbne denne.

Indholdet af denne fil kan være alt fra en eksekverbar fil til et script. Såfremt scriptet bliver kørt vil det ofte give hackeren fri adgang til Pc’en og denne kan gøre alt som brugeren kan.

Det ses fx ved ransomware angreb, men også når virksomheder eller offentlige myndigheder bliver angrebet af såkaldte Advanced Persistent Threats (APT).

Jeg vil i dette indlæg demonstrere nogle af de angrebsvinkler som anvendes og som jeg også bruger når jeg gennemfører penetrationstests. Derefter vil jeg gerne vise en effektiv og relativ billig måde hvorpå mange af disse angreb kan stoppes på.

Phishing angreb benytter ofte specielle fil formater eller filer som kan indeholde kode, som fx Office dokumenter. Det nedenstående eksempel benytter Microsoft formatet HTML Application (.HTA). Såfremt et link med en .HTA fil tilgås i enten Internet Explorer eller Microsoft Edge vil det blive behandlet på en speciel måde. I Internet Explorer vil brugere blive præsenteret med to forskellige prompts:

Efterfulgt af:

Såfremt brugeren klikker på Open og Allow, vil JavaScript indholdet blive afviklet uden for browser nedlåsninger og fx Powershell scripts kan blive startet. At lokke brugeren til at gennemføre denne handling er, i tests jeg har gennemført, bestemt ikke unormalt. Ligeledes afslører generelle statistikker for phishing, at en stor procentdel af brugere kan lokkes til at gennemføre mange handlinger.

I mit ovenstående eksempel har jeg anvendt et Powershell script som af lavet fra værktøjet Powershell Empire. Når det bliver kørt, opretter computere forbindelse tilbage til en Command & Control server, som set herunder:

Brugeren har her åbnet linket fra en Windows 10 computer. Det er ligeledes muligt for hackeren efterfølgende at starte yderligere Powershell scripts der kan finde oplysninger omkring det Active Directory miljø som computeren er en del af. Herunder ses resultater for at finde først computernavne i domænet og derefter medlemmer af Domain Admin gruppen:

En anden mulighed, der er meget anvendt, er at vedhæfte en script fil af typen VBS, som vist her:

Hvis brugeren dobbeltklikker på denne bliver indholdet kørt og kan starte en bagdør. Eksemplet jeg har anvendt herunder er fra værktøjet Metasploit:

Herfra er der igen muligheder for at manipulere brugerens computer. Herunder er vist hvordan filer kan uploades til offeret til brug for yderligere angreb:

Her er værktøjet Mimikatz blevet sendt til brugerens computer. Hvis det bliver kørt kan det udtrække nogle af brugerens oplysninger såsom password, password hash og certifikater. Herunder er det vist hvor Mimikatz bliver kørt via Powershell:

En anden mulighed er at anvende en normal eksekverbar fil som vist herunder:

De ovenstående eksempler viser hvordan en angriber kan kompromittere en virksomhed og operere i denne. På trods af at de fleste virksomheder har antivirus installeret på deres computere, er det ofte relativt let at omgå disse. Ligeledes anvender nogle virksomheder dyre analyseværktøjer som inspicerer netværkstrafik.

Min holdning er at der er en mere effektiv og billig løsning, nemlig Application Whitelisting. Med Application Whitelisting er det muligt at blokere programmer og scripts fra at blive startet. Derved vil en bruger ikke have mulighed for at starte programmerne, selvom denne snydes til det.

Ideen er at alle filer på computeren blacklistes og at der oprettes regler for hvilke filer som godt må eksekveres. Fx vil opstart af en eksekverbar fil, som ikke er whitelistet blive stoppet og brugeren vil få en advarsel, der kan se ud som herunder:

Powershell er en stor angrebsvinkel som anvendes mere og mere. Sammen med Application Whitelisting er det ligeledes muligt at låse Powershell ned med såkaldt LanguageMode. Normalt operere Powershell i FullLanguage Mode, herfra er der adgang til .NET og Windows API’er som vist herunder:

Ved at anvende det begrænsende ConstrainedLanguage bliver adgang til .NET og Windows API’er fjernet, undtaget for whitelistede scripts:

I forbindelse med penetrationstests og sikkerhedsanalyse er det sjældent at jeg oplever Application Whitelisting implementeret ved virksomheder. Der findes både gratis og betalingsprodukter som kan levere denne beskyttelse ligeledes indeholder nogle antivirus produkter denne funktionalitet.

Det er min klare vurdering at korrekt anvendelse af Application Whitelisting vil standse størstedelen af angreb som danske virksomheder og offentlig myndigheder oplever i dag. Såfremt det skulle lykkes en angriber at kompromittere en computer, vil det også stærkt begrænse dennes muligheder for at eskalere angrebet.

I følgende blog posts vil jeg beskrive hvorledes Application Whitelisting kan opsættes og konfigureres selv i store Enterprise miljøer. Ligeledes vil jeg komme ind på hvordan Powershell Constrained Language kan konfigureres

Relateret indhold

Kommentarer (6)
Andrew Rump

Jeg er bange for at det giver en falsk sikkerhed at bruge whitelisting, da antallet af applikationer brugerne i en almindelig dansk virksomhed bruger, er så stor at man alligevel må åbne en ladeport, for at brugerne kan udføre deres daglige arbejde!

Jeg har arbejdet med en løsning engang, hvor brugerne startede deres computer op på en CD, som koblede dem op til en Citrix-server (dvs. de brugte overhovedet ikke harddisken på computeren). Brugerne havde kun adgang til en specifik liste af programmer, men vi måtte også stille en almindelig computer op, så de kunne udføre ad-hoc opgaver. Det fungerede, men brugerne blev glade, da de fik en "rigtig" computer igen.

Og selv med whitelisting, vil der stadig være angrebsvektorer, som f.eks. exploits (PDF, ...), (Word) macroer, ...

Kjeld Flarup Christensen

Og selv med whitelisting, vil der stadig være angrebsvektorer, som f.eks. exploits (PDF, ...), (Word) macroer, ...


Word macroer er sjældent nok til at lave ransomware, eller andre sjove ting. De er nødt til at kalde andre programmer, og måske endda installere noget. Kan man blokere dette, er man kommet langt.

Jesper Ravn

Hej Morten

Det er en rigtig god og spændende analyse, som giver stof til eftertanke.
Ingen tvivl om at Device Guard med AppLocker giver en rigtig effektiv endpoint sikkerhed.
Jeg har selv været stor tilhænger af SRP og AppLocker og har også tidligere testet det en del.

Problemet er bare, at det tager sindssygt lang tid at implementere, hvis du ikke har et 100% homogent IT miljø. Som jeg ser det, skal du identificere samtlige applikationer og deres afhængigheder, drivere, scripts, code libraries.

For mellemstore og store virksomheder, skal det så gøres for land/lokation/afdeling/speciel medarbejder/udvikler.

Efterfølgende skal du også konstant vedligeholde policies, hver gang der kommer nye applikationer til og hver gang der kommer opdateringer, der ikke overholder trust policy.

Ud fra en Cost-Benefit Analyse, er det partisk talt umuligt, at få til at hænge sammen, som jeg ser det.

Det kunne være spændende at høre, hvor lang tid du bruger på at implementere DG/AppLocker hos større kunder og hvor mange ressourcer/mennesker der er dedikeret til et sådanne projekt.

Jeg har selv set lyset i at benytte de Microsoft services, som benytter Microsoft Intelligent Security Graph.
https://www.microsoft.com/en-us/security/intelligence

Med disse får man et holistisk workflow med assume breach tankegang og med enkle parameter som:
Protect – Detect – Respond

Ovenstående mener jeg på mange måder, har overhalet de IT-sikkerhedsteknologier vi kender i dag. Det gælder også whitelist teknologi. Ved at kigge på de typiske angrebsvektorer vi kender i dag, vil man som virksomhed, være rigtig godt kørende, ved at implementere nedenstående services.
Man lejer disse services og de er forholdsvis simple og hurtige at komme i gang med.

Windows 10
http://blog.jravn.dk/?p=2401
http://blog.jravn.dk/?p=2541

Windows Defender med AMSI
Windows Defender Advanced Threat Protection (WDATP)
Office 365 Advanced Threat Protection (O365 ATA)
Enterprise Mobility + Security + Azure AD Identity Protection (EMS)
Azure Security Center
Advanced Threat Analytics (ATA) – on-premises
Operations Management Suite (OMS)

Jeg er enig med dig, at PowerShell er blevet en stadig større angrebsvektor med fileless/in-memory malware.
Microsoft er 100% opmærksom på dette og opdatere løbende deres Windows Defender, WDATP og O365 ATA for at beskytte deres kunder.

Jeg tænker på, at implementere PSLockDownPolicy med værdien 4 = Constrained Language Mode. Dette kan sættes op uden Device Guard og AppLocker. Men jeg ved ikke hvor nemt, det er, at bypasse. Det må jeg få læst op på.

Ebbe Hansen

Altså når nu man har afværget angrebet, er der så noget til hinder for, at malwaren har installeret noget på harddisk-firmware, der så kan trigges ved en senere lejlighed?
At det første angreb blot er buller og brag for at skjule den egentlige hensigt, at have et godt greb om n...... på et nyinstalleret og meget rent system.

Jeg har læst et sted, at kompromitteret hdd-firmware er næsten umulig at afsløre og umulig at fjerne.

Log ind eller Opret konto for at kommentere