Want to know more about the Advanced Windows Exploitation (AWE) course from Offensive Security (Offsec)? Our pentester reviewed the 4 day course.
This year I’ve been to Blackhat and Defcon in Las Vegas – it was my first visit. The main reason for going to the USA was the Advanced Windows Exploitation (AWE) course from Offensive Security (Offsec). This course was on my list for a long time, because I learned a lot in the previous courses I followed from Offsec (OSCP and OSCE certifications).
Day 1: very excited to start the course
The course started with writing your own custom shellcode from scratch. Of course I worked with assembly due to previous exploit writing experience, however never really wrote complete shellcode myself. In the shellcode exercise, the export directory table was used to get function addresses. This method allows you to write reliable shellcode that’s compatible with many Windows versions, which is pretty cool. Using this functionality, a messagebox shellcode had to be written. This topic confirmed that I can learn a lot on custom shellcodes and assembly.
The second topic of the day was a start with a Flash Heap Spray in Flashplayer 17.0.0.188 on Windows 10 (CVE-2015-3104). An introduction was performed on DEP bypass (ROP), ASLR, pykd and a script created by Offsec that searches for ROP gadgets using pykd. Also, heap management was discussed using the two different allocators – GC and FixedMalloc. After this, the concept of a heap spray was explained and a heap spray was performed. The guys from Offsec explained that 95% of the exploits used a technique using vectors, however due to a mitigation technique implemented by Adobe on vectors, modern exploits are corrupting bytearrays in order to exploit the issue. Therefore this technique was discussed in the training; we corrupted the bytearray capacity, length and the pointer to the data.
A deeper look into the specific bug was explained on this day as well. Debugging Flash Heap Spray can be hard due the processes that are parent processes of the sandboxed Flash process and the jitted code that is compiled at runtime. Therefore, Offsec created a python script that can be used with the Windows debugger, which is extremely useful because the script is handling the breakpoint issues while debugging Flash. This script was shared and will be made public by Offsec after AWE.
Day 1 was a nice start of the course with lots of information. I’m wondering how killing day 2 will be, but I’m looking forward to it.
Day 2: hoping not to get lost while in the class
On the second day we started to search for the corrupted bytearray by checking the length of the different bytearray objects. At this point we were able to read and write the flashplayerplugin.exe process space. The next step was bypassing ASLR by leaking a valid pointer to the NPSWF DLL from Adobe Flash Player. After bypassing ASLR it was time to gain code execution by corrupting a Vtable pointer of a class instance, which leads us to our code – the ROP chain. After gaining control of the EIP, in order to execute ROP gadgets the value of the ESP had to be changed; this is also called a stackpivot. This was simply performed by an XCHG instruction. It was now time to write a ROP chain in order to bypass DEP. After executing the ROP chain, the execution flow needs to be restored to prevent the Flash player crashing. This was performed by saving the stack frame information just before pivoting the stack, and restoring this after executing the ROP chain.
Day 2, I obtained an overflow of new information. But we are not there yet on the heap spray … also we were not exactly on schedule due to the vast amount of information.
Day 3: I am destroyed by day 2, however we are not on schedule … so we have to speed up
Of course, we are still in the sandbox … oh, do not forget to bypass the newest version of EMET. The theory behind the sandbox was explained and the concepts on bypassing the sandbox:
- Try to exfiltrate sensible user information within the sandbox.
- Find a 0day in the sandbox IPC implementation, or exploit a known that has not been patched.
- Run a privilege escalation exploit from within the sandboxed process to escape the imposed restriction.
The third method was used in practice. A vulnerability in Symantec was used that was running a local webserver and was vulnerable to an SQL injection by using “xp_cmdshell.” This service was running as SYSTEM. A DLL was written by the Offsec team to exploit the vulnerability, next to this a shell had to be generated with Metasploit. Our previously created shellcode from day 1 was modified in order to write files to a directory that has low process integrity write access. After that the Symantec exploit was loaded with the LoadLibrary functionality in order to pop a SYSTEM shell on the target.
After bypassing the sandbox, we enabled the newest version of EMET… the different checks were explained that were performed by EMET. It is important to make an attack plan, in order to know which EMET protection techniques have to be bypassed in order for the exploit to work. There are two types of attacks – disabling or bypassing EMET. In the training, disabling EMET was performed, because of its two main advantages:
- We can keep our Metasploit shellcode instead of coding custom shellcode.
- We do not have to deal with multiple protection techniques, once EMET is disabled we bypass all protection techniques.
Offsec explained that there is a specific memory address containing the EMET settings, which can be overwritten with new values to disable EMET. This technique was mainly used in exploits, however the developers of EMET turned the page into read-only memory. The instructor explained that a way was found to bypass the read-only memory and make it writable to change the EMET protection settings. This method was explained and was performed in practice.
After the morning, we started on kernel driver exploitation. This is a very cool topic, as it was completely new to me. The communication with drivers was explained: RING levels in a Windows operating system and the differences in using a kernel-space payload or a user-space payload. In order to gain privilege escalation, a very well-known payload was used, which resulted in token stealing from a SYSTEM process. This was performed by looping through the ActiveProcessLinks doubly-linked list to search for the system process (UniqueProcessId 4). When finding this processId, its token was copied to our current process.
Day 4: I am shocked by days 1 – 2 – 3 and agreed on the WTH curve published earlier on ethicalhacker.net
The topic of day 4 was 64-bit kernel exploitation. During this day the MS14-058 vulnerability was exploited in order to gain higher privileged access to the system. This vulnerability is present in the Window manager from Windows; these functionalities are located in win32k.sys. The vulnerability was explained and we had to bypass several checks on the payload that was patched into the memory. After bypassing these checks we were able to gain code execution by applying the SeDebugPrivilege setting on our current process. By doing this, we were able to get debug privileges on all processes, which allowed us to inject a payload into different processes with higher privileges using the CreateRemoteThread function.
The AWE course was awesome, I learned a lot within a very short timeframe. A will to suffer, like that mentioned on the Offsec website, is required for sure in order to finish the course. For now, I will train myself with the materials received from Offsec, after that I will take the 72-hour exam. They shared enough material to continue at home with extra mile challenges. Great work by the Offsec team!
