Back to Basics or Bypassing Control Flow Guard with Structured Exception Handler

This blog post was a submission to Microsoft Bypass Bug Bounty program, but was not eligible to the scope of the program. Thus I am releasing a blog post on the technique which is based on leaking the stack address and overwriting the structured exception handler, thus turning a use-after-free into a structured exception handler overwrite.

To facilitate this bypass, I have again chosen to use vulnerability for Internet Explorer 11 which was patched in MS16-063 in June of 2016 and written about by the company Theori and I’ve previously used in CFG bypass posts here and here.

Alt for ofte hedder adgangskoden "Qwerty12345": Her er syv skridt til langt bedre adgangskoder

Klumme: Stærke passwords, der ikke kan hackes, er en mangelvare i danske virksomheder. Men det kan der gøres noget ved. Her er syv skridt til virkelig gode passwords.

Jeg ser ofte implementerede kontroller omkring password kompleksitet. Formålet med disse kontroller er at sikre, at brugere anvender et stærkt password. Altså et password som en angriber ikke vil kunne udnytte og benytte i et angreb i mod virksomheden. 

Det er min påstand, at klassiske adgangskodepolitikker med et krav om 8-10 karakterer, store og små bogstaver, tal eller specieltegn, ikke fungerer til at sikre, at brugere benytter et stærkt password. 

Læs mere her:


Windows Kernel Shellcode on Windows 10 – Part 4 - There is No Code

This blog post is an addendum to the three blog posts about Windows kernel shellcode I posted based on the techniques by Cesar Cerrudo. You can find the previous blog posts here, here and here.

An assumption in my previous blog posts was the ability to execute arbitrary assembly code in kernel context. While it is possible to obtain this from a write-what-where vulnerability condition and often from a pool overflow, it does require both a kernel read/write primitive and a KASLR bypass to some kernel driver. If we limit ourselves to using the read/write primitive to perform a data only attack, we can omit the KASLR bypass. This blog post describes how each of the three methods can be converted to a data only attack instead of an actual shellcode.

Windows Kernel Shellcode on Windows 10 – Part 2

This blog post is the second in the series on Windows kernel shellcode and picks up the nulling out ACLs method described by Cesar Cerrudo at Black Hat in 2012. You can find part 1 here.

The same assumptions as in the previous blog post apply here, that being the exploit has gained arbitrary kernel mode code execution and we can handcraft the assembly code to run. I see the ACL NULL technique used almost as much as the token replacement one. The idea is to locate the SecurityDescriptor, or in effect the ACL, of a privileges process and replace it with NULL. This value tells Windows that no permissions have been assigned for the process and hence everyone has full access to it. In Windows 10 Anniversary a mitigation for this has been implemented as noted by Nettitude Labs

Windows Kernel Shellcode on Windows 10 – Part 1

When creating Windows kernel exploits the goal is often to somehow gain higher privileges, often SYSTEM. This part of the exploit writing is normally the very last part, and often not very discussed since so many steps come before it. The most common ways I’ve seen that done is either by stealing a process token of a privileged process or by removing the ACL of a privileged process. In essence the techniques I normally come across and use myself are derived and often referenced from the Black Hat presentation by Cesar Cerrudo in 2012. It is a great presentation and white paper and should definitely be read. There are however two issues when trying to use the methods from the white paper; firstly, it does not supply the actual shellcode only the technique in theory and secondly it was written prior to the release of Windows 8.1 much less Windows 10.

Bagdøre og datakompromittering via backupsystemer

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:

Babushka Dolls or How To Bypass Application Whitelisting and Constrained Powershell

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.

Win32k System Call Filtering Deep Dive

Usage of Windows kernel exploits have been on the raise, 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 have 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.

Exploit Development Environment

When I started out tinkering with exploit development, I would have loved to receive some help on how to setup 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.