Tech Blog
Sammen med min gode ven og kollega, Flemming Riis, har jeg på det seneste undersøgt opsætningen af nogle udbredte backupsystemer, herunder hvordan de potentielt kan misbruges af angribere.
Tanken er ikke at »male fanden på væggen«, men at gøre opmærksom på en reel problemstilling, som i følge vores erfaring er noget overset.
Læs mere her: https://www.version2.dk
In the last couple of years I have had an interest in application whitelisting bypasses and avidly followed the work of Casey Smith (@subtee) and Matt Graeber (@mattifestation). The major conclusion from their work is that application whitelisting has to be locked down to avoid trusted application launching attacker code. While it seems quite clear that on Windows 7 and 8.1 Powershell is an easy way to bypass application whitelisting through reflective PE injection, Windows 10 is a different story. With the activation of Powershell Constrained Language Mode along with AppLocker in Windows 10 this avenue seems closed. While Casey Smith has a lot of research on bypassing application whitelisting in other ways here, they all assume prior code execution on the victim machine. I am a great fan of PowerShell Empire by Veris Group as an attack framework, and I really like the HTML Application attack vector. As I will show below this attack does not work out of the box when Powershell Constrained Language Mode is enabled. But then I got to thinking whether using prior public research and code would it make it possible to make the attack vector viable again. This blog post describes how I did that though a lot of nested techniques and code.
Usage of Windows kernel exploits have been on the rise, and are often used to break out of a browser sandbox. Many of the vulnerabilities found over the years have been in the driver win32k.sys, which handles system calls from gdi32.dll and user32.dll. To try and mitigate many of these vulnerabilities proactively Microsoft has implemented what is call Win32 Syscall Filter in Windows 10. The overall idea is to be able to block many System calls to win32k.sys for an entire process, such that unknown vulnerabilities cannot be taken advantage of. I have not been able to find many details about the implementation and how effective it really is, the only discussion I’ve found is the presentation Rainbow Over the Windows by Peter Hlavaty.
When I started out tinkering with exploit development, I would have loved to receive some help on how to set up a good exploit development environment. For those of you who have tried exploit development before, know that there is a lot of trial and error, hence repeating actions as fast as possible and with as little manual work makes the process much more effective. In this blog post I want to share my exploit development environment and explain how I have configured it.
About two weeks ago a blog post was issued from the Windows Offensive Security Research Team (OSR) about hardening Windows 10 against kernel exploitation:
Kernel exploitation on Windows 10 almost always requires a kernel read and/or write primitive. So OSR reported on how Windows 10 Anniversary Update has been hardened to mitigate usage of one of the commonly used primitives. The primitive in question is comes from the tagWND object, which is the kernel mode representation of a window. While reading the blog post, I remembered back to October of last year and some research I did at the time. About two weeks before Black Hat Europe 2016, I was looking into using the tagWND object as a read/write primitive on exactly Windows 10 Anniversary Update. But before I got around to writing up anything about my findings the Attacking Windows By Windows talk from Yin Liang and Zhou Li came out at Black Hat Europe.
This blog post is part two of Bypassing Control Flow Guard in Windows 10. It is also the result of some research I did back in July of 2016, but did not have the possibility to publish before now. The same Internet Explorer vulnerability is used with the same original proof of concept by Theori. This blog post will present another method of bypassing CFG, which also still works on Internet Explorer, but not in Microsoft Edge, due to suppressed API’s. It is assumed that the reader has read the previous blog post, so the details of CFG are not explained, and I jump right to the point of having an arbitrary read/write primitive.
This blog post is the result of some research I did back in July of 2016, but did not have the possibility to publish before now. In June of 2016 Theori published a blog post on an Internet Explorer vulnerability which was patched in MS16-063, the exploit they wrote was for Internet Explorer 11 on Windows 7, and as their own blog post indicates the exploit will not work on Windows 10 due to the mitigation technology called Control Flow Guard. This blog post describes how I ported the exploit to Windows 10 and bypassed CFG, in fact I found another method, which will be posted in an upcoming blog post.
Servicekonti i Active Directory er ekstraordinært udsatte og sårbare overfor en bestemt type angreb, som ofte viser sig yderst effektivt til at opnå fulde administratorrettigheder i domænet. Man lykkes med det igen og igen under penetrationstest og intet afholder ondsindede angribere fra at gøre det samme.
Med en almindelig phishing mail og tilhørende simpel malware, eventuelt bare i form af et script, kan man i løbet af meget kort tid opnå Domain Admin rettigheder eller tilsvarende, med begrænset risiko for at blive opdaget. Den lidt nysgerrige interne bruger kan med lidt teknisk snilde gøre det samme.
Denne angrebsvektor har efter min mening slet ikke fået nok opmærksomhed, og helt nye værktøjer gør angrebet endnu lettere at gennemføre, hvorfor dette blogindlæg har fået prioritet over andre i bunken.
Yderligere er det noget, som man rent faktisk kan gøre noget ved, forholdsvis enkelt, og opnå væsentlige forbedringer af virksomhedens forsvarsmekanismer. Der er lavthængende frugter at plukke!
Læs mere her: https://www.version2.dk/blog/spn-1020590
Jeg er så småt ved at være tilbage mentalt efter lidt over en uges tid i Las Vegas, hvor jeg igen i år deltog på Black Hat og DEF CON konferencerne, nu fjerde år i træk.
Først fire dage med et fremragende kursus i offensiv PowerShell scripting med Veris Group, derefter to dage med Black Hat briefings, og så tre dage på den berygtede DEF CON konference.
Jeg burde nok skrive et mere detaljeret indlæg om alt det jeg lærte undervejs, hvad der var godt og hvad der var skidt, alle de dygtige mennesker man møder osv., men jeg vil i stedet her fokusere på den besynderlige kontrast, jeg som "IT-sikkerheds-nørd" oplevede til "resten" af Las Vegas. Den verden der upåvirket pulserede støjende afsted, mens hackere fra hele verden midlertidigt, tilsyneladende i al ubemærkethed, havde opbygget et blomstrende hovedkvarter i dens midte.
Læs mere her: https://www.version2.dk/blog/bhdc-902530
Jeg har før været inde på "password spraying", og i dette blogindlæg vil jeg uddybe konceptet ud fra både et angrebs- og et forsvarsmæssigt synspunkt og underbygge med et par nyudviklede PowerShell scripts til Proof of Concept. Tanken er at udbrede forståelsen for og kendskabet til denne angrebsmetode, samt give inspiration til hvordan angreb forhindres og opdages.
Vanen tro fokuseres på on-premise Active Directory (AD) og tilhørende NTLM/Kerberos protokoller, som de fleste virksomheder anvender til autentificering af brugerne i miljøet, men svagheder og mulige løsninger er nogenlunde de samme uanset system og protokol.
Denne type angreb foretages f.eks. også nemt mod eksterne tjenester og portaler, som f.eks. VPN, Citrix, TS/RDP eller Outlook Web Access (OWA), der ikke har multi-faktor validering aktiveret. Til sådanne formål findes andre værktøjer, f.eks. THC Hydra og moduler i Metasploit.
Læs mere her: https://www.version2.dk/blog/spray-833910
Hermed anden del af en serie blogindlæg om hvordan man bygger en GPU-cracking computer.
Første indlæg, Sådan bygges en GPU-cracking computer #1, handler om den åbne ramme bygges og hvilke dele og værktøj der skal anvendes.
Dette andet indlæg handler om hvordan delene klargøres og sammensættes.
Læs mere her: https://www.version2.dk/blog/gpucracking2-739095
Jeg er ikke ligefrem en "handy-man". Jeg kan rive ned, men sjældent bygge op. Alligevel – eller måske af samme grund – blev jeg for nogle måneder siden betaget af ideen om at designe og bygge min egen åbne ramme, et såkaldt ”open air rig”, til bl.a. at teste specialbyggede computere til mere krævende beregningsopgaver, eksempelvis cracking af adgangskoder og (tidligere) Bitcoin-mining med GPU’er.
Jeg har efterhånden bygget en del af den slags computere, som er først og fremmest kendetegnet ved, at de er proppet med lige så mange grafikkort, som man har råd til – i både indledende hardwareinvestering og følgende strømforbrug.
Læs mere her: https://www.version2.dk/blog/gpucracking1-739096
Jeg har tidligere været inde på, at man kan Undgå dårlige adgangskoder i Active Directory (AD) ved hjælp af blacklisting. Det er en rimelig fornuftig metode, om end den er reaktiv i den konkrete implementering (der til gengæld er helt gratis).
Hvis man i stedet ønsker at være proaktiv og undgå, at dårlige koder overhovedet oprettes i AD, så vil jeg anbefale, at man i stedet ændrer virksomhedens grundlæggende adgangskodepolitik og generelle tilgang til adgangskoder markant. Der er i store træk behov for en slags paradigmeskifte.
Først og fremmest skal der en væsentlig holdningsændring til omkring, hvad "sikkerhedseksperter" og virksomhedens sikkerhedsansvarlige antager er stærke adgangskoder og gode politikker i praksis, dvs. mod aktuelle og reelle hacker-metoder.
Jeg vil således i dette blogindlæg argumentere for, at man fremover bør kræve væsentlig længere adgangskoder af brugerne, mod at man frafalder krav om kompleksitet og hyppige skift, samt at en sådan ændret tilgang både er mere simpel for brugeren og betydelig mere sikker i relation til nutidens trusler.
Læs mere her: https://www.version2.dk/blog/adgangskoder-670319
Et problem med Active Directory (AD) og tilhørende adgangskodepolitikker er, at selvom krav om adgangskodekompleksitet er slået til, så finder angribere (herunder penetration-testers) nemt dårlige bruger-adgangskoder, som IT administratorer eller sikkerhedsansvarlige ikke har mulighed for at opdage "out-of-the-box".
Simple og meget udbredte adgangskoder, så som "Sommer2015", "Oktober2015", "Password1", "[firmanavn]+[årstal]" o.s.v., lever alle op til almindelige krav om længde og kompleksitet, men i praksis er det utrolig dårlige koder, som vil være de første, en angriber vil forsøge med.
Læs mere her: https://www.version2.dk/blog/undgaa-daarlige-adgangskoder-i-active-directory-389787
På årets SEC-T konference i Stockholm gav jeg en præsentation under titlen: Active Directory persistent backdoors, indicators of compromise and kicking attackers out.
I den forbindelse deler jeg mine slides som PDF her: bit.ly/SECT2015
Seancen blev også optaget og er nu tilgængelig her:https://www.youtube.com/watch?v=w6761-NWmj4
Jeg håber, at indholdet måske kan komme andre til gavn.
/Jakob
Læs mere her: https://www.version2.dk/blog/sec-t-active-directory-bagdoere-og-forsvar-370704
Trods titlen handler dette indlæg ikke om, hvorvidt organisationens almindelige brugere er gjort til lokale administratorer eller ej. Dét sprængfarlige emne har jeg allerede behandlet i indlægget ”Smid nu de lokale administratorer på porten!” – og min, såvel som Microsofts og alverdens sikkerhedsfirmaers, anbefaling er uændret og står vist rimelig klar.
Nærværende indlæg handler derimod om, hvordan man bedst håndterer den lokale ”Administrator” konto, som er indbygget i Windows operativsystemet, både hvad angår tilhørende adgangskode(r) og tildelte rettigheder.
Kontoen er historisk set hadet af systemadministratorer pga. dens uhåndterbarhed, og elsket af hackere pga. den vidtrækkende anvendelighed, men det kan og bør stoppes nu!
Læs mere her: https://www.version2.dk/blog/ustyrlige-admins-253449
Jeg har udfærdiget et "lille" PowerShell script, New-ADReport.ps1, som udtrækker en række interessante informationer om brugere, computere og grupper i Active Directory (AD). Tanken er at give et hurtigt overblik over miljøets tilstand - primært med sikkerhed for øje.
Man kan i store træk sammenligne det med de udtræk, som en klassisk IT-revision jævnligt foretager - med et twist. Der ses eksempelvis på politikker for adgangskoder, inaktive bruger- og computerkonti, anvendelsen af en række specielle rettigheder og konfigurationer, medlemskab af privilegerede grupper m.v.
Forhåbentlig kan alle de, som ikke har investeret i mere forkromede værktøjer til den slags, få glæde af scriptet og måske anvende det til at få strammet lidt op på sikkerheden i Active Directory, evt. til at kontrollere at ens outsourcing-partner og/eller driftafdeling har styr på AD-relaterede processer, konfigurationer og tildelte rettigheder.
Læs mere her: https://www.version2.dk/blog/new-adreport-109508
Jeg får en del spørgsmål relateret til ransomware disse dage; fra virksomheder, venner, familie og (kon)kollegaer. I dag var det et par kommuner, i morgen er det måske dig selv eller dit netværk.
Hvad gør man når man er blevet ramt af ransomware? Hvad kan man gøre for at forhindre katastrofale konsekvenser? Ligger nøglen stadig under måtten?
Nedenfor har jeg lavet en checkliste, som muligvis ikke er komplet (endnu), men som forhåbentlig kan hjælpe brugere og netværksadministratorer rundt omkring.
Læs mere her: https://www.version2.dk/blog/ransomeware-ufrivillig-kryptering-med-mulige-oekonomiske-konsekvenser-beskyt-dig-selv-dine
Jeg har tidligere skrevet et indlæg, som reflekterede over hvor mange administratorer, der egentlig findes i et givent Active Directory (AD). Jeg vil nu udvide med endnu et par kreative eksempler på hvordan en kompetent angriber, kan skjule sig i mængden - steder hvor den almindelige IT-revision aldrig kigger.
Læs mere her: https://www.version2.dk/blog/historien-om-den-skjulte-domain-admin-68832
Lad mig sige det som det er: lokale administratorer er sendt fra de mørkeste afkroge af Helvede. De er IT-afdelingens værste mareridt og blandt virksomhedens største IT risici. Virksomhedens klienter og brugere er ekstremt sårbare og typisk voldsomt eksponerede elementer. Tildeles de administrative privilegier, så er der ikke langt til total kompromittering af miljøet (herunder Active Directory), hvis man altså ikke har taget sine forholdsregler.
Er man IT-ansvarlig i en organisation, hvor brugerne er lokale administratorer, altså brugere der til daglig er logget på med administrative privilegier på den lokale maskine, så vil jeg håbe, at man allerede har udvist rettidig omhu ved at meddele den øverste ledelse, at IT-afdelingen på ingen måde kan garantere, at involverede maskiner er sikre, pålidelige og brugbare. Hvis ledelsen mener, at virksomheden kan leve med en sådan risiko, jamen så er det jo fint, bevares – bare få det på skrift og tag det op igen med jævne mellemrum!
Læs mere her: https://www.version2.dk/blog/smid-lokale-administratorer-paa-porten-67674
